Comments 15
Возможно я не до конца понял вашу идею, но я не могу сходу однозначно расположить предложенные термины в пирамиду, они просто не выстраиваются так ровно.
Намешали всего в кучуКуча — это что-то неупорядоченное. А тут как раз наоборот — выстраивается иерархия.
У вас какие-то конкретные возражения по расположению уровней/элементов или Вы против идеи «иерархичности» в целом?
Забавное сравнение. Но я вас уверяю, что и перечисленный вами набор можно поставить в иерархию, причем даже не в одну. Все зависит от критериев сравнения одного с другим. При условии, что вы, как аналитик, можете достаточно сильно абстрагироваться от деталей, чтобы обнаружить нечто общее. У автора получилось, я считаю.
Огласите, плиз, используемые вами критерии оценки целесообразности. Для независимой проверки ваших выводов относительно пригодности данной статьи.
Лично мне такая структура помогает принимать решения (см. чек-лист). Надеюсь, она окажется полезной и другим.
Я б, в строители пирамид* пошёл, пусть меня научат…
Умение свести всё к единой структуре, от которой будет польза — это уже половина пройденного пути. Я только за+, чтобы побольше было такого рода синтеза. Хотя в пирамиде слои вначале что-то смутили (их очередность). Но чек-лист взял своё!
шутка про слона, которого нужно есть по частямкакая шутка?
Немножко странная схема получилась и чек-лист тоже.
- DDD напрямую связана с бизнес логикой. Соответственно слой с DDD должен идти сразу за слоем "Бизнес-требования" и до всяких там KISS и YAGNI.
- Вы даже в статье говорите, что IoC связан с фреймворком. И как же оно будет прыгать через 2 уровня?
- DIP это не только зависимости ваших компонентов друг от друга, но и зависимости от фраймвора и библиотек. То есть, по идее, правильней сформулировать, что DIP это уровень между вашим компонентом и окружением в роли которого выступает фраймворк и библиотеки.
- Уровни "Расширение" и "Связанность" скорей относятся к особенностям реализации компонента. Я бы скорей выделял уровень "Реализация" с вложенными в него уровнями "Расширение" и "Связанность" между частями реализуемого компонента, а сверху над ним уровень DIP, связывания компонента с окружением.
- Методологии TDD и BDD я бы вынес вообще куда-то в сторонку. Это относится скорее к методам написания кода. Это примерно тоже самое, что включить в пирамиду уровень "Редактор" (IDE, Vim, Блокнот). Редакторы тоже будут влиять на время и стоимость разработки. Я конечно утрирую, но все равно непонятно почему они находятся над DIP, LSP и прочими.
В чек-лист меня смущает порядок пунктов и путаница со временем/состоянием.
7. Не противоречат ли мои изменения выбранной мной методологии?
То есть вы уже сделали изменение и проверяете сделали ли вы его по TDD?
8. Соотносятся ли мои изменения с лучшими практиками используемого мной фреймворка? Не нарушают ли они общий архитектурный стиль моего кода?
Почему вы решаете вопросы совместимости после выполнения работы?
9. Могут ли использованные мной библиотеки решить поставленную подзадачу?
А если не могут, то что вы писали все это время решая поставленную задачу?
1. Реализуемы ли мои изменения с учетом отведенного мне бюджета, времени и прочих объективных ограничений?
А здесь вы говорите об исполнении задачи в будущем.
Обычно, для того чтобы полноценно оценить трудозатраты на выполнение задачи, нужно, хотя бы примерно, прикинуть бизнес модель, архитектуру компонента и возможности реализации задачи в условиях используемого фреймворка с используемыми библиотеками. То есть нельзя выполнить пункт 1 не выполнив часть последующих пунктов.
Я могу и ошибаться в суждениях. Сколько людей столько и мнений. В любом случае, спасибо за проделанную работу.
Архитектурная пирамида приложения