LINUX.ORG.RU

Ad hoc или серебрянные пули?

 ,


0

2

В каком стиле вы чаще решаете возникающие задачи - костылём под конкретный случай или реализуете решение проблемы в принципе? И какой стиль сильнее ограничивает развитие программы?

Deleted

Лучше комплексное решение, чем костыль.

a1batross ★★★★★
()

* Переписываем программы с нуля, более лудшим способом.

Virtuos86 ★★★★★
()

Когда как. Часто бывает цейтнот времени, когда не до обобщений, а требуют уже вчера. А если пишу для себя, то могу и подумать месяц-другой. Иногда правильные мысли приходят через годы.

Кстати, на мой взгляд существует ложное предубеждение против опенсорса, что он, мол, качеством похуже, чем коммерческие программы. А вот, ни фига! Бывает такой опенсорс, что многие коммерческие проекты завидуют молча. Ну, и бывает, полный отстой, конечно, или просто проба пера, или учеба.

dave ★★★★★
()

И какой стиль сильнее ограничивает развитие программы?

Самое сильное ограничение это приверженность какому-то одному стилю. Нужно иметь возможность выбирать стиль исходя исходя из актуальных условий.

ival ★★
()

дык эта..хуякхуяк и в продакшн

anonymous
()

Зависит от имеющегося времени, ну и серьёзности задачи, конечно.

Вообще, стараюсь решить фундаментально, если не нахожусь в жёстком цейтноте.

hobbit ★★★★★
()

Есть стратегия, а есть тактика. Применяю и то, и другое. Очевидно, что главнее системный подход, применяю его всегда, но не на работе.

anonymous
()

В каком стиле вы чаще решаете возникающие задачи

Стараюсь избегать ad hoc насколько это возможно в конкретной ситуации.

какой стиль сильнее ограничивает развитие программы

Фанатизм.

PS: каких ответов ты ожидал?

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)

Стараюсь делать пригодные к повторному использованию компоненты.

Ad hoc оставляю на нижнем уровне и там, где кодится «предметная область».

shkolnick-kun ★★★★★
()

в офисе как получится на то куча обстоятельств.

дома написать кучу, потом разделить на части, переписать каждую в отдельности. потом собрать вместе и по кругу. профит в том что софт не превращается в жижу или черную дыру, как может случится в офисе.

еще. написать алгоритм, посмотреть, громозко/некрасиво, переписать, и так по кругу. это отработка навыка рефакторинга в стиле боевых искуств будийских монахов.

anonymous
()

делегирую.

anonymous
()
Ответ на: комментарий от dave

Часто бывает цейтнот времени

Такова селяви.

anonymous
()
Ответ на: комментарий от dave

Плюсую этого парня. Когда ограничены сроки(т.е. почти всегда) и исключительных случаев около единицы, то ad hoc может быть более рациональным решением. Когда есть время подумать или исключительных ситуаций много то общее рещение предпочтительнее.

Aswed ★★★★★
()

В общем случае, важно не дать костылям «расползтись». То бишь если сроки и всё такое, то можно нагородить подпорок, но ежели они влияют на посторонний код, то надо слать сроки лесом и переделывать, иначе потом всё.

Deleted
()
Ответ на: комментарий от XMs

с пометкой FIXME

Ради интереса: каково, по твоим оценкам, среднее время жизни FIXME и TODO? Сам просто единичные случаи видел, когда это правилось, и то случайно

Deleted
()

Костыли не нужны.

Костыли - это любимый способ «blah-blah»-манагерочков проектов, нахватавшихся поверхностных знаний про б-гомерзский Agile.

GoF + GRASP == Наше Всё.

Bioreactor ★★★★★
()

Сначала костылём. Потом погружаюсь конкретно, пишу фреймворк. Затем задача развивается до фреймворка фреймворков, способных решить задачу разными способами. Под конец где-то теряется нить целеполагания, для чего это нужно и зачем. Система теряет устойчивость развития. Деградация возможностей. Смерть. Про костыль тоже всё забывается.

iZEN ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.