Чистий код: 3 основні принципи

Чистий код — це код, над яким ретельно попрацювали. Хтось не пошкодував часу, щоб зробити його простим і чітким. Хтось приділив належну увагу всім дрібницям і поставився до коду з душею.
— Роберт Сесіл Мартін

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

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

В цій статті я поділюсь своїм баченням чистого коду, яке в мене сформувалось після прочитання книги “Чистий код” Роберта Мартіна та використання описаних в ній принципів на практиці в декількох компаніях, на різних проектах та у різних командах.

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

Назви

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

Можна сказати, що на гарних назвах базуються принципи чистого коду.

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

• Хороша назва завжди коротко і ясно передає суть того, що зберігає змінна або що робить метод.
• В цьому нам може допомогти принцип всюдисущої мови (Ubiquitous language). Він не рідко з’являться в різних книгах та статтях та всі вони доносять одну й ту саму думку — інженери мають спілкуватись з бізнесом однією мовою, як в коді так і під час спілкування.
• Не слід використовувати синоніми. Бізнес часто називає одні й ті самі речі по-різному, але ми маємо обрати для себе один термін й зажди оперувати тільки ним, в тому числі під час спілкування.
• Краще уникати дублювання контексту у назвах, й навпаки — слід додавати контекст там, де його замало. Наприклад, по назві класа зрозуміло, до якої сутності відноситься поле, тому не потрібно дублювати назву класа в назві поля.

Методи

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

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

• Не слід робити методи довгими, в ідеалі вони мають поміщатись в один екран.
• Метод має одну причину для зміни (SRP), рівні абстракції не змішуються. Типовий приклад: сервіс реалізує бізнес-логіку, репозиторій — деталі роботи зі сховищем даних.
• Не робить неочікуваних дій. Наприклад, метод на отримання даних не має ці дані модифікувати в сховищі. Також це стосується назви — вона має описувати все, що робить метод.
• Прапорці з типом boolean — це сигнал, що метод слід розділити на два.
• Бізнес-логіка не має дублюватись (DRY) — її обов’язково потрібно перевикористовувати.

Тести

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

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

• Test-driven Development є невід’ємною частиною чистого коду. Тести мають бути написані до реалізації, а не колись потім.

Закон Леблана: потім означає ніколи

• TDD допомагає подивитись на функціонал, який ми розроблюємо, з точки зору користувача. Навіть якщо це консольна команда або API ендпоінт.
• Рефакторинг без тестів неможливий. Розробники бояться змінювати код, не знаючи як його потім перевірити та на що він може повпливати. Тести забирають цей страх.

Інші принципи описані в книзі також важливі і я притримуюсь їх в своїй практиці. Наприклад, завжди видаляю недоречні коментарі з коду та притримуюсь The Boy Scout Rule, виправляючи код, з яким стикаюсь в рамках задачі.

Але про це іншим разом.

Замість висновків: