Как да започнете да пишете висококачествен код във всяка точка на вашето пътуване по програмиране

КРЕДИТ НА ИЗОБРАЖЕНИЕ: Insane Lab

Ако искате да напишете код за повече от развлекателни цели, тогава качеството на кода е аспект на вашата работа, на който ще трябва да отделите повече внимание. Качеството на кода се определя от сближаване на атрибути като поддръжка, повторна използваемост, четливост, ефективност, склонност към грешки и модулност.

Нека разгледаме някои от тези атрибути малко по-подробно:

  • модулност
    Това определя колко независими са различни части от кода един от друг, т.е. прави ли лоша промяна в една част от кода ви, разбива ли всичко останало? Обикновено искате отговорът на този въпрос да бъде не. Това е подобно на концепцията за свързване, използвана в OOP (обектно ориентирано програмиране). Кодът, който е модулен, може да включва своите съставни блокове на функционалност и да се сменя или изключва, без да кара цялата къща да се спуска на главата ви. С течение на времето ще започнете да оценявате силата на това да имате модулен код, когато се окажете, че трябва да преработите напълно определена функция или функционалност на вашия код.
  • Многократното
    Този атрибут измерва степента, в която части от вашия код могат да бъдат използвани повторно в други (изцяло различни) проекти. Степента, до която кодът ви може да бъде използван до голяма степен, се основава на това колко плътно е свързан с останалата част от вашата кодова база.
    Пример за повторно използване на код би било изграждането на последователност за удостоверяване на потребителя за забавно приложение за социални медии за вашата компания и след това да можете да използвате повторно тази последователност за удостоверяване в система за управление на заплати, без да се нуждаете от останалата част от кодовата база за сайта на социалните медии.
    Идеален пример в реалния живот е този на автомобилните гуми ... тези бебета обикновено работят на всяка кола, стига да са с подходящ размер. Забележете как употребата им върху всеки конкретен автомобил е независима от дизайна на останалата част от автомобила.
  • ремонтопригодност
    Както може би се досещате, този атрибут измерва лекотата, с която кодът ви може да бъде надстроен / променен във времето, без да се въвеждат нови грешки. Когато използвате принципите на OOP, поддръжността на вашия код до голяма степен се определя от това колко плътно са свързани вашите класове.
Свързването е степента, до която класовете или обектите зависят един от друг, тоест, плътното свързване води до резултат, когато група класове са силно зависими един от друг. Този сценарий възниква, когато клас поема твърде много отговорности или когато една грижа е разпределена върху много класове, вместо да има свой клас.

Безопасно е да се каже тогава, че хлабавото свързване ще доведе до по-голяма повторна употреба на кода и по-лесна поддръжка.

  • четливост
    Четен код - всеки програмист твърди, че кодът им е супер четим, но очевидно това не е така. Какво е, четим код тогава? Преди да определим какво е, може би по-важният въпрос е, защо четенето има значение все пак? Когато започнете да работите върху по-големи проекти, ще откриете, че вашата кодова база нараства със стотици редове всеки ден, което означава, че след няколко седмици може би сте забравили логиката зад решенията, които сте взели. По подобен начин другите хора, които гледат кода ви, ще намерят невъзможно да разберат кода ви, ако той не е четим. Да се ​​надяваме, можете да започнете да виждате как наличието на нечетлив код може да превърне поддръжката в кошмар.
    Сега можем да определим четим код като лесен за разбиране или следване логично. Има много неща, които можете да направите, за да направите кода си по-четим и можете да намерите много от тях тук, но като цяло,
    - коментирайте кода си,
    - име на променливи (както временни, така и по друг начин) последователно и описателно,
    - избягвайте изключително дългите редове с код (> 120 знака)
    - формират кодови групи
    - DRY (не се повтаряйте): Ако някога се окажете да копирате и да вмъквате код, STOP и мислите дълго и упорито - вероятно правите нещо нередно
    - YAGNI (нямаш нужда от това): Избягвай да пишеш код, който не се използва, тъй като ще доведе до объркване по пътя
    - използвайте умерено гнездене и
    - използвайте правилно разстояние и / или вдлъбнатина (да, бялото пространство може да бъде красиво) и трябва да сте на път да създавате изкуство!

