Code review, ekibimiz içerisinde en önem verdiğimiz konuların başında geliyor. Moneo Kültürü olarak tanımladığımız birkaç madde var ve bu onlardan birisi. Diğer maddelere önümüzdeki yazılarda mutlaka değiniriz, şimdilik code review süreçlerimizden başlayalım.
Bu yazıya “hazırlık” dememin bir sebebi var. Code review’da bizim için olmazsa olmaz bazı konular var. Bu yazıda ön hazırlık konularını inceleyeceğiz.
Mental hazırlık: Code review, bilgi paylaşım aracıdır
Code review, sadece kodların incelenmesi değildir. Elbette kod kalitesi, hataların tespiti gibi konular için yapılır. Ama herşeyin ötesinde her bir pull request, yazılım ekibi içerisindeki en önemli bilgi transfer aracıdır. Yapılan işin ve işle ilgili teknik bilgilerin paylaşılacağı yerlerden biridir.
Gerçeklerden başlayalım, hayaller vs hayatlar. Çalıştığımız projelerin büyük bir çoğunluğu mükemmel proje yönetim süreçleri, mükemmel task detayları içermeyecek. Daily toplantılarında muhtemelen bir developer diğerini can kulağıyla dinlemeyecek. Jira(vb) içerisindeki bir başkasının işlerini detaylıca incelemeyecek. Zaten en başa döndüğümüzde, yapılacak işler yeteri kadar detaylandırılmayacak. Bunların gerçekler olmadığını düşünen varsa, yorumlara beklerim :)
Bu gerçekleri kabul ettiğimizde, bir pull request developerlar arası en iyi bilgi paylaşım aracı haline geliyor. Çünkü developer bunun için gerçekten vakit harcayacak. Orada verilen her bilgiyi özümseyecek ve sorgulayacak. Tabi bunu yapabilmesi için de pull requestlerin iyi tanımlı olması gerekiyor.
Pull Request Template
Pull Request Template, bizim için code review süreçlerinin ön koşuludur. 1 satırlık bir değişiklik bile olsa, belli başlı bilgilerin PR açıklamasında bulunmasını bekliyoruz.
Peki nedir bu PR template?
Basitçe, o PR ile ilgili açıklamaların yapılacağı bir şablon. Bu iş şablonsuz da yapılır elbette ama en azından temelde hangi bilgileri istediğimizi belirtmek işleri hızlandırıyor ve her PR için el alışkanlığı sağlıyor.
Motivation&Context kısmında, bu PR neden açıldı bilgisi yanıtlanıyor. Bir issue ile ilişkiliyse linklendiriliyor. Ya da açılmasına sebep olan konu, çözülen konu vs detaylarıyla aktarılıyor.
Types of Changes, bu PR’ın ne gibi değişiklikler içerdiğini belirlediğimiz alan oluyor. Seçenekleri arttırabilirsiniz. Bu bir Bugfix’tir ve Breaking Change içerir diye işaretleyebiliyoruz. Böyle bir durumda, review yapan kişi buna göre özen göstererek yapıyor.
Description kısmında ise, yaptığımız kodsal değişiklikleri yazıya döküyoruz. Nasıl çözdük, ne yaptık, neleri değiştirdik gibi konuları açık uçlu biçimde yazabiliyoruz.
How has this been tested kısmında ise, developer yaptığı işleri nasıl test ettiğini yazıyor. Review yapan kişi buradaki bilgilere göre kendisi de senaryoları tekrarlayabilir ya da developerın senaryolarının eksik/geçersiz olduğunu belirleyebilir. Bazen bir işi yanlış test edebiliyoruz. Ya da buraya “test etmedim” de yazabilir.
Screenshots kısmı bizim en çok önem verdiğimiz konu aslında. Görsel olarak ne değişti bilgisini burada görüyoruz. Bu kısım aslında bir self kontrol de sağlıyor. Peki diyelim ki görsel değişiklik içermeyen bir değişiklik yapıldı. Bu durumda ne ekliyoruz buraya? Her işin bir çıktısı olmak zorunda. Diyelim ki bir cli aracı değiştirildi. Bu durumda bunun çıktıları buraya ekleniyor. Ya da veritabanında değişiklik yapıyorsa bu MR, onunla ilgili değişiklikleri ekleyebiliyoruz. Aslında nasıl test edildi kısmındaki çıktıları buraya yüklüyoruz.
Dependencies kısmında ise bunun bağımlı olduğu diğer işleri belirtiyoruz. Örneğin bu PR’dan önce başka bir PR’ın yayına alınması gerekiyordur. Bu durumda onu burada belirtiyoruz. Ya da PR yayına alındıktan sonra sunucu üzerinde bir işlem yapılması gerekiyordur. Yine burada belirtiliyor.
Participiants kısmı ise, bu PR ile ilgili olan kişilerin listesini tuttuğumuz yer. A,B,C kişilerini/takımlarını ilgilendiriyor gibi bir bilgi geçiyoruz.
Baktığınız zaman sanki çok detaylı, çok uzun süren bir işmiş gibi görünebilir. Ama emin olun eliniz hızlıca bu şablona alışacak ve her PR açtığınızda tıkır tıkır dolduracaksınız. Elbette kendi iş süreçlerinize uygun yeni alanlar üretebilirsiniz.
Yazının başlığını “Code Review: Hazırlık” olarak belirlemiştim. İlk etapta mental bir hazırlıktan bahsettim ve bu etapta da PR’ın sunum hazırlığından bahsetmiş oldum. Developerların genel eksiği sunumları iyi yapamamasıdır. İllaki süper slide’lar, gifler hazırlamamıza gerek yok. Teknik olarak böyle basit bilgiler, bizim sunumlarımız oluyor. Code review yapacak kişinin işlerini ne kadar kolaylaştırırsak, o kadar faydalı olur.
Bunun yanı sıra proje hafızasına çok büyük bir katkı sunuyor buradaki bilgiler. Bir iş neden yapılmıştı sorusunun yanında nasıl yapılmıştı sorusunun yanıtı burada kolayca bulunabiliyor.
Static Analyzers & CI/CD
Code review ile ilgili doğru bilinen yanlışlar var. Code review, özünde hata bulma işlemi değildir. Bunu aslında zaten söyledim. Ama yazdığımız koda bakan bir başka göz, hataların tespiti için faydalı olabilir. Bazen bir typo yakalar, bazen kod hatası bazen de logic hatası. Yukarıda verdiğimiz bilgilerden beslenerek bu işlemleri daha kolay sağlar. Aslında bunu ChatGPT gibi düşünebilirsiniz. Ne kadar context verirseniz, o kadar iyi sonuç alırsınız. Aynı zamanda ne kadar az gereksiz bilgi verirseniz, alacağınız sonuçta yine daha iyi olur.
Statik analiz araçları, bizim için temel hataları tespit etmeye yarıyor. Syntax hatası olabilir, unutulmuş bir kod olabilir, kullanılmayan bir method olabilir, siz commit atmadan önce kediniz klavyeye basmış ve yanlış birşey eklemiş olabilir. Bunlar hep yaşandı. İşte bu noktada, code review yapan kişinin bu detaylarla uğraşmaması için, statik analiz araçlarından faydalanabilirsiniz. Code review yapacak kişi, önüne PR geldiğinde “acaba burada syntax hatası var mıdır” diye bir düşünceyle incelemeyecek. Yani beyni aslında bunu arkaplanda düşünmeyecek çünkü bu araçlar sayesinde syntax hatası varsa kişinin önüne gelmeyecek. Code review için bir aday olmayacak.
Bu statik analiz araçları nedir derseniz, açıkçası dilden dile değişir. Kullandığınız araçları yorum olarakta yazabilirsiniz. Biz PHP tarafında hemen hemen tüm araçları projelere dahil ediyoruz. php-cs-fixer, phpcs, phpstan, phan, var-dump-checker, parallel-linter bu araçların başında geliyor.
Peki CI/CD bu işin neresinde? Aslında CD, code review aşamasında bir yerde değil (eklenebilir, ama temel olarak değil). Bizi ilgilendiren kısım CI yani continuous integration, her branch gönderildiğinde/PR açıldığında sizin belirlediğiniz tanımlamalarla çalışır ve istediğiniz kontrolleri yapar. Eğer bir sorun varsa, fail olur ve developerın düzeltmesi beklenir. Bir projeye başladığımızda olmazsa olmazlarımızın başında CI ortamını kurmak gelir. Zaten bir kere kurduktan sonra, tüm projelere benzer ortamı kopyalayabiliyorsunuz. O yüzden buna harcayacağınız 1–2 günlük bir vakit, size gelecekte çok büyük zaman kazandıracaktır. Bir de üstüne otomatize testler ekler ve onları da CI üzerinde çalıştırırsanız, code review yapacak kişi sadece işin kalitesine, çıktı kalitesine odaklanır.
Bu yazımda sizlere code review yapılması için “ön koşullardan” bahsettim. Aslında anlayacağınız üzere bunlar birer zorunluluk, olmazsa olmaz değil. Ama işin kalitesini arttıran, review süreçlerini hızlandıran ve bizim her projede uyguladığımız pratikler bunlar. Eğer buna benzer pratikleri uygulamıyorsanız, ufak ufak kullanmaya başlayın derim. Düzenli code review yapılmayan bir projede sadece PR description bile işlerinizin kalitesini arttıracaktır çünkü size self-control imkanı sağlayacaktır. Siz de kendi projelerinizde uyguladığınız pratikleri yorumlara iletebilirsiniz.