Не так давно – в декабре прошлого года – поменял работу. Появились новые впечатления, мысли, хочу ими поделиться. Еще на предыдущем месте пришлось плотно заниматься архитектурой, это входило в сферу моих обязанностей тимлида. Опыт оказался позитивным, у меня получалось, мне нравилось, и в итоге я решил специализироваться именно в этом направлении. Затем поменял работу и сейчас я ведущий архитектор в крупной телекоммуникационной компании. Впечатления от новой работы неоднозначные, но не будут забегать вперед, начну с начала.
Вообще интерес к проектированию у меня появился давно, еще в студенческие годы (1998) попала в руки книга такого авторитетного товарища, как Гради Буч: «Объектно-ориентированный анализ и проектирование с примерами приложений на С++». По тогдашним временам книга воспринималась как библия проектировщика. Сейчас, конечно, это уже никакое не откровение и даже в чем-то ошибочное мнение, которое было навязано доминирующей тогда объектно-ориентированной парадигмой. Мое отношение к ООП с тех пор сильно изменилось и перешло от восторженного к острожному и умеренно-скептическому. Но это не так важно, важно, что тогда было задано направление и стимул для дальнейшего профессионального развития. И самое главное, именно эта книга сформировала серьезное отношение к проектированию.
Так же, как и в любой другой сложной деятельности в программной разработке не обойтись без проекта, т.е. понимания того, что и как мы будем делать. Нужен какой-то план действий. В программировании такой план может приобретать самые причудливые формы: простой список задач, диаграммы Ганта, UML диаграммы и др. С учетом того, что программная разработка – молодая отрасль, устоявшихся решений еще нет. Вместе с тем есть своя специфика, выраженная в пластичности результата (программного кода), большом числе абстракций, очень грубой, неточной оценке трудоемкости, меняющимся требованиям и др. Все это мешает преиспользовать апробированные решения из других сфер человеческой деятельности, т.е. не получается просто один в один применить то, что уже где-то работает.
Возьмем для примера название этой заметки: программная архитектура. Архитектура – это вообще-то из строительной деятельности, ей занимаются уже не одно тысячелетие. Есть общепринятые нормы и стандарты, есть готовые методики, есть типичные проблемы и их возможные решения. Понятно, что дисциплина развивается, появляются новые материалы, новые строительные технологии, но все равно это уже сформировавшаяся отрасль. Да, она развивается, но это скорее эволюционное развитие. В сфере программной разработки все не так, у нас технологии меняются за пару лет, а то, что использовалось 5-10 лет назад, может оказаться безнадежно устаревшим хламом.
Программная разработка находится в стадии поиска, в стадии взросления, появляется много нового, интересного и пока не понятно, что устоится и станет стандартом. Есть какие-то более-менее успешные заимствования из других отраслей, есть куча новых методик и подходов, все это как-то варится и используется с разным результатом, но по сути общепринятых, устоявшихся стандартов на проектирование нет. Тот же популярный в свое время UML сейчас сильно сдал позиции и используется скорее как дополнение: хочешь – рисуй, не хочешь – обойдемся без него. В каких-то командах его используют, в каких-то нет, но чаще все-таки не используют.
Все это я изложил для того, чтобы была понятна роль архитектуры в современных реалиях программной разработки. А роль эта далеко не однозначна. С одной стороны, все или многие понимают, что вот так «с кондачка» ничего хорошего не сделаешь, если речь идет о больших и сложных проектах. Чтобы получить качественную систему, ее нужно проектировать, т.е. думать о структуре: из каких программных элементов система будет состоять (классы, структуры данных, сервисы и т.д.), как они будут взаимодействовать между собой, какие технологии (языки, базы данных) лучше использовать.
С другой стороны, нет и ясного понимания как этим проектированием заниматься. Есть какие-то подходы и решения, но все это не очень надежно, здесь много вкусовщины, каких-то личных пристрастий и убеждений. И даже опыт не всегда спасает. Будь ты хоть трижды опытный разработчик, все равно твоего опыта и знаний может не хватить, чтобы точно сказать, как нужно делать правильно именно в этом проекте, с учётом специфики этого бизнеса, этой команды. Да и невозможно все предусмотреть, сегодня одни требования к системе, завтра немного другие, а послезавтра совсем другие. Если и можно что-то сказать определенно, так это то, что программный проект будет меняться.
Архитектор в данном случае – это очень удобная фигура, на которую можно спихнуть все заботы о том, как должно быть «правильно», пусть он ищет решение, пусть думает и предлагает варианты. Но это работает только в тех случаях, когда это позволяет бюджет. То есть проект настолько большой и компания настолько богатая, что хватает денег на то, чтобы включить в команду архитектора.
Чаще всего роль архитектора «размазана». Обычно эту лямку тянет тимлид или техлид, иногда собираются синьеры (квалифицированные разработчики) и совместно выстраивают оптимальное решение. Иногда на стадии принятия решения идут к руководству со стороны бизнеса, если руководство в принципе способно понять решение или если нужно согласовать объем ожидаемых трудозатарт. В этом случае по форме архитектора как бы нет, но по сути он все равно есть. При отсутствии формальной роли будут неформальные обязанности. И будут они на тех, кто может и готов их выполнять. Везут на тех, кто везет.
Впрочем, справедливости ради, замечу, что сейчас у бизнеса уже есть понимание таких тонкостей. Во многих вакансиях на тимлидов явно указывают, что помимо прочего им придется заниматься и архитектурой. Хотя это выглядит странно, когда среди множества обязанностей, связанных с программированием, управлением командой, фигурирует еще и разработка архитектуры. Когда он это все успеет?) Но в общем и целом это характерно для российской разработки. Бюджеты все же не такие большие и стараются взять человека, который закроет все вопросы. В общем «и швец, и жнец, и на дуде игрец». Я примерно в таком качестве и был на предыдущей работе)
На этом пока все, продолжение истории будет в новой заметке.
Валерий Чугреев, 28.02.2021
Как-то действительно сверхответственно выглядит должность архитектора. По сути на одно это ментальное усилие просчета и понимания (считай моделирования) уходит колоссальное количество усилий. Человек изобретает новое из нечего, собирает дом из веток и палок — со стороны наверно может показаться «что такого, ну придумал идею, продумал как все будет работать»; но на деле архитектура это ведь и есть сам объект целиком, весь проект и сам «продукт» зависит от качества идеи. И нагружать архитектора лишней работой, это вообще не разумно. Мне кажется эта должность должна быть обособленна от всех остальных обязаностей, чтобы оставались силы на полет творческой фантазии.
Да, роль архитектора действительно ответственная. Интересно, кстати, посмотреть на эту тему с позиции психологии, т.е. готов ли вообще человек отвечать за последствия решений? Где начинается и заканчивается его ответственность?
Если все хорошо, архитектор – молодец, команда тоже. А если наоборот?! Случилась какая-нибудь #опа, причём случилась из-за неудачного проектного решения. Как поведет себя человек, отвечающий за архитектуру?
У меня был интересный опыт в одной компании. Там как раз был такой архитектор, который вроде и умный и знающий, но с ответствененостью «все сложно».
Архитектором там, кстати, была девушка. История поучительная, давно хочу ее написать, но все руки не доходят. Может быть, сейчас в рамках архитектурной темы как раз и соберусь.