Блог Алекса Деверо

Дізнайтеся все, що вам потрібно знати про програмування та код, особливо про JavaScript, TypeScript та React та дизайн.

Зміст

Написання чистого коду - завдання непросте. Це вимагає експериментів з різними порадами та практиками. Проблема полягає в тому, що існує настільки багато практик і порад з цього приводу, що це може бути приголомшливим. Як результат, розробнику може бути важко вибрати ті поради та практики, які варто дотримуватися. Давайте полегшимо це завдання. У цій статті ми спочатку обговоримо деякі переваги написання чистого коду. Потім ми розглянемо шість порад або практик щодо написання чистого коду, який розробники найчастіше використовують.

Переваги написання чистого коду

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

1. Простіше почати або продовжити

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

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

З іншого боку, чистий код, як правило, не має цієї проблеми. Уявіть попередній приклад із протилежними умовами. Тепер наш попередній код чистий та елегантний. Скільки часу знадобиться, щоб це зрозуміти? Можливо, нам доведеться прочитати код протягом декількох хвилин, щоб зрозуміти, як все працює. Врешті-решт, минув деякий час з того часу, як ми це написали. Однак цього разу інвестиції будуть значно меншими, ніж у першому випадку. Наш клієнт цього навіть не помітить.

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

2. Краще для командної підготовки

Ще одна перевага написання чистого коду тісно пов’язана з першим. Це дозволяє легше та швидше усиновити. Я маю на увазі це. Уявімо, що нам потрібно найняти іншого розробника. Скільки часу їй знадобиться, щоб зрозуміти код і навчитися працювати з ним? Це залежить. Якщо наш код брудний і погано написаний, їй знадобиться більше часу, щоб пройти його. З іншого боку, якщо наш код буде чистим, читабельним, зрозумілим і простим, вона зможе почати швидше.

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

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

3. Простіше слідувати

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

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

Другий варіант полягає в тому, що розробник насправді переконає решту команди прийняти та дотримуватися її практики кодування. Це може бути добре, якщо практики кодування, запропоновані розробником, є чистішими та приносять кращі результати. Написання та підтримка чистоти нашого коду не означає, що ми повинні ігнорувати будь-які можливості для його вдосконалення. Швидше навпаки. Я вважаю, що ми завжди повинні ставити під сумнів нашу сучасну практику та шукати ці можливості для вдосконалення.

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

Поради щодо написання чистого коду

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

1. Зробіть код зрозумілим для людей

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

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

2. Використовуйте значущі імена змінних, функцій та методів

Давайте розглянемо другу підказку, яка допоможе нам написати зрозумілий і чистий код. Ця порада стосується використання значущих імен для змінних, функцій та методів. Що означає значуще? Значущі імена - це досить описові імена, щоб інші люди, і не лише ми, змогли зрозуміти призначення змінної, функції або методу. Іншими словами, сама назва повинна підказувати, для чого використовується змінна, функція чи метод або що вона містить.
Код:

Однак є щось, про що слід пам’ятати. Використання описових назв не означає, що ми можемо використовувати стільки символів, скільки хочемо. Хорошим емпіричним правилом є обмеження імен трьома-чотирма словами. Якщо нам потрібно використовувати більше чотирьох слів, можливо, ми намагаємося робити занадто багато речей одночасно, і нам слід спростити наш код. Отже, використовуймо стільки символів, скільки потрібно.

3. Нехай одна функція або метод виконує лише одне завдання

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

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

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

Примітка: така практика, коли кожна функція або метод дозволяє виконувати лише одне завдання, називається принципом єдиної відповідальності. Ця практика кодування була запроваджена Робертом К. Мартіном як один із п’яти об’єктно-орієнтованих принципів проектування, також відомих як SOLID. Якщо ви хочете дізнатись більше про це, я рекомендую прочитати цю статтю.
Код:

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

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

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

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

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

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

5. Будьте послідовними

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

Найкраще зробити вибір набору практик кодування, а потім дотримуватися цих практик у всіх наших проектах. Тоді буде набагато простіше повернутися до нашого старого коду і продовжувати там, де ми зупинилися, або вдосконалити його. А як щодо експериментів? Спробувати нові практики кодування - це добре. Це може допомогти нам знайти кращі способи робити свою роботу. Однак краще експериментувати з різними практиками на окремих експериментальних проектах чи вправах, а не на наших основних проектах.

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

6. Регулярно переглядайте свій код

Це моя остання порада щодо написання чистого коду. Просто писати чистий код - це не все. Наша робота не закінчена з останньою крапкою з комою. Наступним кроком є підтримка чистоти нашого коду. Чистий код вимагає обслуговування. Коли ми щось пишемо, нам слід регулярно переглядати, очищати це та намагатися вдосконалити. В іншому випадку, якщо ми не переглянемо та оновимо наш старий код, він незабаром застаріє. Так само, як і на наших пристроях. Якщо ми хочемо підтримувати їх у найкращій формі, нам потрібно регулярно їх оновлювати.

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

Заключні думки щодо написання чистого коду

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

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

Якщо ви хочете підтримати мене та цей блог, ви можете стати меценатом або купити мені каву 🙂