Kod İncelemesine Başlamak için Öneriler

Gördüğüm kadarıyla yazılım şirketlerinin en çok zorlandığı konulardan biri kod incelemesine başlamak. Diğer yazılımcılarla konuştuğumda da kod incelemesinin faydalarından haberdar olduklarını fakat bir türlü kod incelemesine başlayamadıklarını farkettim. Bu yazıda, kod incelemesine başlarken işinize yarayacağını düşündüğüm bir kaç öneride bulunacağım.

Kod incelemesi, (eng. Code Review, CR), yazdığınız kodun, ana kaynak kodu deposuna gönderilmeden önce bir ikinci (ya da üçüncü, dördünce vs.) göz tarafından incelenmesi olayıdır. Her ne kadar konuştuğum çoğu yazılımcı yararlarını bilse de ne yazık ki bu bilgi deneyimden çok teoriden geliyor. Kimi yazılım şirketleri de kod incelemesinin önemini kabul etmesine rağmen, yazılım süreçlerinde buna olanak sunmayarak bu bilginin teoride kalmasına neden oluyor. Gerçi, hala birim testleri yazmayı gereksiz/fazlalık bulan şirketler olduğunu düşünecek olursak, bu duruma da çok şaşırmamak lazım. 

Benim ÅŸaşırdığım durum, kod incelemesinin yararlı olduÄŸunu kabul eden ÅŸirketlerin, bir türlü kod incelemesine baÅŸlayamamaları, bence bu tip durumlarda en büyük sorumluluk yazılım ekiplerinde düşüyor. EÄŸer ÅŸirketiniz kod incelemesine geçmek istiyor ve yazılım ekipleri geçemiyorsa, bu durum bir takım sorunları iÅŸaret ediyor olabilir. Takım arkadaÅŸlarına güvensizlik, yüksek egolar, iletiÅŸim sorunları, kendine güvenmeme gibi gibi… Bense bu yazıda, bu tip sorunları ortadan kaldıracağını ve kod incelemesine baÅŸlamayı kolaylaÅŸtıracağını düşündüğüm bir takım önerilerde bulunmaya çalışacağım.

EdebileceÄŸiniz HerÅŸeyi Otomotize Edin

Gördüğüm kadarıyla en büyük kavgalar en küçük detaylardan çıkıyor. Örneğin:

• ab karakteri mi kullanılsın boÅŸluk karakteri mi?
• süslü parantez aynı satırda mı olsun bir sonraki satırda mı?

Gibi ucu açık sorular en uzun süren tartışmalara sebep oluyor. Burda tavsiyem, kod incelemesine başlamadan önce bu tip şekle dayalı tartışmaları önceden bir karara bağlamanız, hatta herkesin bunlara uyduğuna emin olmak için bu tip kararları otomotize etmeniz. Emin olun ki kod incelemesine geçerken bu tip tartışmalardan bir ton sorun çıkacaktır. Otomotize ettiğinizde ise zaten yazılımcı kodu derleyemeyeceği için önceden karar verdiğiniz standartlara herkesin uyması gerekecek ve zamanla takımda alışkanlık haline gelecektir.

Eğer bu tip bir kontrolleri nasıl otomotize edeceğinizi bilmiyorsanız, bu projeden yararlanabilirsiniz. Bu projede ki gibi checkstyle, findbugs, jococo vb eklentilerden yararlanarak projenin belirli bir stilde ve belli bir birim test kapsamında geliştirilmesini sağlayabilirsiniz.

Egolarınızı Bir Kenara Bırakın

Kod incelemesinin en büyük engellerinden biri, yüksek egolu bir takımdır. Bu sebepten her yazılımcının egolarından sıyrılması iyi bir kod inceleme süreci için şart diyebilirim. Ne yazık ki yazılım geliştiriciler de, diğer üreten iş sınıfları gibi (mesela yazarlar) ürünlerine (mesela kitapları) yapılan eleştirileri kişisel almaya meyilli oluyorlar. Egodan sıyrılmak için benim tavsiyem ise:

1. Kendinizi geliÅŸtirmelisiniz: Ne yazıkki bir çok meslektaşım aldıkları üniversite eÄŸitiminin onlara yeteceÄŸine ve onları iyi bir mühendis yapacağına inanıyor. Fakat üniversite eÄŸitimi sadece temelleri atıyor. Bunun üzerine siz kat çıkmalı, kendinizi geliÅŸtirmelisiniz. Mutlaka duymuÅŸsunuzdur, Einstein’a ithaf edilen bir söz var; “Ego bilgi ile ters orantılıdır” diye, çok doÄŸru bulduÄŸum bir söz. Bunu sadece teknik anlamda geliÅŸtirme olarak düşünmeyin. DiÄŸer alanlarda da kendinizi geliÅŸtirmelisiniz.
2. Yazdığınız kodun kendiniz olmadığını kabul etmelisiniz: Fakat sadece kendinizi geliştirmeniz de yeterli olamıyor. Kendinizi ürettiğiniz kodla eş değer tuttuğunuz sürece egolarınızdan sıyrılmanız çok zor. İyi bir kod yazıyorsunuz diye iyi biri olmadığınız gibi, kodunuz kötü olduğunda da kötü biri haline gelmiyorsunuz. Aksine, kötü bir yorum aldığınızda buna kendinizi geliştirmek için fırsat olarak bakabilirsiniz.

