Решил написать ещё одну заметку про проектирование больших программных продуктов. Меня периодически спрашивают, как разработать качественную архитектуру. При этом программистов и менеджеров интересуют разные аспекты. Программисты больше фокусируются на технических вопросах (дизайн,технологический стек, язык программирования), а менеджмент — на бизнес-аспектах, например, как выбрать и нанять архитектора, как принятые решения повлияют на стоимость разработки и поддержки проекта.
Есть такая книга «Thinking, Fast and Slow». На русский язык название почему-то перевели как «Думай медленно… решай быстро», хотя буквальный перевод означает «Быстрое и медленное мышление».
Автор книги Даниэль Канеман — нобелевский лауреат по экономике, но книга не только про экономику. Я бы сказал, что она написана скорее в стиле занимательной психологии. Читал давно, но после прочтения, хорошо запомнилось несколько интересных идей. Самое интересное в ней про две системы мышления — быстрая и медленная.
Быстрое мышление хорошо развивается тогда, когда есть быстрый ответ на действие (назовём такое действие знакомым для тех специалистов термином — «фидбэк»). Например, если взять профессию пожарного, то он «чует» опасность, его интуиции можно доверять. Если кричит: «Бежим!» — надо бежать, кричит:«Лежать!» — надо падать и лежать. Иначе в этой профессии не выжить, поскольку фидбэк на действие (или бездействие) срабатывает мгновенно. Причем с возрастом интуиция у них развивается всё больше и больше. Это и есть быстрое мышление. Оно неплохое и нехорошее, оно нужно для того, чтобы экономить силы и время, а иногда даже спасает жизнь.
С другой стороны, если взять профессию терапевта, там фидбэк медленный. Пациент может выздороветь из-за правильного лечения, а может, сам по себе, благодаря крепкому иммунитету. Терапевт может никогда не узнать, сработало его назначения или нет, поскольку пациент может не прийти на повторный приём по нескольким причинам. Например, может перестать обращаться к этому врачу, если стало лучше (нет смысла дальше тратить время и деньги) или, наоборот, стало хуже (опять нет смысла, надо менять клинику/врача). Получается, в таких профессиях сложнее развивать интуицию, поскольку обратная связь может быть очень долгой или полностью отсутствовать. В итоге доверять можно только такому врачу, который смог пройти за годы работы через огромный массив неточных, зашумлённых данных и развить у себя экспертизу в своей профессиональной деятельности.
К чему я веду.
Возьмём, например, сотрудника технической поддержки или системного администратора, который только начинает свой профессиональный путь. Если он делает свою работу небрежно, то фидбэк он получает очень быстро. Что-то не туда воткнул, ввел неправильный пароль, указал неправильный ip адрес, то получает моментальный ответ. Поэтому в этой профессии люди очень быстро учатся и развиваются. У них бывает замечательная интуиция, и они могут раньше других почувствовать, когда что-то пошло не так… Правда, не всегда понимают, как все работает на самом деле.
Перейдём теперь к программистам. Они могут писать грязный код, с больши́м количеством «копипасты» (дублирования кода), сложно поддерживаемый, плохо тестируемый. Тем не менее если программа работает и как-то решает проблемы бизнеса, то о плохом качестве кода могут не знать несколько недель или даже месяцев.
С архитектурой дела обстоят ещё хуже. Для того чтобы разбираться в этом вопросе, нужно выпустить несколько программных продуктов, посмотреть, как они ведут себя на рынке, проследить, как развиваются и только после этого можно получить хоть какой-то фидбэк и понять, насколько были адекватны принятые архитектурные решения. Всё это время программисты и DevOps-инженеры будут месяцами стоически поддерживать проект с ужасной архитектурой.
Получается, что если слабого программиста в организации можно «разоблачить» через несколько недель или месяцев, то ошибки архитектора могут проявить себя еще позже, например, через год или два.
Причём хороший программист не всегда будет нормальным архитектором, он может быть силен в алгоритмах и быть ценным специалистом в своей области, но быть слабым архитектором. Например, выдавать настолько сложные решения, что работать с ними могут только специалисты такого же высокого уровня. Это любимая тема для противников набора в команду звёздных программистов («Rockstar Developer»-ов).
Бывает другая ситуация, когда у программиста срабатывает своеобразный «импринтинг» и он начинает применять везде одно и тоже архитектурное решение, которому он научился в начале карьеры и полюбил. Например, я часто видел и слышал категоричные утверждения:
- Все успешные компании используют Spring и Hibernate!
- В «продакшене» — только Oracle (хотя сейчас чаще слышу — только PostgreSQL)!
- Нам нужна Кафка!
- Все используют микросервисы!
- Только Java, так как C# скоро умрёт (здесь вместо Java и С# можно подставить любые другие языки программирования)!
Это, конечно, звучит мощно и просто, но… нет, не надо торопиться. Здесь как раз и надо включать, то самое «медленное мышление», про которое пишет Канеман, так называемая Система 2:
- Система 1: срабатывает автоматически и очень быстро, почти не требуя усилий и не давая ощущения намеренного контроля.
- Система 2: выделяет внимание, необходимое для сознательных умственных усилий, в том числе для сложных вычислений.
В этом как раз и заключается основная проблема — найти архитектора, который может работать по второй системе. В первую очередь это важно для менеджмента, т. к. если вопрос с архитектурой будет решён правильно, то компания может в несколько раз сократить свои расходы и получить конкурентное преимущество; иначе — получить постоянную головную боль и бесконечные проблемы.
Вот несколько рекомендаций с моей стороны.
- Конечно, замечательно, когда можно довериться интуиции. Только интуицию нужно сформировать, а для этого нужен опыт. Причём опыт не программирования, а именно проектирования архитектуры. Проверить программный код можно относительно быстро, также быстро проверить архитектуру — нет.
Ищите человека с опытом. - Если опытного архитектора нет, а есть простой программист, который выполняет эту роль, то, возможно, его интуиция ещё неразвита в должной степени. Тогда ему на этапе проектирования архитектуру надо стараться думать, анализировать, искать недостающую информацию, а не действовать интуитивно. Не использовать первую систему, не делать на авось. Метод проб и ошибок может оказаться слишком дорогостоящим.
- На проекте должен быть только один архитектор, но об этом как-нибудь в другой раз.