Yazılım Takımlarının “Code Review” Sistemine Geçmesi
Merhaba, şuan bu yazıyı okuyan herkesin güzel işler peşinde olduğuna eminim. O yüzden ilk olarak hepinize yürümekte olduğunuz yolunuzda başarılar dileyerek başlamak istiyorum.
Bu yazının öncelikli hedefi başlangıçta küçük olup büyümeye başlayan yazılım ekipleridir. İlk olarak code review nedir ve neden yapılmalıdır konusuna değinmek istiyorum. Bir versiyon kontrol sistemi kullanıyor olduğunuzu varsayarak ilerliyorum. Doğru çalışan bir projeniz var, ve hatta projeniz live ise yapılan her işin dikkatli ve özenli yapılması gerekiyor. Yani hayat kurtaran her bir commit mesajımız bizim için ölümcül hatalara sebep olabilir. Ya da bu kadar kötü düşünmezsek iki farklı developer’ın gördüğü hatalar birbirinden tamamen farklı olabilir. O yüzden yapılan işlerin farklı bir göz tarafından tekrar kontrol edilmesi çok önemlidir. İşte code review tam olarak budur “kodun tekrar kontrol edilmesi”. Her şeyin yolunda gittiği bir dünyada düşünsek bile. Kodunun başka bir göz tarafından yeniden kontrol edileceğini bilen bir developer mutlaka daha dikkatli ve özenli yazacaktır. Bu da gelecek zamanda kodun bakımının daha kolay olacağını gösterir. Yani neresinden baksak kar diyebiliriz. Tek bir dezavantajı var o da tartışılır, bir developer için ekstra zaman maliyeti demektir bu. Bu yüzden bu sisteme geçmeden önce şirketinizin yöneticileri ve ürün yönetimi tarafıyla görüşmelisiniz.
Github ve Bitbucket çok benzer sistemlerle çalıştığı ve çok yaygın olduğu için bu ikisinden birini kullanmanız sorularınıza çok hızlı yanıt bulmanızı sağlayabilir. Ben örneklerime Bitbucket ile devam edeceğim. Bir yazılım projesinde 2+ çalışan olduğunu düşünelim. Bu projenin bitbucket’ta depolanan bir reposu var.
Bitbucket’ta projemizin içerisine girdiğimizde sol taraftaki menüde bu başlıkları görüyoruz. Bizi bu konu içerisinde en çok ilgilendiren bölüm branches ve pull requests(pr)’dir. Pull request’i yaptığımız geliştirmenin projeye eklenme talebi olarak düşünebiliriz. Projemizi dallandırarak, çalışmalarımızı devam eden geliştirmeyi bozmadan sürdürebilmemizi sağlaması için ise branch’leri kullanıyoruz. Branch ve pull request için isteğe bağlı yapılabilir akış ayarları bulunmaktadır. Bunu takım lideri ya da proje sahibi görebilir ve düzenleyebilir. Bu ayarlar için repository settings kısmını incelemenizi öneririm.
Şimdi şöyle bir yol haritası çizelim. A geliştiricisi yapmakta olduğu işi ana projeye eklemek istiyor.Bu sistemde ayarlarınıza bağlı olarak B geliştiricisi veya C yöneticisinin onayını almalı. Burada kaç kişi tarafından onaylanması gerektiğini seçebiliyorsunuz. A geliştiricisi ilk olarak görevini tanımlayan ya da eğer bir görev yönetimi sistemi kullanılıyorsa ordaki id’yi belirten bir isimle yeni bir branch açmalıdır.
Branch açma işlemini terminalden, bilgisayarında kullandığı Sourcetree gibi bir programdan ya da bitbucket üzerinden yapabilir. Burada yine ayar tanımlarınıza göre değişen Feature/Bugfix/Hotfix/Release gibi branch tipleri bulunmaktadır. Örnekte A geliştiricisi bir id ile bugfix tipinde yeni bir branch açar. Ve tüm çalışmalarını bu branch içinde yapar.
A geliştiricisi çalışmalarını birden fazla commit ile tamamlayabilir. Görevi bittikten sonra ana branch ile birleştirmek(merge) için pull request oluşturmalıdır. Bu yüzden bitbucket üzerinde menüden pull requests’e gelip create pull request’e tıklamalıdır.
Bu ekranda üstteki iki kutu içerisinde hangi branchten, hangi branch içerisine birleştirme talebi yapmak istenildiği belirtilmiştir. Title alanına default olarak branchinizin ismi gelir fakat isteğe bağlı olarak değiştirebilirsiniz. Description alanı için default olarak branch içerisinde göndermiş olduğunuz commit mesajları gelir bu alanı da daha açıklayıcı mesajlar ile doldurabilirsiniz. Son olarak reviewers yani kodunuzu okuyacak kişileri seçmelisiniz. Burada birden fazla kişi seçebilirsiniz. Örnek olarak B geliştiricisi seçilecek. En alttaki close branch bölümünü aktifleştirirseniz (aktifleştirmeniz önerilir) bu görev tamamlandı ve ana branche birleştirildiğinde açılmış olan branch silinir ve karmaşıklık yaratmaz anlamına gelir.
Şimdi pr açtığımıza göre B geliştiricisi gözünden bakalım. B geliştiricisine yeni bir pr açıldığına dair mail veya bildirim gelir, conflictlere sebebiyet vermemek için açılan pr’ların 24 saat içerisinde okunması tavsiye edilir.
Burada B geliştiricisi tarafından okunan pr’ı görüyoruz. B geliştiricisi uygun olmadığını düşündüğü noktalarda yorumunu paylaşabilir ve A geliştiricisi yoruma istinaden yeni commitler atabilir. Yeni commitler atıldığında tekrar pr açmaya gerek yoktur. Aynı pr içerisinde yeni commitler görünecektir. Burada sağ üstteki approve butonuna dikkat çekmek isterim. Yanındaki rakam bu pr’ın kaç kişi tarafından onaylandığını gösterir ve onaylaması gereken kişi sayısı tamamlandığında merge butonu aktif olur. B geliştiricisinin bu branchi merge etmesi gerekmektedir.
B geliştiricisi merge butonuna bastığında karşısına bir seçenek gelir. Merge strategy alanında bu seçenekleri görebilirsiniz. “Squash” seçtiğiniz zaman A geliştiricisinin tüm commitleri birleştirilir ve bir üstte yazan commit mesajı ile tek bir commitmiş gibi birleştirilir. O seçenekler arasından “Merge commit” seçtiğinizde tüm commitler ayrı ayrı görünücek şekilde ana branche birleştirilmiş olur. Burası tamamen sizin tercihinize veya pr’ın içeriğine bağlı olarak değişebilir.
Tüm pr açma ve kod okunma işlemleri ayarlarıyla birlikte daha fazla genişletilerek kullanılabilir. Ana yapısı itibarı ile bu şekildedir. Unutmadan pr açtığınız görevlerin çok büyük olmaması okunabilirlik açısından çok önemlidir. Bu yüzden görev dağılımı yaparken en küçük parçalara kadar ayırmanız tavsiye edilir. Hem okunabilirlik hem yönetilebilirlik açısından daha rahat olur.
Umarım yardımcı olabilmişimdir. Sağlıkla kalın..
