Programcılar yazar olsalardı keşke! yazımı bugün tekrar okudum ve bir şey aklıma geldi; Bunu sizinle paylaşmak istedim.

Kod kalitesi deyince akla hemen yazılım testleri gelir. Kod kalitesinde madalyonun bir yüzü testler ise, diğer yüzü kodun okunabilirlik seviyesidir. İkisi bir araya geldiğinde müşteri gereksinimleri doğrultusunda hamur gibi yoğrulan uygulamalar geliştirilebilir.

Programcı olarak hepimizin ortak yani, yazdığımız kodun zaman içinde okunamaz hale gelmesidir. Bunun birçok nedeni var. Nedenlerin hepsini çok iyi biliyoruz, ama ne yazık ki kötü kod yazmaktan da vazgeçemiyoruz, çünkü artık bu bir alışkanlık haline gelmiş. Bu durumun kolay, kolay da değişeceğini zannetmiyorum.

Programcılar yazar olsalardı keşke! başlıklı yazımda programcıları kitap yazarlı ile kıyaslamıştım. Şimdi tekrar düşünüyorum da, belki bir kitabın oluşma sürecini örnek alarak, daha okunur kod yazmanın yollarını bulabiliriz, şöyle ki …

Bir kitap kitap olarak piyasaya sürülmeden önce kalite kontrolünden geçer. Bunu kitabın içeriğini kontrol eden redaktörler yapar. Redaktörler imla hatalarını düzeltirler, içeriği anlaşılır hale getirir ve yazarın konu dışına taşmasını engellerler. Redaktörler yazarlardan bağımsızdırlar. Genelde kitabın çıkacağı yayınevinde çalışırlar ya da hatta bu yayınevinden bile bağımsızdırlar. Bu bağımsızlık onların yazarın gözünün yaşına bakmayacak derecede gerekeni yapmalarını kolaylaştırır.

Şimdi kendimizi yazar olarak düşünecek olursak, yazdıklarımızı kontrol eden ve bizi hizaya sokan redaktörlerden yoksun olduğumuzu görebiliriz. Bakın, her yazılım ekibinde mutlaka testciler, gereksinim analizcileri, proje yöneticileri vs. vardır ama kodu gözden geçiren bir redaktör yoktur. Bunun çesitli sebepleri var. En önemli sebep, bizlerin progrmacı olarak kodun incelenmesine verdigimiz değer ve bu konuya bakış tarzımızdır. Programcı olarak bu konuya değişik şekillerde bakarız. Örneğin:

• Yazdığımız kodun başkaları tarafından incelenmesi ve düzeltilmesini gerekli görmeyiz, çünkü yazdığımız kod olması gerektiği şekildedir.
• Kod incele seanslarını (code review) angarya olarak görürüz, çünkü en iyi kodu yazdığımızdan böyle şeyler gereksizdir.
• Kod inceleme seanslarının önemine inanırız, ama bir kod incele seansında kritize edilmeyi kaldıramayız. Bu yüzden kod incele seanslarından mümkün mertebe uzak dururuz.

Klasik kod incele seansları çok verimsiz geçer, çünkü bir tarafta “aman ha, karşı tarafı yanlış bir şey söyleyerek kırmayayım” diğer tarafta “ne olursa olsun, yazdıklarımın arkasında durup, savunmalıyım, değiştirilmesine izin veremem!” prensibine göre uygulanırlar. Mevzu burada karşı tarafı kırmamak değil, kodu kırılmayacak hale getirmektir. Ama bunun anlaşılması çogu zaman kolay değildir, çünkü programcılar arasındaki kanka kültürü, karşı tarafa yüklenememe yetersizliği ve koda gereğinden fazla sahip çıkma içgüdüsü kod inceleme işini verimsiz ve gereksiz kılar.

Aynı ekip içinde çalışan ve birlikte kod yazan programcıların birbirlerini kod incele seanslarında kontrol etmeleri mümkün değildir, çünkü bunun için yeterli otoriteye sahip değildirler. İstenilen verimin alınabilmesi için ekipten bağımsız bir redaktörün bu işi eline alması gerekmektedir. Kod inceleme seanslarında “redaktör ne derse o geçerlidir, o yapılır” prensibi geçerli olmalıdır. Redaktörün okey vermediği kod birimleri uygulamanın bir parçası haline gelemez ve geri çevrilir.

