💬 "Кто-то спросит: так ли уж часто читается наш код? Разве большая часть времени не уходит на его написание?

Вам когда-нибудь доводилось воспроизводить запись сеанса редактирования? В 80-х и 90-х годах существовали редакторы, записывавшие все нажатия клавиш (например, Emacs). Вы могли проработать целый час, а потом воспроизвести весь сеанс, словно ускоренное кино. Когда я это делал, результаты оказывались просто потрясающими.

Большинство операций относилось к прокрутке и переходу к другим модулям!

- Боб открывает модуль.
- Он находит функцию, которую необходимо изменить.
- Задумывается о последствиях.
- Ой, теперь он переходит в начало модуля, чтобы проверить инициализацию переменной.
- Снова возвращается вниз и начинает вводить код.
- Стирает то, что только что ввел.
- Вводит заново.
- Еще раз стирает!
- Вводит половину чего-то другого, но стирает и это!
- Прокручивает модуль к другой функции, которая вызывает изменяемую функцию, чтобы посмотреть, как она вызывается.
- Возвращается обратно и восстанавливает только что стертый код.
- Задумывается.
- Снова стирает!
- Открывает другое окно и просматривает код субкласса. Переопределяется ли в нем эта функция?
<...>
В общем, вы поняли. На самом деле соотношение времени чтения и написания кода превышает 10:1. Мы постоянно читаем свой старый код, поскольку это необходимо для написания нового кода.

Из-за столь высокого соотношения наш код должен легко читаться, даже если это затрудняет его написание. Конечно, написать код, не прочитав его, невозможно, так что упрощение чтения в действительности упрощает и написание кода. Уйти от этой логики невозможно. Невозможно написать код без предварительного чтения окружающего кода. Код, который вы собираетесь написать сегодня, будет легко или тяжело писаться в зависимости от того, насколько легко или тяжело читается окружающий код. Если вы хотите быстро справиться со своей задачей, если вы хотите, чтобы ваш код было легко писать — позаботьтесь о том, чтобы он легко читался.

You might ask: How much is code really read? Doesn't most of the effort go into writing it?

Have you ever played back an edit session? In the 80s and 90s we had editors like Emacs that kept track of every keystroke. You could work for an hour and then play back your whole edit session like a high-speed movie. When I did this, the results were fascinating.

The vast majority of the playback was scrolling and navigating to other modules!

- Bob enters the module.
- He scrolls down to the function needing change.
- He pauses, considering his options.
- Oh, he's scrolling up to the top of the module to check the initialization of a variable.
- Now he scrolls back down and begins to type.
- Ooops, he's erasing what he typed!
- He types it again.
- He erases it again!
- He types half of something else but then erases that!
- He scrolls down to another function that calls the function he's changing to see how it is called.
- He scrolls back up and types the same code he just erased.
- He pauses.
- He erases that code again!
- He pops up another window and looks at a subclass. Is that function overridden?
<...>
You get the drift. Indeed, the ratio of time spent reading vs. writing is well over 10:1. We are constantly reading old code as part of the effort to write new code.

Because this ratio is so high, we want the reading of code to be easy, even if it makes the writing harder. Of course there's no way to write code without reading it, so making it easy to read actually makes it easier to write.

There is no escape from this logic. You cannot write code if you cannot read the surrounding code. The code you are trying to write today will be hard or easy to write depending on how hard or easy the surrounding code is to read. So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read."
—"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin, перевод: Е.Матвеев, ООО Издательство "Питер"

#SoftwareDesign

Можно добавить, что 10:1 - это еще оптимистическое соотношение для кода с приемлемым качеством.
Подведем итог: в процессе конструирования кода, 91% времени (в лучшем случае) занимает именно чтение кода и борьба со сложностью (каждым разработчиком регулярно), и только 9% времени (1:10) занимает ввод символов с клавиатуры (одним разработчиком единократно).

#SoftwareDesign

Сегодня в одном из чатов мне напомнили о том, что существует "Overengeneering", и это, в общем-то, как бы плохо. Отсюда напрашивается вывод, что, мол, не нужно развиваться, чтобы не стать оверинженерным и квазинаучным.

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

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

