Итак, в голосовании победила тема Software Development, поэтому основная часть моих постов будет посвящена именно ей.

Сегодня я хотел дать вам пищу для размышлений на тему разработки архитектуры ваших программных продуктов.

Как часто вы занимаетесь разработкой архитектуры?
Нет, серьезно! Как часто вы выделяете отдельную задачу по разработке архитектуры?

Конечно же есть задачи, в которых все настолько тривиально, что вся архитектура укладывается в голове.
Но что со сложными задачами? Мой опыт показывает, что зачастую этим важным этапом пренебрегают.
Начинают сразу писать код, а потом — как пойдет.
Не стоит пороть горячку.

> Хороший продукт не делается в спешке.

Если вы беретесь за важную, большую фичу, вы отвечаете не только за ее разработку, но и за ее здоровье и дальнейшую жизнь.

Что я понимаю под здоровьем? Давайте рассмотрим пример.

Вася разработал фичу Х. На момент сдачи фичи в эксплуатацию все было хорошо, она соответствовала требованиям и хорошо работала. Но потом на Петю упала задача по доработке фичи Х. Петя, посмотрев на код, начал сильно плеваться. Не мудрено. Ведь чтобы ему сделать свою задачу, нужно многое переписать. А все потому что Вася не подумал о том, как в дальнейшем будут расширять функционал фичи Х. Вместо того чтобы заниматься делом, Петя будет поправлять "здоровье" фичи.

Здоровая фича ходит без костылей. Легко воспринимается. Не требует излишней адаптации для доработки.
Иными словами, технический долг этой фичи отсутствует или ничтожно мал.

Конечно же — это палка о двух концах. Но, думаю, идея понятна.

Как же избежать подобных ситуаций?

- Выделяйте время на проектирование архитектуры — да-да, это важно! Создайте себе отдельную задачу, согласуйте ее с менеджером. Поясните зачем это нужно. На выходе постарайтесь получить документ, который описывает почему вы приняли то или иное решение по архитектуре. Это поможет другим людям понять ход ваших мыслей и подхватить, в случае чего, вашу работу.
- Максимально декомпозируйте задачи — это поможет не упустить мелкие (но ресурсоемкие) детали и все уложить в голове
- Привлекайте коллег на ревью архитектуры — ведь коллеги могут увидеть то, чего не увидели вы. Могут задать неудобные вопросы, проверяя вашу архитектуру (да и вас) на прочность. Полезно привлекать коллег из других департаментов. Например, проектировать серверную архитектуру, подключая клиентских разработчиков, и наоборот. Это поможет быть "на одной волне", и прийти к согласию во многих моментах, таких как модели данных.


Помимо проектирования архитектуры перед ее реализацией, имеет смысл делать ревью существующих решений. Ведь однажды спроектированная архитектура может значительно устареть и, скорее, мешать, чем помогать. В таком случае нужно выявить проблемные места и немного подлечить ее рефакторингом.

Чем чаще такие ревью будут проходить, тем легче будет править проблемные места.
Если вы наткнулись на место, вызывающее трудности, недостаточно просто написать коммент

// refactor this mess.

- Создайте отдельную задачу с предложением варианта устранения проблемы.
- Поставьте менеджера в известность и обозначьте возможные риски (желательно упоминая насколько это опасно для бизнеса)
- Запланируйте время для работы над этой задачей. Если задача будет просто валяться в бэклоге, пользы от этого не будет.
- Делайте регулярное ревью пула задач по устранению технического долга.

На многих этапах могут возникнуть терки с менджментом. Но старайтесь говорить на их языке. В терминах бизнеса.
Менеджер никогда не поймет почему синглтон — плохо. Но если вы ему объясните, какую выгоду уничтожение синлтона даст бизнесу, то проблем быть не должно.

Разработчик должен уметь доносить информацию до "бизнес-людей". В этом нет ничего страшного. Более того — это один из ключевых навыков.