Искам да напиша код за качество ... какво трябва да направя?

След като сте съгласни, че целта за писане на висококачествен код си струва да се преследва, нека да проучим как бихме могли да продължим да променим работния си процес в този смисъл.

Приемане на разработка за управление на тестове (TDD)

Това е практика на програмиране (за която можете или не сте чували преди), която включва създаване на тестови случаи, които кодът ви трябва да може да премине, ако е написан правилно. Това може да се разглежда като песимистичен подход към програмирането, но това ви принуждава да помислите за всички неща, които биха могли да се объркат с вашия код, за да можете, преди време, да включите всички вратички, които биха могли да направят вашия код бъги.

Например, ако бъдете помолени да напишете код за калкулатор, който добавя две числа и връща тяхната сума; има два начина да се подходи към тази задача:

Примерите, които следвате, са в Python

  1. Е, проблемът изглежда достатъчно лесен, просто ще напиша функция, която взема два аргумента и връща сумата им.

2. Значи, кодът ни от подход 1 работи отлично, той връща сумата от 6 и 9 като 15 ... нямаме нужда от тестово развитие, нали? Грешно! Нека разгледаме подхода за изпитване за секунда ...

В тестово ориентирания подход би трябвало да помислим за всички неща, които биха могли да ускорят кода ни и да напишем тестове, за да гарантираме, че кодът ни обслужва споменатите сценарии. Например в нашия код на калкулатора, какво става, ако потребителят:

  • премина два низа като аргумент към нашата функция?
  • предадохме цяло число и низ на нашата функция?

След това ще напишем тестове за тези малко вероятно все още апокалиптични сценарии, като така:

Нека сега да разгледаме как би изглеждал кодът за калкулатор, ако е написан с тестовете по-горе:

Моментално TDD подходът създава код, който може да издържи на различна степен на злоупотреба от страна на потребителите и е по-малко вероятно да се счупи. Вече е ясно, че кодът ни от подход 1 не би се справил здраво с тези неочаквани сценарии, тъй като не сме имали възможността да разгледаме тяхното съществуване на първо място.

В много отношения TDD взема назаем от закона на Мърфи:

Всичко, което може да се обърка, ще се обърка

И тук се крие огромната сила на тестово разработената разработка, тя ви принуждава да помислите за всички много начини, по които кодът ви може да се счупи (макар и малко вероятно) ... което по своята същност ви кара да пишете по-здрав код.

Този пример за калкулатор е доста опростен и тестовете, които написахме, не покриват всички възможни сценарии, но концепцията остава същата, независимо колко голям е вашият проект. Най-общо казано, колкото повече тестове пишете, толкова по-добре, защото по принцип това трябва да доведе до по-голямо покритие на теста.

Винаги трябва да се стремите да постигнете 100% тестово покритие, което по същество означава, че когато вашите тестови единици се изпълняват, всички ваши редове от код се изпълняват! Ако тези тестове са добре написани, ще имате по-голяма способност да улавяте всички грешки - давате възможност да ги поправите всички и сте на път да постигнете истински статус без грешки.

Можете да прочетете повече за това как да започнете с TDD тук, както и моята статия тук.

Използвайте инструменти за автоматичен преглед на код

Говорихме много за много неща, които квалифицират кода като висококачествен и може би някой ден ще разберете дълбоко всички аспекти на качеството на кода - дори може да придобиете способността за бърз анализ на скриптове на други програмисти и посочете проблемите и корекциите на посочените проблеми. Докато не настъпи този ден, аз (силно) препоръчвам да интегрирате използването на автоматизирани инструменти за преглед на кода във вашия работен процес.

