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

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

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

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

Когда это все может пригодиться? На стадии дизайна, при реализации и на код-ревью. Другими словами — всегда.

Итак, вот несколько идей, которые можно использовать, когда нужно сделать выбор.

Если попробовать свести разницу в уровнях разработчиков к одному критерию, то, я думаю, это будет качество принимаемых решений. Например, решения по дизайну кода, архитектуре, выбору технологии и т. д.

Первое наблюдение: джун не в состоянии сам принять решение, ему нужна помощь. Мидл, скорее всего, сам выберет какое-то решение, но оно может не быть оптимальным в перспективе. А решение, которое примет синьор, не только закроет текущую задачу, но и останется актуальным в будущем.

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

На основе этих наблюдений уточним критерий уровня разработчика — это качество принимаемых решений в условиях недостаточной информации.

Под качеством я имею ввиду «живучесть» решения. То есть принятое когда-то решение не начинает приносить проблемы и неудобства по мере развития системы. Другими словами, оно является эволюционно устойчивым.

Можно ли разработчику улучшить навыки принятия решений и таким образом вырасти? Я думаю, да. Здесь я собрал несколько советов по развитию этих навыков. А в следующей статье будут практические принципы, которые помогут сделать выбор.

Планирование — важная задача не только для тимлида или менеджера. Часто разработчику приходится отвечать на вопрос «когда это будет готово?».

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