dotcode podcast — “Code Review”

Published in

SDTR

4 min readJun 2, 2023

Herkese merhaba, bu yazı da Berkan Şaşmaz ile birlikte dotcode podcast kanalının dördüncü bölümünde konuştuğumuz “Code Review” bölümüne hazırlanırken aldığım notlardan bahsediyor olacağım.

Bu makaleyi yazdığım tarih itibariyle (02/06/2023), dört bölüm yayınlanmış durumda. Diğer bölümler ile ilgili yazılara aşağıdaki linklerden ulaşabilirsiniz:

dotcode podcast — “Nasıl Daha İyi Kod Yazarız? Kendimizi Yazılım Alanında Nasıl Geliştirmeliyiz?” (1.Bölüm)
“İş hayatına nasıl daha kolay adapte olunur? Yeni mezunlar nelere dikkat etmeli?” (2.Bölüm)
“Open Source Projelere Nasıl Katkıda Bulunulur?” (3. Bölüm)

Bu bölüm için hazırlanırken birkaç maddeden oluşan notlar çıkardım. Kendi tecrübe ettiğim şeyleri listelemek ve bunları bir makale içinde sizlerle paylaşmak istedim.

Code Review Nedir?

Bir projede yapılan bir değişikliğin, değişikliği yapan kişi dışında en az bir kişi tarafından gözden geçirilmesi ve bunun sonucunda daha kontrollü bir şekilde ilgili branche eklenmesi süreci olarak tanımlayabiliriz.

Bu süreç biz geliştiricilere ve doğrudan geliştirdiğimiz ürüne birçok katkı sağlıyor.

Code Review Sürecinin Katkıları

Kod kalitesini arttırır. En az 2 kişi tarafından incelendiği için olası hataların önüne geçilmesinde yardımcı olur.
Yeni kodlar, tasarım şekilleri ve yaklaşımları görmemize olanak sağlar.
Takım içindeki iletişimi arttırır. Takım içindeki know-how aktarımı için önemli!
Ve ilgili projenin genel bir standart ve kurallar çerçevesinde geliştirilmesine olanak sağlar.

Code Review İçin PR Açarken Dikkat Edilmesi Gerekenler

İlk olarak karşımızdaki kişinin bizim gönderdiğimiz işi inceleyeceğini ve bunun için belirli bir süre harcayacağını göz önünde bulundurmamız gerekiyor. Bu yüzden de ilgili işimizi tamamlayıp, PR açtığımızda, ilk göz olarak kendimizin bakması çok faydalı olur diye düşünüyorum.
Belki test etmek için log yazmışızdır ve bunu silmeyi unutmuşuzdur, veya bazen IDE’ler bizim yerimize kod ekleyebiliyor bu tarz gereksiz değişiklikler yapılmış olabilir, bu sebeple ilk bizim ilgili PR’ı incelememiz ve eğer bu tarz bir durum varsa düzeltmemiz lazım.
Ayrıca, yazdığımız koddaki değişiklikleri görünce aklımıza yeni bir yöntem gelebilir, veya atladığımız bir edge case görebiliriz, bunun gibi durumların yaşanmaması içinde bir ön kontrol yapmamız gerekiyor.
Bunlara ek olarak, PR’ın başlığı, açıklaması, labelları, target branchi ve milestone’u doğru bir şekilde belirtilmeli. PR’ı review eden kişinin ilgili işin ne ile ilgili olduğunu, PR’ın başlığı ve açıklamasını okurken anlaması gerekiyor!

Code Review İçin Öneriler

