Clean Code: Hunera Nivîsandina Koda Xwendbar û Domdar

Clean code — koda paqij — ne tenê kodek e ku dixebite, lê kodek e ku ji hêla pêşdebirên din ve bi hêsanî tê xwendin, fêmkirin û guheztin. Robert C. Martin (Uncle Bob) di pirtûka xwe ya navdar “Clean Code” de dibêje: “Koda paqij ew e ku ji aliyê pêşdebirê din ve hatiye nivîsandin ku ew di serê xwe de heye.” Di vê gotarê de, em ê prensîbên bingehîn ên kodkirina paqij lêkolîn bikin.

Çima Clean Code Girîng e?

Li gorî lêkolînan, pêşdebir %70 ji dema xwe li xwendina kodê derbas dikin, ne nivîsandinê. Ev tê wê wateyê ku koda xwendbar, dema hemû tîmê tasîrûf dike. Avantajên kodkirina paqij:

• Lêçûna lênêrînê kêm dibe: Koda zelal ji bo debugkirinê hêsantir e
• Onboarding-a bilez: Endamên nû yên tîmê zûtir dest bi xebatê dikin
• Xeletiyên kêmtir: Koda xwendbar, xeletiyên veşartî eşkere dike
• Refactoring-a hêsan: Guhertinên pêşerojê bi ewlehî tên kirin
• Hevkariya çêtir: Tîm dikare bi hev re bi bandor bixebite

Prensîbên Navkirinê

Navkirin, yek ji girîngtirîn û zehmetirîn aliyên kodkirinê ye. Nav divê niyetê eşkere bike.

Guherbaran

Xirab ❌	Baş ✅
d = 86400	SECONDS_PER_DAY = 86400
let list = getList()	let activeUsers = getActiveUsers()
let flag = true	let isEmailVerified = true
let temp = calc(x)	let monthlyRevenue = calculateRevenue(sales)

Fonksiyon

• Lêker bikar bînin: calculateTotal(), validateEmail(), sendNotification()
• Boolean ji bo is/has/can: isValid(), hasPermission(), canDelete()
• Yek tişt bikin: Nav divê bêje fonksiyon çi dike, eger “û” heye, fonksiyonê dabeş bikin

Fonksiyonên Paqij

Robert C. Martin ji bo fonksiyonên paqij çend rêgezên bingehîn pêşniyar dike:

1. Piçûk Bin

Fonksiyonên baş divê piçûk bin. Di rewşa îdeal de, 5-20 rêz. Eger fonksiyon ji 30 rêzan dirêjtir be, wê dabeş bikin.

2. Yek Tişt Bikin

// Xirab: Fonksiyon gelek tiştan dike
function processOrder(order) {
  // validate
  if (!order.items.length) throw new Error('Empty');
  if (!order.address) throw new Error('No address');

  // calculate
  let total = 0;
  for (const item of order.items) {
    total += item.price * item.quantity;
  }

  // save
  db.orders.insert({ ...order, total });

  // notify
  emailService.send(order.customer, 'Order confirmed');
}

// Baş: Her fonksiyon yek tişt dike
function processOrder(order) {
  validateOrder(order);
  const total = calculateTotal(order.items);
  const savedOrder = saveOrder(order, total);
  notifyCustomer(savedOrder);
}

3. Argûmanên Kêm

Hejmara îdeal a argûmanan: 0 (niladic), 1 (monadic), 2 (dyadic). 3+ argûman (polyadic) ji vê pêve nîşana wê ye ku fonksiyonê divê were refactor kirin.

// Xirab: Pir argûman
function createUser(name, email, age, address, phone, role) { ... }

// Baş: Object bikar bînin
function createUser({ name, email, age, address, phone, role }) { ... }

Prensîbên SOLID

SOLID, pênc prensîbên sêwirana objekt-oriented e ku ji bo avakirina nermalava domdar û berfireh pêwîst in:

S — Single Responsibility Principle (SRP)

Her çîn divê tenê yek sedema guherînê hebe. Eger çînek ji bo zêdetirî yek sedem diguhere, wê dabeş bikin.

O — Open/Closed Principle (OCP)

