şükela:  tümü | bugün
  • robert c. martin'in temiz kod nasıl yazılır kitabı. code complete ile pişti olduğu çok yer olmasına rağmen son zamanlarda okumaktan en keyif aldığım ve en doyurucu yazılım kitabı diyebilirim. keşke çıktığı yılda, 2008'de okusaymışım diye de hayıflandım. zira hidayetine son senelerde erdiğim konuları hali hazırda anlatıyormuş.

    verdiği örnekler ağırlıklı java üzerinden ama kolayca popüler dillere uyarlanabilir. tavsiyelerin odağı nesne yönelimli programlama üzerine.

    http://www.amazon.com/…-craftsmanship/dp/0132350882
  • kodu okuyan kişinin, fonksiyonları, algoritmaları tek tek incelemeden isimlerinden kodu anlayabilmesine olanak veren,( method ismine abc değil de getxlocation şeklinde bir isim vermek gibi)

    genel görünümün okunaklı bir template çerçevesinde hazırlanılmasını sağlayan,

    her methodun tek bir spesific iş yaptığı,

    her coder'ın uygulaması gereken bir felsefedir. başkası kodu okurken çok rahatlar, zaman kazanır.
  • "robert c. martin" tarafindan yazilmis, tum yazilim gelistiricilerin okumasi gereken, ufuk acan bir bas ucu kitabi. okuyup bitirdikten sonra, eger gercekten kitapta verilen kurallar ve oneriler uygulanir ise gelistiriciye kendi koduna baktiginda mutluluk verecek bir kitap. bu kitabi okurken umumi tuvaletlere yazilan populer uyari 'nasil bulmak istiyorsan oyle birak !' geldi aklima.

    kitapta deginilen, aklimda kalan ve benim de birseyler ekledigim birkac noktayi soyle ozetleyebilirim;

    oncelikle temiz kod yazmamizin sebebi baska gelistiriciler degil daha cok biziz. yazdigim kod yiginlarinda kendi yazdigim kodlara yabancilastigim cok olur. bir kod yazarim, bir sene sonra o kodu kendi yazdigimi unutur "bu ne boktan bir kod, bunu yazanin ta ...." diye kufur ederim. kodun gecmisine baktigimda ise kendi adimi gordugumde acaba hangi kafa ile yazdim diye dusunurum. bu nedenle ilerde kendinize kufur etmek istemiyosaniz temiz kod yazin.

    temiz kod sadece iyi okunabilir kod degil, ayrica kolay yonetilebilir koddur. artik yazdigim kodlari bir lego oyuncak misali kucuk ama saglam parcalar seklinde yazmaya calisiyorum. peki ne kadar kucuk bu parcalar? her bir method sadece ve sadece 1 isden sorumlu olacak kadar kucuk(high coherent). o metod sadece verdigim isi yapiyor, cevresinde ne olup bittigi o metod icin onemli degil, isini yapip bitiriyor. bu sayede o methodun isini dogru yapip yapmagini test etmem kolay oluyor. bir baska avantaji da isini iyi yapan o kodu baska yerde de kullanabilmem. cunku bircok is yapan bir kod yigininda, kodu baska yerde kullanmak istediginizde bircok uyumsuzluk problemiyle karsilasmaniz olasi, kodun mutlaka bir yeri, yeni eklemek istediginiz yere ve duruma uygun olmayacaktir. ama tek bir konuda uzman kod diger yerlere daha kolay uyacaktir. tetris oyununu dusunun, cesitli sekillerdeki bloklarda en sevilen parcalar uzun cubuk ve kare olanlar. cunku bunlar basit, ve bu basit yapilari nedeniyle uyumlu. ozelikle o kare olan parca, harika bir parca, istedigin tarafa dondur, hep ayni ve dolayisi ile yonetmesi kolay. bir yazilimdaki methodlar da bu sekilde olacak kadar basit ve kisa olmali. peki bir methodun basitligini ilk bakista nasil test ediyorum? oncelikle 5 satirdan fazla olan kodlar gozume karmasik gelmeye basliyor. bir de kod icinde if-else blogu var ise bu if icindeki ve else icindeki kodlari baska methoda aliyorum, yoksa karmasik artiyor. bir de dongu var ise, hele bir de ic ice iki dongu, bunlarin icinde if-else bloklari, for donguleri, while, do while gibi donguler ayni method icindeyse hepsini mumkun oldugunca farkli methodlara aliyorum.

    methoda verilen isim cok onemli, bir methoda isim verirken "ne vereyim? ne versem olmuyor" diye dusunuyorsaniz buyuk ihtimal o method bir is degil bircok is yapiyor ve bu kodu kirletigimizin ilk sinyalleri. arabami sanayiye goturdugumde ustaya "sen ne ustasisin?" diye sordugumda usta bana "bir arabanin her isini yaparim, soker yine takarim" der ise bir korkarim. bir arabanin her seyini bilirim diyecek kadar buyuk ozguven herkesi korkutur. yada bir usta dusunun "kardes ben elektrik aksaminda cok iyiyim, arabanda elektrik problemi var ise bana gel, diger islere bulastirma beni" der ise o ustayi severim. "her isi yaparim" diyen adamdan korkacaksin, "her isi yaparim" diyen gelistiriciden de korkacaksin, "her isi yaparim" diyen methoddan kosaarak kacacaksin. method dedigin daha en basindan ismiyle yaptigi isi soyler, methodu cagirirken gozun arkada kalmaz. o nedenle ismi yaptigi isi aciklayan, kisa, temiz methodlar yazip, hem bu methodlari cagirken hem bu methodlari uygulamanin cesitli yerlerinde kullanirken kodu okumak cok daha keyifli olur.

    yazdigim kodda "comment" kullanmaktan nefret ediyorum. kod butunlugunu kaybediyor, islevi olmayan bircok satir eklenmis oluyor. bircok durumda da bu "comment" satirlari ekstradan hicbir bilgi vermiyor. koda comment yazmak yerine bol bol guzel isimli methodlar kullanin. elbette bircok durumda comment kullanmak durumundayiz, buna yapilabilecek birsey yok ama ne kadar az olursa o kadar iyi.

    kodu bu gun icin degil yarin icin yazmaya calismak da cok onemli. bazen bir method yazarim sadece 1 satir. 1 satirlik isi icin yeni bir method tanimlamak gerekir. cunku musteri istekleri bitmez bu 1 satir asla 1 satir kalmayacak. ısin kotusu baska methoda alinmadigi icin de sarmasik misali yanlis yerde uzayacak. erkenden bu tarz buyume riski olan kodlar mumkun oldugunca baska methoda alinmali. bunun yaninda 1 satir da olsa baska methoda alindan kod tekrar kullanilabilir olur (re-usability)

    bunlara ek olarak eger "unit test" leriniz yazildiysa (hatta yazilmasa da riski goze alarak) elinize gelen karmasik kodu temizleyin. hem sizin o kodu okumaniz kolay olur, hem de bir sonraki gelistiricinin hayir duasini alirsiniz.

    sacma sapan kisaltmalar da kullanmamak gerekli, insan okuyacak bunu. ornegin adam yazmis "idx", ya da "ctlıd", ne bu kardesim "identificationextension" ya da "catalogıd" de ki ne dedigini anlayalim. sen uzun yazdiginda kullandigin ıde her tekrarda tamamlayacak zaten, compiler da kisaltacak o ismi, yani sana ekstra yuk degil. ama okuyan nasil anlayacak o kisaltmadan ne dedigini. o nedenle yazarken insan okuyacak diye yazilmali.