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.