Çîn divê ji bo berfirehkirinê vekirî, ji bo guhertinê girtî bin. Taybetmendiyên nû bi berfirehkirinê, ne bi guhertina koda heyî ve lê zêde bikin.

L — Liskov Substitution Principle (LSP)

Tiştên çînên jêrîn divê bikaribin li şûna tiştên çînên jorîn bêyî ku bernameya rast bişikînin werin bikaranîn.

I — Interface Segregation Principle (ISP)

Xerîdar nebin mecbûr ku girêdayî navbeynkên ku bikar naynin bin. Navbeynkên piçûk û taybet çêtir in ji yên mezin û gelemperî.

D — Dependency Inversion Principle (DIP)

Modulên asta bilind divê girêdayî modulên asta nizm nebin. Her du jî divê girêdayî abstraksiyonan bin.

Refactoring: Başkirina Berdewam

Refactoring, pêvajoya başkirina avahiya navxweyî ya kodê ye bêyî ku fonksiyona wê biguheze. Martin Fowler dibêje: “Her kodek ku bê refactoring dimîne, bi demê re rizq dibe.”

Kengê Refactor Bikin?

• Rêgeza Sê (Rule of Three): Gava ku hûn tiştekî ji bo cara sêyem dubare dikin, refactor bikin
• Berî zêdekirina taybetmendiyê: Berî ku kodê nû lê zêde bikin, koda heyî paqij bikin
• Di dema code review de: Gava ku hûn dibînin ku kodek çêtir dibe
• Gava ku “bîhn” heye (Code Smells): Fonksiyonên dirêj, çînên mezin, parametreyên pir…

Code Smells — Bîhnên Kodê

Bîhn	Nîşane	Çareserî
Long Method	Fonksiyon > 30 rêz	Extract Method
Large Class	Çîn > 200 rêz	Extract Class
Duplicate Code	Heman kod di 2+ cihan de	Extract Method/Class
Feature Envy	Fonksiyon daneyên çînê din zêde bikar tîne	Move Method
Primitive Obsession	String/int li şûna Value Object	Introduce Value Object

Code Review: Kalîteya Hevkaran

Code review, pêvajoya kontrolkirina kodê ji hêla endamên din ên tîmê ve ye. Ew yek ji rêbazên herî bi bandor ji bo başkirina kalîteya kodê ye.

Rêwerzên Code Review yên Baş

1. Piçûk bikin: PR yên piçûk (< 400 rêz) hêsantir û bi kalîte re têne kontrol kirin
2. Li ser mantiqê bisekinin: Ne tenê format, lê rastbûna mantiqê kontrol bikin
3. Pirsên constructive bikin: “Çima vê rêbazê hilbijart?” ne “Ev xelet e”
4. Otomatîk bikin: Linter û formatter bi CI re entegre bikin da ku format ne bibe pirsgirêk
5. Di demê de bikin: PR yên li bendê neyên hiştin, di 24 saetan de review bikin

Rêwerzên Gelemperî yên Clean Code

• DRY (Don’t Repeat Yourself): Dubarekirinê kêm bikin, kodê ji nû ve bikar bînin
• KISS (Keep It Simple, Stupid): Çareseriya herî hêsan hilbijêrin
• YAGNI (You Aren’t Gonna Need It): Taybetmendiyên ku niha ne hewce ne, lê zêde nekin
• Boy Scout Rule: Kodê hertim ji ya ku we dît paqijtir bihêlin
• Fail Fast: Xeletiyên di destpêkê de ragihînin, wan veşêrin

TAGUM™ û Standartên Kodkirinê

TAGUM™, di hemû projeyên xwe de standartên bilind ên kodkirinê bikar tîne. Ji prensîbên SOLID heta code review ya sîstematîk, ji TDD heta CI/CD — her gav kalîte pêşî ye. Di PratikEsnaf.Net, DeskTR û hemû hilberên me de, koda paqij bingeha serfiraziyê ye.

Ger hûn dixwazin pisporên me yên nermalavê ji bo projeya we kodê bi standartên herî bilind binivîsin, bi me re têkilî daynin.