Обичам да мисля за инструменти за преглед на код като за часовници; те следят за вас, докато пишете кода си и всеки толкова често (преди и / или след запис, в зависимост от конкретния инструмент), ще ви уведомят как можете да подобрите кода си. Има много инструменти за преглед на код и можете да видите списък тук; Аз лично експериментирах с Codacy и Code Climate до този момент. Кодът и климатикът на кода са безплатни за използване с отворен код github repos - частните репозиции се плащат. Бях доволен от Codacy, но и аз съм доста нов в този работен процес, така че, когато научавам повече за различните инструменти, бих могъл или не може да направя промяна.

Първи стъпки с инструменти за преглед на код
След като създадете акаунт с кодекс, добавете обществено хранилище от вашия Github акаунт. От този момент нататък вашият код ще се преглежда всеки път, когато поемете ангажимент за това хранилище.

След прегледа резултатите се публикуват на красиво табло, което подчертава най-важните аспекти на вашия код.

Екранна снимка на таблото за проекти на Codacy

Анализ на резултатите
Прегледът на кода разкрива много неща за нашия код - добре, лошо и грозно. Ще разберете, че стремежът да напишете по-добър код изисква готовност постоянно да се сблъсквате с недостатъците на работата си, така че да можете да я подобрите.

От таблата по-горе, първото, което виждаме, е, че този конкретен проект е получил оценка B - което изобщо не е лошо като отправна точка.

В долния десен ъгъл можем да видим и диаграма за това как се е развило качеството на кода на проекта с течение на времето - това върши доста добра работа да ви държи в съзнание за търсене на положителен растеж.

В допълнение се предоставя информация за сигурността на кода, склонност към грешки, съвместимост, стил и проблеми. Текущите проблеми с вашия код трябва да са във фокуса ви, защото те подчертават уязвимостите на вашия код.

Таблото за управление осигурява категоризирана разбивка на проблемите; бързо ви давам представа в коя област вашият код е най-уязвим. Досега любимото ми нещо за инструментите за преглед на код е, че те (почти винаги) дават изчерпателна информация за отделни проблеми, като например, защо определен проблем е бил маркиран като такъв както и какво бихте могли да направите, за да коригирате споменатия проблем.

Според мен разбирането защо даден код от код повдига проблем, е малко вероятно да го използвате отново в бъдеще. Натрупването на това разбиране за различни въпроси несъмнено ще има положително влияние върху качеството на вашия код.

Разширен изглед на конкретен проблем

Използвайте инструментите за непрекъсната интеграция (CI)

Постигането и / или поддържането на високо качество на кода е достатъчно предизвикателство като самотен вълк програмист, представете си колко по-трудно е като екип, който прави промени в централно хранилище. Често екипите не успяват да доставят софтуер достатъчно бързо поради трудностите при преглед на приноса на членовете на екипа.

Ще напиша още една статия за подобряване на качеството на вашата кодова база като екип, използващ CI инструменти / build-сървъри като Travis CI и Jenkins. Внимавайте за това.

Непрекъснатата интеграция (CI) е практика за разработка, която изисква разработчиците да интегрират код в споделено хранилище няколко пъти на ден. След това всяко регистриране се проверява от автоматизирана конструкция, която позволява на екипите да откриват проблеми рано.
Таблото за управление на проекта Travis CI

Нека приключим това

Писането на код за качество е навик повече, отколкото е умение, и като всички навици, ще трябва да го развиете, като предприемете умишлено действие. Оценявам, че това може да се окаже трудно, поради което трябва да разчитате на инструменти за преглед на TDD и код, за да бъдете честни и да ви насърчават винаги да обмисляте множество гледни точки и да се придържате към най-добрите практики за програмиране.

Ако сте намерили тази статия за най-малко полезна, натиснете бутона на сърцето и ми помогнете да го насоча към повече хора, които се нуждаят от помощ, за да започнете да пишете висококачествен код. Искрено ще оценя отговорите ви с вашите мисли - каквито и да са те. Аз съм в Twitter, ако трябва да разговаряте.

ОТГОВОРНОСТ: Аз не съм експерт (поне още не), а просто човек, документиращ своето учебно пътуване