Kod kalitesi projelerinizin gelece\u011fini nas\u0131l \u015fekillendirir? Uncle Bob’un temiz kod prensipleriyle yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinizi iyile\u015ftirin, okunabilir ve s\u00fcrd\u00fcr\u00fclebilir kodun g\u00fcc\u00fcn\u00fc ke\u015ffedin. Bu makale, yaz\u0131l\u0131m d\u00fcnyas\u0131n\u0131n duayenlerinden Robert C. Martin (Uncle Bob) taraf\u0131ndan ortaya konan temiz kod felsefesini derinlemesine inceleyecek ve neden her geli\u015ftiricinin bu prensipleri benimsemesi gerekti\u011fini somut \u00f6rneklerle a\u00e7\u0131klayacakt\u0131r.<\/p>\n
Yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda hepimiz ayn\u0131 manzarayla kar\u015f\u0131la\u015fm\u0131\u015f\u0131zd\u0131r: Aylar \u00f6ncesinden kalma, ne oldu\u011fu anla\u015f\u0131lmayan bir kod par\u00e7as\u0131 veya \u00fczerinde de\u011fi\u015fiklik yapmaktan korktu\u011fumuz devasa bir fonksiyon. Belki de yeni bir \u00f6zellik eklemeye \u00e7al\u0131\u015f\u0131rken bir haftam\u0131z\u0131 mevcut kodu anlamaya harcam\u0131\u015f\u0131zd\u0131r. \u0130\u015fte bu durum, genellikle “teknik bor\u00e7” olarak adland\u0131r\u0131lan ve projelerin ilerlemesini ciddi \u015fekilde yava\u015flatan bir sorunun, yani kirli kodun do\u011frudan sonucudur. Yaz\u0131l\u0131m projelerinin ba\u015far\u0131s\u0131 sadece i\u015flevsellikle de\u011fil, ayn\u0131 zamanda kodun kalitesiyle de do\u011frudan ili\u015fkilidir. Peki, kod yazmak neden bazen bu kadar zorlu bir maceraya d\u00f6n\u00fc\u015f\u00fcr? \u00c7\u00fcnk\u00fc sadece \u00e7al\u0131\u015fan bir kod yazmak yeterli de\u011fildir; ayn\u0131 zamanda okunabilir, anla\u015f\u0131labilir ve s\u00fcrd\u00fcr\u00fclebilir olmas\u0131 gerekir. Bu noktada, Robert C. Martin, nam-\u0131 di\u011fer Uncle Bob’un “Temiz Kod” (Clean Code) felsefesi devreye giriyor. Bu felsefe, yaz\u0131l\u0131m geli\u015ftirmenin temel ta\u015flar\u0131ndan biri haline gelmi\u015f, say\u0131s\u0131z projeyi ve geli\u015ftiriciyi derinden etkilemi\u015ftir. Zira yaz\u0131lan her sat\u0131r kod, sadece makineye de\u011fil, ayn\u0131 zamanda gelecekteki geli\u015ftiricilere (ve \u00e7o\u011fu zaman kendinize) de yaz\u0131l\u0131r. Karma\u015f\u0131k ve anla\u015f\u0131lmas\u0131 g\u00fc\u00e7 kodlar, zamanla birikerek hem bak\u0131m maliyetlerini art\u0131r\u0131r hem de yeni \u00f6zelliklerin eklenmesini zorla\u015ft\u0131r\u0131r. Bu durum, proje ekibinin moralini d\u00fc\u015f\u00fcrebilir ve teslim s\u00fcrelerinin aksamas\u0131na yol a\u00e7abilir. Dolay\u0131s\u0131yla, temiz kod prensiplerini benimsemek, yaln\u0131zca teknik bir tercih de\u011fil, ayn\u0131 zamanda bir proje y\u00f6netimi ve ekip verimlili\u011fi stratejisidir. \u015eimdi gelin, bu hayati \u00f6neme sahip kavram\u0131 daha yak\u0131ndan inceleyelim ve Uncle Bob’un \u00f6\u011fretilerinden ilham alarak kodlama al\u0131\u015fkanl\u0131klar\u0131m\u0131z\u0131 nas\u0131l geli\u015ftirebilece\u011fimizi ke\u015ffedelim.<\/p>\n
Temiz kod, sadece \u00e7al\u0131\u015fmakla kalmay\u0131p ayn\u0131 zamanda di\u011fer geli\u015ftiriciler taraf\u0131ndan kolayca okunabilen, anla\u015f\u0131labilen ve s\u00fcrd\u00fcr\u00fclebilen kod demektir. Uncle Bob, bu kavram\u0131 “okumas\u0131 bir kitaptan daha kolay olan kod” olarak tan\u0131mlar. Yani, temiz kod, yaz\u0131ld\u0131\u011f\u0131 dilin do\u011fal ak\u0131\u015f\u0131na uygun, mant\u0131ksal olarak d\u00fczenli ve minimal \u00e7abayla kavranabilen bir yap\u0131da olmal\u0131d\u0131r. Neden bu kadar \u00f6nemlidir? \u00c7\u00fcnk\u00fc yaz\u0131l\u0131m geli\u015ftirme s\u00fcrecinin %80’i kod yazmak de\u011fil, mevcut kodu okumak ve anlamakla ge\u00e7er. E\u011fer kodunuz kirli ve karma\u015f\u0131ksa, bu okuma ve anlama s\u00fcreci katlanarak artar, bu da zaman ve maliyet kayb\u0131na yol a\u00e7ar. Bir projede kod kalitesi d\u00fc\u015f\u00fck oldu\u011funda, yeni \u00f6zellikler eklemek, hatalar\u0131 gidermek veya mevcut sistemi iyile\u015ftirmek son derece zorla\u015f\u0131r. Her de\u011fi\u015fiklik potansiyel bir felaket riski ta\u015f\u0131r ve bu da geli\u015ftiricilerin kod \u00fczerinde \u00e7al\u0131\u015fmaktan \u00e7ekinmesine neden olur. Sonu\u00e7 olarak, projenin h\u0131z\u0131 d\u00fc\u015fer, teslim s\u00fcreleri uzar ve geli\u015ftirici motivasyonu azal\u0131r. Dahas\u0131, yeni ekip \u00fcyelerinin projeye adaptasyonu \u00e7ok daha uzun s\u00fcrer, bu da ek bir maliyet unsuru olu\u015fturur. Temiz kodun faydalar\u0131 ise saymakla bitmez:<\/p>\n
Uncle Bob’un Temiz Kod kitab\u0131nda vurgulad\u0131\u011f\u0131 “\u0130zci Kural\u0131” (Boy Scout Rule) da bu ba\u011flamda \u00e7ok \u00f6nemlidir: “Kulland\u0131\u011f\u0131n\u0131z kamp alan\u0131n\u0131, buldu\u011funuzdan daha temiz b\u0131rak\u0131n.” Bu kural, geli\u015ftiricilerin bir mod\u00fclde \u00e7al\u0131\u015f\u0131rken, sadece kendi ekledikleri kodu temizlemekle kalmay\u0131p, mevcut kodu da k\u00fc\u00e7\u00fck iyile\u015ftirmelerle daha iyi hale getirmesini \u00f6\u011f\u00fctler. Bu s\u00fcrekli k\u00fc\u00e7\u00fck iyile\u015ftirmeler, teknik borcun birikmesini engeller ve zamanla kod taban\u0131n\u0131 daha sa\u011fl\u0131kl\u0131 bir hale getirir. K\u0131sacas\u0131, temiz kod, sadece bug\u00fcn\u00fcn de\u011fil, yar\u0131n\u0131n da yaz\u0131l\u0131m projelerinin ba\u015far\u0131s\u0131 i\u00e7in vazge\u00e7ilmez bir unsurdur.<\/p>\n
Temiz kodun belki de en temel ve en s\u0131k g\u00f6z ard\u0131 edilen prensiplerinden biri, do\u011fru ve anlaml\u0131 isimlendirmedir. Uncle Bob, isimlendirme konusunda olduk\u00e7a kat\u0131d\u0131r ve “isimlendirme, yaz\u0131l\u0131m geli\u015ftirmenin en zor iki \u015feyinden biridir” der. \u0130yi isimlendirilmi\u015f bir kod par\u00e7as\u0131, yorum yazma ihtiyac\u0131n\u0131 ortadan kald\u0131r\u0131r ve kodun kendi kendini a\u00e7\u0131klamas\u0131na olanak tan\u0131r. Bir de\u011fi\u015fken, fonksiyon veya s\u0131n\u0131f ad\u0131, o \u00f6\u011fenin ne i\u015fe yarad\u0131\u011f\u0131n\u0131, neden var oldu\u011funu ve nas\u0131l kullan\u0131lmas\u0131 gerekti\u011fini net bir \u015fekilde belirtmelidir. K\u00f6t\u00fc isimlendirme, kodun okunabilirli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r, anla\u015f\u0131lmas\u0131n\u0131 zorla\u015ft\u0131r\u0131r ve bu da beraberinde hatalar\u0131 ve bak\u0131m maliyetlerini getirir. \u00d6zellikle b\u00fcy\u00fck projelerde, geli\u015ftiricilerin kodun farkl\u0131 b\u00f6l\u00fcmlerini h\u0131zla kavramas\u0131 hayati \u00f6nem ta\u015f\u0131r. Anlams\u0131z k\u0131saltmalar, tek harfli de\u011fi\u015fkenler veya genel terimler kullanmak yerine, amaca y\u00f6nelik, a\u00e7\u0131klay\u0131c\u0131 ve tutarl\u0131 isimler tercih edilmelidir. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n ya\u015f\u0131n\u0131 tutan bir de\u011fi\u015fken i\u00e7in \u0130yi isimlendirme, kodun gelecekteki bak\u0131m\u0131n\u0131 ve geni\u015fletilebilirli\u011fini do\u011frudan etkileyen bir sanatt\u0131r. \u0130lk ba\u015fta biraz zaman alsa da, uzun vadede projenize paha bi\u00e7ilmez faydalar sa\u011flayacakt\u0131r.<\/p>\n Temiz kod yaz\u0131m\u0131nda fonksiyonlar, bir hikaye anlat\u0131c\u0131s\u0131 gibi hareket etmelidir. Uncle Bob’un vurgulad\u0131\u011f\u0131 temel prensiplerden biri, fonksiyonlar\u0131n k\u00fc\u00e7\u00fck olmas\u0131 ve tek bir i\u015fi yapmas\u0131d\u0131r (Single Responsibility Principle – SRP). Bir fonksiyonun sadece bir nedeni olmal\u0131d\u0131r ve bu neden de sadece o fonksiyonu de\u011fi\u015ftirmeyi gerektirmelidir. Bu prensip, kodun mod\u00fclerli\u011fini, test edilebilirli\u011fini ve okunabilirli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. B\u00fcy\u00fck, karma\u015f\u0131k ve birden fazla i\u015fi \u00fcstlenen “tanr\u0131 fonksiyonlar\u0131” (god functions) kodun anla\u015f\u0131lmas\u0131n\u0131 ve s\u00fcrd\u00fcr\u00fclebilirli\u011fini baltalar. Bu t\u00fcr fonksiyonlar, i\u00e7inde farkl\u0131 katmanlar\u0131n mant\u0131\u011f\u0131n\u0131, veri eri\u015fimini ve i\u015f kurallar\u0131n\u0131 bar\u0131nd\u0131rabilir. Bunun yerine, her fonksiyon belirli bir soyutlama seviyesinde tek bir, iyi tan\u0131mlanm\u0131\u015f bir g\u00f6revi yerine getirmelidir. \u00d6rne\u011fin, bir kullan\u0131c\u0131 kay\u0131t fonksiyonu sadece kullan\u0131c\u0131 verilerini do\u011frulamal\u0131, veritaban\u0131na kaydetmeli ve bir bildirim g\u00f6ndermeli gibi birden fazla sorumlulu\u011fu \u00fcstleniyorsa, bu fonksiyonu daha k\u00fc\u00e7\u00fck, odaklanm\u0131\u015f fonksiyonlara b\u00f6lmek gerekir. Do\u011frulama, veritaban\u0131 kayd\u0131 ve bildirim g\u00f6nderme gibi i\u015flemlerin her biri ayr\u0131 bir fonksiyona atanmal\u0131d\u0131r. B\u00f6ylece, bir do\u011frulama kural\u0131 de\u011fi\u015fti\u011finde, sadece do\u011frulama fonksiyonunu de\u011fi\u015ftirmek yeterli olur; t\u00fcm kay\u0131t fonksiyonunu etkilemek zorunda kalmazs\u0131n\u0131z. Bu yakla\u015f\u0131m, kodun daha az hata \u00fcretmesine ve daha kolay test edilmesine olanak tan\u0131r. Her k\u00fc\u00e7\u00fck fonksiyonun ba\u011f\u0131ms\u0131z olarak test edilmesi, sistemin genel sa\u011flaml\u0131\u011f\u0131n\u0131 art\u0131r\u0131r. A\u015fa\u011f\u0131daki \u00f6rnek, tek bir b\u00fcy\u00fck fonksiyonun nas\u0131l daha k\u00fc\u00e7\u00fck, odaklanm\u0131\u015f par\u00e7alara ayr\u0131labilece\u011fini g\u00f6stermektedir:<\/p>\n <\/code><\/p>\n G\u00f6rd\u00fc\u011f\u00fcn\u00fcz gibi, ikinci \u00f6rnekte her fonksiyon tek bir i\u015fi yapmaktad\u0131r. Bu sayede, kod daha okunabilir, daha kolay test edilebilir ve gelecekteki de\u011fi\u015fikliklere daha a\u00e7\u0131kt\u0131r. Her bir par\u00e7ay\u0131 ayr\u0131 ayr\u0131 ele almak, karma\u015f\u0131kl\u0131\u011f\u0131 y\u00f6netilebilir seviyelere indirir ve genel yaz\u0131l\u0131m kalitesini art\u0131r\u0131r.<\/p>\n Temiz kod felsefesinde, yorumlar genellikle bir \"koku\" veya \"kodun kendini yeterince a\u00e7\u0131klamad\u0131\u011f\u0131n\u0131n\" bir i\u015fareti olarak kabul edilir. Uncle Bob'un me\u015fhur s\u00f6z\u00fc, \"\u0130yi kod, yoruma ihtiya\u00e7 duymaz\" bu prensibi \u00e7ok net bir \u015fekilde \u00f6zetler. \u0130deal olarak, kodunuz o kadar a\u00e7\u0131k, anlaml\u0131 ve kendi kendini a\u00e7\u0131klay\u0131c\u0131 olmal\u0131d\u0131r ki, ek bir yoruma gerek kalmas\u0131n. Ancak bu, yorumlar\u0131n tamamen yasak oldu\u011fu anlam\u0131na gelmez. Yorumlar, kodun \"neden\" yap\u0131ld\u0131\u011f\u0131n\u0131 veya \"nas\u0131l\" yap\u0131ld\u0131\u011f\u0131na dair belirli karma\u015f\u0131k algoritmalar\u0131 a\u00e7\u0131klamak gibi \u00f6zel durumlar i\u00e7in hala de\u011ferlidir. \u00d6rne\u011fin, bir i\u015f kural\u0131n\u0131n arkas\u0131ndaki yasal bir zorunlulu\u011fu veya belirli bir performans optimizasyonunun arkas\u0131ndaki teknik karar\u0131 a\u00e7\u0131klayan yorumlar faydal\u0131 olabilir. Ancak, kodun ne yapt\u0131\u011f\u0131n\u0131 a\u00e7\u0131klayan yorumlar (ki bu genellikle k\u00f6t\u00fc isimlendirme veya k\u00f6t\u00fc yap\u0131land\u0131r\u0131lm\u0131\u015f kodun sonucudur) sadece g\u00fcr\u00fclt\u00fc yarat\u0131r ve zamanla koddan uzakla\u015farak yanl\u0131\u015f bilgiye d\u00f6n\u00fc\u015febilir. Eski ve g\u00fcncel olmayan yorumlar, kod taban\u0131nda ciddi yanl\u0131\u015f anlamalara yol a\u00e7abilir ve hata ay\u0131klama s\u00fcrecini daha da karma\u015f\u0131k hale getirebilir. Dolay\u0131s\u0131yla, yorum yazmadan \u00f6nce daima kendinize \u015fu soruyu sorun: \"Bu yorumu yazmak yerine, kodu daha a\u00e7\u0131klay\u0131c\u0131 hale getirebilir miyim?\"<\/p>\n Yorumlar\u0131n faydal\u0131 olabilece\u011fi durumlar:<\/p>\n K\u00f6t\u00fc yorum \u00f6rnekleri:<\/p>\n <\/code><\/p>\n Sonu\u00e7 olarak, temiz kod, yorumlara ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 en aza indiren koddur. Yorumlar, kodun kendisiyle \u00e7eli\u015febilir, g\u00fcncelli\u011fini yitirebilir ve ek bir bak\u0131m y\u00fck\u00fc olu\u015fturabilir. Amac\u0131m\u0131z, kodumuzun kendisi arac\u0131l\u0131\u011f\u0131yla en net \u015fekilde ileti\u015fim kurmas\u0131n\u0131 sa\u011flamakt\u0131r.<\/p>\n Yaz\u0131l\u0131m\u0131n kalitesi sadece do\u011fru \u00e7al\u0131\u015ft\u0131\u011f\u0131nda de\u011fil, beklenmedik durumlarda veya hatalarda nas\u0131l davrand\u0131\u011f\u0131yla da \u00f6l\u00e7\u00fcl\u00fcr. Temiz kod felsefesi, hata y\u00f6netiminin de temiz ve \u00f6ng\u00f6r\u00fclebilir olmas\u0131n\u0131 savunur. Hatalar\u0131 do\u011fru bir \u015fekilde ele almak, uygulaman\u0131n sa\u011flaml\u0131\u011f\u0131n\u0131 art\u0131r\u0131r ve kullan\u0131c\u0131 deneyimini olumsuz etkileyecek kesintileri minimize eder. Uncle Bob, \"Hatalar\u0131 kontrol etmek, programlaman\u0131n \u00f6nemli bir par\u00e7as\u0131d\u0131r\" der ve hata kodlar\u0131 yerine istisnalar\u0131n (exceptions) kullan\u0131lmas\u0131n\u0131 \u00f6nerir. Hata kodlar\u0131, genellikle bir fonksiyonun d\u00f6n\u00fc\u015f de\u011ferini kirletir ve \u00e7a\u011fr\u0131 yapan taraf\u0131n her zaman bu hata kodunu kontrol etmesini gerektirir ki bu da \u00e7o\u011fu zaman g\u00f6z ard\u0131 edilir. \u0130stisnalar ise, hata durumlar\u0131n\u0131 program\u0131n normal ak\u0131\u015f\u0131ndan ay\u0131rarak, daha temiz ve odaklanm\u0131\u015f bir hata i\u015fleme mekanizmas\u0131 sunar. Bir istisna f\u0131rlat\u0131ld\u0131\u011f\u0131nda, program ak\u0131\u015f\u0131 do\u011frudan hatay\u0131 yakalayan blo\u011fa atlar, bu da gereksiz <\/code><\/p>\n Yukar\u0131daki iyi \u00f6rnek, hata y\u00f6netimini daha temiz ve anla\u015f\u0131l\u0131r hale getirir. \u00c7a\u011f\u0131ran kod, hata durumunu a\u00e7\u0131k\u00e7a Hata y\u00f6netiminin yan\u0131 s\u0131ra, temiz kodun temel direklerinden biri de test edilebilirliktir. Test edilebilir kod, mod\u00fcler, ba\u011f\u0131ms\u0131z ve k\u00fc\u00e7\u00fck par\u00e7alara ayr\u0131lm\u0131\u015f demektir. Her bir birim (fonksiyon, s\u0131n\u0131f) kendi ba\u015f\u0131na test edilebilir olmal\u0131d\u0131r. Bu, birim testlerinin kolayca yaz\u0131labilmesini ve kodun beklenen \u015fekilde \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olunmas\u0131n\u0131 sa\u011flar. Test edilebilirli\u011fin y\u00fcksek olmas\u0131, hata ay\u0131klama maliyetlerini d\u00fc\u015f\u00fcr\u00fcr ve yeni \u00f6zelliklerin veya de\u011fi\u015fikliklerin g\u00fcvenle sisteme entegre edilmesine olanak tan\u0131r. Uncle Bob, Test-Driven Development (TDD) yakla\u015f\u0131m\u0131n\u0131n, temiz ve test edilebilir kod yazmak i\u00e7in g\u00fc\u00e7l\u00fc bir ara\u00e7 oldu\u011funu savunur. TDD'de, kod yazmadan \u00f6nce testler yaz\u0131l\u0131r. Bu yakla\u015f\u0131m:<\/p>\n Sonu\u00e7 olarak, sa\u011flam bir yaz\u0131l\u0131m geli\u015ftirmek i\u00e7in hem etkili bir hata y\u00f6netimi stratejisi benimsemek hem de y\u00fcksek test edilebilirli\u011fe sahip kod yazmak vazge\u00e7ilmezdir. Bu iki prensip, yaz\u0131l\u0131m\u0131n hem mevcut durumda do\u011fru \u00e7al\u0131\u015fmas\u0131n\u0131 hem de gelecekteki de\u011fi\u015fikliklere kar\u015f\u0131 diren\u00e7li olmas\u0131n\u0131 sa\u011flar.<\/p>\n Modern yaz\u0131l\u0131m sistemleri giderek daha karma\u015f\u0131k hale geldik\u00e7e, bile\u015fenler aras\u0131ndaki ba\u011f\u0131ml\u0131l\u0131klar\u0131n y\u00f6netimi hayati \u00f6nem ta\u015f\u0131maktad\u0131r. Temiz kod felsefesi, gev\u015fek ba\u011fl\u0131 (loosely coupled) ve y\u00fcksek uyumlu (highly cohesive) mod\u00fcllerden olu\u015fan sistemleri te\u015fvik eder. Ba\u011f\u0131ml\u0131l\u0131k y\u00f6netimi, bir bile\u015fenin di\u011fer bile\u015fenlere olan ihtiya\u00e7lar\u0131n\u0131 nas\u0131l tan\u0131mlad\u0131\u011f\u0131n\u0131 ve kar\u015f\u0131lad\u0131\u011f\u0131n\u0131 ifade eder. S\u0131k\u0131 ba\u011fl\u0131 (tightly coupled) sistemlerde, bir bile\u015fenin di\u011fer bir bile\u015fenle olan s\u0131k\u0131 ba\u011flant\u0131s\u0131, birinde yap\u0131lan de\u011fi\u015fikli\u011fin di\u011ferini de etkileme riskini art\u0131r\u0131r. Bu durum, kodun esnekli\u011fini azalt\u0131r, test edilmesini zorla\u015ft\u0131r\u0131r ve yeniden kullan\u0131labilirli\u011fini engeller. Bu nedenle, Uncle Bob ve genel yaz\u0131l\u0131m m\u00fchendisli\u011fi prensipleri, Ba\u011f\u0131ml\u0131l\u0131k Enjeksiyonu (Dependency Injection - DI) ve Kontrol\u00fcn Tersine \u00c7evrilmesi (Inversion of Control - IoC) gibi teknikleri kullanarak ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00f6netmeyi \u00f6nerir. Bu yakla\u015f\u0131mlar, bir bile\u015fenin kendi ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 yaratmas\u0131 yerine, bu ba\u011f\u0131ml\u0131l\u0131klar\u0131n d\u0131\u015far\u0131dan sa\u011flanmas\u0131n\u0131 sa\u011flar. B\u00f6ylece, bile\u015fenler birbirlerinden daha ba\u011f\u0131ms\u0131z hale gelir ve bu da mod\u00fcler bir tasar\u0131m\u0131n \u00f6n\u00fcn\u00fc a\u00e7ar.<\/p>\n Mod\u00fcler tasar\u0131m\u0131n temel faydalar\u0131 \u015funlard\u0131r:<\/p>\n Bir e-ticaret uygulamas\u0131nda \u00fcr\u00fcn listeleme mod\u00fcl\u00fcn\u00fc d\u00fc\u015f\u00fcnelim. E\u011fer bu mod\u00fcl, veritaban\u0131na eri\u015fim, kullan\u0131c\u0131 yetkilendirmesi ve \u00f6nbellekleme gibi i\u015flevleri do\u011frudan kendi i\u00e7inde bar\u0131nd\u0131r\u0131yorsa, bu s\u0131k\u0131 bir ba\u011f\u0131ml\u0131l\u0131k yarat\u0131r. Bunun yerine, bu i\u015flevler ayr\u0131 ayr\u0131 servisler olarak tan\u0131mlanmal\u0131 ve \u00fcr\u00fcn listeleme mod\u00fcl\u00fcne d\u0131\u015far\u0131dan enjekte edilmelidir. B\u00f6ylece, veritaban\u0131 teknolojisi de\u011fi\u015fti\u011finde veya farkl\u0131 bir \u00f6nbellekleme mekanizmas\u0131 kullan\u0131ld\u0131\u011f\u0131nda, sadece ilgili servisi de\u011fi\u015ftirmek yeterli olur; \u00fcr\u00fcn listeleme mod\u00fcl\u00fcn\u00fc ba\u015ftan yazmaya gerek kalmaz.<\/p>\n Mod\u00fcler tasar\u0131m ve do\u011fru ba\u011f\u0131ml\u0131l\u0131k y\u00f6netimi, sadece kodun kendisi i\u00e7in de\u011fil, ayn\u0131 zamanda projenin uzun vadeli sa\u011fl\u0131\u011f\u0131 ve \u00f6l\u00e7eklenebilirli\u011fi i\u00e7in de kritik \u00f6neme sahiptir. Bu prensipleri benimsemek, gelecekteki de\u011fi\u015fikliklere kolayca adapte olabilen, bak\u0131m\u0131 kolay ve sa\u011flam yaz\u0131l\u0131m sistemleri in\u015fa etmenin anahtar\u0131d\u0131r.<\/p>\n Temiz kod prensiplerinin teorik faydalar\u0131 a\u00e7\u0131kt\u0131r, ancak bunlar\u0131n ger\u00e7ek d\u00fcnya projelerindeki somut etkilerini g\u00f6rmek, motivasyonu art\u0131r\u0131r. Bir\u00e7ok \u015firket, ba\u015flang\u0131\u00e7ta h\u0131zl\u0131 teslimat bask\u0131s\u0131yla temiz koddan \u00f6d\u00fcn vererek \"\u00e7al\u0131\u015fan ama kirli\" bir kod taban\u0131 olu\u015fturur. K\u0131sa vadede bu bir avantaj gibi g\u00f6r\u00fcnse de, orta ve uzun vadede maliyetleri katlayarak teknik borca yol a\u00e7ar. Gelin, hayali bir e-ticaret projesi \u00fczerinden bu durumu inceleyelim:<\/p>\n \"H\u0131zl\u0131 Pazar\" adl\u0131 bir startup, pazara h\u0131zla girmek amac\u0131yla minimum temiz kod prensipleriyle bir e-ticaret platformu geli\u015ftirir. \u0130lk aylarda her \u015fey yolunda gider, yeni \u00f6zellikler h\u0131zla eklenir. Ancak alt\u0131 ay sonra, sorunlar ba\u015f g\u00f6stermeye ba\u015flar:<\/p>\n Sonu\u00e7:<\/b> H\u0131zl\u0131 Pazar, bu durumdan dolay\u0131 a\u015fa\u011f\u0131daki zorluklarla kar\u015f\u0131la\u015ft\u0131:<\/p>\n H\u0131zl\u0131 Pazar y\u00f6netimi, teknik borcun s\u00fcrd\u00fcr\u00fclemez oldu\u011funu fark edip, bir \"temiz kod\" refactoring projesi ba\u015flatt\u0131. Uncle Bob'un prensiplerini uygulayarak:<\/p>\n Sonu\u00e7:<\/b> Refactoring sonras\u0131nda H\u0131zl\u0131 Pazar'\u0131n ya\u015fad\u0131\u011f\u0131 de\u011fi\u015fimler g\u00f6zle g\u00f6r\u00fcl\u00fcr oldu:<\/p>\n Bu senaryo, temiz kod prensiplerine yat\u0131r\u0131m yapman\u0131n, k\u0131sa vadeli bir yava\u015flama gibi g\u00f6r\u00fcnse de, uzun vadede projenin ba\u015far\u0131s\u0131, maliyet etkinli\u011fi ve geli\u015ftirici memnuniyeti a\u00e7\u0131s\u0131ndan nas\u0131l paha bi\u00e7ilmez faydalar sa\u011flad\u0131\u011f\u0131n\u0131 a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Temiz kod, sadece teknik bir tercih de\u011fil, ayn\u0131 zamanda i\u015f s\u00fcre\u00e7lerini ve proje ba\u015far\u0131s\u0131n\u0131 do\u011frudan etkileyen stratejik bir karard\u0131r.<\/p>\n G\u00fcn\u00fcm\u00fczde mobil cihazlar \u00fczerinden internet eri\u015fimi, masa\u00fcst\u00fc cihazlar\u0131 geride b\u0131rakm\u0131\u015f durumda. Bu nedenle, web sitelerinin ve uygulamalar\u0131n\u0131n mobil uyumlu (responsive) olmas\u0131 art\u0131k bir l\u00fcks de\u011fil, zorunluluktur. Temiz kod prensipleri, mobil uyumlu tasar\u0131m\u0131n geli\u015ftirilmesi ve s\u00fcrd\u00fcr\u00fclmesinde de kilit bir rol oynar. \u0130yi yap\u0131land\u0131r\u0131lm\u0131\u015f, okunabilir ve mod\u00fcler HTML, CSS ve JavaScript kodu, responsive bir tasar\u0131m\u0131n temelini olu\u015fturur. Kirli veya karma\u015f\u0131k kod, farkl\u0131 cihaz ekran boyutlar\u0131na adapte olabilen esnek bir aray\u00fcz olu\u015fturmay\u0131 ve s\u00fcrd\u00fcrmeyi zorla\u015ft\u0131r\u0131r. \u00d6rne\u011fin, bir stil de\u011fi\u015fikli\u011finin beklenmedik yan etkilere yol a\u00e7mamas\u0131 i\u00e7in CSS kodunun temiz, d\u00fczenli ve \u00f6zelle\u015ftirilebilir olmas\u0131 gerekir. Benzer \u015fekilde, JavaScript kodunun performans\u0131, \u00f6zellikle mobil cihazlarda, kullan\u0131c\u0131 deneyimini do\u011frudan etkiler. Temiz JavaScript, gereksiz hesaplamalardan ka\u00e7\u0131narak ve etkin algoritmalar kullanarak daha h\u0131zl\u0131 y\u00fckleme s\u00fcreleri ve daha ak\u0131c\u0131 etkile\u015fimler sa\u011flar.<\/p>\n Temiz kodun mobil uyumlu tasar\u0131ma katk\u0131lar\u0131 \u015funlard\u0131r:<\/p>\n Responsive bir web sayfas\u0131n\u0131n nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131na dair basit bir \u00f6rnek, CSS'in media query'leri kullanarak farkl\u0131 ekran boyutlar\u0131na nas\u0131l tepki verdi\u011fini g\u00f6sterir. Bu CSS kodunun iyi d\u00fczenlenmi\u015f ve okunabilir olmas\u0131, farkl\u0131 breakpoint'ler (k\u0131r\u0131lma noktalar\u0131) eklemeyi veya mevcut stilleri de\u011fi\u015ftirmeyi kolayla\u015ft\u0131r\u0131r:<\/p>\nint y;<\/code> yerine int userAge;<\/code> veya int customerAgeInYears;<\/code> kullanmak, kodun amac\u0131n\u0131 an\u0131nda ortaya koyar. Benzer \u015fekilde, bir fonksiyonun ad\u0131, o fonksiyonun ne yapt\u0131\u011f\u0131n\u0131 a\u00e7\u0131k\u00e7a belirtmelidir. processData();<\/code> gibi belirsiz bir isim yerine calculateTotalPrice();<\/code> veya authenticateUserCredentials();<\/code> gibi isimler, fonksiyonun i\u015flevini tam olarak yans\u0131t\u0131r. Bu, \u00f6zellikle farkl\u0131 ekiplerin veya yeni kat\u0131lan geli\u015ftiricilerin projeye adapte olmas\u0131nda kritik bir rol oynar. \u0130simlendirme yaparken \u015funlara dikkat edebiliriz:<\/p>\n\n
Fonksiyonlar ve Sorumluluklar: Tek \u0130\u015f Prensibi Nas\u0131l Uygulan\u0131r?<\/h3>\n
\n\/\/ K\u00f6t\u00fc \u00d6rnek: Birden fazla sorumlulu\u011fu olan b\u00fcy\u00fck fonksiyon\nfunction processUserRegistration(user) {\n \/\/ 1. Kullan\u0131c\u0131 verilerini do\u011frula\n if (!user.username || user.username.length < 3) {\n throw new Error(\"Kullan\u0131c\u0131 ad\u0131 ge\u00e7ersiz.\");\n }\n if (!user.email || !user.email.includes(\"@\")) {\n throw new Error(\"E-posta ge\u00e7ersiz.\");\n }\n\n \/\/ 2. Kullan\u0131c\u0131y\u0131 veritaban\u0131na kaydet\n const newUser = { id: generateId(), ...user };\n database.save(newUser);\n\n \/\/ 3. Ho\u015f geldiniz e-postas\u0131 g\u00f6nder\n emailService.sendWelcomeEmail(newUser.email, newUser.username);\n\n \/\/ 4. Kay\u0131t logunu olu\u015ftur\n logger.log(\"Yeni kullan\u0131c\u0131 kaydedildi: \" + newUser.username);\n\n return { success: true, user: newUser };\n}\n\n\/\/ \u0130yi \u00d6rnek: Tek sorumluluklu k\u00fc\u00e7\u00fck fonksiyonlar\nfunction validateUser(user) {\n if (!user.username || user.username.length < 3) {\n throw new Error(\"Kullan\u0131c\u0131 ad\u0131 ge\u00e7ersiz.\");\n }\n if (!user.email || !user.email.includes(\"@\")) {\n throw new Error(\"E-posta ge\u00e7ersiz.\");\n }\n return true;\n}\n\nfunction saveUserToDatabase(user) {\n const newUser = { id: generateId(), ...user };\n database.save(newUser);\n return newUser;\n}\n\nfunction sendWelcomeEmail(email, username) {\n emailService.sendWelcomeEmail(email, username);\n}\n\nfunction logUserRegistration(username) {\n logger.log(\"Yeni kullan\u0131c\u0131 kaydedildi: \" + username);\n}\n\nfunction registerUser(user) {\n validateUser(user);\n const savedUser = saveUserToDatabase(user);\n sendWelcomeEmail(savedUser.email, savedUser.username);\n logUserRegistration(savedUser.username);\n return { success: true, user: savedUser };\n}\n <\/pre>\nYorumlar ve Kod A\u00e7\u0131klamalar\u0131: Ne Zaman ve Nas\u0131l Kullan\u0131lmal\u0131?<\/h3>\n
\n
\n\/\/ K\u00f6t\u00fc \u00d6rnek 1: A\u00e7\u0131k kodu a\u00e7\u0131klayan yorum\nconst userName = \"Alice\"; \/\/ Kullan\u0131c\u0131 ad\u0131n\u0131 tan\u0131mlar (Gereksiz)\n\n\/\/ K\u00f6t\u00fc \u00d6rnek 2: Kodun s\u00f6yledi\u011finden fazlas\u0131n\u0131 s\u00f6ylemeyen yorum\nfunction calculateSum(a, b) {\n \/\/ a ve b'nin toplam\u0131n\u0131 hesaplar (Fonksiyon ad\u0131 zaten a\u00e7\u0131kl\u0131yor)\n return a + b;\n}\n\n\/\/ K\u00f6t\u00fc \u00d6rnek 3: G\u00fcncel olmayan yorum\n\/\/ Bu fonksiyon, kullan\u0131c\u0131lar\u0131 eski sistemde do\u011frular (Ama art\u0131k yeni sistemde do\u011fruluyor!)\nfunction authenticateUser(user) {\n \/\/ ...\n}\n <\/pre>\nHata Y\u00f6netimi ve Test Edilebilirlik: Sa\u011flam Kodu Nas\u0131l \u0130n\u015fa Ederiz?<\/h2>\n
if<\/code> zincirlerinden ka\u00e7\u0131nmay\u0131 sa\u011flar. Ancak istisnalar\u0131n da do\u011fru kullan\u0131lmas\u0131 \u00f6nemlidir; kontrol ak\u0131\u015f\u0131 i\u00e7in istisnalar kullanmaktan ka\u00e7\u0131n\u0131lmal\u0131d\u0131r.<\/p>\n\n\/\/ K\u00f6t\u00fc \u00d6rnek: Hata kodlar\u0131 ile hata y\u00f6netimi\nfunction divide(numerator, denominator) {\n if (denominator === 0) {\n return -1; \/\/ Hata kodu\n }\n return numerator \/ denominator;\n}\n\nlet result = divide(10, 0);\nif (result === -1) {\n console.error(\"S\u0131f\u0131ra b\u00f6lme hatas\u0131!\");\n} else {\n console.log(\"Sonu\u00e7: \" + result);\n}\n\n\/\/ \u0130yi \u00d6rnek: \u0130stisnalar ile hata y\u00f6netimi\nfunction safeDivide(numerator, denominator) {\n if (denominator === 0) {\n throw new Error(\"S\u0131f\u0131ra b\u00f6lme hatas\u0131 alg\u0131land\u0131.\");\n }\n return numerator \/ denominator;\n}\n\ntry {\n let result = safeDivide(10, 0);\n console.log(\"Sonu\u00e7: \" + result);\n} catch (error) {\n console.error(\"Hata yakaland\u0131: \" + error.message);\n}\n <\/pre>\ncatch<\/code> blo\u011funda ele al\u0131r.<\/p>\n\n
Ba\u011f\u0131ml\u0131l\u0131k Y\u00f6netimi ve Mod\u00fcler Tasar\u0131m: Esnek Sistemler Nas\u0131l Olu\u015fturulur?<\/h3>\n
\n
Ger\u00e7ek D\u00fcnya Senaryolar\u0131: Temiz Kodun Projelerdeki Etkisi<\/h2>\n
Vaka Analizi: \"H\u0131zl\u0131 Pazar\" E-ticaret Platformu<\/h3>\n
\u00d6ncesi: Kirli Kodun Yarat\u0131\u011f\u0131<\/h4>\n
\n
a<\/code>, b<\/code>, temp<\/code>, data<\/code> gibi genel isimler her yerde kullan\u0131l\u0131yor, bir de\u011fi\u015fkene bak\u0131ld\u0131\u011f\u0131nda ne i\u015fe yarad\u0131\u011f\u0131 anla\u015f\u0131lam\u0131yordu. Bu, hata ay\u0131klama s\u00fcresini uzat\u0131yordu.<\/li>\n\n
Sonras\u0131: Temiz Kod Refactoring ve Ba\u015far\u0131<\/h4>\n
\n
calculateDiscount<\/code>, applyShippingCost<\/code>, processPaymentWithGateway<\/code> vb.) b\u00f6l\u00fcnd\u00fc.<\/li>\ncustomerOrder<\/code>, productPriceCalculator<\/code>).<\/li>\n\n
Mobil Uyumlu Tasar\u0131m ve Temiz Kod \u0130li\u015fkisi: Performans ve Eri\u015filebilirlik<\/h2>\n
\n
\n