Программная архитектура (часть 1)

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

Вообще интерес к проектированию у меня появился давно, еще в студенческие годы (1998) попала в руки книга такого авторитетного товарища, как Гради Буч: «Объектно-ориентированный анализ и проектирование с примерами приложений на С++». По тогдашним временам книга воспринималась как библия проектировщика. Сейчас, конечно, это уже никакое не откровение и даже в чем-то ошибочное мнение, которое было навязано доминирующей тогда объектно-ориентированной парадигмой. Мое отношение к ООП с тех пор сильно изменилось и перешло от восторженного к острожному и умеренно-скептическому. Но это не так важно, важно, что тогда было задано направление и стимул для дальнейшего профессионального развития. И самое главное, именно эта книга сформировала серьезное отношение к проектированию.

Так же, как и в любой другой сложной деятельности в программной разработке не обойтись без проекта, т.е. понимания того, что и как мы будем делать. Нужен какой-то план действий. В программировании такой план может приобретать самые причудливые формы: простой список задач, диаграммы Ганта, UML диаграммы и др. С учетом того, что программная разработка – молодая отрасль, устоявшихся решений еще нет. Вместе с тем есть своя специфика, выраженная в пластичности результата (программного кода), большом числе абстракций, очень грубой, неточной оценке трудоемкости, меняющимся требованиям и др. Все это мешает преиспользовать апробированные решения из других сфер человеческой деятельности, т.е. не получается просто один в один применить то, что уже где-то работает.

Возьмем для примера название этой заметки: программная архитектура. Архитектура – это вообще-то из строительной деятельности, ей занимаются уже не одно тысячелетие. Есть общепринятые нормы и стандарты, есть готовые методики, есть типичные проблемы и их возможные решения. Понятно, что дисциплина развивается, появляются новые материалы, новые строительные технологии, но все равно это уже сформировавшаяся отрасль. Да, она развивается, но это скорее эволюционное развитие. В сфере программной разработки все не так, у нас технологии меняются за пару лет, а то, что использовалось 5-10 лет назад, может оказаться безнадежно устаревшим хламом.

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

Все это я изложил для того, чтобы была понятна роль архитектуры в современных реалиях программной разработки. А роль эта далеко не однозначна. С одной стороны, все или многие понимают, что вот так «с кондачка» ничего хорошего не сделаешь, если речь идет о больших и сложных проектах. Чтобы получить качественную систему, ее нужно проектировать, т.е. думать о структуре: из каких программных элементов система будет состоять (классы, структуры данных, сервисы и т.д.), как они будут взаимодействовать между собой, какие технологии (языки, базы данных) лучше использовать.

С другой стороны, нет и ясного понимания как этим проектированием заниматься. Есть какие-то подходы и решения, но все это не очень надежно, здесь много вкусовщины, каких-то личных пристрастий и убеждений. И даже опыт не всегда спасает. Будь ты хоть трижды опытный разработчик, все равно твоего опыта и знаний может не хватить, чтобы точно сказать, как нужно делать правильно именно в этом проекте, с учётом специфики этого бизнеса, этой команды. Да и невозможно все предусмотреть, сегодня одни требования к системе, завтра немного другие, а послезавтра совсем другие. Если и можно что-то сказать определенно, так это то, что программный проект будет меняться.

Архитектор в данном случае – это очень удобная фигура, на которую можно спихнуть все заботы о том, как должно быть «правильно», пусть он ищет решение, пусть думает и предлагает варианты. Но это работает только в тех случаях, когда это позволяет бюджет. То есть проект настолько большой и компания настолько богатая, что хватает денег на то, чтобы включить в команду архитектора.

Чаще всего роль архитектора «размазана». Обычно эту лямку тянет тимлид или техлид, иногда собираются синьеры (квалифицированные разработчики) и совместно выстраивают оптимальное решение. Иногда на стадии принятия решения идут к руководству со стороны бизнеса, если руководство в принципе способно понять решение или если нужно согласовать объем ожидаемых трудозатарт. В этом случае по форме архитектора как бы нет, но по сути он все равно есть. При отсутствии формальной роли будут неформальные обязанности. И будут они на тех, кто может и готов их выполнять. Везут на тех, кто везет.

Впрочем, справедливости ради, замечу, что сейчас у бизнеса уже есть понимание таких тонкостей. Во многих вакансиях на тимлидов явно указывают, что помимо прочего им придется заниматься и архитектурой. Хотя это выглядит странно, когда среди множества обязанностей, связанных с программированием, управлением командой, фигурирует еще и разработка архитектуры. Когда он это все успеет?) Но в общем и целом это характерно для российской разработки. Бюджеты все же не такие большие и стараются взять человека, который закроет все вопросы. В общем «и швец, и жнец, и на дуде игрец». Я примерно в таком качестве и был на предыдущей работе)

На этом пока все, продолжение истории будет в новой заметке.

Валерий Чугреев, 28.02.2021

Подписаться
Уведомить о
guest
2 комментариев
Старые
Новые
Межтекстовые Отзывы
Посмотреть все комментарии
Соль
Соль
2 месяцев назад

Как-то действительно сверхответственно выглядит должность архитектора. По сути на одно это ментальное усилие просчета и понимания (считай моделирования) уходит колоссальное количество усилий. Человек изобретает новое из нечего, собирает дом из веток и палок — со стороны наверно может показаться «что такого, ну придумал идею, продумал как все будет работать»; но на деле архитектура это ведь и есть сам объект целиком, весь проект и сам «продукт» зависит от качества идеи. И нагружать архитектора лишней работой, это вообще не разумно. Мне кажется эта должность должна быть обособленна от всех остальных обязаностей, чтобы оставались силы на полет творческой фантазии.