“Так сложилось исторически.”
Когда я прихожу в новый проект, то начинаю разбираться, как в нём всё устроено. Я задаю довольно много вопросов, но на некоторые из них получаю в ответ фразу, написанную выше. Да и сам я периодически грешу таким ответом.
Причина этого проста: нормальный человек просто не в состоянии запомнить всё на свете. В разработке изменения обычно идут настолько быстро, что многие вещи забываются чуть ли не сразу (даже если им предшествовало бурное обсуждение).
Сначала подумать, потом делать
Одним из важнейших навыков техлида, наравне с технической экспертизой, я считаю умение анализировать и принимать решения.
Наш мозг устроен так, что любую проблему мы хотим решить быстро. Из-за этого мы зачастую принимаем самые быстрые и лежащие на поверхности решения. Делаем мы это автоматически, потому что нашему мозгу так проще. На мышление тратится энергия, в то время как автоматические действия совершаются без сложного анализа.
Эта особенность мозга очень сильно мешает техлидам при принятии технических решений. Само по себе слово «решение» подразумевает анализ и осознанный выбор из нескольких альтернатив. Выбор первого попавшегося варианта решением не является.
Поэтому я топил, топлю и буду топить за документарные способы принятия решений. Ресёрчи, RFC и ADR помогают взвешивать варианты и рассматривать достаточное количество альтернатив.
Мозг — машинка для мышления и анализа, а не для хранения информации. Решать сложную аналитическую задачу, удерживая весь контекст в голове, очень утомительно. Если выписать проблему и контекст на внешний носитель, у мозга высвобождаются ресурсы на проведение анализа.
Описывать можно любые технические решения: рефакторинг, смену технологий, API и изменения в БД для новой фичи. Времени это занимает немного, а как минимум открывает возможность технического ревью перед началом работ.
Лучше потратить время на исследование, документ и обсуждение, чем убить полгода на сложную техническую задачу с сомнительным профитом.
Что такое ADR
Наш мозг вообще плохо предназначен для запоминания информации, поэтому гораздо проще и полезнее записывать принятые решения. Для технических решений применяется такой подход, как ADR (Architecture Decision Record, реестр архитектурных решений). Вместо того чтобы запоминать принятые в ходе работы над проектом решения, просто записывайте их и ведите журнал. Какое бы техническое решение вы ни принимали, его точно стоит зафиксировать. Важны как небольшие вещи вроде использования определённой библиотеки по всему проекту, так и крупные изменения, например переезд на микросервисы.
Жёстко зафиксированной структуры ADR нет, вы можете взять любую и дальше доделать её под себя. В качестве референса рекомендую ознакомиться с материалами по ADR от GitHub. Для старта можно взять следующую структуру:
- Дата и время принятия решения.
- Статус ADR: предложено, отклонено или принято.
- Описание проблемы.
- Описание предлагаемого решения и того, как оно решает проблему.
- Преимущества решения.
- Недостатки решения.
- Последствия принятия решения: что поменяется, что станет проще, а что сложнее.
- Внедрение решения: как предлагается перейти на него.
- Альтернативы.
Что даёт ADR
Ведение ADR даёт команде целый ряд преимуществ:
- Все технические идеи проходят этап переноса из головы автора на «бумагу», что заставляет автора хорошенько подумать над самой идеей.
- Такие идеи гораздо проще обсуждать: вся информация уже зафиксирована в тексте.
- Значительно проще вспомнить, «откуда взялся этот говнокод» и «а это почему так сделано».
- Переделывать старые решения становится безопаснее, потому что виден контекст их принятия.
- Онбордить новых членов команды тоже становится проще, потому что они могут почитать ADR вместо вытягивания информации из памяти тимлида через боль и страдания.
С идеей ведения ADR я познакомился в книге Джеймса Стэниера «Карьера Software Engineering Manager».