Управление сложностью (главный императив разработки ПО) на примере шахмат:

"Дейкстра пишет, что ни один человек не обладает интеллектом, способным вместить все детали современной компьютерной программы (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, перевод: Издательско-торговый дом "Русская Редакция"

Я всегда советую swebok, в части модели качества , все что про перфоманс и сопряжении с другими параметрами модели

Я в качестве "простого" введения до сих пор использую книгу от Microsoft:
Performance Testing Guidance for Web Applications. Microsoft Corporation, 2007 (https://learn.microsoft.com/en-us/archive/blogs/dajung/ebook-pnp-performance-testing-guidance-for-web-applications). Там есть человеческим языком про распределения :)

С точки зрения математики измерения производительности есть Akinshin A. Pro .NET Benchmarking. The Art of Performance Measurement. Apress, 2019. 662 p.
Есть её перевод Акиньшин А. Профессиональный бенчмарк: искусство измерения производительности. Питер, 2022. 576 с. (но местами перевод хромает).

О метриках хорошо написано в книге Witte F. Metrics for Test Reporting: Analysis and Reporting for Effective Test Management. Springer, 2024. (перевод с немецкого издания 2018 года с поправками). Интересует глава 18. Metrics for Performance and Load Tests.

Близко находится Kejariwal A., Allspaw J. The Art of Capacity Planning: Scaling Web Resources in the Cloud. O'Reilly, 2017. 236 p. Там неплохие оценки ресурсов, что для нагрузочного тестирования тоже полезно.

P.S. А база: Jorgensen P.C., DeVries B. Software Testing. A Craftsman’s Approach. 5th Ed. CRC Press, 2021. 550 p. Там замечательно про тесты корректности (с математикой!), но про остальные тесты мало…

P.P.S. По отдельным направлениям приходится читать статьи, например, недавнее по тестам облачных функций: SCOPE: Performance Testing for Serverless Computing. arXiv:2306.01620v2, 2025 (https://arxiv.org/abs/2306.01620)

Про палки забыл!

И вообще, есть же икона стиля: https://yasdelie.ru/

Всё так. Но опять огрызками системной инженерии пробуем объяснять, а народ не понимает, так как этот огрызок не стыкуется с другими 😀

По ходу, если реально с нуля хочется понять, о чём речь (причём в основе, а не на маленьком птичьем языке), придётся прочитать минимум Рождественскую системноинженерную сказку “Волшебный карандаш и V-модель” (https://sdu2020.blogspot.com/2018/12/v.html).
А потом уже огрызком пользоваться, понимая область применимости...

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

Дык прям на слайде - IEEE. Top Programming Languages 2025 (http://spectrum.ieee.org/top-programming-languages-2025)

Сри гёрлицы под виндом
Пряли поздно ивнингом.
Кабы я была квиница,
Фёст промолвила гёрлица,
Я б для фазэра кинга
супер сейшн собрала...

Вы против англицизмов?

Покопался в этимологических словарях и понял, что я перевёл бы
Coupling как соединенность/присоединенность,
Cohesion - как объединенность.

Но вместе с этим понял, почему медики используют латинскую терминологию, в химии есть июпак, а в физике — СИ.

[UPDARE]: еще хороший вариант перевода - обвязанность (гидравлике обычно используется термин "обвязка") / привязанность ("привязка" тоже широко используется) и связанность/увязанность.

@jadrovski нашёл смысловой перевод, руководствуясь соображениям первоисточника.

Cohesion однозначно переводится как "сплоченность".

Coupling пока не совсем ясно, но, наиболее подходящие кандидаты - это "сочленение" или "сопряжение".