По этому поводу хорошо выразился И.Е.Репин:

💬 "Сначала художник рисует плохо и просто.
Потом сложно и плохо.
Потом сложно и хорошо.
И только потом - просто и хорошо."

Ладно, И.Е.Репин - не IT-шник:

💬 "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
—Edsger W. Dijkstra, 1984 On the nature of Computing Science (EWD896)

Что можно в этом случае предпринять? Варианта два:

1. Уравновешивать когнитивные искажения технического специалиста, чем, собственно, и должна заниматься организация процессов разработки. По понятным причинам, сейчас мы в неё погружаться не будем. Главное - знать, что эта проблема решаема.

2. Чем большей полнотой знаний обладает специалист, тем большим моментом инерции обладает его устойчивость, тем меньшее воздействие на неё оказывает каждый новый инкремент знаний, и тем лучше достигается сбалансированность решений. Иными словами, лечится это увеличением охвата знаний. Нужно просто не зацикливаться и поскорее пройти этот этап профессионального становления.

Можно ли стать "переусложненным" постоянно развиваясь? Нет, не можно, и это хорошо видно на примере Kent Beck - невероятно эрудированного человека, обладающего редкой способностью объяснять сложные вещи простым языком. Объем списка использованной литературы его книг вызывает состояние легкого удивления, как и простота и ясность его формулировок. Другим таким ярким примером является @vladik_kh .

Объясняется это просто - возможности человеческого мозга ограничены, и, чтобы не потонуть в океане информации, и сохранить какую-то способность ориентироваться в ней, он начинает кристаллизировать её. Постоянно обобщая и систематизируя, он выводит наименее противоречивую форму этой информации. Количество переходит в качество.

Ну а самое главное - overengeneering является как раз следствием недостатка знаний о контексте и моменте своевременности применения тех или иных подходов. Излечить это незнание с помощью информационного голода технически невозможно, т.к. между YAGNI и Spaghetti-code имеется огромная разница, которая заключается именно в полноте знаний.

#SoftSkills #Simplicity

Привет!
Приглашаем на очную встречу ArchDays Recap 27 июля (ср) в Москве.

🧚ArchDays Recap — новый для нас формат, на котором приглашенные спикеры предыдущих конференций:
— расскажут о дальнейшем развитии истории из выступления;
— раскроют некоторые аспекты выступлений, важность которых была осознана уже после;
— ответят на вопросы из зала или из формы на сайте.

📍Программа и регистрация: https://archconf.ru/recap-27-07-22

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

Лишь немногим удается эффективно спланировать самообучение и снять психологическое напряжение.

Без планирования самообразования огромный наукоемкий горизонт требуемых знаний перегружает психику - вся тяжесть требуемых знаний фокусируется в текущий момент времени, и формирует чувство многократного их превосходства над ресурсами мозга. Это вызывает беспокойство. Вопрос влияния планирования на беспокойство хорошо рассматривается в "Planning Extreme Programming" by Kent Beck, Martin Fowler.

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

В погоне за количеством специалисты нередко надрываются, осознают невыполнимость желаемого, впадают в депрессию, подавляют Когнитивный Диссонанс и входят в состояние Психологической Защиты (мол, "академичность" неуместна на практике), и прекращают развиваться. Это порождает еще одну проблему - высокую токстичность коллективов в ИТ-индустрии, которая нередко приводит к расколам или потере ценных кадров.

С целью решения этой проблемы, мы видим перед собой следующие задачи:
1. создание объединенного архитектурного руководства;
2. создание интерактивных графов принятия решений или СППР;
3. создание эталонно-демонстрационных архитектур (Reference Architectures);
4. создание эталонно-демонстрационных приложений (Reference Applications);
5. проведение цикла архитектурных практикумов (workshops);
6. проведение ряда мероприятий с целью популяризации эффективных форм самообучения.

Кому интересно разделить наши цели и сплотить усилия для их достижения - обращайтесь в @ru_arc_bot .

#Goal

💬 "Дейкстра пишет, что ни один человек не обладает интеллектом, способным вместить все детали современной компьютерной программы (Dijkstra, 1972), поэтому нам - разработчикам ПО — не следует пытаться охватить всю программу сразу. Вместо этого мы должны попытаться организовать программы так, чтобы можно было безопасно работать с их отдельными фрагментами по очереди. Целью этого является минимизация объема программы, о котором нужно думать в конкретный момент времени. Можете считать это своеобразным умственным жонглированием: чем больше умственных шаров программа заставляет поддерживать в воздухе, тем выше вероятность того, что вы уроните один из них и допустите ошибку при проектировании или кодировании.

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

Стремление к краткости методов программы помогает снизить нагрузку на интеллект. Этому же способствует написание программы в терминах проблемной области, а не низкоуровневых деталей реализации, а также работа на самом высоком уровне абстракции.

Суть сказанного в том, что программисты, компенсирующие изначальные ограничения человеческого ума, пишут более понятный и содержащий меньшее число ошибок код.

Dijkstra pointed out that no one's skull is really big enough to contain a modern computer program (Dijkstra 1972), which means that we as software developers shouldn't try to cram whole programs into our skulls at once; we should try to organize our programs in such a way that we can safely focus on one part of it at a time. The goal is to minimize the amount of a program you have to think about at any one time. You might think of this as mental juggling—the more mental balls the program requires you to keep in the air at once, the more likely you'll drop one of the balls, leading to a design or coding error.

At the software-architecture level, the complexity of a problem is reduced by dividing the system into subsystems. Humans have an easier time comprehending several simple pieces of information than one complicated piece. The goal of all software-design techniques is to break a complicated problem into simple pieces. The more independent the subsystems are, the more you make it safe to focus on one bit of complexity at a time. Carefully defined objects separate concerns so that you can focus on one thing at a time. Packages provide the same benefit at a higher level of aggregation.

Keeping routines short helps reduce your mental workload. Writing programs in terms of the problem domain, rather than in terms of low-level implementation details, and working at the highest level of abstraction reduce the load on your brain.

The bottom line is that programmers who compensate for inherent human limitations write code that's easier for themselves and others to understand and that has fewer errors."
—"Code Complete" 2nd edition by Steve McConnell, перевод: Издательско-торговый дом "Русская Редакция"

#SoftwareDesign

Пришло время разобраться с термином "Refactoring", значение которого часто понимается неверно в значении "переработать".

По основной версии, слово "refactoring" происходит от математического термина "factoring", и дословно переводится как "факторизация" или "декомпозиция", о чем говорит на своем сайте ключевой автор известной книги "Refactoring: Improving the Design of Existing Code" by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts (благодаря которой, рефакторинг и обрел популярность):

💬 "The obvious answer comes from the notion of factoring in mathematics. You can take an expressions such as x^2 + 5x + 6 and factor it into (x+2)(x+3). By factoring it you can make a number of mathematical operations much easier. Obviously this is much the same as representing 18 as 2*3^2. I've certainly often heard of people talking about a program as well factored once it's broken out into similarly logical chunks."
—"Etymology Of Refactoring" by Martin Fowler

Такое же мнение можно увидеть и на сайте Ward Cunningham:

💬 "Refactoring is a kind of reorganization. Technically, it comes from mathematics when you factor an expression into an equivalence - the factors are cleaner ways of expressing the same statement. Refactoring implies equivalence; the beginning and end products must be functionally identical. You can view refactoring as a special case of reworking (see WhatIsReworking).

Practically, refactoring means making code clearer and cleaner and simpler and elegant. Or, in other words, clean up after yourself when you code. Examples would run the range from renaming a variable to introducing a method into a third-party class that you don't have source for.

Refactoring is not rewriting, although many people think they are the same. There are many good reasons to distinguish them, such as regression test requirements and knowledge of system functionality. The technical difference between the two is that refactoring, as stated above, doesn't change the functionality (or information content) of the system whereas rewriting does. Rewriting is reworking. See WhatIsReworking.

Refactoring is a good thing because complex expressions are typically built from simpler, more grokable components. Refactoring either exposes those simpler components or reduces them to the more efficient complex expression (depending on which way you are going).

