День девятьсот третий.
8 Признаков Того, Что Вы не Контролируете Техническую Сложность
Обладая почти 25-летним опытом работы в качестве консультанта, я помогаю организациям, работающим в области .NET, повышать квалификацию в разработке программного обеспечения, от идеи до производства. Во время таких визитов я тщательно изучаю их методы разработки, стандарты качества, принципы проектирования, инструменты, которые они используют, их конвейер развёртывания, динамику команды, процесс выработки требований и многое другое.

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

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

2. Внедрение технологии, «потому что круто», потому что это помогает привлечь новый персонал, или просто потому, что руководство купилось на золотые горы, обещанные им разработчиками, поставщиками ПО или архитекторами.

3. Предоставление доступа к HTTP API или служебным конечным точкам другим командам или партнерам без контроля обязательств, которые необходимы в этом случае, например, чётко определённого управления версиями, обратной и прямой совместимости, надлежащей документации для разработчиков и т.п.

4. Команды, которые добавляют ненужную сложность, такую ​​как чрезмерное использование абстракций и дополнительных уровней, не обязательных в текущих требованиях. Часто это происходит под предлогом «подготовки к будущему» или для того, чтобы сделать систему «более тестируемой» (обычно это называют попыткой «замокать» всё на свете).

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

6. Дисбаланс между тактической и стратегической архитектурой, с краткосрочными решениями на одном конце шкалы и чрезвычайно амбициозными (и нереалистичными) воздушными замками - на другом.

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

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

С какими из описанных (или не описанных) здесь проблем сталкивались вы в своей карьере?

Источник: https://ddoomen.medium.com/8-signals-that-you-dont-control-your-technical-complexity-87ac4ae66975
Автор оригинала – Dennis Doomen