6 простих порад щодо початку написання чистого коду
Дізнайтеся все, що вам потрібно знати про програмування та код, особливо про JavaScript, TypeScript та React та дизайн.
Зміст
Написання чистого коду - завдання непросте. Це вимагає експериментів з різними порадами та практиками. Проблема полягає в тому, що існує настільки багато практик і порад з цього приводу, що це може бути приголомшливим. Як результат, розробнику може бути важко вибрати ті поради та практики, які варто дотримуватися. Давайте полегшимо це завдання. У цій статті ми спочатку обговоримо деякі переваги написання чистого коду. Потім ми розглянемо шість порад або практик щодо написання чистого коду, який розробники найчастіше використовують.
Переваги написання чистого коду
Почнемо з того, що ми розглянемо деякі переваги написання чистого коду. Однією з головних переваг є те, що чистий код допомагає нам мінімізувати час, необхідний для читання та спроб зрозуміти код. Брудний код має дивовижну здатність гальмувати будь-якого розробника і значно ускладнювати його роботу. Чим грізніший код, тим більше часу розробнику потрібно зрозуміти, наскільки він може з ним працювати. І якщо код занадто брудний, розробник може вирішити зупинитися і почати з нуля.
1. Простіше почати або продовжити
Дозвольте мені продемонструвати це на одному простому прикладі. Скажімо, ми повертаємось до одного з наших проектів через дуже довгий час. Можливо, хтось із наших попередніх клієнтів зв’язався з нами і найняв нас для іншої роботи. Тепер давайте також уявимо, що тоді ми писали не найчистіший код під сонцем, а навпаки. Одразу після першого погляду ми бачимо, наскільки поганий та безладний код. І ми також вже бачимо, як важко буде починати там, де ми зупинились.
Як результат, тепер ми повинні витратити на проект набагато більше часу, ніж ми мали б, тому що нам потрібно зрозуміти код, який ми писали раніше. Це точно не потрібно. Ми могли б уникнути цього повністю, написавши чистий код з самого початку. Тепер ми повинні за це заплатити. І є також невелика ймовірність того, що наш старий код настільки безладний чи поганий, що ми можемо вирішити почати з нуля. Наш клієнт, ймовірно, не буде задоволений, почувши ці новини.
З іншого боку, чистий код, як правило, не має цієї проблеми. Уявіть попередній приклад із протилежними умовами. Тепер наш попередній код чистий та елегантний. Скільки часу знадобиться, щоб це зрозуміти? Можливо, нам доведеться прочитати код протягом декількох хвилин, щоб зрозуміти, як все працює. Врешті-решт, минув деякий час з того часу, як ми це написали. Однак цього разу інвестиції будуть значно меншими, ніж у першому випадку. Наш клієнт цього навіть не помітить.
Це перша перевага коду, написаного таким чином, що узгоджується з порадами, які ми обговоримо. І це не справедливо лише для наших власних проектів, а й для роботи інших розробників. Чистий код дозволяє нам починати набагато швидше. Нам або комусь іншому не потрібно витрачати години на його вивчення. Натомість ми можемо приступити до роботи.
2. Краще для командної підготовки
Ще одна перевага написання чистого коду тісно пов’язана з першим. Це дозволяє легше та швидше усиновити. Я маю на увазі це. Уявімо, що нам потрібно найняти іншого розробника. Скільки часу їй знадобиться, щоб зрозуміти код і навчитися працювати з ним? Це залежить. Якщо наш код брудний і погано написаний, їй знадобиться більше часу, щоб пройти його. З іншого боку, якщо наш код буде чистим, читабельним, зрозумілим і простим, вона зможе почати швидше.
Деякі люди можуть заперечити, що це не така проблема, оскільки ми там і можемо допомогти їй. І це правда. Однак наша допомога повинна бути потрібна лише на короткий час, день-два, може три. Однак це не повинно бути тиждень-два-три. Врешті-решт ми вирішили найняти іншого розробника, щоб пришвидшити нашу роботу, а не гальмувати її ще більше. Нашою метою було не витрачати більше часу, допомагаючи їй навчитися працювати з нашим кодом.
Коли ми докладемо зусиль і напишемо чистий код, іншим людям буде легше дотримуватися його та працювати з ним. Звичайно, нам все одно доведеться виділити трохи часу, щоб допомогти кожному новому розробнику дізнатися про наш код і зрозуміти його. Однак ми говоримо про кілька днів, а не тижнів. Крім того, чистий код допоможе нам залучити до команди більше розробників і допоможе всім їм зрозуміти наш код одразу. Простіше кажучи, чим чистіший код, тим простіше його пояснити і тим менше непорозумінь.
3. Простіше слідувати
Потрібно пам’ятати одну річ. Розуміння та вивчення роботи з кодом - це одне. Однак це лише початок. Нам також потрібно переконатися, що розробник здатний та бажає слідувати нашим практикам кодування. Знову ж таки, цього буде легше досягти за допомогою чистого коду, а не безладно. Це важливо, тому що ми хочемо не тільки писати чистий код, але і зберігати його таким, незалежно від того, скільки людей з ним працює. Треба думати довгостроково.
Останнє, пов’язане з цим. Що робити, якщо хтось із наших розробників вирішить не дотримуватися поточної практики кодування? Зазвичай це питання вирішується самостійно. Скажімо, у нас є група людей, яка працює на одній і тій же основі коду, і один починає відхилятися від стандартного стилю. Тоді відбудеться одна з цих трьох речей. По-перше, решта групи підштовхне цього розробника дотримуватися стандартів. Вона прийме це, бо не хоче їхати.
Другий варіант полягає в тому, що розробник насправді переконає решту команди прийняти та дотримуватися її практики кодування. Це може бути добре, якщо практики кодування, запропоновані розробником, є чистішими та приносять кращі результати. Написання та підтримка чистоти нашого коду не означає, що ми повинні ігнорувати будь-які можливості для його вдосконалення. Швидше навпаки. Я вважаю, що ми завжди повинні ставити під сумнів нашу сучасну практику та шукати ці можливості для вдосконалення.
Отже, якщо один розробник відхиляється від нашої практики, і її практики є кращими, можливо, буде краще, якщо ми внесемо зміни, а не вона. Я думаю, що ми ніколи не повинні ігнорувати чиюсь практику, перш ніж вивчати та випробувати їх. Завжди є місце для вдосконалення, і ми повинні продовжувати його шукати. Нарешті, є третій варіант. Розробник не вирішить ані застосувати нашу практику, ані переконати нас прийняти її. Натомість вона вирішить залишити команду.