Что иметь в виду при переписывании программного обеспечения

[maximkozhin]

У меня такое было…
Дам совет из личного опыта, при разработке занимайтесь проектированием бд до самого последнего поля и ключика.
Планируйте архитектуру приложения заранее, с возможностью расширения не за счет «костылей», а за счет добавления новых архитектурных модулей или компонентов.
Лишние пару дней проектирования сэкономят пару лней разработки, а впоследствии еще и пару дней на тесты и исправления

[zeronice]

Вы хотели сказать, сэкономятся лишние пару лет разработки? Участвовал я в проекте, где кривая архитектура базы породила бесконечное допиливание проекта почти на бегу в проде…

[nothern_wind]

Я вот тоже думаю что он хотел сказать «пару лет разработки». Если, прежде чем взяться за клавиатуру и начать пилить кодярник, взять и порисовать на бумажке или доске, максимально продумать архитектуру и уже после этого взяться за реализацию то экономится значительно больше чем пару дней, если это, конечно, не проект на 3 дня.

[Rastishka]

У меня такое было…
Дам совет из своего личного опыта (противоположный вашему): TTM (time to market) намного важнее, чем всё остальное вместе взятое.
Планируйте архитектуру приложения под существующие нужды (но если есть лишние деньги и время — чуть чуть вперед) и на известных технологиях, потому как скорее всего требования к продукту за время его разработки поменяются непредсказуемо.
Позже, после выхода на рынок и получения фидбека, можно будет заняться рефакторингом или глобальным, или параллельно с разработкой с корректировкой на новые требования.

[maximkozhin]

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

[dbanet]

В виду.

[VolCh]

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