For an example of efficiency, count the terms and operators: (x - 1) * (x + 1) = x^2 - 1. Four terms versus three. Three operators versus two. However, the left hand side expression is (arguably) simpler to understand because it uses simpler operations. Also, it provides you more information about the structure of the function f(x) = x^2 - 1, like the roots are +/- 1, that would be difficult to determine just by "looking" at the right hand side."
—"What Is Refactoring" on wiki.c2.com

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

💬 "Рефакторинг представляет собой процесс такого изменения программной системы, при котором не меняется внешнее поведение кода, но улучшается его внутренняя структура.

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure."
—Martin Fowler in "Refactoring: Improving the Design of Existing Code" by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts, перевод С. Маккавеева

Во 2-м издании это определение слегка изменилось:

💬 "Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior."

#SoftwareDesign

- We don't have time to do it right!
- Do you have time to do it twice?

—Randy Shoup, VP Engineering at Stitch Fix in San Francisco

#SoftwareDesign

💬 "These were elucidated in the mid-70s by Yourdon & Constantine in "Structured Design" and haven't changed. Their argument goes like this:

1. We design software to reduce its cost.
2. The cost of software is ≈ the cost of changing the software.
3. The cost of changing the software is ≈ the cost of the expensive changes (power laws and all that).
4. The cost of the expensive changes is generated by cascading changes — if I change this then I have to change that and that, and if I change that then…
5. Coupling between elements of a design is this propensity for a change to propagate.
6. So, design ≈ cost ≈ change ≈ big change ≈ coupling. Transitively, software design ≈ managing coupling.

