Kod Gözden Geçirme Pratikleri (What to Look For in a Code Review) — Part 1
Bu yazı serimde yazılım dünyamızda önemli konulardan birisi olan kod gözden geçirmede nelere dikkat etmeliyiz sorusuna kendimce ve okuduğum kaynaklardan topladığım bilgiler ışığında yanıt vermeye çalışacağım.
Kod gözden geçirme hakkında yalnızca birkaç saniyenizi ayırıp Google’da arama yaparak kod gözden geçirmenin neden iyi olduğuna dair birçok makale görebilirsiniz. Bu makalelerin çoğu hazır paket tool’ların nasıl kullanılacağı veya teorik olarak nasıl kod gözden geçirme yapılabileceği ile alakalı oluyor. Ben ise yazı serimde daha çok başkasının yazdığı koda nasıl bakmamız gerektiği, nelere dikkat etmemiz gerektiği gibi konuların üzerinde durmaya çalışacağım. Tabi ki konu çok geniş ve herkesin ve her kurumun kendi içinde bir standardı oluyor ve kod gözden geçirme sırasında dikkate alınması gereken farklı noktalar olabiliyor. Bununla beraber functional ve non-functional gereksinimlerin önemine göre kod gözden geçirme süreci farklı yönlere gidebilmekte.
Yukarıda da bahsettiğim üzere konu çok geniş ve bir çok farklı açıdan bakılabilme potansiyeline sahip, ancak ben kendimce farklı konu başlıklarında gruplayarak ve ana konumuzdan çok uzaklaşmadan başkasının yazmış olduğu bir kodu nasıl gözden geçiririz kısmına odaklanmaya gayret göstereceğim.
Peki, başkasının yazdığı kodu gözden geçirirken nelere bakmalıyız?
Kod geçirme sürecini ister ticari bir tool kullanarak yapalım istersek de kod gözden geçirme toplantılarında birebir kodu yazan kişi ile iletişim halinde kalarak yapalım spesifik belli konu başlıkları daha kolay gözden geçirmeye olanak sağlamaktadır. Bunlar:
- Format ile alakalı konular: Satırdaki boşluk karakterleri, tab ve space kullanılarak indentation yapımı veya süslü parantezlerin konumunu bu başlıkta gruplayabiliriz.
- Stil ile alakalı konular: Değişken ve metotlarımızda kulladığımız static/final kelimelerin yerleri, metotların kullanıldığı yere en yakın yerde tanımlanması gibi maddeleri bu başlıkta gruplandırıyoruz.
- İsimlendirme: Kullanmış olduğumuz değişken, metot, sınıf veya parametre isimleri standartlarımıza uyuyor mu ve anlamlı mı gibi konuları bu başlıkta gruplandırıyoruz.
- Test yüzdesi: Eğer TDD yaklaşımını benimseyerek kod yazıyor isek yazılan kodun “test coverage” oranı bizim için doğrudan bir metrik olacağı için bu konu başlığı altında değerlendirebiliriz.
Bununla birlikte, bu kontrollerin çoğu otomatikleştirilebildiğinden, bizlerin bunları gözle yapması muhtemelen çalıştığımız kurumların zaman ve kaynaklarını en iyi kullanımı değildir. Google ile basit bir arama yaptığımızda yukarıda bahsettiğimiz konu başlıklarını önceden tanımlanmış kuralları işleterek yapan ve bize sonucu gösteren bir sürü open source veya ticari tool bulabiliriz.
Peki, madem otomatik olarak kullanabileceğimiz tool’lar var, biz birer birey olarak kod gözden geçirme süresince nelere dikkat etmeli veya neleri gözden geçirmeliyiz? Diğer bir deyişle, herhangi bir tool’un yapamadığı neyi biz insan gücü ile yapabiliriz? Bu sorunun cevabı maalesef çok uzun ve onlarca veya yüzlerce konu başlığını cevap olarak verebiliriz. Ancak önemli gördüğüm konulara kısaca aşağıda değinmek istiyorum.
Tasarım ile alakalı konuları herhangi bir tool’a delege edemeyiz çünkü tasarım kurumdan veya kişiden bağımsız veya tool’a indirgenemeyecek kadar soyut bir kavram olarak karşımıza çıkmaktadır.
- Eklenen kod kodun var olan mimari yaklaşımına uyuyor mu?
- SOLID, DDD veya bilinen diğer tasarım yaklaşımlarına uygun bir geliştirme yapılmış mı?
- Kullanılan tasarım desenleri var mı? Eğer varsa amacına uygun kullanılmış mı?
- Eklenen kod blokları hiyerarşi veya business anlamda doğru yere mi konumlandırılmış? Mesela sipariş ile alakalı sınıflar veya metotlar sipariş ile ilişkilendirilmiş klasör/sınıflar altında gruplandırılmalı.
- Kod tekrar kullanımı önemsenmiş mi? Duplication yapılmış mı?
- Kodda over-engineering yapılmış mı? Bazen o an gereksiz olan kodları yazmamız uzun vadede bize yarardan çok zarar getirecektir. Mümkünse YAGNI prensibine sadık kalmalıyız.
Okunabilirlik ve bakımın kolaylığı diğer bir madde, burada ilk bakmamız gereken yer belki de kodu okuduğumuzda anladığımız ile kodun yaptığının eşleşmesi, diğer bir deyişle kodun kendini kolayca anlatabilme yetisinin olmasıdır.
- Testler de anlamlı yazılmış ve kodu düzgün test ediyor mu?
- Test yazımı tüm alt senaryoları da kapsayacak şekilde kurgulanmış mı? Sadece happy path dediğimiz başarılı senaryolar mı var yoksa istenmeyen hata durumları için de test yazılmış mı?
- Yazılan ve throw edilen exception mesajları anlamlı mı? Her hataya özel hata mesajı yapısı kurgulanmış mı?
- Bakıldığında anlaşılmayan veya net olmayan bir yer var ise gerekli dokümantasyon yapılmış mı?
Fonksiyonalite;
- Kod gerçekten de yapması gerekeni yapıp beklendiği gibi davranıyor mu? Herhangi bir yan etkisi var mı?
- Kod, kontrol için yanlış değişkeni kullanma veya yanlışlıkla “or” yerine “and”” kullanmak gibi kolayca gözden kaçacak hatalar içeriyor gibi mi görünüyor?
Bunların dışında;
- Kodda muhtemel güvenlik riski olarak değerlendirilebilecek bir blok var mı? Varsa bunun için ekstra bir çalışma yapılmış mı?
- Geliştirme yaptığımız ürüne özel kurallar varsa (yasal, hukuk gibi) bu kurallara uyuluyor mu?
- Otomatize ettiğimiz testlerde tespit edemediğimiz performans sorunu yaşanabilecek bir yer var mı? Örnek olarak veritabanı çağrımı yapılan yerler veya gereksiz yere üçüncü servis çağırımı var mı?
- Hardcoded ortam bazlı değişken veya konfigürasyon var mı?
Yazı serimde sonraki konu başlıklarım:
- Test ve test yazımı ile alakalı konular https://akkoyunramazan.medium.com/kod-g%C3%B6zden-ge%C3%A7irme-pratikleri-what-to-look-for-in-a-code-review-part-2-testler-17bc02cf85d6
- Performans ile alakalı konular
- Veri Yapıları kullanımı
- SOLID prensipleri
- Güvenli yazılım geliştirme
Buraya kadar geldiğiniz ve yazımı okuduğunuz için teşekkür ederim. Görüş ve önerilerinizi iletirseniz daha iyi olmak için kendimi geliştirmeye devam edebilirim.
Sonraki yazılarımda görüşmek üzere ->
