В Waterfall скатываются обычно по другой причине. А высокая неопределенность оценки играет, как раз, на руку Agile, поскольку он предоставляет больше возможностей для раннего выявления отклонений об плана и своевременного принятия соответствующих бизнес-мер.
В Scrum оцениваются, как правило, только Stories путем коллективной оценки. В этом смысле Exreme Programming лучше справляется с задачей максимально раннего выявления отклонения от плана, поскольку использует двухуровневую оценку, сперва Stories оцениваются коллективно (тут есть отличия между 1-ой и 2-ой версией), а затем, при планировании итерации, уже оцениваются Tasks индивидуально.
При этом нужно не забывать, что оценка — это вероятностная распределенность, и, если делать оценивание правильно, то выражать оценку нужно не только вероятностной оценкой, но и ее среднеквадратическим отклонением распределения времени, которое, как раз, и выражает неопределенность оценки и служит бизнесу для грамотного управления бизнес-рисками. Чаще всего для этого используется методика оценки PERT.
Ну, и, кроме того, нужно не забывать, что оценка имеет свою стоимость, которая растет, как правило, экспоненциально в зависимости от точности, и бизнес-выгоды, которые растут линейно. Поэтому точность оценки должна находиться в балансе между затратами на оценку и ее бизнес-выгодами. Как правило, на оценку выделяется не больше 5% итерации.
Полагаю, что имелось ввиду получение проблемы «Parallel Inheritance Hierarchies».
Если я Вас правильно понял, тогда то, что Вы предлагаете сделать, очень похоже на "Replace Type Code with Subclasses". Это, действительно, решает проблему «Switch Statements» (классифицированный Code Smell). И это, действительно, может привести к Code Smell «Parallel Inheritance Hierarchies» и взрывному комбинаторному росту типов. Чтобы этого не допустить, вместо «Replace Type Code with Subclasses» можно применить «Replace Type Code with State/Strategy».
Действительно, в OOP желательно избегать условных операторов в исполняемом коде, поскольку вся суть ООП заключается в возможности группировать вместе данные и поведение. Чтобы обеспечить полиморфизм, условные операторы желательно переносить из исполняемого кода в конструкторы/фабрики (тут есть вариации в зависимости от возможностей конкретного языка). Здесь Вы мыслите совершенно верно. Правда, действовать нужно без фанатизма, ибо если Code Smell «Switch Statements» не угрожает перерасти в «Divergent Change» или «Shotgun Surgery», то он большой угрозы не представляет.
Лучше начинать с первого издания. Второе издание подходит лучше для формализации процессов, и оно лучше адаптировано под сложившуюся на рынке обстановку. Но для понимания лучше все-таки первое издание. Это почти что две разные книги. Прочесть стоит обе. На русский было переведено только первое издание, если я не ошибаюсь. Ценность второго издания еще и в том, что его легче сочетать со Scrum-процессом (подробней эту тему раскрывает Henrik Kniberg в «Scrum and XP from the Trenches: How We Do Scrum» 2nd edition).
Я ценю ваши глубокие познания подкапотного устройства, но не очень отчетливо понимаю, каким образом то, что Вы описали, релевантно к девушке, которая в силу обстоятельств изучала PHP, а потом узнала, что для реализации ее математических навыков более подходит другой язык, например, Python? Что именно, не входящее в стандартный Python-Tutorial (а лучше «Learning Python» 5th edition by Mark Lutz, kimisa ), может помешать ей это осуществить?
Соглашусь, что я, наверное, неправильно выразился, и под «синтаксисом» я имел ввиду ту часть знаний, которая дается официальным руководством.
У нас в практике был случай, когда для одного проекта нам требовался разработчик со знанием Python, но у нас был превосходный кандидат с великолепной теоретической подготовкой, правда, с опытом на PHP, и лишь поверхностным знанием Python. Мы тогда решили, что нам проще и быстрее перепрофилировать его, нежели тратить время на поиск релевантного Python-разработчкика. И время подтвердило правильность нашего выбора.
Где-то деаллокация вручную, где-то по счётчику ссылок, где-то mark-and-sweep GC с разными триггерами на срабатывание, где-то GC умеет определять циклические ссылки, где-то нет.
Ключевое слово здесь «где-то». И именно тем самым, что применяется «где-то», занимается (упомянутое мною) общее устройство компиляторов/интерпретаторов. Например, идея упомянутого Вами mark-sweep сборщика, примененного в Golang, была впервые предложена еще Дейкстрой в 1978 году.
А вообще, за 15 лет у меня было только два случая, когда знаний по GC, изложенных официальным руководством по языку, было недостаточно. Поэтому давайте, пожалуйста, воздержимся от гипертрофирования проблемы применительно к такому простому случаю, как у девушки.
При всём уважении к МС, это едва ли эталонное приложение, на мой взгляд.
Возможно, но это субъективно (спасибо что прямо об этом говорите). Другое субъективное мнение по этому поводу можно услышать от Greg Young (автора термина CQRS): «A perfect example of this [you can see] if you go look at the CQRS and Event Sourcing by Microsoft Patterns and Practices, which is heavily focused on doing this inside of Azure using their toolkits.»
создать у себя в проекте папочки Repository, Unit of work, etc и гордо думать, что у вас хорошая архитектура
При всем уважении, лучше не измерять качество архитектуры папочками. Качество архитектуры измеряется экономикой разработки, и соответствием поставленной задаче достигнутого баланса Quality Attributes (сейчас они стандартизованы).
Ваше возражение было против предлога «В» оригинальной цитаты автора. Именно он стал причиной вашего диалога с автором в стиле RTFM. Дальше вы использовали попеременно предлог «у» и родительный падеж. Но даже если Вы по случайности не заметили предлог «В» оригинальной цитаты автора, которую оспорили, то есть разница между «менеджером Scrum-команды» и «менеджером(-ами) участников Scrum-команды». В последнем случае менеджер находится вне Scrum-процесса. В первом случае — объектом отношений является сама команда, соответственно, менеджер, в таком случае, является участником Scrum-процесса, и вы даже описали его обязанности и ответственность по отношению к команде:
Который отвечает за оценку команды в целом и отдельных сотрудников, нанимает/увольняет/отправляет на обучение, отвечает за результаты работы команды.
Вы даже попросили меня оспорить это:
На какой странице [The official Scrum Guide] там идет речь о том, что менеджеры не нужны?
Я не утверждал, что менеджер входит в Scrum-команду.
Автор: В scrum-командах нет начальника, который в классической системе управления дает фидбэк (к слову говоря, совершенно субъективный) своим сотрудникам. Эту функцию берет на себя вся команда.
Вы: Это неверно. У скрам-команды, конечно, же есть начальник… Подробное описание роли менеджера скрам-команды (род. падеж) читайте в...
Вы именно приписали.
Всякое может быть. Если Вы процитируете, о каких именно моих словах идет речь — мне будет понятней. Пока что я не могу обнаружить, чтобы я что-то Вам приписал.
P.S.: Если Вы хотите поговорить не по предмету обсужения, то я предлагаю не флеймить здесь, а продолжить в привате.
Тут, наверное, опечатка. «Процитировал» Вас, а не «приписал».
и доблестно бросились ее опровергать.
Если помните, то я просто спросил у вас номер страницы «The official Scrum Guide», которая подтверждает Ваши слова. Вы написали кучу слов, но так и не ответили на первоначальный вопрос.
Повторяя иногда мои же тезисы.
Если только Вы — Ken Schwaber, Jeff Sutherland, или, на худой конец, Kent Beck (по вопросам Agile, учитывая что Scrum — это Agile, надеюсь, что хоть это не стало для Вас сюрпризом).
Себе то вы право рассказывать про скрам оставили.
И вы, конечно же, не поленились процитировать эти мои слова перед своей репликой.
P.S.: Тот факт, что Вы перешли от аргументации по сути к обсуждению субъекта диалога, говорит намного больше, чем само содержание Вашего ответа. И это, как бы, не совсем профессионально.
P.S.S.: Когда выбираете литературу, то, если это не первоисточник (и), то старайтесь, хотя бы, чтобы ее рецензировал первоисточник, как, например, книги автора Henrik Kniberg. Я не хочу сказать, что вы прочитали плохую книгу, в конце-концов, Mike Cohn и Ron Jeffries обладают весомым авторитетом в Agile. Может быть, вы просто не так поняли автора. Я не знаю, и это не есть предмет обсуждения. Есть только один документ, который устанавливает, что в Scrum должно быть.
Это, как раз, ключевой аргумент. K.Rubin может выражать официальную позицию Scrum не больше, чем Вы, в отличии от первых двух персон, перечисленных мною: «Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them.» — «The official Scrum Guide»
нужен ли такой вывод для CTO,CEO, VP of Product, HR etc?
Нужны ли эти роли в Scrum-команде и требуется ли их участие именно в Scrum-процессе? «This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together… The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.» — «The official Scrum Guide».
Таким образом, участие перечисленных Вами ролей в Scrum-процессе не требуется, поскольку официальный документ однозначно говорит, что Scrum состоит только из тех ролей, которые содержит документ.
Но, поскольку Scrum — это фреймворк, а не финальная методология, то Вы вольны строить на его основе свои собственные процессы (только они не будут при этом изменять сам Scrum): «Rather, it is a framework within which you can employ various processes and techniques.» — «The official Scrum Guide»
есть начальник. Который отвечает за оценку команды
«The Development Team is responsible for all estimates.» — «The official Scrum Guide»
есть начальник. Который… отвечает за результаты работы команды.
«The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.» — «The official Scrum Guide». А вообще, в Agile заказчик принимает на себя часть финансовой ответственности за право влиять на процесс разработки.
Начальник команды — это тот ради кого и внедряется Scrum.
Scrum внедряется ради получения заказчиком бизнес-выгод, предоставляемых Agile-разработкой, которая заключается в техническом обеспечении итеративной разработки, таким образом, чтобы будущие проектные решения опирались на feedback от практической эксплуатации реализации проектных решений предыдущих итераций. Это открывает возможность эффективного управления бизнес-рисками.
А роль «начальника» в Agile-разработке закреплена в 4-м принципе Agile Manifesto: «Business people and developers must work together daily throughout the project.» А также в «The official Scrum Guide»: «Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.»
Да, кстати, как же я мог забыть… Жирной точкой в этом вопросе можно считать сайт Ward Cunningham (надеюсь, этот человек в представлениях не нуждается). Будем его считать третьим авторитетом (правильней было бы сказать — отцом целого ряда авторитетов). Много текста, поэтому цитировать не буду. Посмотреть можно здесь. Предвосхищая возражения, сразу прошу обратить внимание на «Last edit May 26, 2013» внизу страницы. Если этого мало — загляните еще и в глоссарий ГОФ, а так же в «Библию» ООП — «Object-Oriented Software Construction» 2nd Edition by Bertrand Meyer. В общем, большинство (по крайней мере, авторитетное большинство) — на стороне Alan Kay в этом вопросе.
Про Ken Schwaber и Jeff Sutherland — я слышал. Про K.Rubin — не слышал. Не могли бы Вы подсказать, на какой именно странице "The official Scrum Guide" идет речь о роли менеджера?
Ладно, давайте с другой стороны. Ок, Alan Kay — личность известная далеко не всем начинающим программистам, обратимся к (ну, не знаю, к первому взятому наугад) авторитету современности, к автору бестселлера «Code Complete» 2-е изд. Steve McConnell:
«Don't expose member data in public. Exposing member data is a violation of encapsulation and limits your control over the abstraction.» (далее идут отсылки источникам такой формулировки и примеры).
Я не заостряюсь на том, что инкапсуляция — это принцип, и даже отличительная особенность OOP, т.е. без инкапсуляции ООП теряет свои отличительные признаки.
Что такое «Encapsulation»? Смотрим у МакКоннела же:
«Encapsulation picks up where abstraction leaves off. Abstraction says, „You're allowed to look at an object at a high level of detail.“ Encapsulation says, „Furthermore, you aren't allowed to look at an object at any other level of detail.“»
Здесь речь идет об управлении сложностью, но очевидно, что «Encapsulation» неразрывно связана с «Abstraction».
Что такое «Abstraction»? Это то, что обуславливает само существование класса как Abstract Data Type (ADT).
Итак, вот я посмотрел внимательно Вашу Википедию, и самый популярный/авторитетный источник информации. И нигде не обнаружил, что
должны ли данные быть скрыты для поддержания парадигмы?… ООП говорит нам — лучше да, чем нет, но необязательно.
Более того, никаких расхождений с Alan Kay я не обнаружил.
Когда мы говорим об ООП как о парадигме, а не о реализации языковых конструкций для сокрытия данных, — то инкапсуляция, как отличительный признак ООП, непосредственно связанный с абстракцией и самим смыслом существования класса/ADT — должна быть.
Давайте для объективности заглянем к другому (тоже взятому наугад) авторитету, известному по принципам GRASP, Craig Larman, «Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development» 3-е изд.
«Encapsulation — A mechanism used to hide the data, internal structure, and implementation details of some element, such as an object or subsystem. All interaction with an object is through a public interface of operations.»
Интересно, и что же такое «интерфейс»?
«Interface — A set of signatures of public operations.»
О как… интересно, а «operations» — это, случайно, не «данные»?
«Operation — In the UML, „a specification of a transformation or query that an object may be called to execute“ [RJB99]. An operation has a signature, specified by its name and parameters, and it is invoked via a message. A method is an implementation of an operation with a specific algorithm.» (почти как Alan Kay сказал)
Ну, пожалуй, остановимся на двух. С третьим, я думаю, будет тоже самое.
Рад был бы поверить Вам, что большинство считает также как и Вы, но… похоже, что большинство, включая самую авторитетную его часть, все-таки больше на стороне Alan Kay в этом вопросе.
Вы все время уходите в сторону, и путаете «определение» с конкретным формулированием отношения ООП к сокрытию данных, данное автором этого термина. Еще раз напомню — речь идет о сокрытии данных.
для доказательства своей позиции
Процитируете «мою позицию»?
Нет, я уверен в том, что многие языки, которые общепризнано считаются объектно-ориентированным, не реализуют то ООП, которое имел в виду Алан Кей.
сейчас под ООП имеют в виду не то, что имел в виду Алан Кей
Последние два утверждения интересны (хотя и бесполезны в отношении вопроса сокрытия данных), потому что признав в первом утверждении существование современных «чистых» (в концепции Alan Kay) ООП-языков, вы автоматически оспорили свое второе утверждение. Значит, все-таки не все так считают. Вообще, это плохая привычка говорить от лица всех.
Вы уверены в том, что значение ООП, заложенное автором этого термина, не реализуется ни одним современным языком программирования? Интересно…
Термины нередко имеют совсем не то значение
Тут многое зависит не от самого термина, а от субъекта восприятия. Раз уж Вы убеждены в том, что Ваше мнение очевидно всем, то невольно напрашивается вопрос — чем Вы тогда здесь сейчас занимаетесь?
P.S.: просто хотел напомнить, что мы обсуждаем не значение термина ООП в понимании тех, кто не знаком с его сутью и историей, а:
должны ли данные быть скрыты для поддержания парадигмы
Википедия — источник, конечно, так себе… ну да ладно, в каком именно предложении вам очевидно?
Автору термина «OOP», Alan Kay, например, это не очевидно (или, даже, очевидно не это): «OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.»
Я имел ввиду, что остальные технические знания абстрактны от конкретного языка. Это вопросы проектирования, архитектуры, алгоритмы, базы данных, тестирование, рефакторинг, качество кода, методологии разработки, распределенные системы, операционная система и общее устройство компиляторов/интерпретаторов, методики оценивания задач и т.п.
Знание того, что под капотом, требуется только общее, чтобы понимать алгоритмическую сложность тех или иных конструкций. Есть разница между «программированием на языке» и «программированием с использованием языка».
Обе цитаты из «Clean Architecture: A Craftsman’s Guide to Software Structure and Design», 2017
В базах данных очень много нюансов, и баланс выбора постоянно меняется в том числе по мере неравномерного развития самих БД. Причем, для каждого Bounded Context существует свой собственный баланс. Не хочу вдаваться в технические подробности — это обширная тема.
простейшее разделение на commands/queries уже очень помогает.
Да, и я даже приводил в качестве примера ссылку на одно из лучших демонстрационных эталонных приложений (reference application). Это хорошо работает, когда логика простая, например, запрос возвращает сразу DTO. Для более сложных случаев, когда используются усложненные сценарии создания агрегата, используется Identity Map и т.п., такой подход может привести к понижению Cohesion, и росту таких Code Smells как Shotgun Surgery или Divergent Change, что негативно отражается на экономике разработки. Хороший код всегда стремится к Low Coupling & High Cohesion. До тех пор, пока Вы в этом балансе — все ок.
Ну, не знаю, я, например, языки меняю как перчатки. Многие популярные языки семантически сильно похожи. У хорошего разработчика знание синтаксиса конкретного языка занимает не более 5-ти процентов. Так что, как говорится, «глаза боятся — руки делают». Дерзайте. Попробуйте найти удаленную работу, если в городе небольшой выбор. Или рассмотрите вариант переезда. Серьезная математическая подготовка — это серьезный аргумент, чтобы рассмотреть переезд в Москву.
У меня товарищ тоже преподавал математику в ВУЗе. Потом стал программистом, попал в крупную компанию. Там на него обратил внимание отдел Data-solutions, и его математические навыки очень даже пригодились. Есть в программировании области, где математика важна. Двигайтесь в сторону Machine learning.
Если вы (корректно) используете реляционную базу, значит, она подходит под вашу модель данных и «просто» переехать, особенно целиком, на другое хранилище не просто сложно, а зачастую абсолютно не нужно.
На начальной стадии развития проекта мало что может удовлетворять, потому что приходится иметь дело с недостаточной информированностью. Если бы это было не так, то до сегодняшнего дня все работали бы по BDUF. А поэтому, выбрать сбалансированное решение, и предсказать этот баланс наперед не всегда возможно на начальной стадии.
Например, при распиле монолита, часто применяются принципы DDD, и агрегато-ориентированные базы данных становятся более привлекательными. Часто вопрос пересмотра выбора БД наступает в момент назревания необходимости шардить данные. Иногда БД перестает удовлетворять при добавлении каких-то новых бизнес-фич. Или, например, требуется внедрить Event Sourcing. Иногда приходится рассматривать проприетарные cloud-решения, предлагаемые крупными хостинг-провайдерами.
Именно поэтому, раз уж мы говорим о Clean Architecture, Роберт Мартин говорит:
«It is not necessary to choose a database system in the early days of development, because the high-level policy should not care which kind of database will be used. Indeed, if the architect is careful, the high-level policy will not care if the database is relational, distributed, hierarchical, or just plain flat files.»
«From an architectural point of view, the database is a non-entity—it is a detail that does not rise to the level of an architectural element. Its relationship to the architecture of a software system is rather like the relationship of a doorknob to the architecture of your home.»
Хороший архитектор максимизирует количество непринятых решений.
Хорошо, вместо контроллера теперь есть набор «функций» для доступа к модели, которые, кстати, тоже можно структурировать, используя каталоги файловой системы, например.
Это пока еще не функции, а паттерн Command, так же как и UseCase/Interactor являются разновидностью этого же паттерна. Технически можно сделать их чистыми функциями, здесь Greg Young рассказывает как это сделать.
С точки зрения Crean Architecture, Front/Page Conttroller — это всего лишь IO-устройство. А с точки зрения Hexagonal Architecture, это всего лишь один из портов. Поэтому, для Clean Architecture вопрос реализации роутинга и пр. не имеет принципиального значения.
У Вас чередуются термины Dependency Injection и Dependency Inversion, — это вещи немного разные, хотя последний и может реализовываться посредством первого.
При этом не совсем понятно, что вы имеете ввиду под DI, обычно, чтобы их отличать, Dependency Inversion пишется полностью — Dependency Inversion Principle (DIP).
сторонник практики инверсии зависимостей (Dependency Inversion, D в SOLID). Поэтому подобные зависимости мне нужно инициализировать где-то снаружи и передавать в конструктор контроллера.
DIP — это политика. Во втором предложении цитаты вы говорите уже о механизме пассивного внедрения зависимостей. Кстати, не обязательно в конструктор, можно и через сеттеры. В случае с конструктором можно использовать каррирование для управления зависимостями (не уверен что в Ruby это возможно).
# Плохо (инициализируем зависимость в конструкторе)
Вы, наверное, имели ввиду Service Locator или Plugin Pattern.
Но мы пойдём дальше и реализуем паттерн Unit of Work
В популярных ОРМ, объект Session реализует не Unit of Work, а паттерн Facade, чтобы облегчить работу с множеством компонентов ORM. Unit of Work не должен содержать метод .load(), так как это уже обязанность Repository/DataMapper.
Здесь возникает ощущение дежавю, как и с контроллерами: а не является ли репозиторий такой же рудиментарной сущностью? Забегая наперёд, отвечу — да, является.
Здесь вы немного поспешили с выводами. А что если Вашему проекту потребуется заменить RDBMS на Polyglot persistence (например, NoSQL + Graph Database) или даже ApplicationDatabase? Хороший архитектор максимизирует количество непринятых решений, и именно для решения этой задачи паттерн Repository и предназначен. Часто он, для достижения полного сокрытия источника данных, используется совместно с паттерном QueryObject или Specification.
Ну и еще такой вопрос — при использовании Polyglot Persistence, как вы думаете осуществлять двухфазные/компенсационные транзакции в Вашем случае?
То есть, мы можем отказаться от Repository и Controller в пользу единого унифицированного Action!
Только не Action, а паттерн Command. Такой подход активно применяется в CQRS.
Только Repository создается обычно для обслуживания одной доменной модели, или даже — одного агрегата.
Попробуйте добавить поддержку, например, Identity Map, и вы очень скоро обнаружите, что ваш подход приводит к Low Cohesion.
def initialize(attrs, payment_service)
Если уж вы и решили присовокупить сервис уровня приложения к доменной модели, то лучше было бы это сделать через Cross-Cutting Concern, Robert Martin как раз об этом пишет в Clean Code. Но лучше было бы их не присовокуплять, а использовать Domain Event.
Поэтому в рамках фреймворка Dandy я реализовал роутер
Задача Clean Architecture как раз и сводится к тому, чтобы минимизировать зависимость приложения от фреймворков.
P.S.: В целом, Вы на правильном пути. Видно желание докопаться до истины и результат. Надеюсь, что чем-то смог Вам помочь.
Если Вы правильно наложите ограничение — то не может. Можно даже наложить это ограничение технически, используя, например, обособленный сетевой периметр, ACL, DB-триггер и т.п. А лучше даже использовать специализированные хранилища. Хотя, чисто технически, можно подменить даже stack вызова функции, — так что тут все зависит от баланса стоимости затрат на реализацию этого ограничения и выгод от его взлома.
Смысл появляется тогда, когда у вас существуют функции, которые не живут в IO.
Ну почему же. С IO-устройствами тоже можно обращаться функционально, если наложить ограничение на изменяемость данных, т.е. если от CRUD отбросить Update и Delete. Именно в этом и заключается идея Event Sourcing, со слов автора термина CQRS Greg Young. Там у него есть еще вот такой интересный доклад на тему функциональной обработки данных.
Таки да. В IDDD, правда, бегло отыскать внятно сформулированного ответа мне не удалось, а вот в DDD Distilled это сформулировано предельно ясно: «When using DDD, a Bounded Context should align one-to-one (1:1) with a single Subdomain. That is, when using DDD, if there is one Bounded Context, there is, as a goal, one Subdomain model in that Bounded Context. It may not always be possible or practical to achieve, but where possible it is important to design in that way. This will keep your Bounded Contexts clean and focused on the core strategic initiative.»
Есть отличия. В основном этот термин используется для отделения смыслового ядра от неспециализированных подобластей (для которых можно применить готовые решения из коробки, например, учет прихода-расхода, и освободить ресурсы для более качественной проработки смыслового ядра). Глава 15 у Эванса. Просто пример у Chris Richardson по ссылке не самый удачный, сбивает с толку (что видно по комментариям внизу примера).
Я как раз имел ввиду случай, когда BC состоит из нескольких физических сервисов. Это относительно редкое исключение. В основном, один BC — один сервис.
максимально следовать принципам KISS и YAGNI и не усложнять пока это возможно.
Суть YAGNI заключается не в том, чтобы не усложнять, а в достижении наилучшей экономики разработки в условиях неполной информированности. А это значит, что выделение лишних абстракций (и любое другое усложнение) оправдано лишь в том случае, если стоимость их выделения в будущем будет существенно дороже, чем сейчас.
С другой стороны, «хороший архитектор всегда максимизирует количество непринятых решений», обеспечивая при этом высокие экономические показатели разработки при любом сценарии развития программы. YAGNI должен способствовать эволюции программы, а не препятствовать ей. Например, если код нарушает Open-Closed Principle (OCP) или Stable Dependencies Principle (SDP), то это, на самом деле, не YAGNI, поскольку это противоречит основной его цели — достижение наилучшей экономики разработки в условиях неполной информированности.
Приведенный вами фрагмент кода нарушает Stable Dependencies Principle (SDP). Оправдано ли это нарушение? Ответ зависит от баланса получаемых выгод и затрат. Если у Вас всего один такой метод — разумеется, вам дешевле пофиксить его, когда публичный интерфейс веб-фреймворка будет изменен. С другой стороны, мне известны проекты, которые на протяжении двух лет не могли соскочить со старой версии используемого фреймворка. Хорошее приложение стремится минимизировть зависимость от конкретного фреймворка и от конкретной его версии.
Определенная доля правды в Вашем ответе, действительно, присутствует. Репутация Agile сегодня на рынке, действительно, пострадала. И пострадала она вполне предсказуемо, и здесь масло в огонь подлил Ken Schwaber, когда убедил Jeff Sutherland «оставить инженерные практики за рамками Scrum, чтобы упростить модель и позволить командам брать на себя ответственность за выбор тех или иных практик».
С одной стороны, это облегчило освоение Scrum широкими массами. Это стало модным и массовым. С другой стороны, то, что осваивали широкие массы, на самом деле было немного далековато от принципиальной идеи Agile. Итеративное планирование — это не первопричина, а технически-обоснованная бизнес-возможность, достигаемая в результате Agile-разработки, и без последнего она теряет экономический смысл по сравнению с BDUF. «A steep change cost curve makes XP (Agile) impossible» — Kent Beck (основатель XP, подписант Agile Manifesto, наставник Роберта Мартина).
А по поводу «информационный энтропии», то «хороший архитектор максимизирует количество непринятых решений» — Роберт Мартин. Именно поэтому, уже на следующий год после того, как он в 2001 году организовал собрание для подписания Agile Manifesto, он выпустил книгу «Agile Software Development. Principles, Patterns, and Practices.», которая была посвящена тому, как нужно писать код, чтобы было возможным работать по Agile.
Ключ к качеству — не следует избегать первоначального проектирования, тут без специалиста в этой области не обойтись.
Конечно. Именно об этом говорит Kent Beck: «McConnell writes, „In ten years the pendulum has swung from 'design everything' to 'design nothing.' But the alternative to BDUF [Big Design Up Front] isn’t no design up front, it’s a Little Design Up Front (LDUF) or Enough Design Up Front (ENUF).“ This is a strawman argument. The alternative to designing before implementing is designing after implementing. Some design up-front is necessary, but just enough to get the initial implementation. Further design takes place once the implementation is in place and the real constraints on the design are obvious. Far from 'design nothing,' the XP strategy is 'design always.'»
Ну, и, классическое разъяснение по этому поводу — Is Design Dead?
От себя добавлю, что лично я редко встречал успешный Scrum, и больше предпочитаю Extreme Programming (XP) для небольших команд и SAFe для крупных проектов. Даже если мы и вынуждены работать по Scrum в силу каких-то формальных причин, то всегда стараемся комбинировать его с XP.
Для юнит-теста надо надо мокать базу, для этого надо пилить слои. Надо делать, какой-нибдуь IRepository.GetUserProfile(), делать слой данных, делать мэппинг данных из UserProfile в UserProfileResponse. (Вы же не будете класть объекты уровня Api в DAL).
Классический вопрос, озвученный в 2014 году David Heinemeier Hansson: "TDD is dead. Long live testing." (хотя на самом деле с TDD он мало связан, но, так случилось, что объектом его критики стал именно TDD, вероятно потому, что архитектура Ruby on Rails часто критиковалась приверженцами TDD). Результатом его поста стал 5-ти серийный сериал "Is TDD Dead?", в котором подробно раскрывается озвученная Вами проблема. В сериале принимал участие сам David Heinemeier Hansson, создатель Ruby on Rails, Martin Fowler, автор книги PoEAA, по которой и был создан Ruby on Rails, и Kent Beck — основатель TDD и друг Martin Fowler. Т.е. более компетентный ответ сложно найти.
Проблема данного кода не в том, что его трудно протестировать изолированно (изоляцию, на самом деле, легко осуществить на уровне коннектора БД, о чем писал Кент Бек в «Test-Driven Development By Example»), если изоляцию вообще нужно делать, а в том, что в этом коде невозможно отделить то, ЧТО он делает, от того, КАК он это делает. Т.е. смешаны политики разного уровня, которые будут изменяться в разное время, с разной частотой и по разным причинам. В качестве примера можно привести некогда популярный веб-фреймворк Pylons, который прекратил свое существование, крупные обратно-несовместимые изменения в веб-фреймворке CherryPy, которые отразились на другом веб-фреймворке TurboGears, и т.п. На фронтенде хорошо известна история с совершенно обратно-несовместимым релизом Angular2.
И здесь перед вами возникает вопрос поиска баланса выгод и затрат — что произойдет, если IO-устройство (а, с точки зрения принципов Clean Architecture, Front/Page Controller — это просто IO-устройство) выпустило обратно-несовместимый релиз или объявило о прекращении своего существования? Что произойдет, если вам понадобится добавить поддержку, например, CLI-интерфейса? Дешевле ли Вам заложить уровень абстракции сейчас, и защитить свою политику более высокого уровня от низкоуровневых изменений, или же вам дешевле каждый «апгрейдить» свой код? Каждое решение — это поиск компромиса.
В связи с тем, что в последнее время заметно усилился интерес к CQRS, построение запроса обычно инкапсулируется в Query объект (пример), при этом не обязательно использовать ни доменные модели (по причине вырожденности их поведения), ни Repository. Сторонники Clean Architecture выделяют класс UseCase/Interactor, который, так же, как и класс Query, является разновидностью паттерна Команда, но, по определению, имеет немного более высокий уровень политики.
Вы можете подсказать название статического анализатора, который умеет полноценно распознавать классифицированные Code Smells из описанных каталогов? К примеру, распознавать Shotgun Surgery или Divergent Change? С удовольствием выслушал бы. Известные мне анализаторы умеют распознавать в лучшем случае лишь Feature Envy (не считая проверки Style Guide).
То, что шустрые ребята собрали в кучу ряд стандартных подпроцессов и дали им красивые имена не делает эту методу стандартом. Более того в ряде реальных бизнесов и продуктов, Agile не работает в принципе.
Нужно, наверное, немного внести ясность, что такое Agile и как он возник. Agile — это исторический момент перехода количественных изменений методик разработки в качественные. Примерно как вода, при при накоплении энергии до температуры 100°C, переходит в новое качественное состояние.
Изначально все работали по BDUF, поскольку изменение реализованных проектных решений стоило очень дорого (стоимость росла экспоненциально). BDUF тоже стоит недешево, поскольку он создается в условиях недостаточной информированности (и обработка этой недостаточности требует работы высококвалифицированных архитекторов), а вероятность ошибки в этих условиях слишком высока. Но тем не менее, он стоил дешевле изменения реализованных решений.
В определенный исторический момент уровень зрелости методик разработки (OOP, TDD, Refactoring, Design Patterns, PoEAA и т.п.) достиг такого уровня, при котором изменение уже реализованных проектных решений стало стоить дешевле создания BDUF. График роста стоимости изменения кода изменился с экспоненциального на асимптотический.
Наука, отвечающая за линейный рост стоимости изменения кода, как я уже, говорил, называется архитектура. А поэтому, на собрании, которое организовал всем известный Robert C. Martin (автор Clean Code) для подписания Agile Manifesto в 2001 году, присутствовал ряд ведущих архитекторов того времени: Ward Cunningham, Kent Beck, Martin Fowler и др.
Иными словами, достижение низкой стоимости изменения кода открыло бизнес-возможность вести разработку итеративно, таким образом, чтобы проектные решения будущих итераций опирались на обратную связь (feedback) от практической эксплуатации реализации проектных решений предыдущих итераций.
Отсюда становится понятно, почему бывает что «Agile не работает в принципе», если правильно понимать его принцип (разумеется, кроме принципиальной причины, существует еще и ряд других причин — организационные, финансовые и пр.). Принципиальная же причина заключается в том, что многим проектам не удается удержать стоимость изменения кода низкой (обычно — в силу невысокого внутреннего качества программы), в итоге, исправление реализованных проектных решений стоит настолько дорого, что дешевле спроектировать все заблаговременно.