Kendinizi bir profesyonel olarak adlandırmak istiyorsanız temiz kod yazmalısınız. Elinizden gelenin en iyisini yapmamak için mantıklı bir mazeret yoktur.
Robert Martin, Clean Code
Nesne Tabanlı Programlama dilleri ile büyük kurumsal yazılımlar üzerinde çalışan herkesin okuması gereken en önemli kitaplardan biri olan Clean Code’u okuyorum.
Robert “Bob Amca” Martin’in bu şaheserini daha önce okuma girişimlerim başarısız olmuştu çünkü dikkatli bir şekilde, not alarak, altını çizerek hatta daha iyisi kod yazarak okunması gereken bu kitaba ciddi zaman ayırmak gerekiyor ve bu zamanı bulmak da kolay değil.
Robert Martin, bu kitapta, temiz kod yazma perspektifinden; object priented programming, unit test, exception handling, concurrency gibi pek çok kavramı ele alıyor.
400 küsür sayfalık bu kitabın yarısına yaklaştım ve pek çok not aldım. Bu notlardan en önemli olanlarını fırsat buldukça paylaşmak istiyorum. Yazının bundan sonrası, naçizane çevirimle Robert Martin’in cümleleri olacak. Arada Benim Notum diye belirttiğim bazı notlar ve en sonda da son yorumlarım olacak.
Giriş
Temiz kod yazmayı öğrenmek zordur. Bu konuda bilgi sahibi olmanız yeterli değildir. Temiz kod yazmaya çalışırken ter dökmelisiniz. Pratik yapmalı ve başarısız olmanızı izlemelisiniz. Başkalarının pratik yapmasını ve başarısız olmasını izlemelisiniz.
Bölüm 1 : Temiz Kod
Kötü Kod
Seksenlerde bir firma çok iyi bir uygulama yazmıştı. Çok popülerdi ve pek çok profesyonel bu yazılımı satın alıp kullanmıştı. Daha sonra versiyon yayınlama aralığı seyrekleşti. Hatalar düzeltilmedi. Yükleme süreleri uzadı ve her versiyonda daha fazla çökme yaşanmaya başladı. Bir gün hayal kırıklığıyla uygulamayı kapattım ve bir daha hiç kullanmadım. Kısa süre sonra iflas ettiler.
20 yıl kadar sonra firmanın yazılımcılarından biriyle tanıştım ve ona ne olduğunu sordum. Cevap korkularımı doğruladı: Ürünü pazara sunmak için acele etmişler ve bunu yaparken darmadağın bir kod yığını oluşturmuşlardı. Ürüne özellik ekledikçe kod yığını daha kötü olmuş ve kod yönetilemez hale gelmişti. Kötü kod bir firmayı batırmıştı.
Dağınıklığa sahip olmanın bedeli
Bir yazılımcı olarak deneyim sahibiyseniz mutlaka kötü kod tarafından yavaşlatılmışsınızdır.
Robert Martin
Projenin başında çok hızlı ilerleyen takım bir iki yıl içerisinde salyangoz hızına düşer.
Yeniden başlamak isterler. Yönetim önce itiraz eder ama düşük verimlilik sebebiyle kabul ederler.
Yeniden yazma işi bittiğinde yazılımcılar gitmiştir ve yeni yazılımcılar yeniden başlamak istemektedir. Çünkü kod kötüdür.
İsterlerin değiştiğinden, sıkı takvimden, aptal yöneticilerden, hoşgörüsüz müşterilerden vb şikayet ederiz. Ama Dilbert, problem bizde. Biz profesyonel değiliz.
Eğer yöneticimin istediklerini yapmazsam kovulurum diyebilirsiniz. Muhtemelen hayır. Yöneticiler öyle görünmeseler de doğruyu duymak isterler. Takvimlerine karşılı takıntılı gibi görünseler de aslında onlar da iyi kod ister. Onlar takvimlerini ve isterleri tutkuyla savunabilirler. Bu onların işi. Sizin işiniz de kodunuzu aynı tutkuyla savunmak.
Bir cerrah, patronu istediği için ameliyat öncesinde el yıkamaktan vaz geçer mi ? Hayır. O halde yazılımcılar da yönetimin profesyonel olmayan isteklerini uygulamamalılar.
Temel Çelişki
En az bir kaç yıl deneyimi olan tüm yazılımcılar (önceki yazılımcıların bıraktığı) dağınıklığın onları yavaşlattığını söylerler. Ve aynı yazılımcılar, takvime yetişebilmek için kendileri de dağınıklık yaratırlar.
Gerçek profesyoneller bu çelişkinin ikinci kısmının yanlış olduğunu bilirler. Kötü kod yazarak takvime yetişilmez. Yarattığınız karmaşa sizi yavaşlatır ve takvime yetişmenize engel olur. Takvime yetişmenin tek gerçek yolu – hızlı gitmenin tek yolu – kodu her zaman olabildiğince temiz tutmaktır.
Benim Notum: Nesne Yönelimli Programlama ile düzgün kod yazmaya çalışmış herkes burada bahsedilen şeyi anlayacaktır. Düzgün kod yazmak istiyorsanız başlangıç hızınız düşük olur. Ama bu aşamayı atlatırsanız, yazılımınız büyüdükçe, ek özellikler eklemek ilk başta yaptığınız alt yapı yatırımı sayesinde oldukça kolaylaşmış olacaktır.
Temiz Kod nedir ?
Kötü kod kötü kodu doğurur. Kötü kod üzerinde çalışırken onu daha kötü hale getirme eğilimindeyizdir.
Temiz kod, orijinal yazarı dışında bir geliştirici tarafından okunabilir ve geliştirilebilir. Birim ve kabul testleri vardır. Anlamlı isimleri vardır. Bir şeyi yapmak için birçok yol yerine tek yol sağlar. Minimum bağımlılıkları vardır. Açıkça tanımlanmış ve minimal bir API sağlar.
“Big” Dave Thomas
Testleri olmayan kod temiz değildir. Ne kadar zarif olursa olsun, ne kadar okunabilir ve erişilebilir olursa olsun, test edilmeyen kod, kirlidir.
Benim Notum: Robert Martin, bu işin tüm büyük ustaları gibi ateşli bir unit test savunucusu. Unit Test’i olmayan kodu değiştirdiğinizde yazılımın başka yerlerini bozma ihtimaliniz artar. Bu noktada yine hızlı gitmek için yavaş git felsefesi devreye girmektedir. Unit Test’ler sizi düzgün bir oop implementasyonu yapmaya zorlarlar. Bu da başlangıçta normalden bir kat daha yavaş kod yazmanıza sebep olurken, uzun vadede kazanan siz olursunuz. Kitabın unit test’le ilgili bölümünde unit testlerin neden bu kadar önemli olduğu çok detaylı bir biçimde açıklanıyor. Yakında o bölüme dair notlarımı da yayınlayacağım.
Bir nesnenin veya metodun birden fazla şey yapıp yapmadığına bakarım. Bir nesne birden fazla iş yapıyorsa muhtemelen iki veya daha fazla nesneye bölünmelidir. Bir metot birden fazla iş yapıyorsa, metodu parçalara böler, ne yaptığını daha net bir şekilde söyleyen bir metot ve bazı alt metotlar haline getirerek temiz bir hale getiririm.
Bizler Yazarlarız
Javadoc’taki @author(yazar) alanı bizim ne olduğumuzu anlatmaktadır. Bizler yazarlarız. Yazarların da okuyucuları vardır ve elbette bu okuyuculara kendilerini anlatmak yazarların görevidir. Bir daha tek satır olsun kod yazacağınız zaman unutmayın ki siz bir yazarsınız ve okuyucularınız sizi yazdığınız kodla yargılayacaklar.
Yavru Kurt Kuralı
Kamp alanını bulduğunuzdan daha temiz bırakın.
Eğer her birimiz, her bir commit’imizde kodu biraz daha temiz göndersek, kodumuz kaosa sürüklenmezdi. Her seferinde bir değişkenin ismini değiştirin, büyük bir metodu parçalayın, tekrar eden bir kaç satır kodu ortadan kaldırın.
Bölüm 2: İsimlendirme
İsim Amacı Belli Etmeli
- İsim amacı belli etmeli.
- İyi isim seçmek zaman alır. Ama aldığından fazla zamanı kazandırır. Bu yüzden isim seçmeye vakit ayırın ve daha iyi isimler buldunuz zaman eskileri değiştirin.
- Bir değişkenin adı size neden var olduğunu, ne yaptığını ve nasıl kullanıldığını anlatmalı. Eğer yorum yazmanız gerekiyorsa, değişkenin ismi amacını belli etmiyordur.
Aşağıdaki iki kodu inceleyin. İlk kodun ne yaptığını anlamak imkansız iken, ikinci kod ne yaptığını açıkça anlatıyor. Her iki kodun yaptığı iş ve yapıları kesinlikle aynı. Tek fark isimler.
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}public List<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
if (cell.isFlagged())
flaggedCells.add(cell);
return flaggedCells;
}Telaffuz edilebilir isimler seçin
Bir ismi telaffuz edemiyorsanız üzerine tartışamazsınız. Aşağıdaki iki örneği inceleyin. Kodun ikinci örnekte gelmiş olduğu durumda class ve metot isimleri telaffuz edilebilir hale gelmiştir.
class DtaRcrd102 {
private Date genymdhms;
private Date modymdhms;
private final String pszqint = "102"; };class Customer {
private Date generationTimestamp;
private Date modificationTimestamp;;
private final String recordId = "102"; };Aranılabilir isimler seçin
- Sınıftaki maksimum öğrenci sayısının değiştiğini düşünün. Kodun içerisinde arama yaparken MAX_CLASSES_PER_STUDENT metnini bulmak 7 metnini bulmaktan çok daha kolaydır.
- Benim Notum: buradaki 7 bir magic number. Bu sihirli sayı kodu okuyana ilk etapta hiç bir şey ifade etmez. Sonradan edeceği de şaibeli. Sayılar kodun içerisinde şekilde kullanılmamalı, sabit haline getirilmeli.
- Aynı şekilde bir değişkene e ismini vermek de iyi fikir değil. İngilizcede en sık kullanılan harf olan e’yi kodun içinde ararsanız pek çok yerde karşınıza çıkabilir.
- Bence, tek harfli isimler yalnızca yerel metotlarda kullanımalı.
Profesyonel bir yazılımcının akıllı bir yazılımcıdan farkı, netliğin en önemli şey olduğunu bilmesidir. Profesyoneller, yeteneklerini başkalarının anlayabileceği kadar iyi kod yazmak için kullanırlar.
Robert Martin
Aşırı Yükleme yerine statik fabrikalar
Yapıcı metotlarınızı(constructor) aşırı yükleme(overload) yapmak yerine statik fabrika metotları oluşturursanız oluşabilecek bazı belirsizliklerin önüne geçebilirsiniz.
Complex fulcrumPoint = new Complex(23.0); Complex fulcrumPoint = Complex.FromRealNumber(23.0); Bu metotların kullanılmasını zorlamak için public yapıcı metotlarınızı private yaparak gizleyebilirsiniz.
Her konsept için tek kelime kullanın
Fetch, retrieve ve get gibi hepsi aynı anlama gelen isimleri aynı projede farklı yerlerde kullanmayın. Bunlardan birini seçin ve onla devam edin.
Bu tür ayrımları yapmak için projeye özgü bir sözlük, bir standartlar dokümanı hazırlamak iyi olabilir.
Yazar rolümüzle amacımız kodumuzun mümkün olduğunca anlaşılabilir olmasıdır. Kodumuzun yoğun bir çalışmayla değil, ilk okumayla anlaşılabilir olmasını isteriz. Kod yazarken; akademide olduğu gibi anlamak okuyucunun sorumluluğunda değil, edebiyatta olduğu gibi kendini ifade etmek yazarın sorumluluğunda olmalı.
Robert Martin
Gereksiz eklemeler yapmayın
Gas Station Deluxe adlı hayali bir uygulama yazdığımızı düşünelim. Her sınıfa GSD kısaltması ile başlamak son derece gereksizdir.
Herhangi bir isme gerekenden fazla içerik eklemeyin.
Son sözler(Bölüm 2)
Yazılımcılar, bir şeylerin adını değiştirmekten başka yazılımcıların itiraz edeceği sebebiyle çekinirler. Biz bu çekinceye katılmıyoruz ve yeniden isimlendirme düzgün bir şekilde yapılmışsa müteşekkir oluyoruz. Çoğu zaman sınıfların ve metotların ismini hatırlamayız. Modern araçların(IDE) bu konuda sunduğu kolaylıklardan faydalanırız. Böylece dikkatimizi kodumuzun paragraflar ve cümleler gibi güzel okunabilir olmasına ayırabiliriz(ya da en azından tablo ve satırları gibi. cümleler her şeyi açıklamak için her zaman en iyi yöntem olmayabilir)
Benim yorumlarım
Temiz kod yazmak zordur ama bu zahmete değer. Temiz kod yamayı öğrenmek için gereken bedeli(zaman) ödemeliyiz. Uzun vadede kazancımız kaybımızdan çok daha büyük olacaktır.
Bir şeyleri değiştirmekten çekinmemeliyiz. Kodun iyi olması bizim sorumluluğumuzda. Bahane bulmamalı, üstümüze düşeni yapmalıyız.
Her yazılımcı bir yazardır ve yazarın görevi kendini düzgün ifade etmektir.
Temiz kod, iyi isimlendirmeyle başlar. Kodumuzun her bir parçası kendini ifade etmeli. Böylece bu koda geri döndüğümüzde ne yaptığımızı anlamamız daha kolay olur.