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