Evet biliyorum, kod redaktörlerinden faydalanmak uçuk bir fikir, ama artık başımızı kaldırıp, bazı sorunları çözmek için yeni çözümlerin peşine düşmemiz gerekiyor. Kod redaktörlüğü de böyle bir çözüm olabilir. İlla sadece kod radaktörlüğü yapacak birisinin işe alınması gerekmiyor. Ekip içinde yeterli otoriteye ve bilgiye sahip birisi bu işi yapabilir, örneğin ekip lideri. Ama bu neye benziyor biliyor musunuz? Bu yayınevi patronunun piyasaya süreceği kitapları kendisinin kontrol etmesi gibi bir şey. Ekip liderinin de kendine has sorumlulukları ve çalışma alanları var. Ekip liderine kod redaktörlüğü sorumluluğunu da vermek ne kadar doğru olur, bilemiyorum. Bana doğru gibi gelmiyor. Nasıl Scrum’da bir Scrummaster, projede bir proje yöneticisi, sürümleri oluşturan sürüm yöneticisi varsa, proje bünyesinde kod kalitesini kontrol eden bir kod redaktörü de olmalı. Biliyorum, böyle bir pozisyon yine lüks olarak algılanacak, ama o zaman proje battı, kalite yerlerde serzenişlerini de hazırlıklı olunmalı.

Kod redaktörü ekip içinde huzursuzluğa neden olabilir. Programcılar sadece kod redaktörünü tatmin edebilmek için kod yazmaya başlayabilirler. Ama istediğimizde zaten tam da bu değil mi? Programcılar kafalarına göre takılmasınlar, belli standartlarda kod yazsınlar ve bunun kontrolcüsü ve bekçisi de kod redaktörü olsun. Patronunun söylediklerini yapmakta zorlanmayan bir programcının moralinin kod redaktörünün itirazları sonucu bozulacağını bir safsata olarak görüyorum. Nihayetinde programcı olarak amacımız ileriye gitmek ve daha iyi kod yazabilmek ise, birilerinin yaptığımız yanlışları düzeltmesinde ne gibi bir sakınca olabilir? Bu durumdan sadece benlik güden programcıların şikayet edeceği malum!

Kod redaktörünün sorumluluğu çok büyük. Bu yüzden yazılım yapma konusunda da çok büyük bir bilgi birikimine sahip olması gerekiyor. Bu birikim yazılım mimarilerinden tasarım şablonlarına, tasarım prensiplerinden çevik yazılım yöntemlerinin uygulanışına kadar çok geniş bir yelpazeyi kapsamak zorundadır. Bu durumda en az son on yılını aktif programcı olarak geçirmiş bir şahsın kod redaktörlüğü görevini layıkıyla yerine getirebileceğini düşünüyorum. Kod redaktörü de aslında bir programcı olduğu için çalışma zamanının belli bir kısmını ekip içinde programcılığa, belli bir kısmını da kod redaktörlüğüne ayırabilir. Bu durumda sadece kod redaktörü rolüne sahip bir programcıyı işe almak yerine, tecrübeli bir yazılımcıdan faydalanılabilir.

Er ya da geç her projede kod birimleri okunamaz hale geliyor, çünkü birden fazla programcı kontrolsüz bir şekilde kod birimlerini değiştiriyorlar. Projeler her zaman hızlı ilerlemeli filozofisiyle yönetiliyor. Okunurluk seviyesi düşük bir proje benzini bitmiş bir araba gibidir. Ne kadar o arabayı itmeye çalışsanız da, benzin koymadığınız sürece hızlı ilerleme özelliğinden faydalanamazsınız. Aynı şekilde okunurluk seviyesi düşük kodun da çok hızlı bir şekilde değiştirilmesi mümkün olmadığından, projenin hızlı ilerlemesi belli bir zaman sonra imkansız hale gelebilir. Yazımın başında da belirttigim gibi, hızlı ilerleyebilmek için madalyonun iki yüzünü de göz önünde bulundurmamız gerekiyor.

Programcıların kodun okunurluğuna çok önem vermedikleri bir dünyada kod redaktörlerine ihtiyaç büyük. Önümüzdeki zamanlarda projelerde böyle bir rolün olusması ümidiyle…

EOF (End Of Fun)
Özcan Acar

• Yazar Hakkında
• En Güncel Yazıları

Özcan Acar

Özcan Acar 1974 İzmir doğumludur. İlk ve orta öğrenimini İzmir’de tamamladı. Almanya'daki lise öğreniminden sonra doksanlı yılların sonunda Almanya’nın Darmstadt şehrinde bulunan FH Darmstadt üniversiteden bilgisayar mühendisi olarak mezun oldu.

KurumsalJava.com, SmartHomeProgrammer.com ve Mikrodevre.com adresleri altında blog yazıyor. Kurduğu BTSoru.com'da ona yazılımla ile ilgili sorularınızı yöneltebilirsiniz. Pratik Programcı Yayınları bünyesinde Pratik Spring, Pratik Agile ve Pratik Git ismini taşıyan kitapları bulunmaktadır. 21.12.2009 tarihinde Java Champion olarak seçildi.

Son Yazıları (hepsini göster)