Это вопрос об оценке соотношения затрат/выгод или рентабельности перспективного проекта.
Я работаю в проекте программного обеспечения 6-8 лет. У него много проблем, а также неудач и несколько неудачников на его пути. Вот сейчас после поднятия проекта (программного приложения) из мертвых, когда приходит новое требование, разработчики ищут в коде (а не в рабочих фичах с точки зрения использования) соответствующий код. Есть идеи создания, переписывания проекта с нуля. Интересно, есть ли с вашей точки зрения смысл искать в старом коде что-то, что соответствует новому требованию для текущего приложения? Потому что если отличается, то разработчики возвращаются к запрашивающему, описывают, что нашли в коде, и еще раз обсуждают требование.
С одной стороны, это способствует разработке требований и процессу сбора требований, с другой стороны, это может быть пустой тратой времени или ненужным увеличением времени. Потому что может быть лучше и быстрее начать с нуля с новым кодом для новой функции. И особенно, если новая система или переписывание системы может иметь место.
Хотя могут быть мнения по этому вопросу, было бы полезно найти методологию, чтобы я мог порекомендовать, что лучше: продолжать инвестировать в старый код или строить с нуля?
Ваш вопрос довольно сложный и не поддается однозначному ответу. Учитывая неоднозначность вопросов, которые поднимает ваш вопрос, вы обнаружите, что большинство участников StackoverFlow склонны игнорировать его как основанный на мнении. Тем не менее, вопрос реальный, который, ИМХО, заслуживает ответа.
Устаревший код знаком программистам, которые его написали, поэтому они, естественно, сначала будут обращаться к нему для удовлетворения новых требований. Заказчику, скорее всего, все равно, как выполняется задача, но он склонится к исправлению существующего кода. Если они не знают, как пишется и работает код, у них будет мнение, что ремонт всегда будет быстрее и дешевле, чем замена. Часто это так, в зависимости от новых требований.
Однако увеличение количества исправлений с течением времени может привести к возникновению технического долга , который может поставить под угрозу не только усовершенствование приложения, но и снизить его производительность. См. работы Мартина Фаулера, Уорда Каннихэма и Стива Макконнелла, в частности вебинар последнего по управлению техническими долгами .
Более того, появление новых языков и сред может привести к более эффективным, безопасным и/или действенным решениям. Переход к этим новым подходам может рассматриваться как долгожданный вызов или ужасная идея, в зависимости от личности разработчика. Я бы определил пару целевых архитектур приложений и перечислил преимущества, недостатки и интересные моменты (которые не попадают ни в одну из категорий).
«Мифический человеко-месяц: очерки разработки программного обеспечения » Фреда Брукса — это классическая книга по разработке программного обеспечения, в которой рассматриваются эти вопросы на высоком уровне. Ищите « второй системный эффект ».
Пожалуйста, найдите https://stackoverflow.com/ и https://softwareengineering.stackexchange.com/ для соответствующих записей.
Тодд А. Джейкобс
искатель правды
Тодд А. Джейкобс