Merge pull request #143 from emacsway/emacsway

Emacsway

emacsway/it/ddd/grade/domain/aggregate-encapsulation.rst

@@ -352,6 +352,7 @@ Exporter
 ----------------------
 
 Возникает целесообразность облегчить метод экспортирования, придав ему сигнатуру ``Endorser.Export() EndorserState`` вместо ``Endorser.ExportTo(ex EndorserExporter)``.
+В Python для этого есть даже задокументированные методы \__getstate\__() и \__setstate\__().
 Получится что-то типа DTO с тем лишь отличием, что он пересекает не сетевые границы, а границы инкапсуляции Агрегата.
 В Golang этот вариант выглядит чуть более привлекательным, хотя и менее OOP, но зато не контрастирует с FP принципами Value Object.
 
@@ -412,6 +413,10 @@ Exporter
 Это затрудняет создание обобщенных классов, например, `обобщенного композитного первичного ключа <https://martinfowler.com/eaaCatalog/identityField.html>`__.
 В результате плодятся промежуточные структуры, которые затем нужно преобразовывать к нужному виду.
 
+Вместе с данными экспортируется и иерархия данных, т.е. внутренняя структура агрегата. А значит, за обход структуры будет отвечать уже не агрегат в единственном месте, а потребители экспортируемых данных во мнодественных местах, что удорожает изменение программы.
+
+Затрудняется обратная совместимость, т.к. состояние единственно, а поведение множественно, что значит - версионируемо.
+
 Знание о возвращаемом типе подталкивает к применению generics там, где этого несложно избежать.
 
 Возвращаемая структура и ее типизация является избыточным знанием, которое может препятствовать обобщению (абстрагированию) клиента этого метода, например, препятствовать выделению абстрактного класса паттерна Repository.

emacsway/it/sdlc/models/agile/agile.rst

@@ -77,7 +77,7 @@
 В нашем случае решение так же заключается в разбиении целого (процесса разработки) на части (итерации), только вместо согласованности единого языка здесь критерием разделения выступает достаточность полноты требований.
 
 Agile является естественным следствием эволюции итеративной разработки, краткий обзор которой можно посмотреть в превосходной статье Craig Larman "`Iterative and Incremental Development: A Brief History <https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf>`__".
-В ней говорится о том, что цикл PDSA известен еще с 1930 года, в 1957 году впервые была применена :ref:`инкрементальная <emacsway-incremental-development>` модель разработки, а в 1968  году - :ref:`итеративная <emacsway-iterative-development>`.
+В ней говорится о том, что цикл PDCA (PDSA) известен еще с 1930 года, в 1957 году впервые была применена :ref:`инкрементальная <emacsway-incremental-development>` модель разработки, а в 1968  году - :ref:`итеративная <emacsway-iterative-development>`.
 
 Как уже говорилось ранее, итеративная модель разработки открывает широкие возможности для :ref:`удешевления обработки неопределенности <emacsway-adaptation>`.
 Однако долгое время эти возможности оставались экономически нецелесообразными по причине быстрорастущего характера роста стоимости :ref:`Adaptation <emacsway-adaptation>`, приближющегося к экспоненциальному.

emacsway/it/sdlc/models/agile/analysis/concerns/balancing-business-technical-concerns.rst

@@ -304,6 +304,29 @@ Frederick Brooks в своем бестселлере "Мифический че
 
     -- "Scrum and XP from the Trenches: How We Do Scrum" 2nd edition by Henrik Kniberg, перевод под редакцией Алексея Кривицкого
 
+..
+
+    💬 Одной из проблем при найме разработчиков является заблуждение о небольшом разбросе в их квалификации – ошибочное мнение, будто программисты не слишком отличаются друг от друга (с точки зрения производительности, качества кода и т. д.). Но исследования показывают, что верхний квартиль по уровню квалификации способен работать примерно вчетверо быстрее, чем нижний [Prechelt00]. Довольно большая разница, согласитесь. Кроме того, модель COCOMO, основанная на многолетних масштабных исследованиях, показывает, что уровень квалификации группы разработчиков – наиболее важный из всех факторов, влияющих на ее производительность [Boehm00]. Наконец, очень слабые программисты в среднем создают код худшего качества (с плохим дизайном) и с бо‌льшим количеством дефектов, что дополнительно тормозит всю систему.
+
+    Но все эти влияния проявляются не немедленно, а с некоторым запозданием. Например, если вы наймете много слабых разработчиков, пройдет относительно много времени, прежде чем начнут ощущаться последствия их плохой работы / некачественного кода. Соответственно среднее снижение скорости поставки новой функциональности (вызванное сильным влиянием разброса квалификации программистов) произойдет не сразу, а спустя какое-то время.
+
+    Отложенный характер эффектов негативно влияет на способность системы к обучению и коррекции. Если результат или случайное следствие какого-либо действия проявляется с большой задержкой во времени, люди часто не видят (причинно-следственной) связи между ними, не понимают, что именно A повлияло на Б или, еще сложнее, что A повлияло на Б, а Б в ответ повлияло на А.
+
+    Следовательно, люди не учатся и не исправляют ошибки – в правилах, управленческих действиях, инструментах и т. д. Именно из-за отложенных эффектов постепенное улучшение через практику бережливого подхода кайдзен может занимать длительное время: чтобы увидеть, улучшается ли что-то и как, требуется терпение и способность проникать в суть вещей.
+
+    -- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева
+
+..
+
+    💬 Петли положительной или отрицательной обратной связи[9] и отложенные эффекты – тонкие моменты, которые делают динамику системы еще более сложной и менее понятной. К примеру, как программисты могут повысить свой уровень квалификации? Один из способов – учиться у высококвалифицированных специалистов и видеть много примеров отличного кода. Но компания, в которой работает много (очень дешевых) программистов с низкой квалификацией, производит мало образцов качественного кода, а также не привлекает и не может удержать крутых программистов, которые могли бы играть роль наставников. Те скорее найдут работу в другом месте.
+
+    Таким образом, группа разработки входит в самоусиливающуюся нисходящую спираль – последовательность петель положительной обратной связи, где каждая петля усиливает последующую. К счастью, этот нисходящий тренд ограничен бюджетом.
+
+        Попробуйте… увидеть в системе петли положительной обратной связи.
+
+    По мере того как уходит все больше крутых разработчиков, которые могли бы создавать отличный код и обучать других, у слабых разработчиков становится все меньше возможностей для обучения. Процент слабых разработчиков растет, а качество кода и производительность падают все ниже. Код становится все более грязным, запутанным, с большим количеством повторений, что снижает способность группы быстро реализовывать новую функциональность. Падение скорости реализации новой функциональности вынуждает нанимать еще больше дешевых разработчиков. Короче, в системе создается множество самоусиливающихся петель положительной обратной связи.
+
+    -- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева
 
 .. index::
    single: Concerns; solution to balancing business and technical concerns in Agile