On the way to perfect computing

Мы – представители одной из самых молодых профессий. Мы как строители и зодчие, которые каждый день кирпич за кирпичиком возводят новые сооружения. Некоторые строения иногда сносят – они уже свой век отжили-отсулжили.

В отличии от сроительства в программировании “сносить” приходится довольно часто. Здесь “здания” могут стремительно еволюционировать и достраиваться очень даже в непредстказуемых местах (зависит от степени прогибания под заказчика Также здесь “здания” могут стремительно рухнуть, не постояв и нескольких месяцев. Причины могут быть разные – то ли из-за фазы луны:), или из-за технического несовершенства, или из-за несовершенства управленцев.

Давайте опустим первое и последние, и поговорим о технических аспектах.

Программный продукт еще можно сравнить с живым существом. Оно растет и развивается, со временем.
И очень важно тратить определенное время-усилия на разработку архитектуры, если вы хотите чтобы продукт смог вырасти из стадии эмбриона до непоколибимого титана. Не важно, даже если вы не пишите проект с нуля, а присоединились к нему на определнной стадии – все равно занимайтесь
архитектурой!
Также может случиться, что в вашей компании команда архитекторов сидит высоко в облаках, медитируя на uml диаграммы ну оочень высокого уровня абстракции, и им нет дела до того, что какой-то кусок в вашей подсистеме ну ооочень корявый, и вы 70% своей рабочей жизни тратите на сооружение заплаток.
Архитекторы тоже должны писать код. Но это уже другая история…

Приминение ООП уже никого не пугает/удивляет. Правда, даже в таких ООП-шных языках как Java иногда можно встретить кучу классов с открытыми свойствами – как C-шные структуры, и кучу классов-менеджеров (SomeEntityManager,etc с методами – как замена С-шным функциям.
Окей, даже ознакомившись с пачкой шаблонов проектирования, и прочитав Александревску от корки до корки, можно напедалить кучу, в принципе, вменяемого кода, и вместе с этим офигенно усложнить архитектуру.

Хорошо, скажете вы, это все понятно, и что нужно делать?

- Не бойтесь создавать/менять архитектуру в целом:
При стандартном раскладе у вас в проекте – продукт побит на какие-то части(модули), если же продается-развертывается монолитная система, это будут подсистеммы. Хорошо, когда эти модули выполняют совсем различные задачи и их можно по отдельности легко менять (если у вас всего этого еще нет, возмите чистый листочек, ручку, и подумайте как нарезать такие модули из существующей системы). Даже в обычном приложении можно стремиться к shared nothing architecture со строительных блоков которых можно будет собирать что угодно.В идеале, должен будет появиться boot-loader process, который будет регистриоровать модули и дергать за их ниточки, и набор библиотек или программ-модулей.

Хорошо, теперь имея модули:
- продумайте архитектуру внутри модуля и его наружные интерфейсы:
Что эти имеют общего в целом? какие у них общие интерфейсы, life cycles?

- необходимо создать общий интерфейс для модулей.
Посмотрите на составляющие модуля. Конечно, внутри модуля может быть реализованно что угодно,в зависимости от прикладной области. Но постарайтесь определить компоненты одного ранга, важности и сгруппировать их каким-либо образом(паттерны, или карандаш с ручкой вам в помощь).

Вот так, в упрощенном варианте, применив эти 2 шага, вы сможете выделить кучу отдельных строительных блоков.
Вы сможете лучше понять свой продукт и направления его развития. При поступлении нового запроса на разработку функционала вы сможете сказать, почесав за ухом – мы это сделаем в виде отдельного модуля, или компоненты.

Зачем это все нужно?
Да затем что:
- Ваш продукт станет стройнее, вернувшись через пол года к какому-то куску кода, вам не нужно будет перелопачивать 50-60 классов, чтобы понять где и что зарыто, вы будете серфить одну из 4-5 подсистемм, которая будет состоять из 10 классов, что намного проще. Вы ПОБЕДИТЕ в борьбе со
сложностью.
- Цена-усилия на разработку уменьшатся, ведь для исправления/разработки какой-то фичи можно будет доверить не только старожилу, но и новому учаснику в команде,
которому не нужно будет много знаний об архитектуре проекта чтобы приступить к работе.
- Цена-усилия на тестирование уменьшатся, ведь внося изменения в какой-то отдельный модуль, уже будет сложнее все поламать, будет меньше сковзных
зависимостей и ситуаций, когда меняешь в одном месте, а вылазит в другом.

В завершение, приведу последнюю аллегорию – архитектура для продукта, как физическая форма для спортсмена. В плохой форме спортсмен не сможет быстро бегать, быть выносливым к травмам, и уж тем более наращивать силу. Спортсмены достигают хорошей формы посредством тренировок. Вот и мы, хотя бы иногда – должны придирчиво осматривать продукт, оценивая его физическую форму.