Як кількість рядків коду впливає на складність його підтримки в майбутньому
Привіт, мене звуть Андрій, я керівник напряму NodeJS у компанії ArtJoker Software. Хочу поділитися думкою про те, який підхід до написання нового коду є найкращим. Ця стаття дозволить вам подивитися на деякі усталені підходи з нової точки зору, через призму мого досвіду, та знайти рішення для написання коду.
Кількість рядків — показник, який використовують для прогнозу часу, який потрібен для роботи, або для визначення продуктивності праці. Але цей показник не свідчить про складність підтримки коду. Невеликий обсяг ще не гарантує те, що ваш код буде відмінним та без багів, а кожен девелопер зможе його підтримувати. Зазвичай, це означає протилежне.
У мої обов’язки як керівника підрозділу входить управління, допомога розробникам у написанні та підтримці коду програми, опис технічних завдань тощо. Буває так, що я пишу код для нового проєкту, або він призначений для виправлення, доопрацювання, чи обслуговування вже існуючого коду.
Причина, з якої я вирішив описати саме цю тему, полягає в тому, що сьогодні я помічаю все більше і більше розробників, які хочуть показати, наскільки вони розумні. Вони пишуть, як їм здається, дуже зручний і складний код, в якому, якщо ви хочете додати нові функції, вам потрібно дописати тільки один рядок коду. Але вони не думають, що такий підхід робить код дуже обмеженим, а одна невелика зміна може викликати значні помилки.
Ця стаття буде корисною як для мідлів, так і для сеньйорів. Для починаючих програмістів це скоріше інструкція — як уникнути помилок в майбутньому.
Думайте про тих, хто підтримуватиме код
Пишіть код, завжди уявляючи, як розробники будуть його підтримувати і писати функціонал поверх нього. Це можуть бути сеньйори або джуніори. Якщо для досвідченого розробника адаптуватися до вже заданого підходу і зберегти початкову ідею не буде складно, то для джуніора це може бути серйозним випробуванням. Думайте про молодших розробників, щоб зробити підходи якомога логічнішими, код — легким для сприйняття і написання нових функцій.
Почнемо з того, що розробники дописують новий код задля того, щоби надати нові функціональні можливості проєкту. Але ж вони бачать його вперше, тож багато досліджують, аби знайти той самий рядок коду, який треба змінити. Насправді, це іноді займає більше часу, ніж написання нового модулю.
Код частіше читають, ніж пишуть. Тож попіклуйтеся про документацію, єдину мову та стандарт оформлення коду. Уникайте дезінформації та асоціацій, які зрозумієте тільки ви. Використовуйте слова, які простіше вимовити, та якомога менше синонімів. Наш мозок влаштовано так, краще використовувати прості різні слова, замість синонімів чи умовних позначень.
Simplicity
Підтримувати код складніше, ніж писати новий, тому при написанні намагайтесь максимально спростити його. Ви ж знаєте, як розробники ненавидять колег, чий код вони рефакторять? Пам’ятаєте, як часто люди кажуть: «Працює, тож не чіпай, можеш щось зламати»? Це відбувається через те, що якийсь розробник написав код, не дивлячись у майбутнє. Не будьте як він, зробіть свій код зручнішим, а світ — трохи кращим за допомогою таких рішень. Як саме? Розглянемо далі.
Найкращий підхід для мене — це простота. Я б назвав це більше стилем коду, ніж підходом, оскільки підхід — це щось локальне в одному файлі або класі. Стиль коду — це те, як код вашого проєкту виглядає глобально. Simplicity підходить для кожного проєкту, і тут я хочу поділитися своїм особистим висновком, зроблемним після написання певної кількості проєктів.
Правила написання коду, який легко підтримувати в майбутньому
Коли починаєте писати новий проєкт, думайте про те, як наступні програмісти будуть підтримувати його. Кожна зміна може внести безлад та сповільнити роботу. Уявіть програміста, який щосили намагається знайти потрібний рядок в коді або виправити якусь помилку. До того ж, він відчуває тиск з боку замовника, бо треба зробити все якомога швидше. З таким настроєм він, напевно, зробить нові неправильні ходи — така ситуація несе повний хаос та нові витрати.
Щоб запобігти хаосу, дотримуйтеся таких принципів.
Уникайте непотрібної абстракції
Вам знайомий сценарій, коли у вас 100+ класів із
Не дотримуйтесь правила DRY фанатично
Не треба придумувати новий клас зі своєю окремою логікою, аби реалізувати трохи функціоналу. Краще просто скопіювати його. Звичайно, це створює великий обсяг коду, але цей код буде легше підтримувати.
Уникайте довгого ланцюга відповідальності
Тут та ж сама ідея, що і в першому пункті, але для функцій мета полягає в тому, щоб уникнути великої кількості функцій з дуже маленькою функціональністю.
Приклад з довгим ланцюгом відповідальності
Приклад з коротким ланцюгом відповідальності
Не використовуйте коментарі в коді
Велика кількість коментарів у коді означає, що ваш код — загадка, і зрозуміти його можна тільки за коментарями. Розробники повинні підтримувати не тільки код, але й коментарі. З плином змін, які відбуваються в коді, коментарі стають неактуальними, завдають клопоту та дезінформації, що робить їх зайвими та навіть шкідливими.
Не намагайтеся застосувати кожну хорошу практику
Хороша практика придатна для конкретної мети, наприклад, як шаблон MVC для REST API. Але якщо ви хочете реалізувати всі відомі вам практики, такі, як усі шаблони, SOLID, поліморфізм, інкапсуляція та успадкування, це може бути поганою ідеєю, не раджу використовувати її. Застосовуйте різні практики тільки за умови, якщо ви побачите точне рішення з ними та ніякі інші варіанти не підходять.
Чи впливає обсяг коду на подальшу його підтримку
Не впливає. Але значення має структура. Запобігайте використанню багатьох практик, зайвих коментарів, намагайтеся обійтись без зайвих кроків чи надто довгого ланцюга відповідальності.
Код, який виглядає компактно, але містить велику кількість вкладених складних функцій — це не зручно. Просто об’ємний код, в якому надто складно знайти «заповітний» рядок — теж не підходить. Шукайте компроміс. Як я зазначив, «Більше — значить краще» не зовсім актуальний для коду підхід.
Що кажуть відомі експерти
Я розповів вам про основні принципи, які використовую в своїй роботі та рекомендую, але якщо ви хочете детальніше вивчити це питання, раджу ознайомитися із Simplicity стилем ближче за допомогою цих авторів.
Про деякі з цих висновків Роберт Мартін (дядько Боб), автор «Чистого коду» та «Швидка розробка програм. Принципи, приклади, практика» розповідає у курсі Software Programming, який безкоштовно доступний на YouTube. Я наполегливо рекомендую його подивитися, бо складне тут подається простою мовою.
Simplicity: не тільки для початківців (або як написати простіший код) — ненудна лекція від Кейт Грегорі — регіональної директорки Microsoft у Торонто, Онтаріо, та партнерки-засновниці Gregory Consulting Limited. Кейт ділиться деякими конкретними підходами, які, ймовірно, спростять ваш код, і обговорює, що потрібно знати і робити, щоб послідовно писати простіший код і пожинати переваги цієї простоти.
Simplicity is not simple — лекція Девіда Хога. Як визначити, коли і чому код є складним, і як ми можемо зробити його простішим? Девід розповідає про методи спрощення продуктів і досвіду, про деякі міркування та рішення, з якими ми можемо зіткнутися під час боротьби з ускладненнями. Також розглядає деякі приклади кодів, які вдалося зробити простішими, не жертвуючи функціональністю.
Маєте власний досвід та інсайти щодо рефакторингу вже готового проєкту або написання коду з думкою про рефакторинг, який колись відбудеться? Діліться ними у коментарях, та нехай випадків, коли за рефакторингом та виправленням помилок минають тижні, буде менше!
58 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів