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

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

Посудите сами.

Когда затевается очередной холивар, участникам видится идеальный проект.

Проект, в котором будет достаточно времени на внедрение всех процессов.

Процессы, в которых будет уделено время на планирование, проектирование системы и рефакторинги.

Когда топят за “быстрые” инструменты, свято верят, что вот этот прототип потом выкинут и напишут “нормально”.

Когда топят за “гибкие” инструменты, свято верят, что этот проект на года.

Когда топят за “крутые” инструменты, свято верят, что в проекте всегда будут участвовать высоко-квалифицированные кадры.

Я в этих вопросах пессимист.

Завтра этот проект будет поддерживать вчерашний студент, поэтому выбираю максимально стандартные инструменты, с хорошей документацией.

“Быстрый” и “крутой” инструмент, но основан на неявных подходах, на соглашениях об именовании, не поддерживается IDE - в топку.

Время начальной разработки пренебрежимо мало по сравнению со временем поддержки. Если что-то затрудняет изучение кода - в топку.

Читать и изменять код на порядки сложнее, чем его писать. Стиль кода заточен не на лаконичность, а на ясность и легкость внесения изменений.

“Инженерия требований?” - “Что это?”

“Разработка требований к программному обеспечению”, К. Вигерс - TLTR!

“Подумать над архитектурой? Написать проектную документацию?” - ну вы сами знаете, “нужно вчера”, “да, нам только попробовать”, “ещё будет время”…

У программиста в этой ситуации есть только три верных товарища: инструменты рефакторинга, тесты и документация.

Только не вздумайте говорить о них менеджеру, а то вдруг он - эффективный.

Если какое-то решение по инструментам, библиотекам, дизайну кода плохо поддаётся рефакторингу - в топку.

Если плохо тестируется - в топку.

Да, может, именно сейчас, в этот самый момент, вы не будете покрывать тестами то, что на кодили.

Но, вряд ли, будущий вы скажете себе спасибо за не тестируемый код.

Документация. Не, я не про ту макулатуру, которую называют ТЗ или ТП.

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

И не про тот идиотизм в комментариях к коду в стиле Капитана Очевидность, “это есть получить ID”.

Я про то бесценное осознание, которое приходит во время кодирования. Этому эфемерному сокровищу нужно давать жизнь в виде печатных слов.

На старте проекта вас озарило, что проект нужно разрабатывать по такому-то архитектурному паттерну? - быстро запишите это в readme.md, не задумывайтесь, не подбирайте слова, вылейте эту мысль в документ, как она сейчас крутится на языке - потом отредактируете.

Расскажите будущему себе и тем, кто будет поддерживать этот проект, почему всё так, как есть.

Про “правильные” комментарии к коду в сети полно информации - изучайте. Читайте “Совершенный код”, С. Макконел главу “Процесс программирования с псевдокодом”.

Task-и/ticket-ы/issue-сы в вашей системе планирования - это не только забавное развлечение по перетаскиванию карточек между колонками, но и самое подходящее место для описания того, что и как в итоге было реализовано. Добавьте скрины или скринкасты UI, добавьте ссылку на вики-страницу со спецификацией алгоритма/API/структуры данных.

В идеальном проекте всё будет хорошо, неважно что вы выберете. На то он и идеальный.

В жизни, стратегия “не сделать хуже” на много надёжнее благих намерений.