(This skips loads of interesting stuff, but I'm just trying to set up the argument for why rapid decomposition of a monolith into micro-services is counter-productive.)"

-- "Monolith -> Services: Theory & Practice" by Kent Beck

Продолжение:

💬 "Managing Coupling

Note I don't say, "Eliminating coupling." Decoupling comes with its own costs, both the cost of the decoupling itself and the future costs of unanticipated changes. The more perfectly a design is adapted to one set of changes, the more likely it is to be blind-sided by novel changes. And so we have the classic tradeoff curve.

You manage coupling one of two ways:

1. Eliminate coupling. A client and server with hard-coded read() and write() functions are coupled with respect to protocol changes. Change a write() and you'll have to change the read(). Introduce an interface definition language, though, and you can add to the protocol in one place and have the change propagate automatically to read() and write().
2. Reduce coupling's scope. If changing one element implies changing ten others, then it's better if those elements are together than if they are scattered all over the system —less to navigate, less to examine, less to test. The number of elements to change is the same, but the cost per change is smaller. (This is also known as the "manure in one pile" principle, or less-aromatically "cohesion".)"

-- "Monolith -> Services: Theory & Practice" by Kent Beck

Кстати, если вдруг кто-то пропустил, последнее определение SRP от 2022-07-06:

💬 "The Single Responsibility Principle (SRP):
Gather together those things that change for the same reasons and at the same times. Separate those things that change for different reasons or at different times."
— Robert C. Martin

Отражение такого явления можно увидеть даже в современном фольклоре - мемах.

Источник.

"Нам некогда делать DDD..." "Нам некогда писать тесты..." Наверное, каждый из нас слышал подобные утверждения.

Но, странное дело, практические эксперименты показывают, что, хотя мы и пишем больше кода, разработка продвигается быстрее. Разве не должна была она замедлиться?

В главе "Chapter 1. What Is Design and Architecture? :: What went wrong?" книги "Clean Architecture: A Craftsman's Guide to Software Structure and Design" Robert C. Martin приводит статистику Jason Gorman по результатам многократного прохождения кат как с применением TDD, так и без применения TDD, с интересным выводом:  TDD дает прирост темпов разработки около 10%. Я могу подтвердить этот вывод наблюдениями из собственного опыта.

Почему так? Почему написание бОльшего количества кода занимает меньше времени?

Если вспомнить, то, в процессе конструирования кода, отношение времени чтения кода и борьбы со сложностью ко времени ввода символов с клавиатуры составляет не менее 10:1 (или 91% к 9%).

Если мы увеличим вдвое количество кода без повышения когнитивной нагрузки, то это будет уже 10:2 (83% к 17% вместо 91% к 9%). Совокупное время конструирования кода увеличится всего на 100%*(12 - 11)/11 = 9%.

Написание вдвое большего количества кода занимает всего на 9% больше времени.

А теперь посмотрим, что произойдёт, если уменьшить вдвое когнитивную нагрузку при написании прежнего объема кода. Соотношение времени станет 5:1, вместо 10:1, что равно 83% к 17% вместо 91% к 9%. Совокупное время уменьшится на 100%*(6 - 11)/11 = -45% - ровно столько времени сэкономится, если разработчик будет тратить вдвое меньше времени на борьбу со сложностью.

Чувствуете разницу, 9% против 45%? Это в корне противоречит иллюзиям о мнимой экономии на отсутствии юнит-тестов или качественного Software Design даже для MVP.

TDD является эффективным средством управления сложностью и снижения когнитивной нагрузки за счет сужения фокуса внимания, использования механизмов обобщения и триангуляции. Математическое объяснение этого явления можно найти в главе "1. Recurrent Problems : 1.1. The Tower of Hanoi" книги "Concrete Mathematics: A Foundation for Computer Science" 2nd edition by Ronald L. Graham, Donald E. Knuth, Oren Patashnik.

Когда человек говорит, что использование TDD или DDD займет у него больше времени, то это значит, что основная часть времени будет потрачена на освоение этих подходов. Да, это неизбежно, но эти затраты однократные в его профессиональной карьере. Для специалиста, владеющего этими подходами, их использование даст экономию времени, поскольку они существенно снижают когнитивную нагрузку.

#SoftwareDesign

Overengeneering уже обсуждался, но к этой теме есть что добавить:

💬 "The essence of this argument is that patterns are often over-used. The world is full of the legendary programmer, fresh off his first reading of GOF who includes sixteen patterns in 32 lines of code. I remember one evening, fueled by a very nice single malt, running through with Kent a paper to be called "Not Design Patterns: 23 cheap tricks" We were thinking of such things as use an if statement rather than a strategy. The joke had a point, patterns are often overused, but that doesn't make them a bad idea. The question is how you use them."
—"Is Design Dead?" by M.Fowler

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

💬 "Главным Техническим Императивом Разработки ПО является управление сложностью. Управлять сложностью будет гораздо легче, если при проектировании вы будете стремиться к простоте.

Есть два общих способа достижения простоты: минимизация объема существенной сложности, с которой приходится иметь дело в любой конкретный момент времени, и подавление необязательного роста несущественной сложности.

Software's Primary Technical Imperative is managing complexity. This is greatly aided by a design focus on simplicity.

Simplicity is achieved in two general ways: minimizing the amount of essential complexity that anyone's brain has to deal with at any one time, and keeping accidental complexity from proliferating needlessly."
—"Code Complete" 2nd edition by Steve McConnell, перевод: Издательско-торговый дом "Русская Редакция"

Обратите внимание, уменьшить essential complexity нельзя, но ею можно управлять в момент времени. А вот рост accidental complexity (несущественной, технической сложностью) можно уменьшить. Именно об этом говорил M.Fowler в первой цитате. За более подробной информацией об этих терминах лучше обратиться к первоисточнику:
- "No Silver Bullet—Essence and Accident in Software Engineering" by Turing Award, Fred Brooks.

Статья так же включена в must have книгу:
- "The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr.

, которая имеет несколько достаточно качественных переводов на русский язык, и читается на одном дыхании за выходные.

Ну а мы пока подведем итог:
Лекарство не должно быть хуже болезни. А цель должна оправдывать средства. Внося сложность в систему, мы должны обретать возможность управлять еще большим уровнем сложности, т.е. решение должно быть оправданным.

Вопрос применения паттернов - это вопрос поиска баланса между уровнем управляемой ими сложности и уровнем привносимой ими сложности.

#SoftwareDesign #Simplicity

На этой неделе поработал немного с Golang, и поймал себя на мысли, что Golang - хороший пример того, как индустрия разрешает противоречие между информационной перегруженностью и переусложненностью современной области знаний, с одной стороны, и стесненностью ресурсов времени практикующих специалистов на их освоение, с другой стороны. Что является, кстати, одной из уставных целей нашего объединения.

На почве предыдущего поста мне вспомнились слова Никлауса Вирта:

💬 "Богатство функциональных возможностей во многих современных языках - это действительно проблема сама по себе, а не решение других проблем. Избыток возможностей - это еще одно следствие веры многих программистов в то, что ценность языка пропорциональна количеству этих возможностей (как я это называю- это вера в "колокольчики и свистки"). Однако, мы знаем, что будет лучше, если каждое базисное понятие представляется единственной, специально для этого предназначенной конструкцией. Это не только сокращает усилия по изучению языка, но и сокращает размер его описания, что, в свою очередь, помогает избежать несогласованности и неправильного понимания. Поддержание языка максимально простым и регулярным всегда было приоритетом в моей работе: описание Pascal занимало около 50 страниц, Modula - около 40, а Oberon - и вовсе 16. И я рассматриваю эту тенденцию как прогрессивную. Истинная ценность языков программирования зависит от качества и практичности их абстракций. Пример - абстракция, называемая "число" или абстракция "логическая величина", замещающая конкретную строку битов.

Ценность такого рода абстракции основывается на ее целостности. В случае чисел должны быть применяемы только арифметические операции, независимо от того факта, что логические операции, в принципе, также могут быть применимы к битовым строкам, представляющим числа."
—"О культуре разработки ПО" / Никлаус Вирт

Кстати, вспомнилось, что Golang унаследовал идеи Oberon.

#Simplicity

Если вы задумываетесь о качестве процессов в вашем проекте, но не знаете с чего начать, то настоятельно порекомендуем ознакомиться с Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology.

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

Самое интересное, что эффективность многих практик, до которых мы дошли самостоятельно эмпирическим путем была подтверждена статистически, что не может не радовать.

Eric Evans дает интересное определение Constantine's Law нетехническим языком:

💬 "МОДУЛИ дают возможность посмотреть на модель с разных сторон:
во-первых, можно изучить подроб­ности устройства модуля, не вникая в сложное целое;
во-вторых, удобно рассматривать взаимоотношения между модулями, не вдаваясь в детали их внутреннего устройства.

<...>

То, что при делении на модули должна соблюдаться низкая внешняя зависимость
(low coupling) при высокой внутренней связности (high cohesion)- это общие слова. Определения зависимости и связности грешат уклоном в чисто технические, количест­венные критерии, по которым их якобы можно измерить, подсчитав количество ассо­циаций и взаимодействий. Но это не просто механические характеристики подразде­ления кода на модули, а идейные концепции. Человек не может одновременно удер­живать в уме слишком много предметов (отсюда низкая внешняя зависимость). А плохо связанные между собой фрагменты информации так же трудно понять, как неструктурированную "кашу" из идей (отсюда высокая внутренняя связность).

MODULES give people two views of the model:
They can look at detail within a MODULE without being overwhelmed by the whole, or they can look at relationships between MODULES in views that exclude interior detail.

<...>

It is a truism that there should be low coupling between MODULES and high cohesion
within them. Explanations of coupling and cohesion tend to make them sound like technical metrics, to be judged mechanically based on the distributions of associations and interactions. Yet it isn't just code being divided into MODULES, but concepts. There is a limit to how many things a person can think about at once (hence low coupling). Incoherent fragments of ideas are as hard to understand as an undifferentiated soup of ideas (hence high cohesion)."
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans, перевод В.Л. Бродового

#SoftwareDesign

Авторы исследования выделяют 4 основные метрики (см. картинку), по которым им удалось проклассифицировать команды. Всего вышло 4 группы, от элиты до аутсайдеров. Опираясь на метрики, можно понять, чем чревата работа в каждой из команд лично для вас и предположить какие проблемы вас ожидают.

Кратко о результатах исследования можно увидеть по ссылке.