Вообще естественная продолжительность жизни человека — 30 лет. Так что будешь копить, а жить расхочется… «Жить сейчас» имеет смысл, хотя и дорого и рисковано…
Вот, по сохранившимся свидетельствам, «эффективный менеджер» Сталин умел въезжать в предметную область типа сталелитейной за две недели. Правда, у него были навыки скорочтения — в нищие времена семинарского отрочества брал на ночь книги из букинистической лавки и вручную переписывал. Это я к тому, что времени для въезжания в предметную область у менеджеров было достаточно — месяца по-любому должно хватить.
Фэйл был нашего ПМ, который трахал моск всякой левой фигнёй, что нервировало и отвлекало от дела… Но всё равно — ставить задачу по системе, использующей БД, не используя ни одного термина из области БД, а только в терминах UI — это источник рисков…
«Лучше когда можно» — это «на стадии проектирования», до того, как реально будет нужно.
Насчёт «Code complete» — ну, С++ уже само по себе отпугивает и smells bad. Для Java это — прошлая эпоха. Если книгу про то, что водопад лучше аджиля, написал С++-ник, то это следует отнести на профессиональную деформацию восприятия: для С++ это в значительной степени так, в то время, как для Java есть автоматический рефакторинг средствами IDE и дизайн можно улучшить уже после написания кода (это возможно за счёт отсутствия у языка Java, по сравнению с С++, излишней «гибкости» в нехорошую сторону). Мартин Фаулер теперь пишет, что улучшения дизайна можно безопасно оставлять на потом.
m36 исходит из «сильной» точки зрения — "(сможем и будем) сделать когда надо", а вы — и- «слабой» — "(лучше) сделать когда можно". Из «слабой» позиции можно охватить в разы больший scope, но, в общем, с меньшей надёжностью.
А с высоконагруженным проектом надо заранее (ага, «как слабый») продумывать механизм миграции и смены бэк-энда «на грячую».
Вопрос — почему простой в несколько часов стОит как 6-10 месяцев (1200-1700 часов) работы программиста? С этого и начинается — не хотят отдавать 300 тыр за простой — отдают 1200 тыр за всё по итогам…
Первый экземпляр всё равно ломают на нагрузочном стенде, по крайней мере раньше было так. Нужна уверенность, что крылья не отломаются при взлёте в начале лётных испытаний;-). С учётом возможной итеративности проектирования вероятность перетяжелённости стремится к нулю…
Смысл моего коммента был в том, что атмосфера, на самом деле, практически ничего не «показыает», а самолёты ломают обычно не от плохого проектирования, а от попадания туда, где они и должны ломаться.
Думаю, тут тормоза не из-за создания новых объектов, а из-за двукратного лазания в мапу — при гете и при путе. Если бы можно было получить Map.Entry и модифицировать уже его…
Ну, можно сделать версионирование — тогда данные о пользователе в заказе останутся на момент внесения или исполнения заказа…
Насчёт «Code complete» — ну, С++ уже само по себе отпугивает и smells bad. Для Java это — прошлая эпоха. Если книгу про то, что водопад лучше аджиля, написал С++-ник, то это следует отнести на профессиональную деформацию восприятия: для С++ это в значительной степени так, в то время, как для Java есть автоматический рефакторинг средствами IDE и дизайн можно улучшить уже после написания кода (это возможно за счёт отсутствия у языка Java, по сравнению с С++, излишней «гибкости» в нехорошую сторону). Мартин Фаулер теперь пишет, что улучшения дизайна можно безопасно оставлять на потом.
А с высоконагруженным проектом надо заранее (ага, «как слабый») продумывать механизм миграции и смены бэк-энда «на грячую».
Вопрос — почему простой в несколько часов стОит как 6-10 месяцев (1200-1700 часов) работы программиста? С этого и начинается — не хотят отдавать 300 тыр за простой — отдают 1200 тыр за всё по итогам…
Смысл моего коммента был в том, что атмосфера, на самом деле, практически ничего не «показыает», а самолёты ломают обычно не от плохого проектирования, а от попадания туда, где они и должны ломаться.
… и просто доработать потом напильником…