2 ГЛАВА

Основні тези другої глави "Змінні":

Використовуйте осмислені назви змінних. Ім'я змінної повинне передавати її

призначення та використання. Назви змінних мають бути зрозумілими та короткими.

Уникайте назв змінних, які відрізняються лише регістром. Це може призвести до

плутанини та помилок.

Використовуйте змінні зі
зрозумілим контекстом. Наприклад, уникайте використання назв "i" або "j" в
масивах, де ці змінні використовуються для ітерації.

Уникайте змінних, які мають загальне значення. Якщо змінна

використовується в багатьох місцях програми, її значення може бути змінено в одному
місці, що призведе до помилок у всій програмі.

Використовуйте константи для значень, які не можуть змінюватися.

Наприклад, число Пі не змінюється, тому його можна визначити як константу.

Не використовуйте "магічні числа" у своїй програмі.

"Магічні числа" - це значення, які використовуються без пояснень або коментарів у
коді.
Краще визначати їх як константи з зрозумілими назвами.

Використовуйте змінні для полегшення зрозуміння складних виразів.

Якщо ви використовуєте складний вираз більше одного разу, легше зрозуміти код,
якщо ви визначите його як окрему змінну з осм

3 ГЛАВА

Основні тези третьої глави "Функції":

Функції повинні бути короткими та зосередженими на одній задачі.

Функція повинна робити тільки те, що передбачено в її імені, а не додаткові
операції.

Функції мають бути простими для розуміння та читання.

Коментарі мають використовуватися тільки тоді, коли неможливо зрозуміти функцію
без них.

Функції повинні бути максимально короткими. Доброю практикою є те, щоб функція
складалася не більше ніж з 20 рядків коду.

Функції повинні бути максимально спрощеними. Уникайте довгих циклів, складних

умовних операторів та глибоких вкладень.

Функції повинні бути максимально єдиною точкою входу

. Краще використовувати відокремлені функції для кожної операції, ніж створювати
складні умовні оператори та зациклення.

Функції мають повертати значення або змінювати стан програми, але не робити і те, і
те одночасно.

Функції повинні мати зрозумілі назви та вказувати на їх призначення.

Ім'я функції повинно передавати інформацію про те, що вона робить.
Функції повинні бути локальними, тобто їх використання має бути обмежене у межах
класу чи модуля.
Такі функції більш прості для тест

4 ГЛАВА

Основні тези четвертої глави "Коментарі до коду":

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

Коментарі мають бути написані грамотно та чітко. Вони повинні бути зрозумілі для
будь-якого розробника.

Уникайте написання зайвих коментарів. Наприклад, не потрібно коментувати імена

функцій або змінних, якщо вони вже мають зрозумілі назви.

Коментарі повинні бути оновлювані разом з кодом. Якщо ви внесли зміни в код,
перевірте, чи не потрібно оновити відповідний коментар.

Не використовуйте коментарі як заміну для поганого коду.

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

Коментарі можуть бути корисні для документування публічного API вашої бібліотеки
або програмного інтерфейсу.

Використовуйте коментарі для пояснення незрозумілих або нетипових використань

стандартних функцій.

Використовуйте коментарі для пояснення різних сценаріїв використання ваших функцій,

особливо якщо вони можуть викликати складність з розумінням.

В цілому, коментарі мають бути короткими, чіткими і зосередженими на по

5 ГЛАВА

Основні тези п'ятої глави "Форматування":

Форматування коду повинно бути чітким та легко зрозумілим.

Повинні використовуватись пробіли, відступи, інтервали та інші елементи
форматування, щоб зробити код більш читабельним.

Код повинен бути форматований відповідно до стандартів в компанії або проекті, або
використовувати відомі стильові конвенції,
такі як стиль "K&R" або "Allman".

Розмір рядків коду повинен бути обмеженим, ідеально - не більше 80 символів на

рядок. Це робить код більш читабельним,
особливо при використанні вузьких екранів або вікон.

Використовуйте відступи для показу блоків коду, таких як цикли, умови, функції,
класи та інші.
Це робить код більш читабельним і допомагає зрозуміти структуру коду.

Використовуйте правильні імена змінних та функцій. Це повинні бути зрозумілі та

легко згадувати назви, щоб код було легко читати.