İlk olarak ön yargısız olarak koda yaklaşmak çok önemli. Orada yapılan işi yapan kişiden bağımsız olarak, belirtilen kıstaslara göre bakmamız ve gözden geçirmemiz lazım. Beklediğimiz sonuçları karşılıyor mu, eksik bir senaryo var mı vb.
Ayrıca, burada şu da önemli, yaptığımız işler direkt müşteriye etki ediyorsa veya bununla ilgili dökümanlar yazılması gerekiyorsa döküman da ilgili PR içinde gelmiş mi veya bununla ilgili bir issue var mı diye bakmamız da gerekiyor.
Bu süreci genel olarak geliştirme süreci olarak görmeliyiz. Yani “kod + test + döküman” gibi bir check-listimiz olabilir diye düşünüyorum (bunu issue/PR template ine de ekleyebiliriz — PR’ı açan kişinin bir ön kontrol yapması bu şekilde sağlanabilir). Burada, bu koşullardan biri sağlanmazsa hem GitHub gibi code review yaptığımız UI’lar üzerinden hemde özelden ilgili geliştiriciye geri bildirimimiz olduğunu belirterek, daha hızlı bir şekilde bu süreci yönetebiliriz.
Bize gelen değişiklik isteklerini iyi bir şekilde karşılayıp ona göre gerekli değişikliği yapmamız veya neden bu şekilde yapma gereği duyduğumuzu anlatmamız lazım. “İletişim” gerçektende bu noktada ve projenin genel kalitesi noktasında çok önemli.
Bazen incelediğimiz kodların, başka bir geliştirici tarafından da gözden geçirilmesine ihtiyaç duyabiliriz. Bunun gibi durumlarda, yani kritik noktalarda, başka birini de reviewer olarak atamaktan çekinmemek lazım.
Bize gelen değişiklik isteklerini, iyi bir şekilde incelemeli ve ona göre düzenlemeliyiz. Yani, bir kısmını düzeltip, bir kısmını düzeltmemezlik yapmamalıyız. Masa tenisi maçı gibi bir iletişim orada olmamalı 😄çünkü karşımızıdaki kişinin bizim işimizi incelerken bölündüğünü, ve zaman harcadığını göz önünde bulundurmalıyız. Bu sebeple, PR’ı gözden geçiren kişinin yorumlarını iyi bir şekilde değerlendirmeli, ve ona göre gerekli aksiyonu almalıyız.

Proje Bazlı Veya Şirket Genelinde Code Review’ı Kültür Olarak Yansıtmak İçin Neler Yapılabilir?

Şuan bulunduğum şirkette (Volosoft), GitHub taki repositorylerimiz üzerinden bazı kısıtlamalar koyuyoruz ve bu çok faydalı oluyor.
Örneğin, hiçbir şekilde ana bir branche otomatik commit atamıyoruz. Her yaptığımız değişiklik için bir Pull Request açmamız ve bu PR için en az 1 kişiyi reviewer olarak atamamız gerekiyor.
Eğer ilgili kişi review etmezse o PR mergelenemiyor, bunu da aynı şekilde GitHub’ın ayarlarından zorunlu kılıyoruz. Bu sayede, yapılan her iş aslında en az 2 kişi tarafından gözden geçirilmiş oluyor.
Bence, code review sürecini bir kültür olarak şirketin dinamiklerine katmak için bu çok güzel bir yaklaşım.
Bunun dışında, belirli aralıklarla geliştirici takımları olarak bir PR üzerinden toplu bir şekilde code review yapıyoruz ve bunu yazan geliştiricinin kodunu eleştirmek için değil, değerlendirmek ve kendi düşünce ve kurallarımıza göre gerekli yerlerde geri bildirimlerde bulunmak ve genel proje kalitesini arttırmak için yapıyoruz.
Bu da kesinlikle şirket içinde iletişimi arttıran, code review durumunu daha eğlenceli bir süreç haline getiren ve günün sonunda projeye ve biz geliştiricilere katkı sağlayan bir süreç haline getirilmesini sağlıyor.

İlgili podcast bölümü şuan 4 platformda yayında ve aşağıdaki linklerden ulaşabilirsiniz:

Sosyal medya hesaplarından da bizi takip etmeyi unutmayın, böylece yeni bölümler hakkında hızlı bir şekilde haberdar olabilirsiniz:

Okuduğunuz için teşekkürler, umarım keyif almışsınızdır. Bir sonraki yazı da görüşmek üzere…