Aşırı Öznel Yorumlardan Kaçının

Kod incelemesi başlı başına öznel bir durum, başkasının yazdığı koda yorum yapıyorsunuz. Ama aşırı öznel yorumlardan kaçınmalısınız. Yorumlarınız her zaman kod incelemesinin getirdiği yararları arttıracak yönde olmalı. Örneğin, bir kod parçası tasarıma uymuyorsa bunun altını çizmelisiniz ya da yazılan kod yarış durumlarına (eng. Rece Condition) sebep oluyorsa bunu belirtmelisiniz. Ama gidip kod incelemesini size gönderen kişinin sizinle birebir aynı kodu yazmasını bekliyorsanız, kod incelemesini sürecinize oturtmakta zorlanabilirsiniz.

Bunu engellemek için benim tavsiyem ise yorumlarınızda referans vermeye özen gösterin. ÖrneÄŸin, Immutable olabilecek bir sınıf mutable olarak tanımlandıysa, Effective Java‘dan Item:15’i referans verebilirsiniz. Sadece dış kaynakları deÄŸil, iç kaynakları da referans olarak kullanabilirsiniz. EÄŸer ÅŸirket içinde takip ettiÄŸiniz kurallar varsa bunları da referans vermekten çekinmeyin.

Küçük Küçük Başlayın

Bunu bir kaç sebepten dolayı söylüyorum. Öncelikle, tüm projeleri aynı anda kod incelemesine geçirmeye çalışmayın. Bir iki projeyi plot proje olarak seçip onlarda baÅŸlayabilirsiniz. DiÄŸer bir sebep ise, hemen büyük araçlar büyük uygulamalar almaya kalkmayın. BaÅŸlangıç için sadece omuz üzerinden yapacağınız bir inceleme bile yeterli olabilir. EÄŸer illa bir uygulama ile baÅŸlayacaksınız, Review Board uygulamasını tavsiye edebilirim. Evet, Review Board’ın diÄŸer uygulamalar kadar güzel bir UI’ı yok, ama baÅŸlangıç için kesinlikle iÅŸinizi görecektir. Unutmayın, kod incelemesinin yararlarından faydalanmak için büyük paralar harcamanıza gerek yok. Düşünün ki Linked-in, Yelp gibi ÅŸirketler de bu uygulamayı kullanıyor.

Kod İncelemesi için Yönergeniz Olsun

Kod incelemesini gönderecek bir yazılımcının aklına bir takım sorular takılabiliyor. ÖrneÄŸin, “bu kodu kim onaylayabilir” ya da “bu kodu kaç kiÅŸinin onaylaması gerekiyordu” gibi… Bu sorunun cevabını bulmak inceleme süresini uzatabiliyor ki zaten kod incelemesine baÅŸlarken, kod incelemesinin geliÅŸtirme süresini olumsuz yönde etkileyeceÄŸi düşünülüyor. Belirsiz olmayan bir süreç tartışmayı uzatıp süreci olduÄŸundan uzun gibi gösterebiliyor, bu da kod incelemesinin negatif görünen yönlerinin olduÄŸundan daha kötü algılanmasına neden olabilir. Bundan dolayı benim tavsiyem, kod incelemesine baÅŸlarken yönergenizi belirleyin. Yönergeleriniz de neyi kimin onaylayabileceÄŸi ya da kaç kiÅŸinin onaylaması gerektiÄŸi gibi bilgilerin açık ve herkes tarafından ulaşılabilir olmalı.

Yönergenin sağladığı diğer bir şey ise takip edilebilirlik. Büyük ihtimalle sürecinizi ilk oturturken, deneyip yanılıp sizin için doğru olan bir süreci oturtmaya çalışacaksınız. Belki bazı yeni fikirleri de deneme şansınız olacak. Bunları ve sonuçlarını da bu yönergenizde tutabilirsiniz, böylelikle neyin ne kadar süre aldığı, ne gibi sonuçları olduğunu da daha rahat takip edebilirsiniz.

Son

Umarım şirketiniz kod incelemesine geçmeyi düşünür ve bu önerilerde geçişinizi kolaylaştırır. Ama şirketinize kod incelemesine geçmeyi düşünmüyorsa, yazılım süreçlerini iyileştirmek gibi bir çabası yoksa, çalıştığınız yeri ve kariyer planınızı gözden geçirin derim. Büyük bir şirketin, tüm şirket genelinde böyle bir süreç oturtması tabiki de zaman alacaktır ama hiç bu yönde bir adım atmıyorsa, şirket emeğinize değmiyor olabilir.