Використовуйте правильні розміри та імена для коментарів. Коментарі повинні бути

короткими та зрозумілими.

Форматування коду повинно бути однорідним у всьому проекті. Він повинен бути
написаний у одному стилі, і уникати змішування стилів.
Використовуйте структуру функцій та класів, щоб зробити код більш читабельним та
зрозумілим.
Функції повинні бути короткими та робити лише одну річ,
тоді як класи повинні мати чіткий та зрозумілий інтерфейс та робити лише те, що
повинні робити.
У цій главі Роберт Мартін робить акцент на тому, що форматування коду - це не
просто питання естетики,
а суттєво впливає на розуміння та підтримку коду. Якщо код не читабельний, то його
важко підтримувати, тестувати та розширювати,
що може призвести до багатьох проблем у майбутньому.

6 гЛАВА

Об'єкти повинні мати чіткий та однозначний інтерфейс, який не допускає

двозначності. Інтерфейс повинен бути простим та
зрозумілим для користувачів.

Об'єкти повинні мати чітко визначену відповідальність та не повинні втручатися в

відповідальність інших об'єктів.

Об'єкти повинні бути пов'язані між собою на основі взаємодії та залежностей, а не

на основі даних.
Така побудова системи забезпечує більш гнучке та простіше розширення.

Об'єкти повинні бути створені на основі абстракцій, а не на основі конкретних

реалізацій.
Це дозволяє змінювати реалізацію об'єкта без зміни інтерфейсу та взаємодії з іншими
об'єктами.

Об'єкти повинні мати чітку структуру та не повинні бути занадто великими.

Великі об'єкти можуть стати складними для розуміння та підтримки.

У цій главі Роберт Мартін розглядає практичні приклади, щоб допомогти читачеві
зрозуміти,
як правильно побудувати об'єктно-орієнтований код та які підходи потрібно
використовувати для досягнення мети побудови чистого та
читабельного коду.

7 гЛАВА

Виняткові ситуації повинні бути використані лише в тих випадках, коли дійсно є
потреба в їхньому використанні
. Вони не повинні використовуватися як заміна умовних операцій.

Помилки повинні бути виявлені та оброблені якомога швидше, щоб уникнути поширення
помилки по системі.
Обробка помилок також повинна бути чіткою та зрозумілою для користувача.

Необхідно розробляти плани відновлення в разі виникнення помилок, щоб відновити

роботу системи якомога швидше та з мінімальним втручанням.

Обробка помилок повинна бути розумною та ефективною. Не слід зловживати

виключеннями та винятками,
оскільки це може призвести до складнощів в обробці та підтримці коду.

Необхідно використовувати логування для відстеження помилок та відновлення

працездатності системи.
Логи повинні бути структуровані та зрозумілі для користувачів.

У цій главі Роберт Мартін розглядає практичні приклади та наводить поради щодо
того,
як правильно обробляти помилки та виняткові ситуації у програмному забезпеченні,
щоб забезпечити його стабільність та працездатність

8 ГЛАВА.

Я переперевірив, і ви праві - восьма глава книги "Чистий код" дійсно називається

"Границі" (Boundaries).
В цій главі Роберт Мартін описує, як розуміти та розмежовувати зони впливу
(boundaries) між різними компонентами програми
, а також як взаємодіяти з зовнішніми системами та компонентами. Він наводить
приклади і рекомендації щодо керування залежностями
від зовнішніх систем та меж відповідальності різних компонентів програми.
Відділення коду від зовнішніх систем і компонентів за допомогою абстракцій.

Використання інтерфейсів для взаємодії з зовнішніми системами, замість прямого

доступу до них.

Використання "Adapter pattern" та "Facade pattern" для розширення або спрощення

взаємодії з зовнішніми системами.

Використання тестування з імітацією (mocking) зовнішніх систем та компонентів для

покращення тестування та відлагодження коду.

Розділення коду на рівні модулів, які відповідають різним межам взаємодії з

зовнішніми системами та компонентами.

Використання принципу "Dependency Inversion" для зниження залежностей від зовнішніх

систем та компонентів.

9 ГЛАВА

Модульні тести повинні бути простими і швидкими для запуску, щоб їх можна було
виконувати дуже часто.

Тести повинні бути автоматизованими і повністю незалежними від інших тестів.

Модульні тести повинні бути написані перед кодом, який вони тестують, і повинні
бути повністю автоматизовані.
Тести повинні перевіряти одну конкретну функцію або метод, і повинні бути
незалежними від зовнішніх ресурсів,
таких як бази даних чи мережеві послуги.

Для тестування слід використовувати тестові фреймворки, які дозволяють легко

створювати, запускати та аналізувати результати тестів.

Код повинен бути розроблений таким чином, щоб його можна було легко тестувати,
включаючи використання залежностей, інтерфейсів та моків.

Розробник повинен дотримуватися правила "Arrange, Act, Assert" (підготовка,

виконання, перевірка) при написанні тестів.

Модульні тести повинні перевіряти не лише очевидні сценарії, але й різні граничні
умови, помилки та виключні ситуації.

10 ГЛАВА

Клас повинен бути невеликим, з однією чіткою відповідальністю.

Клас повинен мати явний інтерфейс, який дозволяє користувачам класу легко розуміти,
як його використовувати.

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

Клас повинен мати високий рівень співвідношення між простотою та загальною

функціональністю.

Клас повинен бути легко тестованим, з можливістю мокування залежностей та

інтерфейсів.

Назви класів повинні бути чіткими, короткими та зрозумілими, відображаючи сутність

класу.

Код класу повинен бути написаний у зрозумілому та однорідному стилі, з чіткими

коментарями та відформатованим відповідно до конвенцій.

Клас повинен бути розроблений з можливістю розширення, з використанням принципу

відкритості-закритості.

Клас повинен бути розроблений з урахуванням принципу однієї відповідальності, тобто

один клас повинен виконувати одну конкретну функцію.

Клас повинен бути розроблений з урахуванням принципу підстановки Барбари Лісков,

тобто заміна об'єкту підкласом повинна
не мати впливу на коректність роботи системи.

11 ГЛАВА

Система повинна бути побудована з компонентів, які є самодостатніми та можуть

працювати відокремлено.

Компоненти системи повинні мати мінімальну залежність один від одного.

Архітектура системи повинна бути легко зрозумілою, з чітко визначеними рівнями та

інтерфейсами.

Код системи повинен бути написаний у зрозумілому та однорідному стилі, з чіткими

коментарями
та відформатованим відповідно до конвенцій.

Система повинна бути розроблена з урахуванням принципу розділення відповідальності,

тобто кожен
компонент повинен виконувати конкретну функцію.

Система повинна бути легко тестована, з можливістю мокування залежностей та

інтерфейсів.

Система повинна бути розроблена з урахуванням принципу відкритості-закритості,

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

Система повинна бути розроблена з урахуванням принципу підстановки Барбари Лісков,

тобто заміна
об'єкту підкласом не повинна мати впливу на коректність роботи системи.

Система повинна бути легко підтримуваною, з можливістю швидкого виявлення та

виправлення помилок.

Система повинна бути легко масштабованою, з можливістю додавання нових компонентів

без зміни існуючого коду.

12 ГЛАВА

Головна ідея 12-ї глави книги "Чистий код" полягає в тому,

що розробка чистої архітектури повинна бути метою у всіх проектах програмного
забезпечення. Архітектура повинна дозволяти підтримувати систему протягом довгого
часу,
розширювати її та збільшувати її масштаби без значних зусиль.

Для досягнення цього автор рекомендує використовувати принципи SOLID,

що допомагають створювати модульний, легко зрозумілий та розширюваний код.
Також, автор наголошує на важливості збереження розумного балансу між простотою та
загальною архітектурою.

Далі, автор розглядає вплив зовнішніх факторів, таких як технічна заборгованість,

рівень кваліфікації команди, відносини з замовником тощо, на процес розробки
архітектури та висуває
рекомендації щодо керування цими факторами для забезпечення високої якості
архітектури.

Крім того, автор надає поради щодо визначення головних абстракцій, що лежать в
основі архітектури,
та висуває концепцію "гексагональної архітектури", яка дозволяє максимально
розширювати систему без необхідності змінювати її ядро.

Крім того, автор обговорює різні способи формування архітектури, такі як підхід
"знизу вгору"
та підхід "зверху вниз", та вказує на переваги та недоліки кожного з них.
Ось кожен з принципів SOLID:

