- Kod incelemesi kulağa iyi bir fikir gibi geliyor, değil mi?
- Kod incelemesiyle iki geliştirici koda bakıp sorunları bulabilir ve projenin nasıl geliştiğine dair anlayışlarını paylaşabilir
- İncelemeci, yazarın kodunu yakından incelerken faydalı püf noktaları öğrenebilir ya da yazara faydalı püf noktaları gösterme fırsatı bulabilir
- Ancak bu, kod incelemesini kullanan 'aydınlık taraf' incelemecilerinin yöntemidir. Yani kod incelemesini, kodu iyileştirmek ve geliştiricilerin kolektif becerilerini artırmak için kullanırlar
- Kod incelemesi tamamen farklı amaçlar için de güçlü bir araç olabilir. İncelemeci 'karanlık tarafa' geçerse, kodun iyileştirilmesini engellemek veya geciktirmek için çeşitli yöntemler kullanabilir
- Hatta yama yazarını bezdirmek ya da tamamen yıldırmak gibi başka kişisel amaçların peşine de düşebilir
- Yakın zamanda 'karanlık tarafa' geçmiş bir incelemeciyseniz, henüz tüm olasılıkları düşünmemiş olabilirsiniz
- Bu yüzden bu yazı, karanlık taraf kod incelemecileri için bir antipattern listesi sunuyor
[Antipatternler]
The Death of a Thousand Round Trips
- Kodu okurken önemsiz bir şey fark ettiğiniz anda bunu inceleme yorumu olarak yazın ve okumayı hemen bırakın
- Geliştirici dürüstçe o önemsiz şeyi düzeltir ve güncellenmiş yamayı gönderir
- İncelemeci bu sürümü okumaya başlar ve başka bir önemsiz şey bulur. Bunu ilk incelemede söyleyebilirdi ama söylememiştir. Onu da işaret eder ve yine okumayı bırakır
- Bunu, geliştirici umudunu kaybedene kadar tekrarlayın
The Ransom Note
- Bu yama geliştirici için özellikle önemli görünüyor
- Ama incelemeci için o kadar da önemli değil. Dolayısıyla güç pozisyonu incelemecidedir
- Geliştiricinin istediği değişikliği, incelemeci açısından önemli olan ek işler tamamlanana kadar rehin tutabilirsiniz
- Bu ek işlerin aslında aynı commit içinde yer alması gerekmez, ama incelemeci için önemlidirler
The Double Team
- Tek bir yama, iki incelemeci
- İncelemecilerden biri her değişiklik talep ettiğinde geliştirici usulca yapar. Sonra sıra diğer incelemecinin şikayet etmesine gelir
- İncelemeciler sırayla birbiriyle çelişen talepler öne sürer
- Ama yorumları hep geliştiriciye yazarlar. İnceleme dizisinde birbirleriyle doğrudan tartışmaktan kaçınırlar
- Amaç, geliştirici pes edene kadar onu kaç kez ileri geri savurabileceklerini görmektir
The Guessing Game
- Ortada bir sorun vardır ve o sorunu çözmenin çeşitli yolları vardır
- Geliştirici bir çözüm seçer ve yamayı gönderir
- İncelemeci, o spesifik çözümü sorunu çözüp çözmediğiyle ilgisiz nedenlerle eleştirir
- Örneğin muğlak tasarım ilkelerini ihlal etmesi ya da gelecekteki geliştirme planlarıyla uyumsuz olması gibi gerekçeler sunar
- Eleştiriyi yeterince belirsiz yaparsanız geliştirici, mevcut yamayı nasıl değiştirirse bu eleştiriyi gidereceğini anlayamaz
- Bu durumda geliştiricinin yapabileceği en iyi şey, asıl sorunu çözmek için tamamen farklı bir çözüm seçip onu uygulamaya çalışmaktır
- Sonra incelemeci bunu da aynı derecede faydasız bir biçimde reddeder
The Priority Inversion
- İlk kod incelemesinde önemsiz ve basit şeyleri işaret edin
- Geliştiricinin bunları düzeltmesini bekleyin, sonra büyük bir sorunu gündeme getirin
- Yamanın kayda değer bir bölümünü baştan yazmayı gerektiren temel bir sorun vardır. Bu da daha önce yapılan birçok ufak düzeltmenin çöpe gitmesi anlamına gelir
- Birine tonla iş yaptırıp sonra onu attırmak kadar "çalışman istenmiyor ve zamanın değerli değil" mesajını iyi veren çok az şey vardır
- Bu tek başına bile geliştiricinin pes etmesine yetebilir
The Late-Breaking Design Review
- Haftalar ya da aylar boyunca çok sayıda ayrı yamayla son derece karmaşık bir iş üzerinde çalışılmıştır
- İncelemeci, bu çalışmanın genel tasarımına katılmıyordur; ancak ya ilk tartışmada yer almamıştır ya da tartışmayı kaybeden taraftadır
- Sonra incelemeciden, bu çalışmanın ortasındaki küçük ama önemli bir parçayı incelemesi istenir (örneğin birçok geliştiriciyi engelleyen bir bug için kolay bir düzeltme). Bu, incelemeci için bir fırsattır
- İncelemeci, şimdiye kadar yapılmış tüm çalışmanın genel tasarımına dair gerekçe ister
- Geliştirici tüm işin yalnızca bir kısmından sorumluysa ve cevabı bilmiyorsa, bu incelemecinin sorunu değildir. İncelemeci tatmin olana kadar "approve" düğmesine basmaz
The Catch-22
- Yama büyükse okunması çok zordur. Kendi başına anlamlı alt parçalara bölünmesini isteyin
- Tersine, çok sayıda küçük yama varsa bunların bazıları kendi başına anlam ifade etmez. Tekrar birleştirilmelerini isteyin
- Belirli bir durumda bir tür trade-off ilgili görünüyorsa, bunu şikayet edecek bir neden bulmak için kullanabilirsiniz
- Örneğin kod kolay anlaşılır şekilde yazılmışsa performansı kötü olacaktır; iyi optimize edilmişse de okumak ve bakımını yapmak zor olacaktır
The Flip Flop
- Kodun aynı bölümünde insanların genel olarak yaptığı türden değişiklikler vardır
- İncelemeci daha önce bu tür değişiklikleri birçok kez incelemiştir
- Yeni bir değişiklik gelir. Yazar önceki değişiklikleri dikkatle incelemiş, mevcut örüntüyü özenle takip etmiş ve bu alana hakim görünen bir incelemeci seçmiştir
- İncelemeci, daha önce hiç sorun etmediği bir yönüne birden itiraz eder. Mevcut örüntüyü izlemek artık yeterli değildir
- Peki yazar aynı türden eski değişiklikleri gösterip incelemecinin tutarsızlığına dikkat çekerse ne olur?
- İncelemeci, "Doğru. Onlar da değiştirilmeli" der
- İncelemeci, mevcut örneklerin hepsini değiştirmeyi gönüllü olarak üstlenmemeye dikkat etmelidir. Şanslıysa geliştirici bunu, mevcut örnekleri de bizzat değiştirmesi gerektiği yönünde bir talimat olarak yorumlar ve incelemeci büyük emekten kurtulur
Ama ciddi olarak ...
- Buraya kadar yazı bir şakaydı. Bununla incelemecilerin bu kötü davranışları bilerek yaptığını öne sürmek istemiyorum
- Açıklamaların çoğu, incelemecilerin gerçekte yaptığı şeylerin abartılmasıdır ya da hayal kırıklığı yaşamış yama göndericisinin hislerinin abartılmasıdır
- Gerçekte bunları yapmayın demek istiyorum!
- Gidiş gelişleri en aza indirmeye çalışın, önemsiz noktalara takılmadan önce (gerekliyse) büyük yeniden yazımları isteyin ve bir yamayı eleştirirken hangi sürümün kabul edilebilir olacağına dair yapıcı öneriler sunun
- Tüm kod tabanı hakkında bir görüşünüz varsa, bunu tek bir geliştiricinin yamasını incelerken laf sokma fırsatına çevirmek yerine bütün geliştiricilerle genel bir tartışma yapın
- Bunu yanlışlıkla yaptıysanız farkına varın. Yanlışlıkla bir geliştiricinin hayatını zorlaştırdığınızı kabul edin, özür dileyin ve daha yardımcı olmaya çalışın
- Temel sorun, yetkinin kötüye kullanılmasıdır
- Bir geliştirici başka bir geliştiricinin yamasında kod incelemecisi olduğunda geçici bir yetki elde eder. İncelemeci, o yamanın commit edilmesini engelleme gücüne sahiptir
- Yetki sorumluluk getirir. Yetkinizi amaçlanan kullanım için ve yalnızca gerektiği kadar kullanmalısınız
- Antipatternlerin çoğu (ya da burada hicvedilen daha hafif davranışlar), yetkinin kötüye kullanılmasıdır. İncelemeci, yamanın iyileştirilmesiyle ilgisiz veya buna ters düşen kişisel gündemleri kovalamak için geliştirici üzerindeki geçici yetkiyi kaldıraç olarak kullanır
- Kişisel gündemler antipatternden antipattern'e değişir: alakasız işler, kişisel stil tercihleri, tembellik, değişime direnç ya da yama gönderene duyulan kişisel antipati gibi
- Yama göndericisi geçmişte kod incelemecisiyken bu kötü davranışları sergilediyse, o antipati haklı da olabilir. Bu yüzden kod incelemecisinin yetkisini dikkatli kullanması gerekir
- Geliştiriciler birbirine karşı bir intikam sarmalına girerse yazılım projesi mahvolur
Gatekeeping kod incelemesi
- Buraya kadar daha çok akranlar arasındaki kod incelemesine odaklandım
- Kod incelemecisi ile yama göndericisi meslektaştır; birbirlerine karşı hiyerarşik sorumlulukları yoktur ve kod tabanı üzerinde nihai karar yetkisine sahip değildirler
- Bu yüzden kod incelemesinden doğan güç geçicidir
- Akran incelemesi bağlamında, kod incelemecisi ile yazarın temelde aynı hedeflere sahip olması gerekir
- Hangi özelliğin ekleneceği, onaydan önce ne kadar cilalama gerektiği ya da kabul edilebilir kodlama stilinin ne olduğu konusunda ciddi anlaşmazlıklar varsa bunlar kod incelemesi dışında ele alınmalıdır
- Ama başka tür kod incelemesi durumlarında bu böyle değildir. Özellikle proje dışından birinin istenmeden yama göndermesi halinde durum çok farklıdır
- Bu senaryo genellikle özgür yazılımda görülür
- Çünkü dünyanın herhangi bir yerindeki biri kaynak kodunu değiştirip değişikliklerini geri göndermeye çalışabilir
- Ama başka durumlarda da olabilir
- Sahipli (proprietary) kod geliştiren bir şirkette, bir takımın geliştiricisi başka bir takımın projesine yama gönderip şansını deneyebilir
- Bu gibi durumlarda, yamayı alan tarafın o değişikliği en baştan istememesi ya da yapılma biçimine tamamen katılmaması nedeniyle yamayı hiç kabul etmeme olasılığı çok daha yüksektir
- Bu durumda olan şey, akran incelemecisi olarak verilmiş geçici yetkinin kötüye kullanılması değil; proje sorumlusu olarak kalıcı yetkinin meşru biçimde kullanılmasıdır
- Kendi yazılım projemin yönünü ben belirlerim
- Kod incelemecisi böyle bir 'gatekeeping' rolündeyken, yamanın mevcut genel tasarım ilkelerini veya gereksinimleri ihlal ettiğini söyleyerek eleştirmek her zaman yanlış değildir
- Belki de o sorunu, gereksinimlerle uyumlu bir biçimde nasıl çözeceğini bilmiyordur
- Aslında işin zor kısmı bu olabilir ve aynı değişikliği henüz yapmamış olmamın tek nedeni de bu olabilir
- Ancak gatekeeping bağlamında bile açıklama yapmadan 'The Guessing Game' uygulamak kabalıktır
- Ben genelde geliştiricinin zor kısmı gözden kaçırdığını açıklamaya çalışırım; kendim de cevabı bilmiyorsam bunu söylerim
- Elbette 'The Death of a Thousand Round Trips' gibi pasif-agresif engellemelere hiçbir mazeret yoktur
- Eğer gerçekten yamayı koda hiç almak istemiyorsanız ve bu kararı verme konusunda meşru yetkiye sahip bir gatekeeping rolündeyseniz, göndericinin daha fazla zaman kaybetmemesi için bunu açıkça söyleyebilirsiniz
Disclaimer
- Bu yazı için notları, yıllar boyunca içinde bulunduğum (her iki tarafta da) kod incelemelerinden, başkaları arasında gözlemlediğim kod incelemelerinden ve sadece sohbetlerde duyduğum kod incelemelerinden topladım
- Dolayısıyla bu yazı, yakın zamanda kodumu inceleyen belirli bir kişiyi hedef almıyor
13 yorum
Düşündüğünüz kadar abartı olmayabilir....
Bunu gerçekten yaşadım; az kalsın yazılım geliştirmeyi bırakıyordum, toparlanmam gerçekten zor oldu.
Yazıyı okuyunca az kalsın PTSD tetikleniyordu.
Görünüşe göre bu makale için notları şimdiye kadar epey iyi toplamışsınız!!
Sadece okumak bile psikolojik istismar düzeyinde...
Özetin son satırda olması asıl mesele, değil mi? hahaha.....
Vay... az kalsın kanser oluyordum;;
Böyle şeyleri,
si + smyapan yerlere giderseniz Türkiye'de de sıkça görebilirsiniz. Buna genelde bölgecilik denir. Kötü niyetli insanlar ekmek teknelerini korumak için türlü türlü şeyler yapar.Kötü niyetli birçok yöntem varmış.
Uzun vadede bakınca, ortada makul bir neden yokken böyle davranan insanlar ya 1) erken dönemde geliştirici çevresinden dışlanır, ya da 2) berbat karakterine rağmen yeteneği olağanüstü olduğu için büyük bir rol üstlenmiştir ve dışlanması zordur; bu durumda biri adaptör rolünü üstlenip iletişim kanalı olarak aradaki bağlantıyı sürdürdüğü için o durum devam eder, ama o aracı kişi herhangi bir nedenle ortadan kalkarsa çok geçmeden hızla dışlanır. İnsan ne kadar çırpınırsa çırpınsın, sonuçta bir şeyler yapmak için insanların bir araya gelmesi gerekir ki para dönsün; para dönmesi için de insanların gidip gelmesi gerekir. Bu yüzden insanlarla iyi geçinemeyen kişiler, eninde sonunda gruptan dışlanır ve geride kalır.
Genelde bir grubun içinde, karakteri kötü olmasına rağmen uzun süre hayatta kalmış insanlar, bunu sanki kendileri bir dizideki Sherlock gibi yüksek işlevli bir sosyopat oldukları için başarmış sanma yanılgısına düşer. Oysa mesele sadece işe yarıyor olmalarıdır; çevresindekiler dişini sıkıp onları kullanır, ama işe yararlılıkları ortadan kalktığında ilişki "seninle birlikte olmak berbattı, bir daha da görüşmeyelim" noktasına gelir. Cumberbatch'in başrolünde olduğu Sherlock da dışarıdan baktığımızda çekici bir sosyopat gibi görünür, ama çevresinde Sherlock'tan vazgeçmeyen ve ona değer veren insanlar olmasaydı ortada hiçbir hikâye olmazdı.
Kötü bir karaktere sahip olmasına rağmen uzun süre ayakta kalan insanlar, çoğu zaman bunu sanki bir TV dizisindeki Sherlock gibi yüksek işlevli bir sosyopat oldukları için başardıklarını sanıyor; ama aslında sadece işe yaradıkları için çevrelerindekiler dişini sıkıp onları kullanıyor, işe yararlılıkları bittiğinde de ilişki "seninle birlikte olmak berbattı, bir daha da görüşmeyelim" noktasına geliyor. ==> Müthiş bir ifade. Bunu aklımda tutmalıyım.
İş yerinde zorbalığı ya da power harassment'ı hatırlatıyor.
Şaka deniyor ama yazıyı okurken bir anda aşırı sinirlendim..