Ідеальний код: чи можливо досягти його на реальних проєктах?
Розробники про те, чи справді варто підтримувати чистоту коду
Чистий код легко читається, проходить усі тести та зрозумілий для програмістів з першого погляду. Але чи не звучить це, як щось фантастичне?
Ми поговорили з досвідченими розробниками, щоби переконатися, чи справді такий код існує за межами підручників, і попрохали дати поради новачкам.
Що таке чистий код
«Одна з головних переваг написання чистого коду — коли сам повернешся до коду, який писав два роки тому, зрозумієш, що мав на увазі»
Яна Ведель,
розробниця у We4Sea B.V.
Добре структурований код набагато легше розуміти та модифікувати. Ще «гігієна» коду зменшує кількість помилок та спрощує процес тестування.
«Чистий код — це код, який легко читати та підтримувати. Чистота коду дозволяє значно скоротити час на виконання майбутніх завдань», — пояснює Роман Ткачик, Senior Software Engineer у GlobalLogic.
Нанизькорівневих проєктах доводиться доточувати алгоритми до «ідеалу», щоби досягти максимальної продуктивності на обмежених можливостях заліза. Ідеал, створений за допомогою високорівневих мов, Роман ще не зустрічав. Він впевнений: написання ідеально чистого коду вимагає додаткового часу та креативу, і його досягання не завжди є раціональним.
«Чистий код — це код, який легко підтримувати й дуже легко розширювати, — каже Роман Бухтіяров, Software Developer в Unity Technologies. — Звучить ідеально, але насправді такого майже ніколи не буває, тому що у нас завжди є трикутник потреб, де є “якісно”, “недорого” та “вчасно”. Ми маємо вміти жонглювати між цими змінними. І “якісно” не завжди у пріоритеті».
Основний момент, який відрізняє гарний проєкт від проєкту з неякісним кодом — відсутність єдиної структури. Коли одна частина написана в одному стилі, інша — в другому, тому що всі розробники мають різний бекграунд. Роман каже, що саме тому основним завданням команди є налаштування культури написання коду.
Для цього є чудовий інструмент — код-рев’ю, коли команда має змогу дати фідбек.
Чи існує чистий код у реальному житті
В’ячеслав Щупак, Software Developer у Sportradar та лектор курсу «Чистий код та патерни проєктування», каже, що звичку писати гарний код можна порівняти з чистотою у кімнаті: спершу здається зручним, що все розкидане. Але коли починаєш шукати потрібний предмет, одразу стає зрозуміло, що було б доцільніше витратити пару хвилин і поставити його на місце, ніж потім марнувати пів години на пошуки.
Водночас розробник каже, що йому доводилося досить часто мати справу з чистим кодом.
«Я зустрічав чистий код на багатьох опенсорс-проєктах. З тих, які хочу відзначити, — AKKA, Mongo Driver. А також уproprietary-проєктах, в яких налагоджені процеси код-рев’ю та TDD»
В’ячеслав Щупак,
Software Developer у Sportradar,
лектор курсу «Чистий код та патерни проєктування»
Інші опитані нами розробники менш оптимістичні: так, Віталій Полховський каже, що за всю свою довгу кар’єру в IT мав справу з ідеально чистим кодом всього одного разу:
«Єдиний великий проєкт, що я бачив і до якого було не підкопатись, — це Spice (розробка Каліфорнійського університету, Берклі), програма моделювання електронних схем. Але там не тільки код, а ще й ідеальні математичні рішення. Декілька років тому Spice був занесений до списку найвидатніших досягнень людства в електротехніці — поряд із законом Ома, правилом Кірхгофа тощо».
Техлід Сергій Журавльов впевнений: хоч ідеально чистого коду не існує, до нього треба прагнути:
«Хоча ідеально чистий код зустрічається, напевне, ніколи, є код, максимально наближений до такого. І він є на проєктах, де є нормальний дев-рев’ю процес і налаштовані стилі коду. Перед тим як розробники вносять якісь зміни, вони проходять перевірку. Є інструменти, які визначають “важкий” або “неважкий” код, наприклад. Якщо всі перевірки правильно налаштовані, код буде наближений до ідеального».
Чи варто переписувати чужий код, якщо він неідеальний
Переписування вже наявного коду — це рішення, що має бути узгоджене з керівництвом або замовником, оскільки воно здебільшого вимагає додаткового робочого часу.
«Писати чистий код з часом стає звичкою. Як їздити на автомобілі — водій або виробляє звичку і пропускає пішоходів на переходах, або ні. В цьому є сенс для коду, який не одноразовий, а буде підтримуватися далі», — каже В’ячеслав Щупак, Software Developer у Sportradar.
Головне завдання розробника — розв'язати поставлену задачу. Роман Ткачик, Senior Software Engineer із GlobalLogic, впевнений, що спеціально «дотягувати» чужий код до ідеальності немає сенсу:
«Наша основна задача полягає у розв'язанні конкретної проблеми. І хоча у процесі вирішення може виникнути потреба в переписуванні наявного коду — це не є типовою ситуацією. Тож іноді виправляти код, який не відповідає ідеальним стандартам, немає сенсу, особливо якщо він все ще виконує свою функцію».
Яна Ведель, розробниця у We4Sea B.V., повністю погоджується:
«Якщо працює, краще не чіпати :) На проєктах буває таке, що кодом до тебе займалися інші розробники, ти маєш зважати на їхній попередній код — а всі пишуть по-різному. І ти не завжди на 100 % можеш зрозуміти код, який писала людина до тебе. Якщо є якісь частини коду, у яких ти не впевнений, але треба додати нову фічу, ти тестиш, воно працює — а це найважливіше».
Варто також завжди пам’ятати про час, який витрачається на переписування коду, та зважити — а чи вартує це того?
«Чому я не виправляв код, який виглядав, м’яко кажучи, не дуже? Тому що цей код, коли його викликаєш, приносить результат. І якщо я його виправлю, результат буде таким самим, просто буде написаний краще. Тому сенс його виправляти? Особливо, якщо це код, за який відповідає інша команда. Або розповсюджений приклад — таску треба зробити за 8 годин, а на рефакторинг піде 2-3 години», — каже Сергій Журавльов, техлід та лектор курсу Java Developer.
Інструменти, які допоможуть покращити код
- Принципи SOLID та ReSharper від JetBrains
«Принципи SOLID є фундаментом для написання якісного коду. А ReSharper від JetBrains значно спрощує процес виявлення та виправлення проблемних ділянок коду, дозволяючи зосередитися на основному завданні», — наголошує Роман Ткачик, Senior Software Engineer у GlobalLogic.
- Black для Python
«Black допомагає відформатувати код згідно зі стандартами (для Python це PEP-стандарти). Ще дуже допомагає код-рев’ю — перед тим як викотити код на прод, колеги переглядають його і можуть порадити щось з оптимізації», — стверджує Яна Ведель, розробниця у We4Sea B.V.
- SonarQube та покриття коду тестами
«Ми користуємося SonarQube, який допомагає сканувати код на можливі баги, проблеми, невідповідності щодо культури коду. Також там можна задати мінімальний поріг покриття тестів. Коли ти пишеш тести, то часто помічаєш, де твій код неідеальний. Тому наша планка зараз — 80 % коду, покритого тестами», — каже Роман Бухтіяров, Software Developer в Unity Technologies.
- Принципи KISS, YAGNI, DRY, WTF/Minute та інструменти IDE
«Користуюся принципами KISS, YAGNI, DRY, WTF/Minute. Інструменти сучасних IDE сильно допомагають бачити зайві речі, сортувати, групувати, переносити тощо», — ділиться В’ячеслав Щупак, Software Developer у Sportradar.
Поради джуніорам
1. «Найкращим способом наблизитися до написання чистого коду є практика і самоосвіта. Вивчайте design-patterns і намагайтеся виявляти їх у реальному коді. Читайте статті, блоги та книги з програмування. Я особливо рекомендую книги Роберта Мартіна, такі як Clean Architecture та Clean Code», — Роман Ткачик, Senior Software Engineer з GlobalLogic.
Читайте також: «Чиста» серія та Head First — 10 кращих книг для Java-розробника
2. «Прислухайтеся до старших колег. Все прийде з досвідом. Не нехтуйте саморозвитком. Слідкуйте за новими технологіями та стандартами, читайте новини індустрії, LinkedIn. Можливо, вийшла якась бібліотека, що може скоротити час на написання коду та покращити його якість. Як-то кажуть, якщо є робот-пилосос, нащо замітати віником :)», — Яна Ведель, розробниця у We4Sea B.V.
3. «Вивчайте принципи SOLID. Їх важливо розібрати. Ці п'ять принципів розмиті, їх можна по-різному інтерпретувати та по-різному використовувати. Також я б радив знайти 2–3 розробників, які або публікують свої проєкти, або записують відео на YouTube. Але ці проєкти мають бути від спеціалістів вищого за ваш рівня», — Роман Бухтіяров, Software Developer в Unity Technologies.
