Філіпп Кучерявенко, PHP developer.
Олександр Дробот, JS developer в IT-команді NIX.
«Чистий» код – насамперед читабельний. У ньому все логічно: від назв змінних і функцій до розташування файлів. Ця властивість дозволяє зрозуміти навіть найскладніший код, а значить і підтримувати його буде простіше.
Надалі з кодом матимуть справу один чи кілька розробників. Це може бути легасі-код, який «успадкує» інша команда. Або до роботи з власним кодом повернеться той же розробник. Наприклад, для інтеграції нової фічі. І до того моменту він вже міг забути, що там робив і навіщо.
«Чистота» коду важлива, та чи можна інколи поступитися принципам? Так!
• Коли треба розробити швидке рішення
Інколи немає часу на оптимізацію коду: потрібен хотфікс на проді чи простий Proof of Concept. Все-таки робочий код ліпший за гарний, тож у розумних межах можна поступитися принципами.
Обговоріть у команді невідкладність задачі, щоб показати переваги та недоліки обох рішень. Порахуйте естімейти та визначте технічний борг, який залишиться після «швидкого» коду.
- Коли маєте справу із незрозумілим рішенням
У деяких ситуаціях написаний за всіма канонами «чистий» код може виглядати незрозуміло. Ніби все коректно, без полотна рядків, але технологія незнайома більшості ваших колег. Тоді не гріх буде написати розгорнутіше, щоб інше не викликало ще більше питань.
Це рішення все одно слід проговорити з командою: безпосередньо у процесі роботи, в коментарях під час код рев’ю або після завершення спринта в контексті техборгу. Так ви поділитеся з колегами нестандартною ідеєю. Водночас вони зможуть запропонувати свій варіант.
- Коли рішення працює повільно
В окремих проєктах спрощення може призвести до падіння перфомансу. Можна написати код на кілька рядків, де відбуватиметься обробка циклу в циклі і в циклі. Зазвичай це не проблема. Але в масштабах Big Data проєктів така кількість ітерацій шкодить ефективності рішення.
Краще написати один цикл, що покриватиме всі задачі. Спершу це виглядатиме складно, але згодом швидкість зросте у рази. Не забудьте додати коментар у коді, чому зробили саме так, щоб інший розробник не зніс ваш «брудний» код і не «поклав» усю систему.
Початківцю варто відразу привчатися писати чисто. Тоді навіть швидкі рішення ви не зможете зробити погано. Все буде більш-менш структуровано, зі зрозумілим неймінгом.
Перелічені вище випадки не дозволяють писати «брудно», йдеться про певні послаблення. Базові ж речі обов’язкові, щоб і за 2 роки потому ви розуміли свій код.
«Чистий» код – основні принципи
Лаконічному коду присвячено чимало книг. Можна відшукати й короткі огляди з базовими правилами про форматування, коментарі тощо.
Головне – пам’ятайте, що ви пишете код не для машини, а для людей. Спираючись на цей підхід, вам буде простіше «очищувати» код від зайвого.
Щодо більш прикладних принципів, то важливі такі з них:
1. Використовуйте зрозумілі назви
З назви функції чи класу має бути очевидно, для чого вони. Наприклад, «Знижка постійного клієнта» або «Надсилання email про замовлення». Не слід назвати просто «А» чи «Знижка». Програма не працюватиме повільніше від того, що в назві три слова. Навпаки – повна назва допоможе розробникам.
Функція може бути частиною класу, і якщо назва незрозуміла, девелоперу доведеться заходити всередину і дізнаватися, що там відбувається.
Інколи початківці пишуть занадто довгу назву, бо функція і знижку рахує, і до бази звертається, і повідомлення відправляє. Тут діє базове правило «одна функція – одна фіча».
Проблема неймінгу вказує на проблему розділення коду. Деякі новачки вказують щось одне, але це теж неправильно. Функція має робити лише те, що зазначено в назві. Наприклад, надсилати email та повідомлення в Telegram. Тому якщо назвати її «Надсилання email», нікому й на думку не спаде про зв'язок із месенджером. Тому, якщо хтось із колег видалить цю функцію, програма перестане надсилати повідомлення ще й у Telegram.
2. Скорочуйте обсяг коду
Велика кількість рядків зазвичай є там, де клас (наприклад, контролер із MVC) виконує забагато завдань. Наприклад, в одному блоці оброблюються запити, виконується перевірка та відбувається звернення до бази даних.
Краще ділити код на логічні блоки (про це поговоримо далі). Але й в окремих блоках слід подумати про скорочення кількості коду. Звісно, 100 рядків можуть працювати не гірше за 30, але читати такий масив важче.
Є рішення – напишіть вкладену функцію в функції, щоб блок займав менше місця на екрані. Зробіть стовпчиком кілька викликів функції, запишіть результат їх виклику у змінні та використовуйте їх.
Рядків стане трохи більше, але зрозумілість коду від того лише поліпшиться. Зрештою ви ж пишете не для мікроконтролерів, а створюєте прикладні програми та вебсервіси.
3. Розділяйте код на логічні блоки
Якісний код нагадує Lego: велика складна річ створена з маленьких простих «цеглинок». А код, який використовується разом, розміщуєте поруч. Тоді розробникам легко роздивитися як окремі блоки, так і весь алгоритм. Найпростіший шлях до цього – кожна частина коду виконує окрему задачу.
Блоки не мають бути надмірно пов’язані один з одним. Часто дві функції використовують одна одну, але логіка в нижньому рівні спирається на верхню. Формально це різні юніти, але їх неможливо роз’єднати чи змінити без переписування всього ланцюга. А це заважатиме масштабуванню системи.
Найкращий код можна видалити без модифікації пів системи. Такий собі side effect «чистоти» коду. Інколи розробники намагаються передбачити розвиток проєкту та ускладнюють зв’язки, але насправді це зайве. Зазвичай командам складно вгадати нові ідеї замовника чи продукт оунера. Краще писати рішення чітко, без «вангування».
4. Не дублюйте
Класичний принцип – Don’t Repeat Yourself (DRY). Початківці полюбляють перевикористовувати все, що тільки можна. Це не дуже погано, але є одне «але».
Принцип DRY говорить не стільки про рядки, скільки про бізнес-ідею, логіку. Наприклад, є функція для розрахунку 5% від числа – для знижки на товари. Перед вами може постати задача зробити нарахування 5% для збільшення ціни з доставкою. Уже хочеться використати код функції в обох випадках, та це буде помилка. Ви поєднаєте різні задачі. І якщо знадобиться змінити розмір знижки, доведеться окремо змінювати блок із розрахунком ціни з доставкою. Тому для різних задач і код має бути різним.
5. Коментуйте зміни у коді
Зараз усе частіше говорять: хороший код не потребує коментарів. Дійсно, досвідчений розробник може легко зрозуміти з читабельного коду, що виконує кожен юніт. Коментарі до очевидного зайві й тільки «забруднюють» код. Початківці ж часто пишуть коментарі, дублюючи назву функції, що не має сенсу.
Коменти необхідні в таких випадках:
- Якщо в коді є невідомі чи неочевидні нюанси, про які варто повідомити новачку в команді. Наприклад, можна написати, що «тут використано таку-то технологію, тому що є зав’язка на такий-то модуль, який неможливо змінити». Або простіше: «Не видаляй цей клас, бо одне й інше впаде».
- Як нагадування про необхідність змін у форматі To-do. Наприклад, у вас немає часу реалізувати інноваційне рішення. Тож пишете так, щоб усе працювало. Далі додаєте коментар як нагадування про зміни певної частини коду під час рефакторингу.
6. Дотримуйтеся єдиного кодстайлу
Усі на проєкті мають слідувати заздалегідь визначеному кодстайлу. Це набір правил, як ви оформлюєте код. Йдеться про вигляд, стилістику, а не про архітектуру.
Кодстайл визначає, де ставити пробіл чи додавати в кінці крапку з комою, коли починати новий рядок тощо. Для кожної мови програмування існує безліч кодстайлів.
Розробник може обрати комфортний і зрозумілий для себе кодстайл. Та якщо на проєкті кожен буде оформлювати код, як йому заманеться, то почнеться хаос, що погіршить читабельність. Тому приєднавшись до проєкту, дізнайтесь, які в команді правила, і спершу слідуйте їм, навіть якщо для вас вони не оптимальні. Згодом запропонуйте, що і чому доцільно оптимізувати.
7. Орієнтуйтесь на SOLID
Що на бекенді, що на фронтенді писати «чистий» код допомагає SOLID – принципи об'єктно-орієнтованого програмування і проєктування. Буває важко відразу їх зрозуміти, якщо пишете код з нуля. Під час переписування чужого коду ви краще зрозумієте правила SOLID та побачите їх взаємозв’язок.
Насправді SOLID – це не тільки про «чистоту» коду. Завдяки цим принципам код стає придатним до перевикористання і легко масштабованим.
Не забувайте і про об’єктність програмування. Думайте об’єктно: у вас є об’єкт із певним станом та зовнішніми інтерфейсами, які змінюють цей стан. Так ви бачитимете головне в коді й не будете його навантажувати зайвим.
SOLID має концепт, який працює не лише в розробці, – Single responsibility. Тобто один клас, компонент чи метод виконує одну задачу. В житті так само: виделка виконує лише свою задачу. Якщо зрозуміти це на такому рівні, то і дотримуватися цих принципів легше, і код стає читабельним.
Чи можна навчитися «чистоти» коду на чужих прикладах?
В цілому ви можете перейняти досвід колег, однак на більшості проєктів код не такий вже й «чистий». Часом якийсь блок писали з обмеженими ресурсами, а модуль – просто вставили як хотфікс і записали до техборгу, а про якийсь ще шматок коду взагалі ніхто нічого не знає, бо його 5 років тому створила інша команда, а нині всі бояться його чіпати. Тож при вивченні чужого коду розвивайте критичне мислення і міркуйте, як би ви могли спростити той чи інший елемент.
Якщо щось здається вам нечитабельним, з’ясуйте причину:
- Розпитайте керівників команди чи колег. Інколи поява неоптимального коду може бути викликана чимось, на що ви не вплинете.
- Зверніться до системи контролю версій. Дізнайтеся, як і коли код став «брудним», хто його писав, які таски та пул реквести передували цьому. Не бійтесь працювати з легасі! В реальності саме легасі-код заробляє гроші. Новачки часто мріють про проєкт із нуля, щоб написати все красиво і правильно. Але тоді ваш розвиток буде не таким швидким. Ви отримаєте досвід роботи з технологією, але не з «очищення» коду. У проєкті з історією є змога побачити й погані приклади, які ви самі ж не захочете повторювати в майбутньому.
Початківці соромляться запитувати про щось незрозуміле. Думають, це прояв некомпетентності. Але вони ж дійсно можуть чогось не знати.
Тут радимо такий лайфхак: скажіть, що у вас є ідея, але в процесі брейнстормінгу виникло кілька «дурних» запитань, треба в дечому пересвідчитися. І далі розпитайте колег про все, що вас цікавить. Коли матимете потрібні відповіді, подякуйте і скажіть, що передумали, бо ваша ідея, мабуть, не спрацює.
Не боятися незнайомого – порада, корисна не тільки новачкам, а й усім розробникам. Вона виходить далеко за межі цієї теми. Намагайтеся постійно тестувати нові підходи, шукати різні рішення і тим самим підвищувати свою експертизу.
Програмування не має суворих правил, яким всі мають 100% слідувати. Якби так було, то девелоперів вже давно замінила б програма. Поки цього не сталося, розвивайтесь в усьому, зокрема в написанні «чистого» коду. Адже його читатимуть такі ж люди, як і ви.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
