Довідник корисних принципів, правил, законів та концепцій, які допомагають розуміти закономірності, приймати рішення та ефективно вирішувати практичні завдання. У цьому розділі зібн відомі та придатні на практиці ідеї з розробки, тестування, управління, продуктивності та інших галузей.
Когнітивні викривлення та принципи мислення
| Назва | Альтернативна назва | Правило / принцип | Опис |
|---|---|---|---|
| Принцип Парето | Принцип 80/20, Закон значущої меншості | 20% зусиль або причин дають 80% результату або наслідків | Невелика частина дій приносить більшість успіху, тоді як інші зусилля дають лише малий ефект. Цифри 80 і 20 умовні, вони слугують зручним орієнтиром, а не жорстким математичним законом. |
| Закон Мерфі | Закон підлості, Закон хронічного недовіри | Все, що може піти не так, піде не так | Якщо існує можливість вчинення помилки, вона обов'язково трапиться. Цей закон нагадує про необхідність ретельного планування та створення резервних варіантів дій для мінімізації ризиків. |
| Принцип Пітера | Принцип кар'єрного зростання | Люди мають тенденцію займати посаду, вищу за їхню компетентність | В ієрархічній організації кожен працівник прагне до підвищення. Згодом кожен співробітник досягне свого "некомпетентного" рівня — рівня, на якому вже не може ефективно працювати. Внаслідок посади часто займають некомпетентні фахівці. |
| Бритва Оккама | Принцип економії мислення, Закон простоти | Не слід множити сутності без необхідності (Entia non sunt multiplicanda praeter necessitatem) | З кількох можливих пояснень даних фактів слід обрати найпростіше. Чим менше припущень — тим надійніший висновок. Цей принцип лежить в основі наукового методу та ефективної відладки. Див. також: Бритва Кванти. |
| Ефект Даннінга — Крюгера | Ефект перевалу дурості, Синдрм самовпевненого новачка | Люди з низькою компетентністю схильні переоцінювати свої здібності | Некомпетентні люди не здатні усвідомити свою некомпетентність. Чим більше людина знає, тим краще вона розуміє межі своїх знань. І навпаки — новачок часто вважає себе експертом через відсутність метакогнітивних навичок. |
| Закон Гудхарта | Проблема індикаторів, Закон підміни цілей | Коли міра стає метою, вона перестає бути хорошою мірою | Щойно показник (KPI) стає ціллю для досягнення, він перестає бути надійним індикатором реального стану справ. Люди починають оптимізувати метрику, а не реальний результат, що призводить до викривлень та маніпуляцій. |
| Бритва Кванти | Бритва скептиків, Принцип достатнього доказу | Сила твердження пропорційна силі доказів. "Надзвичайні твердження вимагають надзвичайних доказів" | Карл Саган: якщо хтось стверджує щось надприродне — тягар доказування лежить на ньому. В розробці: новий фреймворк "революційний" — покажіть бенчмарки та міграційні кейси. Див. також: Бритва Оккама. |
Продуктивність та управління часом
| Назва | Альтернативна назва | Правило / принцип | Опис |
|---|---|---|---|
| Закон Паркінсона | Закон розширення задач, Закон роздування термінів | Розтягується до часу відведеного на неї | Скільки б часу не було виділено на задачу, вона займе все це час. Якщо на проект дано місяць — він буде робитися місяць. Якщо рік — буде робитися рік. Контроль строків та жорсткі дедлайни — ключ до ефективної роботи. |
| Принцип Хофштадтера | Закон Хофштадтера, Закон многократно помилкового планування | Робота завжди займає більше часу, ніж очікується, навіть з урахуванням закону Хофштадтера | При плануванні строків практично неможливо коректно оцінити складність задачі, особливо на останніх етапах. Завжди слід додавати суттєвий запас часу до будь-якої оцінки, оскільки неминуче виникнуть непередбачувані труднощі. |
| Закон Деккі | Лінійний закон часу, Закон 50% | Якщо задача вже зайняла половину відведеного часу, вона займе подвоєний залишок часу | Еволюція закону Хофштадтера. Якщо ви витратили половину передбачуваного часу на півшляху до мети — ви будете працювати удвічі довше запланованого. Допомагає своєчасно коригувати очікування та строки. |
| Матриця Ейзенхауера | Матриця пріоритетів, Розділення задач | Розподіляй задачі по 4 квадрантах: важливе/термінове — неважливе / не термінове | Квадрант I: зробити зараз. II: запланувати. III: делегувати. IV: видалити. Критичний інструмент для боротьби з "пожежами" замість стратегічної роботи. |
| Принцип 1–3–5 | Правило планування дня, Метод пріоритизації дня | В день: 1 велика + 3 середніх + 5 малих задач | Реалістичний ліміт продуктивності: за день реально зробити лише ~9 задач, якщо їх ранжувати за складністю. Запобігає перевантаженню та вигоранню. |
| Ефект Цейгарник | Ефект незавершених дій, Закон незакритих циклів | Незавершені задачі запам'ятовуються краще завершені | Мозка "зависає" на відкритих циклах. Рішення: записуй все, декомпізуй, закривай. Використовується в трекерах задач та GTD-методології для зниження тривожності. |
| Law of the Last Responsible Moment | Закон останнього відповідального моменту, Принцип максимуму відкладання | Не приймай рішення раніше часу — інформація з часом стає ціннішою | Ранні фіксують варіанти та блокують гнучкість. Відкладання до останнього можливого моменту зберігає максимум альтернатив. Основа Agile та Lean. |
Програмування та розробка
| Назва | Альтернативна назва | Правило / принцип | Опис |
|---|---|---|---|
| Принцип KISS | Keep It Simple, Stupid; Будь простіше | Стремись до максимальної простоти в рішеннях та дизайні | Більшість систем працюють найкраще, якщо вони прості. Не слід ускладнювати там, де можна зробити простіше. Прості системи легше підтримувати, відлагоджувати та масштабувати. Див. також: YAGNI. |
| DRY (Don't Repeat Yourself) | Не повторюйся, Принцип єдиного абстрактного представлення | Кожна частина коду має мати одне і єдине представлення | Будь-яка знання або логіка в системі повинні бути представлені однократно. Повторюваний код призводить до розсинхронізації, багів та труднощів підтримки. Виноси загальну логіку в функції, модулі або бібліотеки. Див. також: Boy Scout Rule. |
| YAGNI (You Ain't Gonna Need It) | Ти цього не будеш використовувати, Принцип відмови від прогнозів | Не додавай функціональність, поки вона реально не знадобилася | Завжди реалізуй те, що потрібно в даний момент — і нічого більше. Передбачення про майбутні потреби майже завжди помилкові, а передчасна оптимізація ускладнює код та уповільнює розробку. Див. також: KISS. |
| Принцип найменшого здивування | Principle of Least Astonishment (POLA), Закон очікуваності | Поведінка системи повинна відповідати очікуванням користувача | API, інтерфейс або код повинні поводитися так, щоб це було максимально передбачувано та інтуїтивно зрозуміло. Якщо функціональність поводиться неочікувано — це погано спроектована система, незалежно від її потужності. |
| Boy Scout Rule | Правило скаутів, Принцип очищення | Залишай код чистішим, ніж ти його знайшов. Кожна зміна — міні-рефакторинг | Щоразу, коли вносиш правку, покращ Surroundiding-код: убери дублі, перейменуй, спрости. Накопичувальний ефект — вічний рефакторинг без окремої фази. Див. також: DRY. |
| Закон Ділберта | Закон накопичення проблем, Ефект Матрьошки | Кількість накопичених проблем росте пропорційно до кількості людей, що вирішують ці проблеми | Більше учасників = більше рішень = більше побічні ефекти та нові проблеми. Масштабування команди без синхронізації погіршує систему. |
| Test Pyramid (Майк Кон) | Принцип піраміди тестів, Ієрархія тестування | Чим нижчий рівень тесту — тим більше їх має бути; E2E-тести — вершина піраміди, дуже мало | Баланс: багато юніт-тестів → середня кількість інтеграційних → мінімум E2E. Швидкий зворотній зв'язок на низькому рівні запобігає дорогостоячим регресіям. |
| Broken Windows Theory (в розробці) | Теорія розбитих вікон, Ефект деградації коду | Ознаки деградації залучають нові ознаки; маленькі "баги" ведуть до системного занепаду | Прогнилі вікна в будівлі сигналізують: тут нікому нема діла. В коді: не зачищені TODO, погані імена, дублі — все це знижує стандарт команди та прискорює деградацію. |
Архітектура та проектування
| Назва | Альтернативна назва | Правило / принцип | Опис |
|---|---|---|---|
| Закон Фолкса | Закон необхідності, Формула Фолкса | Не обирай рішення, поки не вивчиш усі існуючі альтернативи. "Перед вибором інструменту відмови — вивчи все, що вже написано" | Найвідоміший закон в розробці ПЗ: перед написанням свого рішення, перевір — чи немає вже готового. Пов'язаний з принципом "не винаходь велосипед". |
| Закон Хаммера | Закон інструменту, Ефект молотка | Для кожної проблемної точки світу залишається достатньо молотка. "Якщо у тебе є молоток — кожна проблема виглядає як цвях" | Схильність бачити всі проблеми через призму звичних інструментів та методів. Проводить до субоптимальних рішень: програміст намагається "закодити" те, що вирішується процесом або комунікацією. |
| Закон Геммона | Закон прискорення, Втікаючий рубеж | Коли продуктивність об'єкта збільшується — потреба в об'єктах зростає, зводячи наніто очікуваний ефект підвищення ефективності | Автоматизація одного процесу без оптимізації інших створює "вузьке горлечко" elsewhere. Масштабування окремих елементів без системи дає лише ілюзію покращення. |
| Теорема Конвея | Закон відповідності архітектури, Обратна теорема Конвея | Організація, що проектує систему, зобов'язана пройти структуру, яка її відтворює. "Комунікаційні структури диктують структуру коду" | Архітектура продукту дзеркально відображає архітектуру команди. Якщо команди розділені — і код буде монолітом з silos. Для мікросервісів потрібні кросс-функціональні команди. Див. також: Закон Конвея. |
| Закон деметера (LoD) | Принцип найменшого знання, Закон малоеформованості | "Тільки розмовляй зі своїми безпосередніми друзями" — не звертайся до проміжних членів внутрішніх модулів інших об'єктів | Мінімізація пов'язаності: об'єкт має знати лише про свої безпосередні залежності. Зменшує крихкість та спрощує рефакторинг. |
Управління та організація
| Назва | Альтернативна назва | Правило / принцип | Опис |
|---|---|---|---|
| Закон Конвея | Конвергенція архітектури та організації, Закон комунікаційних структур | Системи проектування не уникають комунікаційних структур організацій | Архітектура ПЗ напряму відображає структуру команди, яка його створює. Щоб покращити архітектуру системи, часто необхідно перестроїти комунікаційні потоки всередині команди. Розділили команду — розділили і систему. Див. також: Теорема Конвея. |
| Принцип Діогена | Не чіпай працююче, Закон невтручання | Якщо працює — не виправляй (If it works, don't fix it) | Існуюча працююча система є кращим рішенням, ніж потенційно краща, але нереалізована. Будь-яка зміна несе ризики та витрати — вони мають бути строго обґрунтовані вимірюваною користю. |
| Закон Рікрофта | Закон взаємних аргументів, Закон контраргументації | Будь-яке гучне твердження має рівний йому по силі контраргумент | В будь-якій суперечці або обговоренні можна знайти як прихильників, так і противників практично будь-якої точки зору. Це не означає, що всі думки рівнозначні — але важливо шукати аргументи за і проти для формування зваженого судження. |
| Правило двох піц (Amazon) | Оптимальний розмір команди, Закон Джефа Безоса | Команда повинна з'їсти дві піци — не більше ~8 людей. Більше — надто багато комунікації | 9 людей = 36 можливих зв'язків. Ефективна команда — 5–8 людей. Для масштабування: розбивай на кілька автономних команд з чіткими API-контрактами. Пов'язаний з теоремою Конвея. |
| Закон Шентона | Закон сумісності команд, Принцип розподілу задач | Задачі повинні розподілятися по команді пропорційно до їхньої здатності вирішувати ці задачі | Якщо одна команда бере на себе надто багато — вона стає вузьким горлечком. Розподіляй навантаження, враховуючи експертизу та завантаження. Інакше — перевантаження лідерів + простій решти. |
Загальні принципи та ефекти
| Назва | Альтернативна назва | Правило / принцип | Опис |
|---|---|---|---|
| Ефект плацебо | Обернене плацебо, Ефект ілюзії корисності | Віра в ефективність впливу може викликати реальний фізіологічний або психологічний результат | Якщо людина вірить, що отримує допомогу — вона з більшою ймовірністю допоможе. Обернений ефект (ноцебо) — очікування негативу може погіршити симптоми навіть при без шкідливому впливі. Вплив сильний в проектах: "рецепт працював у всіх" часто допомагає і на твоєму проекті. |
| Ефект Бербона | Закон деградації інтерфейсів, Парадокс покращень | Користувачі не приймають покращення системи, якщо вони змінюють звичний інтерфейс | Чим краще стає система з точки зору розробника — тим менше користувачі готові її використовувати, якщо це порушує їхні усталені звички. Зміни потрібно впроваджувати поступово, зберігаючи зворотну сумісність та інтуїтивність. |
| Ефект ореола (Гало) | Гало-ефект, Ефект сяючого ореола | Загальне враження про людину або продукт спотворює оцінку їхніх окремих якостей | Якщо об'єкт сприймається позитивно в цілому, ми схильні переоцінювати і всі його властивості — навіть ті, які не перевірили. В розробці: красивий UI змушує вірити в якість "під капотом", що може бути оманливим. |
| Ефект обрамлення | Фреймінг-ефект, Ефект контексту подачі | Одне і те саме зміст сприймається по-різному в залежності від способу подачі | "95% без жиру" звучить краще, ніж "5% жиру". Один і той же код, описаний як "рішення проблеми" або "додаткова функція", отримує різну реакцію команди. Контекст та формулювання критично важливі при комунікації. |
| Ефект якоря | Ефект прив'язки, Anker-Effekt | Перша отримана інформація суттєво впливає на наступні рішення та оцінки | Початкова цифра або факт служать "якорем", до якого потім адаптуються всі наступні судження. В переговорах перший озвучений номер часто стає базою для угоди. В розробці: початковий план проекту задає тон всім подальшим оцінкам. |
| Фундаментальна помилка атрибуції | Ефект відповідності, Гіпотеза відповідності | Схильність пояснювати поведінку інших внутрішніми якістю, ігноруючи зовнішні обставини | Якщо колега запізнився — ми думаємо: "він безвідповідальний". Якщо запізнилися ми — "пробки були". Ми переоцінюємо характер людини та недооцінюємо вплив ситуації. Веде до конфліктів в командах та хибних висновків про причини проблем. |