+
Вход

Въведи своя e-mail и парола за вход, ако вече имаш създаден профил в DEV.BG/Jobs

Забравена парола?
+
Създай своя профил в DEV.BG/Jobs

За да потвърдите, че не сте робот, моля отговорете на въпроса, като попълните празното поле:

111+1 =
+
Забравена парола

Въведи своя e-mail и ще ти изпратим твоята парола

Принципи на чистия код: Как да пишем код за хората, не за компютрите

© Текстът е предоставен от DataArt

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

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

Йевен Кузменко е автор на статията по темата.


Пет причини, поради които чистият код е важен за работата на всеки един програмист

  1. Качеството на кода влияе върху разходите за внедряване на нови функции и способността на бизнеса да бъде гъвкав.
  2. Помага на приложението да бъде поддържано, тъй като разходите за поддръжка са четири пъти по-високи от тези за разработка.
  3. Кодът трябва да бъде лесно четим за хората, а не само за компютрите.
  4. Кодът се пише веднъж, но се чете много пъти, често извън IDE. Въпреки че IDE предлагат удобства като анотации, препоръки и насоки, кодът се преглежда и в по-опростени инструменти като GitHub.

Трислойна архитектура срещу слоева архитектура

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

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

Днес те питаме…

Кой е най-важният фактор за теб при избора на нова работа?
Loading ... Loading …

Стандартни принципи

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

1. Не се повтаряй (DRY)

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

  • Използвате константи, променливи, функции и класове, вместо да повтаряте стойности или логика;
  • Използвате наследяване и интерфейси за споделяне на общи поведения между различни класове;
  • Опростявате рутинни задачи с помощта на генератори на код, шаблони и рамки.
2. Не усложнявайте задачата излишно (или казано иначе – keep it simple)

При сблъсък с лесна задача не усложнявайте решението. Сложните решения затрудняват поддръжката и увеличават разходите. За да избегнете тези проблеми:

  • Разделете сложните проблеми на по-малки.
  • Избягвайте ненужни функции и зависимости.
  • Използвайте кратки функции/класове, които изпълняват специфична цел.
  • Използвайте добре известни шаблони и алгоритми.
3. Без ненужни неща

Избягвайте излишни функционалности, ако проектът или клиентът не ги изискват, тъй като това повишава разходите за поддръжка и усложнява решението. Постигнете това чрез:

  • Създаване на функционалности, нужни на продукта.
  • Допълнителна гъвкавост само при нужда.
  • Уточняване на изискванията с Product Owner, когато сте несигурни.

SOLID принципи

1. Принцип на единствената отговорност (SRP – Single Responsibility Principle)

Кодът трябва да изпълнява само една задача. Уверете се, че методът/класът изпълнява единствено предназначение и има една причина за промяна.

2. Принцип на отвореност-затвореност (OCP – Open/Closed Principle)

Новите функционалности трябва да изискват нов код, а не модификации на съществуващ. Използвайте абстракция и полиморфизъм, за да постигнете този принцип.

3. Принцип на Лисков за заместване (LSP – Liskov Substitution Principle)

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

4. Принцип на сегрегация на интерфейса (ISP – Interface Segregation Principle)

Клиентите не трябва да зависят от интерфейси, които не използват. Разделете интерфейсите на отделни отговорности.

5. Принцип на инверсия на зависимостите (DIP – Dependency Inversion Principle)

Високото ниво на модулите не трябва да зависи от ниското. Използвайте слоеве за абстракция, за да осигурите гъвкавост.

Explore more

Виж
WordPress обявите
Събрани на едно място
Right Arrow
Виж
Blazor обявите
Събрани на едно място
Right Arrow
Виж
T-SQL обявите
Събрани на едно място
Right Arrow
Виж
SAFe обявите
Събрани на едно място
Right Arrow

Осем съвета за чист код

  1. Придържайте се към принципа за минимална изненада – компонентите на системата трябва да се държат, както се очаква.
  2. Внимавайте с езика на комуникацията – използвайте терминологията на бизнеса и стандартизирайте езика.
  3. Малкото е повече – прекаленото количество обекти затруднява проследяването на кода.
  4. Не оставяйте „мъртъв“ код – това може да създаде объркване.
  5. Не давайте лош пример – ако нарушите принципите, и колегите ви може да го направят.
  6. Задайте процес на преглед на кода – автоматизираните анализатори трябва да наложат стиловете, а човешкият преглед – да разглежда общата картина.
  7. Включете автоматизирани тестове – тестовете осигуряват стабилност при рефакториране.
  8. Правете изключения само когато е необходимо – обмислете добре предимствата и недостатъците, преди да нарушите правилата.

Шест признака, че сте написали качествен код

  1. Лесен е за четене извън IDE.
  2. Може да се покрие с автоматизирани тестове.
  3. Позволява добавяне на нови функции без значителни промени.
  4. Минимизира броя на регресионните грешки.
  5. Избягва дублиране на потребителски истории.
  6. Лесно се обновява до нови версии на рамки.

Винаги се ориентирайте спрямо положителните резултати и прилагайте правилата, когато водят до предимства. 

Aко всичко друго се провали, следвайте съвета на програмиста Джон Уудс: „Винаги пишете код така, сякаш човекът, който ще го поддържа, е агресивен психопат, който знае къде живеете.“