Отсутствие планировки при строительстве Мегаполиса имело много последствий, о которых мы поговорим в этом разделе. Последствия были серьезными и выходили далеко за рамки того, что мы по наивности могли бы ожидать от плохой архитектуры. Некогда ровная колея пошла под откос.
Невразумительность
Как вы уже поняли, архитектура Мегаполиса и отсутствие спланированной структуры породили систему, разобраться в которой было очень трудно, а изменить — практически невозможно. Новые участники проекта (как, например, я) были ошарашены его сложностью и не могли понять, что же происходит.
Плохая архитектура способствовала наслоению новых плохих архитектурных решений — по сути, она не оставляла разработчикам другого выхода, потому что осмысленных путей расширения этой архитектуры не существовало. В ходе проектирования всегда выбирался путь наименьшего сопротивления для текущей задачи. Не существовало очевидных
путей исправления структурных проблем, поэтому новая функциональность просто вставлялась туда, где она создавала меньше хлопот.
Примечание
Очень важно поддерживать качественную архитектуру программного проекта. Плохая архитектура со временем разрастается.
Отсутствие связности
Компоненты системы были плохо связаны друг с другом. Вместо одной, четко определенной роли каждый компонент содержал пеструю россыпь функций, порой слабо связанных друг с другом. При взгляде на компонент было трудно понять, зачем он вообще существует, и так же трудно разобраться, где именно в системе реализуется та или иная функциональность.
Естественно, поиск и исправление ошибок в коде превратилось в сущий кошмар, что серьезно отразилось на качестве и надежности продукта.
И функциональность, и данные располагались в неверных местах системы. Многие «основные функции» системы были реализованы не в центральных блоках системы, а имитировались в периферийных модулях (ценой огромных усилий и затрат).
Дальнейшие археологические изыскания показали, почему это произошло: в исходной группе разработчиков шла активная борьба тщеславий, и некоторые ключевые программисты начали строить свои маленькие программные империи. Они захватывали функциональность, которая, по их мнению, была особенно эффектной, и втискивали в свои модули, даже если она там была неуместна. Из-за этого им приходилось создавать еще более изощренные коммуникационные механизмы, чтобы вернуть управление в нужное место.
Примечание
Здоровые отношения в группе разработки вносят непосредственный вклад в архитектуру системы. Нездоровые отношения и гипертрофированные самомнения порождают нездоровые продукты.
No related posts.