🤜🏼 En Önemli Teknik Yetenek “Code Review” 🕵🏼 İşte 8 Sebep!
Evet, yanlış duymadın. Öncelikle “Code Review” ne demek onunla başlayalım.
Code Review Nedir?
X kişisi tarafından yazılan bir kodun başka bir kişi veya kişiler tarafından incelenmesi işlemidir. Genelde kodların geliştiricinin yerel ortamından başka bir ortama alınmadan önce ilgili kişiler tarafından incelenmesi ve fikir, görüş paylaşma işlemi olarak da düşünülebilir. Kodu yazan ve inceleyen kişinin aynı X kişisi olması istenen bir durum değildir.
Kodu inceleyen kişi(ler)in o alanda yetkin olması önemli bir kriterdir. Her zaman kod inceleyici yorumları mutlak doğru olmayabilir veya kod inceleyici geliştirmeye açık her durumu fark edemeyebilir. Dolayısıyla kodu birden fazla kişinin incelemesi çok yerinde bir harekettir.
Kod incelemelerinden sorunsuz geçmiş veya incelemeler sonucu revize edilmiş kodlar hala daha kusur barındırabilir. Kodu yazan, inceleyen ve revizyon durumuna göre kod inceleme süreci acayip değişkenlik gösterir.
Yazı boyunca Code Review için CR kısaltmasını kullanacağım.
İlk madde ile saldırmaya başlıyorum.
1. Yazmak için değil okunması için. 🤓
Kodlar yazıldığından çok daha fazla okunur. Dolayısıyla kodları yazmak için değil okunması için yazarız, yazmalıyız. CR bilinci ile yazılan kodlarda bu durum göz önünde bulundurularak henüz yazma aşamasında daha özenli, düşünceli ve çevik hareket edilir. Bilinir ki, bu kodları bir insan evladı okuyacak, yani anlaşılmalıyım!
2. Sorumluluk bilinci. ⏱
CR’in olduğu süreçlerde geliştiricilerin ekip bilinci ve sorumluluğu daha yüksektir. Kimse herkesin fark edeceği basit revizyon ihtiyacı olan kodlar ile kendi CR sürecini uzatmak istemez. Bu yüzden kodu yazarken monolog halinde “acaba bu fonksiyonu daha efektif hale getirebilir miydim? öyleyse nasıl?” gibi sorular sorar. CR sayesinde geliştiriciler CR olmayan durumlara göre kesinlikle daha sorumlu, duyarlı ve üretken davranır.
3. Paylaşmak güzeldir. 🤗
CR süreci hem öğrenmenizi hem de öğretmenizi sağlayan bir kazan kazan modelidir. Başkalarının problem çözme yaklaşımlarını gördüğünüzde size ilham olduklarını fark edecek ve kodlama pratiklerinizde o yaklaşımları da denemeye başlayacaksınız. Beyniniz için çok iyi bir egzersiz değil mi? Akıl akıldan üstündür. Öte yandan o kişilerin kodlama pratiklerini iyileştirmelerine bir katkınızın olması da olası.
Akıllı insan kendi aklını kullanır, daha akıllısı başkalarının aklını.
4. Disiplinin hatırlatıcısıdır. 🏆
CR kesinlikle ciddi bir şey yapıyormuş gibi hissettirir. Şöyle düşünün, canlıya majör bir özellik eklemen gerekti. Geliştirmeyi yapıp tüm testlerini tamamladığını düşünüyorsun. O halde canlıya geçebilmen için hiçbir engel var mı? Yok! (Eğer bu proje hafta sonları ikişer saat bakarak ilerlettiğin kimsenin gerçekten ciddiye almadığı bir repodan ibaretse.)
Ya öyle değilse? Mesela söz konusu proje şirkette üzerine çalıştığınız bir ürünse. Bu majör özellik için pek çok kişiye içeride tam olarak neyi, neden ve nasıl yaptığını anlatman ve onları ikna etmen gerekir. Çünkü üzerinde çalıştığın iş ciddi bir iş. CR süreci ekibin disiplinli olması gerektiği konusunda bir hatırlatıcı gibidir.
5. Ekibi ekip yapar. 💪
Solo çalışmayı sever misin? CR süreci tek başına yürütülemez, en az iki veya daha fazla kişinin koordine çalışmasını gerektirir. Yani CR ekip olmaya bir adım daha yaklaşmanızı sağlar.
Öte yandan ekipçe kodların kalitesi hakkında tartışarak ve fikir alışverişinde bulunarak ekibin en iyi versiyonunu yakalamaya çalışmanız da güçlü bir ekip olmayı sağlayan ikinci faktör olarak düşünülebilir.
6. Açık kaynak işlerde öncelik sahipleri CR’ciler! 💥
Tek başına CR süreci sizin açık kaynak kod geliştirdiğiniz veya açık kaynak kod topluluğunu desteklediğiniz anlamına elbette gelmez. Ancak açık kaynak kod geliştirmek, açık kaynak repolara katkı sağlamak isteyen biriyseniz CR süreçlerinde aktif rol almış olmanız size çok büyük avantaj sağlar.
Çünkü açık kaynak bir projeye destek vermek istiyorsanız başkasının yazdığı kodu anlayabilme yeteneğine sahip olmanız gerekir, bu da CR süreçlerinde pekiştirilen bir yetenektir. Öte yandan açık kaynak kodlu bir proje geliştirmek istiyorsanız yazdıklarınızın anlaşılır olması gerekir ve yine bu da CR süreçlerinde deneyimleyerek geliştirdiğiniz bir yetenektir.
CR sürecine aşina birisi, aşina olmayan birisine göre açık kaynaklı işler konusunda elbette çok daha öndedir.
7. Omzunuzdaki yükü dengeler. 🏋🏻♂
CR olmayan süreçte günah keçisi ilan etmek kolaydır, aşağıdaki diyaloğa bakın, tanıdık geliyor mu?
- Necmi abiii! Ya bu dün canlıya aldığımız kodda bi sıkıntı mı var???
- Sorma Ceyda, sabahtan beri gelen tüm analizler patlıyor, ona bakıyorum.
- Ee bu son eklediğimiz kodu kim yazmıştı…
- Harun, abi sen bi gelsene iki dakka!
Aslına bakarsanız sadece kodu yazan Harun değil aynı zamanda kodu incelemeyen tüm ekibin ortak bir sorunu bu. Eğer CR yapılmış olsaydı kodu inceleyenler de kodun kalitesine, verimliliğine, mantıksal bir sorun veya hata olmadığına dair bir değerlendirme yapacaktı. Bu değerlendirme sonucu da kod inceleyiciler en az Harun kadar güncellemeden sorumlu olacaklardı. Sorumluluğu, yükü ve stresi tüm ekipçe paylaşmak iyidir.
Sonuç itibariyle başta yapılmayan CR süreci en son da yapılmak zorunda kalınabilir. 😜
- Şimdi Harun sen anlat bakalım bi şu fonksiyonda niye bu parametreyi geçmiştin?
- Tabi anlatayım abi, …
8. Mesafeler bu sevdaya engel değil. 🔥
Annem hep derdi, “oğlum dot net falan yaz, MVC frameworkün olsun, yerin yurdun belli olsun, hea bir de ssk veya bağkur.”
Şaka bir yana, dünyanın farklı kıtalarında, farklı zaman dilimlerinde yaşayan insanların senkron olup çalışabilme ve açık kaynak kodlu bir işletim sistemi gibi karmaşık sistemi gönüllü geliştirebilme motivasyonları bana hep çekici gelmiştir.
İşte bunlar, buralar hep code review, fazla söze gerek var mı?
Siz bu konuda ne düşünüyorsunuz? Yazıya ek olarak sevgili Lemi Orhan Ergin’in anlatımıyla CR süreci ile ilgili bir video bırakıyorum.
Yorumlarınız benim için değerli, kalın sağlıcakla.
