Думаю, любой руководитель проекта или ведущий программист хотя бы раз сталкивался с ситуацией, когда код приложения вдруг оказывался совершенно запутанным и непонятным, а поддерживающие его люди в ответ на просьбу исправить ошибку или добавить новый функционал уходили «в астрал» на несколько дней, взяв с собой изрядную долю бюджета и, вернувшись, представил еще более запутанный код с исправленной ошибкой, но добавленной еще парочкой других.
А у вас, как у человека, ответственного за проект, возникло смешанное чувство досады, недовольства работой своих программистов и ожидания неприятных последствий, которые обязательно следуют за провалившимся проектом, вышедшим за любые вменяемые рамки и почти тратящим бюджет бесконтрольно.
Большинство неудачных проектов имеют одну закономерность.
Они полностью лишены структуры.
Архитектуру таких систем я называю «пластилиновой».
Немного абстракции
Хорошо спроектированные системы кажутся мне проволочными кубиками с четкими краями, определенными архитектурой, и плавными линиями, реализованными умным кодом.Если необходимо внести в них изменения, проволочный каркас расплетается в нужном месте, добавляются новые детали, после чего все снова собирается.
Такие системы являются жесткими, простыми для понимания, а структура видна практически сразу.
Но, к сожалению, есть и другие.
Боюсь, что их большинство.
Эти системы выглядят как бесформенный кусок пластилина.
Сначала создается небольшой шарик базового функционала.
Возможно, где-то в его недрах спрятан проволочный каркас грамотной и продуманной архитектуры.
Но потом все меняется.
Каждая новая функция, каждое новое исправление и модификация делается наспех, по принципу «лишь бы работало».
Каждый раз, когда мы делаем такую коррекцию, мы берем комок пластилина и приклеиваем его сбоку от существующей системы.
Таких исправлений может быть десяток, сотня, а то и тысяча.
Кусочки пластилина лепятся хаотично, они разного размера и формы, их много.
На поверхности все продолжает работать, добавляются новые функции, исправляются ошибки, но изнутри система стремительно усложняется и превращается в бесформенный комок, состоящий из отдельных разноцветных кусочков.
И тут в какой-то момент появляется задача, затрагивающая несколько компонентов системы.
Привычным движением мы образуем еще один комочек.
Но вдруг понимаем, что у нас перестала работать какая-то совсем другая функция.
Исправляем, надевая еще один кусок, и получаем ошибки еще в двух.
И это цепная реакция.
В лучшем случае за ним следует масштабный, сложный и очень дорогой рефакторинг, который уничтожает всякую надежду на создание системы вовремя и в рамках бюджета.
В худшем случае система поставляется «как есть», с огромным количеством ошибок и абсолютной невозможностью ее расширения или модификации.
За редким исключением, такой продукт проваливается на рынке, менеджер (на мой взгляд, вполне заслуженно) подвергается епитимье, после чего его отправляют в ссылку.
Несколько причин
Почему это происходит? Вариантов много, но наиболее значимыми мне кажутся три из них: 1. Неадекватные сроки реализации проекта.Все спешат и нервничают. Заказчик крутится как сумасшедший, угрожая высшему руководству разрывом договора.
Не выспавшийся руководитель проекта, проработавший три недели без выходных, мечется и кричит программистам, чтобы они работали быстрее.
Программисты, которые последний месяц живут в офисе и работают на кофеине, делают все возможное, чтобы как можно быстрее положить конец этой напасти.
Нет времени думать.
Времени на проектирование нет. Нам нужно выпустить функции.
По одному.
Обычно такой проект утопает в собственных ошибках.
На этапе приемочных испытаний заказчик предоставит список из ста тридцати пяти с половиной ошибок, ровно девяносто восемь из которых являются критическими.
И, как ни странно, они действительно будут критичными.
На исправление каждого уйдет один-два дня, учитывая безумную «пластилиновую» структуру.
Результаты оставляю на усмотрение читателя, принимая во внимание отношение к подобным проектам в его собственной компании.
2. «Плавающая» спецификация.
Если исходное техническое задание проекта недостаточно подробное, функции описаны расплывчато, а часть функционала не указана вообще, то такой проект гарантированно находится под угрозой «пластилиновой архитектуры».
Изначально все спроектировано и реализовано «как положено».
Система может иметь нормальную структуру, грамотную архитектуру и чистый код. Но, в какой-то момент (обычно ближе к сдаче, при демонстрации заказчику) оказывается, что какой-то функционал совершенно не совпадает с тем, что хочет заказчик.
И — вот в чем проблема — не было описано настолько подробно, чтобы можно было бы потребовать от заказчика перенести внедрение на этап RFC после сдачи основного проекта.
В результате мы оказываемся, по сути, в предыдущем рассмотренном случае - острая необходимость (проект завершается, и финальный платеж обычно самый крупный) внести большое количество изменений в код при отсутствии времени и бюджет. Потом комок пластилина начинает разрастаться, появляются ошибки, еще больше ошибок, лавина ошибок.
Итог — глобальный и длительный рефакторинг, либо нестабильный продукт. 3. Проект, брошенный на волю случая Это, пожалуй, худший вариант. За программистами никто не следит, действия не скоординированы, проверки кода не проводятся.
Руководитель проекта ограничивается проверкой наличия программистов на рабочих местах и изредка бегло просматривает результаты их «творческой работы».
Обычно это происходит, когда вам нужно продемонстрировать продукт покупателю.
Каждый программист наслаждается свободой и «творит вечно».
Половина из них изобретают велосипед. Другая половина прикручивает к нему квадратные колеса.
Они пишут код. Класс за классом, метод за методом.
Однако иногда в старые классы или старые методы добавляют код, добавляя в ветку пару десятков условий.
Это легче.
Так быстрее.
Вам не обязательно так думать.
Начальник доволен, проект продвигается быстро.
Очевидно, до определенного предела.
Дальше это тот же пластилиновый комок.
Все с теми же последствиями.
Что делать?
В результате возникает вопрос: как предотвратить «пластилиновый» код. Есть много важных вещей, которые нельзя игнорировать: В проекте должен быть четко выделенный разработчик, отвечающий за архитектуру системы (не только в начале проекта, но и на протяжении всей разработки).Регулярные проверки кода необходимы, и участие руководства в них весьма желательно.
Даже не будучи техническим специалистом, он будет иметь представление о том, сколько ошибок допускают его игроки.
Все изменения спецификации должны быть записаны, и код должен быть соответствующим образом перестроен.
Если возможно, любые исправления следует удалить.
Да, уничтожить «симптом» жука легко, но это сродни лечению симптомов болезни.
Неясно, какой орган будет затронут в следующий раз, когда появится эта ошибка.
Но на самом деле я могу дать только один совет. На мой взгляд самое важное: Думать! Думайте, прежде чем писать код, думайте во время его написания и думайте даже после того, как код написан.
Не начинайте писать код, не продумав архитектуру, если вы программист. Запретите это своим программистам, если вы менеджер.
И «пластилиновая» архитектура больше не появится в ваших проектах.
Теги: #архитектура #качество кода #Идеальный код
-
Каталепсия
19 Oct, 24 -
Быстрый Доступ К 2D-Массиву Во Flash
19 Oct, 24 -
Хабра-Rss И Акрегатор
19 Oct, 24
