Kod kalitesini artırmak için bir çok yol izlenebilir; unit test, continuous integration, continuous deployment, agile methodology etc. ancak en önemli yollardan biri code review dır. Bazen kaliteli diyebileceğimiz kodlar yazmaya çalışsak bile öyle anlar geliyor ki proje müdürünüz bir anda gelip bu feature'u bugün yetiştirmemiz gerekiyor deyip spaghetti code yazma süreciniz başlıyor. Bu gibi durumlar hep olacak ancak daha sonrasında geriye dönüp yazmış olduğunuz kodu review-refactoring etmemiz gerekmekte. Yada normal akışında geliştirme yapıyor olsak bile teknik olarak bilgili birisi (genelde takım liderleri) yapmış olduğumuz geliştirmelere bir göz atıp ondan sonra master branch'ine commit/checkin yapıyor olmamız gerekir.
Code Review yapmanın bir çok avantajı var;
- Kod kalitesini arttırır,
- Bug bulmamızı kolaylaştırır,
- Developer kendisi olmasa bile bir başkası review işlemi yapacağından geliştirme yaparken daha dikkatli olmasını sağlar,
- Review işlemi yapan kişi daha önce hiç karşılaşmadı şekilde olumlu geliştirmelerle karşılaşabilir ve onun gelişimine de katkısı olur,
- Yazılım standartlarına bağlı kalmaya yönlendirir.
Gibi gibi birçok faydasından bahsedebiliriz.
Başlangıçta biraz garip gelebilir ancak iyi bir flow bulduğumuzda hem yazılım kalitesi, hem ekip çalışması ve ekibin moral-motivasyonu açısından ne kadar büyük bir değişim olduğunu fark edeceksiniz dir.
Code Review İçin İzlenebilecek Yollar/Kurallar
Code Review için belli başlı kabul edilen bazı kurallar mevcut. Bazı software tool'lar kullanarak başlanabilir ancak developer olarak bizlerin uyması gereken bazı kurallar sıralayabiliriz.
Kısa Commit'ler ve Anlaşılır Commit Mesajları
İlgili branch'e commit yaparken bir seferde bütün her şeyi commit'lemekten ziyade kısa kısa paketler halinde yaptığınız geliştirmeleri commit edin ve anlaşılır commit mesajları kullanmaya çalışın. Böyle yaparak her şeyi step-by-step açıklamış olacaksınız ve hem review yapacak kişi için kolay anlaşılabilir olacak hemde kendiniz için geriye dönüp baktığınızda yaptığınız geliştirmeyi hatırlaması daha kolay olacaktır.
Kodları Review Edin Developer'ı Değil
Review yaparken başkalarının yapmış olduğu işleri incelediğinizden eleştiri yaparken bazen yapılan işe değilde kişinin kendisine eleştirilerde bulunulabiliyor. Ancak bu devloper'la üzerinde olumsuz tepebilir. Yanlış yaptıkları bir şeyi gördüğünüzde onları sürekli eleştirmek yerine nasıl daha doğru yapabilirlerdi o yönde tavsiyelerde bulunmak daha çok önemlidir. Tabi bunları söylerken kullandığınız ses tonu da oldukça önemlidir.
Developer olarak, review eden kişi commit'inize yorumlarda bulunduğunda bunu kişisel algılamamaya çalışın tabi doğrudan kişisel bir söylemde bulunulmuyorsa.
Muhakkak Checklist'iniz Olsun
Hem review edecek olan kişi hemde developer için checklist'inizin olması önemli daha sistematik bir review süreci için oldukça önemlidir.
- Bugs,
- Duplicate Code,
- Login Pages,
- Code Style and Formatting
- etc..
Bu gibi checklist'ler yaparak süreci daha kolay hale getirebiliriz.
Multiple Reviewers
Genelde bir kişi bulmak bile çok zor oluyor ancak eğer mümkünse kodunuzu birden fazla kişiye review ettirin. Eğer kodla ilgili bir anlaşmazlık var ise örneğin; a kişisi burda factory design pattern kullanman doğru olmuş dedi, B-C kişileri hayır burda abstract factory kullanmalısın dedi. Hemen bu gibi durumlarda oylama yapılıp çoğunluğa göre karar verilebilir.
Ne Zaman Review Yapılmalı ?
Aslında bu büyük oranda development ekibine bağlı.Size bir geliştirme atandı ve 4 gün içinde dev branch'inde geliştirme yaptınız ve test'e gönderdiniz, testlerden herhangi bir bug vs. çıkmayıp "Ok production'a alabiliriz.." dedikten sonra yapmış olduğunuz geliştirmeleri master branch'ine merge işleminden önce review edecek olan kişiye gönderilmesi en doğru olan zamandır diyebiliriz. Review edilmeyen kodları master'a merge etmemek gerekir.
Review İşleminden Sonra..
Dev ortamda yaptığınız geliştirmeleri review eden kişi eğer herhangi bir sorun görmez "OK" verir ise master branch'ine merge işlemini yapabilirsiniz. Eğer yaptığınız geliştirmeler review eden kişiden onay almaz ise tekrardan dev branch'de istenilen refactoring işlemlerini yapıp projenin son halini tekrardan review eden kişiye assign etmek gerekir. Bu sefer reviewer'dan "OK" aldıysanız üstte de belirttiğim gibi master branch'ine geliştirmelerinizi merge edebilirsiniz.
Özetle Code Review yazılım kalitesini artırmak için yapılabileceklerin en başında gelir. Eğer Development ekibinin başında olan kişi iseniz büyük ihtimalle review işlemini yapan kişi siz olacaksınızdır ve takımınıza belli başlı kabul görmüş yazılım geliştirme standartlarına uymalarını sağlarsanız review süreciniz daha rahat ve keyifli geçecektir.