Совет по дизайну. Две модели для данных

[Bepec]

Тут нужно как обычно смотреть на скорость и необходимость. Одна быстронаписанная утилитка может сэкономить часы для разработки/тестирования основной программы.
Конечно потом эту утилитку надо будет переписать, но острая необходимость её переписать будет отдалена в далёкое будущее.

В идеале каждую программу надо переписывать раза 3-4. Именно из-за того, что предусмотреть всё с самого начала нельзя. И программа написанная за неделю мало будет отличаться от программы написанной за 2 дня.

А вот программа написанная за месяц уже может претендовать на звание не говнокода. Но это месяц без программы

PS к тому же такая программа вырисовывает будущую архитектуру. Можно сказать поднимает навык

[vulko]

Все всегда предусмотреть сложно, но не невозможно!

Просто нужно прежде чем что-то делать, подумать как это сделать. Часто спихивая очередную задачу на разработчика, все целиком ложиться на его совесть и даже код ревью ничем уже не поможет, т.к. если все просто, то никаких вопросов нет, а если все сложно, то врядли кто-то будет вникать в архитектуру. Глянули, закомплитили -> профит.

Одна быстронаписанная утилитка может сэкономить часы для разработки/тестирования основной программы.
Конечно потом эту утилитку надо будет переписать, но острая необходимость её переписать будет отдалена в далёкое будущее.

Логика неверная. Это просто желание схалтурить сейчас и отодвинуть все на далекое будущее. Хорошо если утилитка нужна только на этапе разработки/отладки. А если это часть конечного продукта, то халтурить не стоит.

Потому что сэкономленное сейчас время, потратиться как минимум в дальнейшем. Но это крайне оптимистичный прогноз. В реальности же потраченное позже время, будет все равно больше.

[Bepec]

Расписывать бесполезно, как я понял.

Вкратце - как бы вы ни старались, первая версия программы будет кривой, забагованной и страшной по архитектуре.

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

ИМХО.

[OKTA]

Будем честны - идеал недостижим, сколько не переписывай 

[vulko]

Расписывать бесполезно, как я понял.

Вкратце - как бы вы ни старались, первая версия программы будет кривой, забагованной и страшной по архитектуре.

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

ИМХО.

ну если все делать на отъе**сь, конечно так все и будет))

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

а когда поверх непродуманной и кривой архитектуры начинать городить говнокод, количество багов растет как снежный ком.
в итоге получается "франкенштейн", у которого к тому же руки растут из ж*пы, а ноги из ушей торчат. и автор пытается все это заставить бегать и играть в футбол.
когда приходит осознание безнадеги, начинается переписывание.

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

[Bepec]

Очередной идеалист. Все мы через это проходим

[OKTA]

Гейтс Билл был таким же, но все мы знаем, что получилось 

[vulko]

Очередной идеалист. Все мы через это проходим

Сомневаюсь что говнокодеры через это проходят. Они всегда хотят как бы похалтурнее.
Забывают правда, что кроилово всегда ведет к попадалову. Другое дело что попадалово не обязательно на них приходится.

П.с. я не идеалист, просто у меня есть личная отвественность. чего и вам желаю.

[Bepec]

Личная ответственность != затягивание срочной работы

Как и везде тут нужно идти по тонкой грани между говнокодом и идеальным кодом.

PS если хоть 1 программист в мире скажет - "я не говнокодил никогда", то его можно сразу бить камнями - врёт как дышит.

[Old]

Как и везде тут нужно идти по тонкой грани между говнокодом и идеальным кодом.

Нифига себе "тонкая грань". Вы указали две крайности между которыми все.

[vizir.vs]

ИМХО крупный проект сложно написать круто с первого раза. Поэтому и выпускают версии 1.1, 2.0 и так далее.

[Igors]

Дело не в сроках. Наивно полагать что "вот я все тщательно обдумаю, сделаю основательно - и все будет Ok". Обдумывание хорошо (и даже необходимо) - но до определенного предела. Если обсуждать будущий проект с коллегами (исполнителем, заказчиком), то в какой-то момент становится заметно: разговор пошел по кругу, ничего принципиально нового уже не вносится. И тогда надо начинать делать. И вылезут проблемы  которые  недооценили (а иногда и не подозревали). Это нормально

[Old]

Если обсуждать будущий проект с коллегами (исполнителем, заказчиком), то в какой-то момент становится заметно: разговор пошел по кругу, ничего принципиально нового уже не вносится. И тогда надо начинать делать.

И тогда надо начинать думать и проектировать. Желательно вдалеке от компьютера с блокнотом и карандашом.

И вылезут проблемы  которые  недооценили (а иногда и не подозревали). Это нормально

Да, если из разработки выкинуть главный этап - проектирование, то проблемы вылезут практически сразу. Это нормально.

[Bepec]

Все программы рождены из гавнокода
Это как яйцо и курица, правда порядок мы точно знаем.

Говнокод -> идеальный код.

[vulko]

Если обсуждать будущий проект с коллегами (исполнителем, заказчиком), то в какой-то момент становится заметно: разговор пошел по кругу, ничего принципиально нового уже не вносится. И тогда надо начинать делать.

И тогда надо начинать думать и проектировать. Желательно вдалеке от компьютера с блокнотом и карандашом.

И вылезут проблемы  которые  недооценили (а иногда и не подозревали). Это нормально

Да, если из разработки выкинуть главный этап - проектирование, то проблемы вылезут практически сразу. Это нормально.

плюсую.
именно с блокнотом и карандашом, а не "в уме", как некоторые очень уверенные в себе говнокодеры

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