Предположим, требования к продукту консолидированы и непротиворечивы. Ибо это отдельный процесс, который заслуживает отдельного рассмотрения. Он ещё и взаимосвязан с принятыми решениями о конструкции (Twin Peak).
Я упрощу и не буду рассматривать вопрос проектирования элементов системы, поиска границ моделей, особенности нисходящего/восходящего проектирования, композиции/декомпозиции и т.п.
Ключевая ошибка - полагать, что решение создаётся из ничего. Если так подходить, то всегда существует риск возникновения нескольких субъективных мнений по поводу различных решений, который рискует перерости в борьбу мнений за лидерство (особенно при слабой теоретической подготовке оппонентов).
При правильном проектировании решение выбирается. Сперва идёт дивергентная фаза (поиск возможных вариантов решения), затем следует конвергентная фаза (сокращение количества вариантов решения до одного).
Мне нравится описание решения, позаимствованное у авиаконструкторов:
"это означает, что по всем его подсистемам, по всем его режимам функционирования выбран комплекс проектно-конструкторских решений, который неулучшаем по всем принципам оптимальности и единственен. Эта ситуация и будет соответствовать полному решению многокритериальной задачи."
https://t.me/emacsway_log/1826
Как сказал Роберт Мартин, архитектура - это о том как не надо делать.
Ключевым фактором здесь выступает нахождение критериев для сокращения количества вариантов решения. И вот здесь возникает самое интересное.
Индивидуальный опыт ничтожно мал для того, чтоб предвидеть к каким проблемам может привести то, либо иное решение в будущем. Но ещё чаще этого опыта недостаточно для понимания того, как сохранить принятое решение открытым:
💬 "A good architect pretends that the decision has not been made, and shapes the system such that those decisions can still be deferred or changed for as long as possible. A good architect maximizes the number of decisions not made."
—"Clean Architecture: A Craftsman's Guide to Software Structure and Design" by Robert C. Martin
Это потому, что новички ещё не проходили на своём опыте "как же так, я же спрашивал, и вы говорили мне, что это не понадобится?!" (c)
В общем, в Quality Attributes Adaptability и Modifiability (когда и зачем они нужны и как достигаются) я сейчас проваливаться тоже не буду.
Скажу только, что каким-то образом список вариантов решений нужно сократить, ибо реализация должна быть одна.
В дело часто вступает "Эффект неоднозначности" ("мы всегда так делали - некогда экспериментировать") и "Эффект недавнего" (16 паттернов в 32 строках кода, потому что программист только что прочитал книгу о паттернах). Когнитивные искажения мы тоже рассматривать не будем для упрощения.
В общем, в условиях отсутствия ясного понимания объективных критериев для сокращения количества вариантов решения, в дело включается вкусовщина, а она у всех разная.
Самое интересное то, что такая позиция не построена на знании теории. Она отражает субъективный опыт. Любые попытки отвергания своей позиции программист воспринимает как посягательство на уровень его компетентности, а значит, как угрозу для его социального положения, которое он вынужден защищать. В дело вступает психологическая защита.
Заезженный holy war (больное место российского финтеха) - анемичные модели vs OOP. При этом, как правило, никто из таких "вояк" не может ответить на базовый вопрос о том, какую именно проблему и каким образом решает OOP? Многие с ужасом узнают, что то, что они считали OOP, на самом деле является hybrid objects. А почему не FP? А каким образом FP решает ту же проблему, что и OOP? В каких случая предпочтительней FP, а в каких OOP? А можно ли их использовать совместно (CQS)?
Корень проблемы - в недостаточности и неоднородности опыта. Команда может набивать шишки самостоятельно, обобщая опыт своих участников и консолидируя его в коллективное мнение.
А может обратиться к теории, которая является обобщённой практикой. Самое интересное то, что поскольку решение принимается на основе обобщённого опыта, то и отвергание решения больше не воспринимается как посягательство на уровень своей компетентности, а значит, и не вызывает защитной реакции.
Теория даёт то, чего не хватало команде - критерии для сокращения количества вариантов решения. Команда начинает понимать к каким негативным последствиям в условиях их контекста может привести тот, либо иной вариант решения.
Чем больше команда знает, тем больше вариантов решения она может исключить! Потому что у неё остаётся меньше неясности.
Это в корне опровергает предположение о том, что чем больше в команде "умников", тем больше "зоопарк" конфликтующих решений.
Я не раз проходил в своей практике ситуацию, когда при грамотно выстроенном процессе обучения команд вся токсичность и конфликтность растворялась менее чем за год. Даже многолетние расколы устранялись. Команды становились слаженными и спаянными. Я понимаю, что в это трудно поверить тем, кто не проходил этого на личном опыте.
Когда мне в комментариях начинают доказывать невозможность создания слаженных высококвалифицированных команд, и утверждают, что грамотные специалисты - это источник проблем и конфликтов, то они своим примером демонстрируют действие закона отрицательного отбора. Видимо, сказывается привычка подавлять любой результат, отличающийся от достигнутого.
В отдельную категорию конфликта следует выделить ситуацию, когда менеджмент нанимает крутого спеца в слабо-подготовленную команду и думает: "ну, всё, теперь - заживём!" Статистика показывает, что в подавляющем большинстве случаев гармония не возникает, и команда отторгает грамотного специалиста (мне известен случай, когда невероятно гениальный специалист продержался всего один день). Таким образом команда вытесняет раздражителя своей зоны комфорта, чтоб не выглядеть ущербно на его фоне. Вообще говоря, это управленческая ошибка, и этот вопрос лежит больше в плоскости "change management".
Решается эта проблема, опять же, повышением уровня квалификации команды, а не изгнанием носителей компетенций. Иначе количество ошибочных решений будет только возрастать.