Code Review — 1
Merhabalar,
Uzunca zamandır planladığım, yazılım mühendisliğiyle ilgili yazılarıma başlama kararı aldım. Başlamak zor belki ama devam ettirmek daha da zor. İçerik üretmek ve bunu düzenli olarak devam ettirebilmek ise en zor olanı.
Yaklaşık 5.5 senedir yazılım mühendisi olarak çalışıyorum. Yazılarımda genellikle kendi tecrübelerimi, çalıştığım iş yerlerinde gördüklerimi ve okumalar vasıtasıyla elde ettiğim bilgileri paylaşabilmeyi umuyorum. Bu yazıları okuyan arkadaşların yapacağı eleştiriler ve geri bildirimler ile kendi bilgilerimi güncelleyip, kendimi geliştirebilmek ise benim açımdan muazzam olur.
İlk yazım olduğu için girizgah kısmını biraz uzun tuttum:) Şimdi gelelim yazımızın asıl konusuna. Bu yazıda “Code Review” kavramıyla ilgili bildiklerimi ve daha detaylı bilgilere sahip olabilmek için bildiğim referansları paylaşacağım.
(İleriden gelen edit: Serinin 2. yazısı için https://medium.com/@ibrahimsckn35/code-review-2-b1863db188ef)
Not: “Code Review” kavramının Türkçe kullanımını hiç görmediğim için bu terimi İngilizce olarak kullanacağım.
Code Review Nedir?
Code Review yazılan bir kodun başka bir yazılımcı veya yazılımcılar tarafından incelenmesi olayıdır. “İnceleme” kavramı çok geniş bir alanı kapsadığı için, kavramı biraz daha açmak gerekir.
İnceleme kavramını açabilmek için öncelikle “Code Review” yapılmasının amacı nedir sorusuna cevap vermek gerekir. Durumdan duruma değişmekle beraber amaçları aşağıdaki şekilde sıralayabiliriz.
Neden Code Review Yapıyoruz?
“Code Review” neden yapıyoruz sorusunun cevabı, ürettiğimiz ürüne, takıma hatta sektöre bağlı olarak değişiklik gösterebilir. Bu sebeple daha genel olan amaçları aşağıda sıralamaya çalışalım.
Kodun doğru şekilde çalıştığını onaylamak
“Code Review” yapan herkesin ilk dikkat ettiği konunun bu olduğunu söyleyebilirim. Bu işlemi yaparken zaman kısıtı da söz konusu olduğu için bazı püf noktalara dikkat etmek gerekir. 2 örnek vermek gerekirse;
- Döngüler (for/foreach/while) ve karar (if/else) adımlarının kontrol edilmesi
Döngülerin giriş ve çıkışları genel olarak hepimizin çok hata yapabildiği bir nokta oluyor. Olası hataları sıralamak gerekirse, kodun döngüden hiç çıkmaması(sonsuz döngü) veya döngüden istenildiği kadar iterasyonu tamamlamadan çıkması örnek olarak gösterilebilir.
Döngüler gibi karar adımları da kodun akışını değiştirdiği için çokça hata yapılabilen alanlar oluyor. Bu nedenle kodun if/else bloklarına hangi koşullarda girdiği ve bu bloklarda doğru işi yapıp yapmadığı “Code Review” aktivitesinin önemli bir kısmını oluşturabiliyor. (Döngüleri ve karar adımlarını kontrol edebilmek için “unit test” daha efektif bir yol olsa da review yaparken de buraları kontrol etmenin faydalı olduğunu düşünüyorum.)
2. Null check kontrolleri
Yazılımcıların özellikle de C#,Java,C++ gibi compiled diye tabir ettiğimiz dillerde kod geliştirenlerin en sık yaptığı hatalardan biri “null reference exception” hatası olabiliyor. Bu hatayla daha nadir karşılaşmak için “Code Review” önemli bir fırsat. (Visual Studio ortamında kod geliştiren yazılımcılar için Resharper gibi yardımcı toollar verdikleri uyarılarla null reference hatasını minimuma indirebiliyor. Emin değilim ama Visual Studio dağıtımları da artık default olarak null reference gibi olası hataları yakalıyor olabilir. Bknz. Resharper null reference documentation )
Kodun doğru işi yaptığını onaylamak
Bu konu kendi takımımda da tartışma konusu oldu ama en sonunda kodun doğru işi yaptığını basit bir şekilde kontrol etmenin “Code Review” aktivitesi içinde yapılması gerektiğine karar verdik. Buradaki kontrolü kısaca anlatmak gerekirse kod doğru şekilde çalışıyor olabilir ama gereksinimi (requirement) karşılıyor mu diye kontrol ediyoruz. Bunu kontrol ederken use case dökümanını veya “requirement specification” gibi bir döküman varsa onu açıp, gereksinim karşılandı mı kontrolü yapıyoruz. Başka bir olasılık ise kodu yazan arkadaşın “commit” mesajında ne yapmaya çalıştığını açık ve sade bir şekilde anlatması olabilir. Review yapan yazılımcı “commit” mesajını da kendine baz alabilir. Hatta “use case” dökümanı da commit mesajına eklenebilir.
Örnek vermek gerekirse bizden faktöriyel hesabı yapmamız istenirken toplama işleminin kodu yazılmış ise, kod doğru olsa bile istenen işi yapmadığı için “Code Review” işleminden geçemiyor.
Coding Guideline / Code Conventions kontrolü yapmak
Genellikle yazılım ekiplerinde herkesin kendine has kod yazmasını engellemek için “Coding Guideline” oluşturulur ve takım üyelerinin buradaki maddelere uyması beklenir. Beklentilere bazı örnekler vermek gerekirse değişkenlerin isimlendirilmesi, indentetation kontrolü, fonksiyonların belli bir uzunluğu geçmemesi gibi örnekler verilebilir.
Aslına bakarsınız bu tarz statik kod analizlerini yapan toollar var. Bu yazıda daha önce bahsettiğim Resharper tool’unda takım halinde kurallar belirlendikten sonra herkesin Resharper hatalarına veya uyarılarına dikkat etmesi bu işlemi daha kolay hale getirebilir. Diğer bir alternatif olarak da çalıştığım takımda kullandığımız Sonarqube uygulamasını örnek verebilir. Sonarqube ile de dil bazlı olarak özelleştirilebilen kurallar ile kod yazan herkesin aynı kurallara uyması sağlanabilir. Sonarqube uygulamasının bir eklentisi olan “SonarLint” ile Visual Studio üzerinde kod yazarken, yazma anında hatalarımızı görmek iş “Code Review” aşamasına gelmeden dahi bu tarz hataların giderilmesine sebep oluyor. (SonarLint)
“Knowhow” paylaşımı yapabilmek
Çoğu yazılımcı kodunu çocuğu gibi sahiplendiği için koduna gelen olumsuz geri bildirimleri kişiselleştirebiliyor veya yanlış manalara getirebiliyor. Bu noktada koddaki hataları bulmak, daha iyiye götürebilmek için kodu yazan kişiye geri bildirimler vermek ne kadar doğruysa, kodu “review” eden kişinin “review” ettiği koddan faydalanmaya çalışması da o kadar doğru bir şey aslında.
Bu zamana kadarki iş tecrübelerimde “Code Review” yaptığım zaman, programlama dillerinin çokça bilmediğim özelliklerini öğrenme şansım oldu, problemlere çok daha farklı çözüm yaklaşımlarını görme şansı elde ettim. Şunu net olarak söyleyebilirim ki yazılımcılar kod yazdıkça geliştiği kadar kod okuyunca da gelişiyor. “Code Review” yaparken de bu mantıkla bakarsak kazan-kazan durumu oluşabilir.
Bunun yanı sıra literatürde“collective code ownership” diye tanımlanan bizim “takımın kodu paylaşması” diye uydurmaya çalışacağımız:) olgunun oturabilmesi için de “Code Review” en önemli araçlardan biri. Kod parçaları ve yazılımcılar arasında 1->1 ilişki olmasındansa n->n ilişki olması takımlar için çok daha faydalı bir pratik. Kendi yazmadığınız bir kodu okuyarak hem kod hakkında bilgi sahibi olabilir hem de ileride benzer tarzda bir iş geldiğinde tekrar kullanma gibi seçenekleri değerlendirebilirsiniz.
Kod okunulabilirliğini arttırmak
Üniversiteden yeni mezun olmuş veya “cool” diye tanımladığımız yazılımcı arkadaşların daha az satırla kod yazabilmek için ciddi manada uğraştıklarını görüyorum. Görüyorum yerine biliyorum demek daha dürüst olur çünkü yeni mezun olduğumda ben de kendimi iş yerindeki arkadaşlarıma gösterebilmek için kolay kodları bile daha “akıllı” şekilde yazmaya çalışıyordum. Tabi “akıllı” yazmak isterken “basitlikten” ve “okunulabilirlikten” feragat etmiş oluyoruz.
Burayı daha iyi vurgulayabilmek için Martin Fowler’ın çok meşhur sözünü hatırlamak gerek. “Herhangi bir ahmak bilgisayarın anlayabileceği bir kod yazabilir, iyi programcılar insanların anlayabileceği kodları yazanlardır”. (Martin Fowler). “Code Review” diğer hiçbir amaca hizmet etmese dahi kod okunulabilirliğini arttıyorsa takım için çok faydalı bir pratik diyebilirim. Sadece değişken adları, fonksiyon adları ve sınıf adlarını değiştirerek bile kodların çehresinin olumlu manada değiştiğine çokça şahit oldum.
(Not:İlk yazımda yaptığı review ile bana çok yardımcı olan ve değerli zamanını ayıran Gokhan Topcu’ya teşekkürlerimi sunarım)
