Первое знакомство
Семь лет назад я пришёл на свою первую программистcкую работу в системный интегратор, который занимался разработкой софта для силовых ведомств. После университета, года в армии, а затем недолгой работы по специальности в отраслевом НИИ это был дивный новый мир: относительно приличный офис, новые люди, новая терминология (в основном, .NET, IBM DB2, MS SQL и прочие вендор-локи) и новые взаимоотношения.
Отдел, в котором я должен был работать, только создавался, и меня временно посадили к другим парням, которые делали что-то очень важное и часто летали вместе с железом в Сочи - "внедрять на объект". У них часто что-то крашилось, иногда - крашилось в Сочи уже после того, как они возвращились в Москву. В эти моменты они шумели и собирались перед одним монитором. Среди них было несколько гуру, которые, засучив рукава, могли войти в состояние потока и за день разобраться в серьёзной проблеме. Были неуверенные в себе новички, которым только предстояло набрать опыт, получить компетенции и обрести уверенность. Были ребята, которых трудно назвать блатными, но которые откровенно саботировали процесс и занимались прокрастинацией (впрочем, спустя какое-то время они куда-то исчезали). Тогда я и увидел в первый раз человека, который называл себя системным архитектором.
Мужчина средних лет, невысокого роста, худой, жилистый. Тёмные волосы, восточные глаза, колючий цепкий взгляд, крючковатый нос. Неизменная светло-голубая рубашка, заправленная в брюки, лакированные ботинки. Пританцовывающая походка. Дурная привычка постукивать пальцами по любым поверхностям (стенам, дверям, столам) благодаря которой можно было заранее знать, что он идёт по коридору. Весьма эклектичная речь, сочетавшая в себе программистские термины и армейский мат. Паталогически циничный юмор. Взрывной характер. Привычная жесткость по отношению к подчиненным, особенно в случае косяков в Сочи. Трудоголизм, обросший легендами ("Да он N лет не ходил в отпуск, каждый день на работу ходит!"). Вот кто задавал здесь атмосферу, и лишь немногие из гуру могли позволить себе относительно независмое поведение в его присутствии.
Аппаратные войны, квадратики и стрелочки
Прошло несколько месяцев, наш отдел постепенно разрастался, и я познакомился с ещё парой системных архитекторов.
Один из них был неважным программистом, но отличался большим самомнением, а также способностями к токсичности и агрессии. В свободное от работы время он занимался рукопашным боем. Я даже удивлялся, как природа создала такого человека? Он с удивительной лёгкостью провёл интригу и разрушил отдел, в котором я работал, после чего забрал себе всех сотрудников, включая меня. Мой бывший начальник, проигравший в аппаратной борьбе, был вынужден уволиться. После этого архитектор продолжил конфронтацию с другими отделами. С подчинёнными легко заводился и переходил на крик, в том числе с теми, кто годился ему в отцы. В кабинете расставил столы так, чтобы видеть мониторы всех своих сотрудников, сам вместе со своей правой рукой сидел у окна. При этом сам проект был, видимо, ему не так интересен. На показах системы заказчику, в те моменты, когда система была сырой и не вполне соответствовала ТЗ, он проявлял себя слабо, но по привычке играл роль хозяина положения. В результате проект сильно буксовал и, видимо, не сорвался лишь благодаря связям высшего руководства и клиентов.
Второй архитектор, напротив, был программистом высокого класса с многолетним опытом работы в иностранной компании - производителе CPU, в том числе на менеджерских позициях. Было ему в районе сорока лет и, видимо, не найдя лучшей работы, он согласился на даунгрейд до позиции linux engineer и пришёл к нам. За его плечами чувствовалась мощь созданных им систем, среди которых были крупные и сложные проекты, в своё время стоявшие на переднем крае технологий. Подчиняясь первому архитектору, второй стал неформальным лидером команды, и на его фоне первый стал выглядеть совсем уж невыгодно. За этим последовало несколько атак, но второй сумел удержаться. Именно он и объяснил мне, что системный архитектор - это прежде всего тот, кто умеет рисовать на доске квадратики и соединять их стрелочками (а ещё он предложил мне не слишком увлекаться разработкой - в системном интеграторе все равно ничего не получится). Эта простая метафора мне запомнилась, и я попытался сложить собирательный портрет системного архитектора:
- Жёсткий лидер;
- Хитрый политик;
- Глубокий аналитик, который может разбить предметную область на компоненты и установить их взаимосвязи друг с другом;
- Компетентный инженер, знающий детали имплементации системы.
Подчернку, что в подобных реалиях для системного архитектора soft skills безусловно важнее, чем hard skills, поскольку просто хороший инженер, ставший архитектором, не выживет в столь агрессивной среде.
Новые проблемы
Шли годы, я сменил несколько компаний, пока не попал в ту, которая занималась настоящей разработкой. Это было совсем не похоже на пересборку системы из готовых кубиков, чем обычно занимались системные интеграторы. Практически каждый компонент системы писался с нуля, и за каждым компонентом стоял сильный senior. Каждый из них в совершенстве владел искусством рисования квадратиков и стрелочек в разных масштабах (начиная с внутренней архитектуры собственного компонента и заканчивая системой в целом) и был способен принимать качественные архитектурные решения так, что вмешательства системного архитектора зачастую и не требовалось. В этот момент я понял, что системного архитектора от "обычного" разработчика должна отличать какая-то новая зона ответственности, новая функция.
По сравнению с системными интеграторами в компании - вендоре софта стало значительно меньше аппаратной борьбы. Однако вскрылась новая проблема: большинство разработчиков обладали сильно выраженной индивидуальностью. Многие из них, как и подобает настоящим художникам, уже выработали свой собственный стиль разработки. Именно это разнообразие стилей часто мешало соединять общую работу воедино.
- Какие максимальные длина фукнции и количество передаваемых параметров допустимы?
- Нейминг переменных - допустимы ли однобуквенные переменные?
- Пользоваться ли линтером?
- Обработка ошибок - возвращать из функций статус коды или кидать исключения?
- Должен ли конкретный метод быть стриминговым или унарным?
- Если функция по сигнатуре может вернуть ошибку или исключение, но разработчик заглянул в её имплементацию и увидел, что ошибок там никогда не бывает, допустимо ли не проверять ошибку?
- Использовать паттерны или писать "по-простому"?
Это лишь небольшая часть вопросов, которые могут возникнуть при командной разработке. Недооценка этих стилистических разночтений крайне опасна, поскольку может привести к "разъезду" кодовой базы, появлению неподдерживаемого кода, а также к изоляции разработчиков внутри своих проектах, что чревато снижением bus factor'а. Нередко то, что является нормой для одного разработчика, может быть совсем неприемлемым для другого. По отдельности каждый пишет рабочий код, но даже самая простая интеграция может привести к конфликтам.
В этот момент (а лучше гораздо раньше) в игру и должен вступать системный архитектор. Как именно - читайте в следующих публикациях.