Single Responsibility Principle (Принцип єдиної відповідальності) - клас повинен

мати тільки одну
причину для зміни. Це означає, що кожен клас повинен виконувати тільки одну функцію
або роль.

Open/Closed Principle (Принцип відкритості/закритості) - програмні зміни повинні

бути виконані
за допомогою додавання нового коду, а не зміни існуючого. Це означає, що класи та
методи повинні бути відкритими для розширення
, але закритими для зміни.

Liskov Substitution Principle (Принцип підстановки Лісков) - класи повинні бути

заміненні своїми підкласами без
зміни коректності програми. Це означає, що нащадки класів повинні мати здатність
замінити своїх батьків без впливу на коректність
програми.

Interface Segregation Principle (Принцип розділення інтерфейсу) - клієнти не

повинні з
алежати від інтерфейсів, які вони не використовують. Це означає, що інтерфейси
повинні бути зручними
та зрозумілими для користувачів, та містити тільки необхідні методи.

Принцип інверсії залежності (Dependency Inversion Principle, DIP) -

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

13 ГЛАВА

У програмуванні поток (thread) - це легковажний процес,

який виконується незалежно від основного процесу програми.
Потоки використовуються для паралельної обробки завдань та забезпечення більш
ефективного використання ресурсів комп'ютера.

У багатопоточних програмах зазвичай є кілька потоків, кожен з яких може виконувати

свої власні завдання.
Наприклад, веб-браузер може мати окремі потоки для завантаження зображень, скриптів
та інших елементів сторінки.

Основна перевага використання потоків полягає в тому, що вони дозволяють програмі

виконувати кілька завдань одночасно,
що забезпечує більш ефективну роботу програми та більш швидку обробку даних.

Однак, необережне використання потоків може призвести до складнощів, таких як гонки

за даними (race conditions)
та блокування (deadlocks). Тому важливо добре розуміти, як потоки працюють та як
їх слід використовувати в програмах.

....
Не довіряйте потокозахищеність: Не припускайте, що дані та код, що працює в одному
потоці, буде безпечним у відношенні до інших потоків.
Ізоляція інформації та взаємодія потоків повинні бути ретельно продумані.
Синхронізація: Використовуйте механізми синхронізації, такі як блокування (locks)
та семафори (semaphores),
для координації доступу до ресурсів між потоками. Але будьте уважні, щоб уникнути
блокування та голодування потоків.

Розподілені алгоритми: Для підвищення продуктивності деякі алгоритми можна

розподілити між декількома потоками.
Однак, не завжди є доцільним робити це через збільшення складності коду та
зменшення його зрозумілості.

Захист від дедлока: Дедлок - це ситуація, коли два або більше потоків блокують один
одного та не можуть продовжити виконання.
Для запобігання дедлокам можна використовувати порядок блокування (lock ordering)
та ієрархію блокування (lock hierarchy).

Потокова безпека: Визначте, які ресурси мають потокову безпеку та як їх

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

Загалом, многопоточність - це складна тема, яка потребує уважного планування та

дослідження.

14 ГЛАВА

Головна ідея полягає в тому, що під час написання коду не завжди вдається одразу
створити ідеальну структуру, тому код потребує поступового поліпшення. Для цього
потрібно використовувати різноманітні
техніки рефакторингу, щоб покращувати код без зміни його зовнішньої поведінки.

Автор наголошує на тому, що маленькі інкрементальні зміни, зроблені на ранніх

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

Також автор пропонує кілька рекомендацій щодо того, як ефективно використовувати

техніку послідовного очищення:

Спочатку зробіть код працюючим, а потім вдосконалюйте його.

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

17 ГЛАВА

Розділ 17 книги "Чистий код" Роберта Мартіна торкається питань "запахів коду" -
технологічних боргів і проблем, що накопичуються в процесі розробки програмного
забезпечення,
а також евристичних правил, які допомагають запобігти та усунути такі проблеми.

Автор визначає запах коду як ознаку коду, який може вказувати на наявність
технічного обов'язку.
Запахи коду можуть бути викликані різними факторами, такими як поганий дизайн,
відсутність модульності, невідповідність угод тощо.

Мартін представляє набір евристичних правил для запобігання та усунення запахів

коду.