Друзья, проблема с устаревшим кодом — это результат коллективной работы. Не стоит искать виновных. Если вы столкнулись с этой проблемой, то виноваты все, включая руководство. Нельзя сказать, что вчера всё было хорошо, а сегодня всё резко стало плохо. Ухудшение кода происходит постепенно, на протяжении долгого времени. И этот процесс хорошо заметен и прогнозируемый.
Если у вас постоянно срываются сроки разработки или приложение работает нестабильно или и то и другое одновременно, то вам точно стоит задуматься.
Обобщенные признаки Legasy кода
-
Нечитаемый код. Это основная причина, по которой legasy требует больших усилий для понимания. Это требует от разработчиков значительных усилий, что, в свою очередь, приводит к снижению производительности и увеличению количества ошибок в работе.
-
Дублирование кода. Одним из ключевых принципов программирования является повторное использование кода. Когда программист замечает повторяющиеся фрагменты, он стремится объединить их в одну функцию для многократного применения. Важно помнить, что каждый фрагмент кода несет определенную ответственность. Удваивая свой код, вы пропорционально увеличиваете и свою ответственность.
-
Плохая архитектура. Программирование — это сложный процесс, который требует знания множества принципов, шаблонов и практик. Не говоря уже о быстро меняющихся технологиях, которые постоянно развиваются. Из-за необходимости сочетать так много различных элементов, всегда существует риск получить совсем не то что требовалось.
Причины появления Legasy
-
Большая кодовая база с затрудненой навигацией. По мере роста проекта становится всё труднее находить и использовать уже существующий код, который обеспечивает необходимую функциональность. Если структура вашего решения или проекта не способствует удобной работе с кодом, то возникает тенденция к повторному написанию уже созданных фрагментов.
-
Невозможно повторно использовать код. Иногда вы можете найти существующий код, предоставляющий требуемые функции, но не всегда есть возможность использовать его повторно. Это особенно актуально, когда в этом коде присутствует множество других зависимостей, которые вам не нужны. Ситуация становится ещё сложнее, если иерархия зависимостей является глубокой. Кроме того, структура решения может препятствовать повторному использованию, в результате чего проекты не могут ссылаться друг на друга из-за циклической зависимости.
-
Сложный для понимания код. Обычно над приложением работает несколько разработчиков, и не всегда их уровень квалификации одинаков. Когда код трудночитаем, с ним сложно работать. При необходимости внести изменения, разработчики часто стремятся сохранить существующую структуру, что только усложняет понимание кода. В других ситуациях они могли бы избежать этого, создав новую структуру.
-
Устаревшие библиотеки. Речь идёт не только о безопасности вашего приложения. Рано или поздно наступит момент, когда вы не сможете поддерживать своё приложение, и всё время разработчиков придётся тратить на устранение старых ошибок.
-
Не понимание предметной области. Важно помнить, что программист не всегда является экспертом в предметной области. Например, при обсуждении различных сценариев использования, мы можем использовать разные термины для описания одних и тех же вещей. Эти термины могут в итоге отразиться в отдельных фрагментах кода в базе данных. Вы можете найти модели с названиями «продавец» и «магазин», хотя они могут означать одно и то же.
-
Срочность. Когда у вас сжатые сроки, качество кода становится менее важным. Вас не беспокоит, насколько он читабельный, пригоден для повторного использования и тестирования. В результате код становится сложным и трудным для поддержки. В некоторых случаях разработчики просто копируют существующий код и вносят в него изменения для реализации новых функций.
-
Индивидуальные стратегии проектирования. Нет единого вектора развития продукта. Архитектура отдана на откуп отдельным разработчикам. В результате разные элементы системы становятся трудно стыкуемыми и это приводит к дальнейшему ухудшению общего дизайна приложения.
-
Архитектура решений. Это стратегия проектирования на более высоком уровне, которая уделяет больше внимания иерархии зависимостей, многоуровневой логике и проектированию на уровне приложений. Если архитектура решений плохая, не интуитивная и непонятная для каждого разработчика, то и код, скорее всего, будет таким же.
Можно ли улучшить код? Или Legasy это приговор?
Конечно можно, и Legasy — это не приговор! В каждом из описанных выше пунктов есть ответы, что делать или как этого не допустить. Я не могу говорить за все случаи, но могу утверждать, что всегда есть решение, которое поможет конкретно вам. Иногда для этого потребуется приложить немного усилий, а иногда — более серьёзные вложения. Но в любом случае, если есть желание, всё можно исправить.