Geçenlerde bir arkadaşımla sohbet ederken aklıma geldi, yıllar önce ilk kod yazdığım zamanlarda ‘code review’ denen şeyden haberimiz bile yoktu sanırım. Ya da belki vardı ama biz pek umursamıyorduk hani. Tek derdimiz kodu çalıştırabilmekti. Hani bir proje teslim edersin ya, o hissi yaşatıyordu bana o zamanlar. O dönemlerde kamp yapmaya da yeni yeni başlamıştım, aman aman dağlara tırmanıyorduk eşimle. Bir keresinde şöyle bir şey olmuştu; inanılmaz dik bir yamaca tırmanmıştık ve hava kararmaya başlamıştı. Döndüğümüzde de her şeyin yolunda gittiğini sanıyordum ama meğersem bizim takımdan bir arkadaşın getirdiği matara biraz hasarlıymış, su sızdırıyordu. Neyse efendim, sonuç olarak o gece biraz susuz kaldık ama işte ne yapalım, o zamanlar yeniydik bu işlerde.
Şimdi dönüp baktığımda, o matara sızdırırken yaşadığımız küçük sıkıntı ne kadar da bir kodun içindeki hatalara benziyor değil mi? İşte code review tam da bu noktada devreye giriyor. Basit bir matara sızıntısı bile kampın keyfini kaçırabilirken, bir yazılım projesindeki küçük bir hata da projenin bütününü etkileyebiliyor, hatta bazen projeyi tamamen sınıfta bırakabiliyor. Ne kadar da doğru bir benzetme oldu, değil mi?
Peki nedir bu code review olayı tam olarak?
Açıkçası code review, bir geliştiricinin yazdığı kodun başka bir geliştirici tarafından gözden geçirilmesi süreci. Bu kadar basit aslında. Hani bazen bir kod yazarsın ya, saatlerce üzerinde uğraşırsın, çalışır da, ‘tamamdır’ dersin. Ama sonra başka bir göz baktığında, ‘aa bak şöyle daha basitmiş’ ya da ‘burada böyle bir risk var’ gibi önerilerle gelir. İşte bu, code review’un en temel hali. Bence bu, kaliteyi artırmanın en etkili yollarından biri. Hem de bunu yapmak için ekstra bir araç kurmana gerek yok, sadece insan gücü ve biraz zaman…
Neden önemli peki bu code review? Düşünsene, sen bir hata görmemişsin ama karşıdaki geliştirici o hatayı anında yakalıyor. Bu, projenin daha sağlam, daha güvenilir olmasını sağlıyor. Bir de şöyle bir şey var, bazen bizler kendi yazdığımız koda o kadar çok odaklanıyoruz ki, dışarıdan bakınca bariz olan hataları göremiyoruz. Bu durum, benim kendi programlarımda da başıma çok geldi. Kendi yazdığım bir proxy programı vardı hani, filter’ları geçmek için uğraşıyordum. Bir ara filtreyi delmekte zorlanınca kendi yazdığım programın yetersiz olduğunu fark ettim. İşte o zaman anladım ki, başkasının gözüyle bakmak şart.
Ayrıca, code review sadece hata bulmakla kalmıyor. Yeni başlayan geliştiriciler için harika bir öğrenme aracı. Tecrübeli geliştiricilerin kodlarını inceleyerek yeni teknikler öğrenebiliyorlar, farklı yaklaşımları görebiliyorlar. Mesela ben de bazen Dapper ile sorgu yazarken, başka bir arkadaşımın yazdığı sorguya bakıyorum ve ‘vay be, bu şekilde de yapılırmış’ diyorum. Tabi bu durum, ekibin genel kod kalitesini de yukarı çekiyor.
Bir de işin ekip çalışması boyutu var tabii. Code review, ekip üyeleri arasında bilgi paylaşımını teşvik ediyor, birbirlerine destek olmalarını sağlıyor. Bu da daha güçlü bir ekip ruhu yaratıyor. Hani bazen olur ya, bir konuda takılırsın ve kimseye sormaya çekinirsin. Code review kültürü oturduğunda, bu çekinceler ortadan kalkıyor çünkü herkes birbirine yardım etmeye daha yatkın oluyor.
Peki, bu code review’u nasıl daha etkili hale getirebiliriz? Öncelikle, kesinlikle bir kültüre dönüşmeli. Yani sadece ‘yapılması gereken’ bir iş olmamalı, herkesin benimsemesi gereken bir alışkanlık haline gelmeli. Ne güzel değil mi? Bunun için de bazı adımlar atılabilir.
Öncelikle, code review’ların zamanında yapılması çok önemli. Hani bir kod gönderdin diyelim, üzerinden 2 hafta geçtikten sonra review yapılırsa ne anlamı kalır ki? O arada sen zaten başka işlere dalmışsındır, hatta belki o kodu yazdığın fikri bile unutmuşsundur. Bu yüzden, bir pull request (PR) açıldığında, en kısa sürede review edilmesi gerekiyor. Hatta bazı ekiplerde, bir PR’ın merge edilmeden önce en az 2 review’dan geçmesi gibi kurallar da olabiliyor. Bu, bence gayet mantıklı bir yaklaşım.
İkinci olarak, review yaparken yapıcı olmak gerekiyor. Hani hata buldun diye geliştiriciyi demoralize etmektense, ‘şöyle yapsak daha iyi olur’ veya ‘burada şöyle bir risk olabilir, acaba şöyle mi yapsak?’ gibi yaklaşımlar daha sağlıklı olur. Amaç birbirini eleştirmek değil, projenin kalitesini hep birlikte artırmak. Bu arada, her zaman haklı olmayabilirsin de, bunu da akılda tutmak lazım. Bazen senin önerdiğin çözüm, karşıdaki geliştiricinin daha iyi bir fikriyle değişebilir. İşte bu da güzel bir şey aslında 🙂
Şimdi gelelim işin pratik kısmına, yani kod örneklerine. Diyelim ki bir kullanıcı oluşturma API’si yazıyorsun ve bunu Vue.js üzerinden çağıracaksın. Basit bir POST isteğiyle veri göndereceksin. İlk aklıma gelen, belki de ilk başlarda benim de yapabileceğim bir hata şu şekilde olabilir:
// YANLIŞ – Sadece basit bir POST isteği
// Vue.js tarafı (basit bir örnek) async function postKullaniciYanlis(userData) { try { const response = await fetch('/api/kullanici', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(userData) }); if (!response.ok) { throw new Error(`HTTP error! status: ${response.status}`); } const data = await response.json(); console.log('Başarılı:', data); } catch (error) { console.error('Hata oluştu:', error); } }Şimdi bu kod çalışır, evet. Ama ne olur ne olmaz, bir de işin server tarafına bakalım. Eğer server tarafında da bazı kontroller eksikse, işte o zaman başımıza iş açılabilir. Mesela, gelen verinin valida olmaması, güvenlik açıklarına yol açabilir. Hani bazen olur ya, bir siteye girersin ve anında bir hata mesajı alırsın. İşte o hataların birçoğu, server tarafındaki eksik validasyonlardan kaynaklanıyor olabilir.
Peki, daha güvenli bir yaklaşım ne olurdu? Server tarafında da bazı validasyonlar eklerdik. Mesela gelen `userData` objesinin boş olup olmadığını kontrol eder, gerekli alanların dolu olup olmadığını kontrol ederdik. Hatta belki de Dapper ile PostgreSQL’e kaydederken bazı kısıtlamalarımız olurdu. İşte bu kısım, aslında code review’un en çok işe yaradığı yerlerden biri. Başka bir geliştirici, senin atladığın bir güvenlik açığını burada fark edebilir.
// DOĞRU – Server tarafında validasyon ve Dapper ile PostgreSQL’e kayıt
Şimdi C# tarafında bir örnek yapalım. Bu örnekte, gelen verinin basit bir validasyonunu yapıp, Dapper ile PostgreSQL’e kayıt ekleyeceğiz. Yani, hem Vue.js’ten gelen veriyi işleyeceğiz hem de veritabanına güvenli bir şekilde kaydedeceğiz. Bu arada, Dapper’ın ne kadar hızlı olduğunu biliyor musun? Gerçekten performanslı bir ORM.
// C# (ASP.NET Core Web API) tarafı - Controller örneği using Microsoft.AspNetCore.Mvc; using Dapper; using Npgsql; // PostgreSQL için namespace using System.Threading.Tasks;[ApiController] [Route("api/[controller]")] public class KullaniciController : ControllerBase { private readonly string _connectionString;
public KullaniciController(IConfiguration configuration) { // appsettings.json'dan connection string'i alıyoruz _connectionString = configuration.GetConnectionString("DefaultConnection"); }
[HttpPost] public async Task PostKullanici([FromBody] KullaniciDto kullanici) { // Basit bir null kontrolü yapalım if (kullanici == null) { return BadRequest("Kullanıcı bilgileri boş."); }
// İsim ve soyisim boş olmamalı diyelim if (string.IsNullOrWhiteSpace(kullanici.Ad) || string.IsNullOrWhiteSpace(kullanici.Soyad)) { return BadRequest("Ad ve Soyad boş olamaz."); }
// Veriyi PostgreSQL'e kaydetme using (var connection = new NpgsqlConnection(_connectionString)) { connection.Open(); var sql = @"INSERT INTO Kullanicilar (Ad, Soyad, Email) VALUES (@Ad, @Soyad, @Email)"; await connection.ExecuteAsync(sql, kullanici); }
return Ok(new { Message = "Kullanıcı başarıyla eklendi." }); } }
// Basit DTO (Data Transfer Object) public class KullaniciDto { public string Ad { get; set; } public string Soyad { get; set; } public string Email { get; set; } }
İşte bu kadar basit aslında. Yani bir yandan Vue.js’ten veriyi alıp gönderiyorsun, öte yandan da server tarafında gerekli kontrolleri yaparak veritabanına işliyorsun. Bu arada, bu tarz bir yapılandırmayı daha detaylı incelemek istersen, şuradaki Google aramasına bakabilirsin. Farklı yaklaşımları karşılaştırıyorlar.
Sonuç olarak, code review sadece bir zorunluluk değil, aynı zamanda bir kalite güvencesi ve gelişim aracı. Ekip olarak bu kültürü benimsediğimizde, hem daha sağlam projeler üretiyoruz hem de birbirimizden bir şeyler öğreniyoruz. Hani bazen olur ya, bir projede çalışırsın ve o projeden çok şey öğrenirsin. Code review da tam olarak bunu sağlıyor. O yüzden, hadi bakalım, siz de projelerinizde code review kültürünü yaygınlaştırmaya ne dersiniz?