Bir Kod Satırını Değiştirmek 6 Gün Sürüyor (2015)

• Fabrika kullanım oranı %10 düşünce şirket işten çıkarma yerine yoğun sezon öncesi stok biriktirmek istedi; bunun için 3 aylık birikmiş iş sınırını 4 aya çıkarma talebi başlatıldı
• BT yöneticisi, çekirdek rutindeki tek bir hard-coded değeri değiştirmenin yeterli olacağını düşündü; ancak önce ticket açılması, iş etkisinin yazılması, onay alınması ve kuyruk önceliğinin ayarlanması gerekiyordu
• Programcı, Module ORP572’nin 1252. satırında MonthsOfBacklog değerini "3"ten "4"e değiştirip testleri geçirdi; ancak kod incelemesinde mevcut politika ihlalleri de düzeltme kapsamına alındı
• Değişikliğin kapsamı Parameters dosyasına kayıt ekleme, debug komutlarını kaldırma, atanmamış değişken uyarıları, hard-coded Employee ID, erişim yetkileri, test ortamı, test planı ve kullanıcı imzası gibi yan prosedürlerle büyüdü
• İş açısından gerekli değişiklik 1 satır ve 1 bayttı; ancak toplam geçen süre 6 gün oldu ve iç prosedürler ile politikalar küçük bir değişikliğin gerçek lead time’ını büyük ölçüde artırdı

---

3 aylık sınırı 4 aya çıkarma talebi

• Başkan Philip, fabrikanın %10 atıl durumda olduğunu söyleyerek, işten çıkarma yerine daha fazla birikmiş iş üretip yoğun sezon öncesi stok yapmak istedi
• Operasyon müdürü Lee, şirket politikası gereği yalnızca 3 aylık birikmiş iş üretilebildiğini; sınır 4 aya çıkarılırsa yeterli iş oluşacağını söyledi
• BT yöneticisi David, legacy yazılımın çekirdek rutininde yalnızca bir satır kod değiştirmenin yeteceğini düşündü ve IT Services’a ticket gönderilmesini istedi
• BT yöneticisi Judy, talebi Ticket# 129281 olarak atadı; ancak Business Impact bölümünün ve Director onayının gerekli olduğunu söyledi
  • David işten çıkarma olasılığından bahsedince Judy bu bölümü bizzat doldurdu ve talebi hızlandırılmış işleme aldı
  • 2 gün sonra bile talep Developer Queue’da 14 Bug Report’un ardından ilk Enhancement olarak kalmıştı
  • David, talebin acil olarak işaretlenmesini ve doğrudan Ed’e gönderilmesini emretti

Tek satırlık değişikliğin prosedür değişikliğine dönüşmesi

• Ed, Module ORP572 line 1252’de hard-coded değişken MonthsOfBacklog değerini "3"ten "4"e değiştirdi
  • Unit test’i geçti ve batch test’ini 2 kez çalıştırdı
  • Operations iş kuyruğu beklendiği gibi %10 arttı
  • Değişiklik Code Review’e ve Homer’ın User Acceptance Testing sürecine geçti
• Kod incelemesinden sorumlu Shirley, hard-coded değişkenin şirket politikasına aykırı olduğunu söyleyerek bunun Parameters dosyasında bir kayıt haline getirilmesini istedi
  • Mevcut 2 Debug komutunun, atanmamış değişken uyarısının ve hard-coded Employee ID’nin de production’a alınmadan önce düzeltilmesi gerektiğini söyledi
  • Ed’e ORP572 atandığı için, yeni şirket politikasını ihlal eden mevcut hatalardan da sorumlu olması gerektiği görüşündeydi
• Test ortamı da gecikme etkeni oldu
  • Homer, ay sonu muhasebe kapanış kontrol testi nedeniyle kullanılamadığı için Marge’ın kullanılması gerekiyordu
  • Ed’in Marge erişim yetkisi yoktu; IT Security’den Joe ise David’in imzası olmadan yetki veremeyeceğini söyledi
• Parameters kaydı işi ek taleplerle genişledi
  • MonthsOfDemand adının yurtdışındaki programcılar tarafından anlaşılmasının zor olduğu gerekçesiyle daha iyi bir ad gerekiyordu
  • Yeni Parameter kaydının audit trail’e sahip olması gerekiyordu; ancak bu politika belgelenmemişti ve wiki güncellemesi de 3 ay gecikmiş durumdaydı
  • Ed, adı SelectedMonthsOfBacklogDemand olarak değiştirdi ve bu kaydı ve audit trail’i koruyan Module PAR634’ü ekledi
• Test sorumlusu Tony, Marge’da 129281in göründüğünü ancak Test Plan olmadığını belirtti
  • Ed, eski ve yeni yöntemle çalıştırıp WorkOrdersHours raporundaki toplam artışı doğrulamanın yeterli olduğunu söyledi; ancak Tony bunun tüm fabrikayı etkilediğini belirterek kullanıcı seçimi Test Cases, Expected Results, belgelenmiş Test Runs ve kullanıcı sign-off’u istedi
  • 2 gün sonra Philip, David’e Tony’nin Ed’in programını derhal production’a taşımasını sağlamasını emretti
• Toplam geçen süre 6 gün oldu; mission critical code değişikliği ise 1 satır ve 1 bayttı
  • 24 adet Excedrin tüketildi
  • Hacker News’te sinir içinde harcanan süre 14 saat olarak yazıldı

[GN⁺]

Hacker News görüşleri

• Asıl mesele, yorumcunun “bunu değiştirmek için kod tabanındaki çözülmemiş diğer sorunları da birlikte düzeltmek gerekir” diye dayatmasında yatıyor
  Böyle durumlarda şöyle geri itmek gerekir: “Kod kalitesini artırma yönü iyi, ama Y’yi değiştirirsek X/Y/Z onayı gerekir ve birkaç gün daha uzar. Söylediğiniz konuyu bir teknik borç işi olarak açalım, öncelik ve kapasiteye göre sonraki bir PR’da ele alalım. Şimdilik bu yerel PR’ı yayına almak için ne gerektiğine odaklanalım.”
  En büyük ders, odaklı PR’lar hazırlamak ve yorumcu kapsamı genişletmeye çalıştığında buna karşı çıkmayı öğrenmekti. Genel olarak diğer mühendisler bunu pragmatik biçimde karşıladı. Bunun satır sayısıyla ilgisi yok. Tüm kodda yalnızca format değişmiş olabilir ve mantık değişmemiş olabilir; ya da sadece birkaç feature flag değişse bile etkisi büyük olabilir. Aynı anda yalnızca tek bir odaklı değişiklik yapılmalı

  • Asıl meselenin “bunu değiştirmek için diğer çözülmemiş sorunları da düzeltmek gerekir” olduğuna katılmıyorum. Buradaki en kötü şey, tek satır kod değiştirmenin 6 gün sürmesi ve bunun neredeyse yarısında mühendisin daha issue’ya bile bakmamış olması
    Eğer bu, hemen ele alınmazsa şirketin insan çıkarmak zorunda kalacağı kadar yüksek öncelikli bir işse, birinin bakmasından önce geçen 2-3 gün asla yaşanmamalıydı. Ama bu geliştirme sürecinde bu sanki “hızlı yol” gibi görünüyor
    Son 2 günde de test planı yetersiz bulunduğu için hiçbir şey olmamış gibi duruyor. “Bunu değiştirmek için diğer çözülmemiş sorunları da düzeltmek gerekir” kısmı burada sadece 2 saat tutmuş ve daha o noktaya gelmeden bile bu sürecin temel sorunu olarak gösterilebilecek en az 2-3 şey daha var
  • Genelde o anda üstlenilen işle doğrudan ilgili olmayan iyileştirmelerden kaçınırım. Sadece eksik bir noktalı virgül eklemek bile aşırı hevesli bir yorumcunun dikkatini çekip seni legacy düzeltme tavşan deliğine sürükleyebilir
    FIXME ya da TODO bırakmak yerine, unutulmaması için sessizce bir issue açmayı tercih ederim. İncelemenin bu kısmı bozuk. Teknik borcun kapatılması, işin bitmiş sayılması için bir koşul değil; ayrı planlanmalı
  • Kapsam genişletme yapan insanlar, bunun yarattığı mimari hasarın farkında değil. Tek bir kod bloğuna aşırı takıntı olunca insanlar onun etrafından dolaşmanın yollarını aramaya başlıyor
    Bu katmanlar biriktikçe ortaya çıkan kod, çevre yollarının çokluğuyla kötü ün salmış Atlanta, GA ile ahlaken eşdeğer bir hale geliyor
  • Daha iyi çözümün kuralları otomatikleştirmek olduğunu düşünüyorum
    Yeni bir kural eklendiğinde otomasyon, mevcut tüm ihlal noktalarına kural istisnası yorumu ekleyebilmeli ve bunları izlenebilir kılmalı. Acilen yayına alınması gereken bir kodun kuralı ihlal etmesi gerekiyorsa, istisna yorumunu ekler ve daha sonra düzeltecek sorumlu olarak kendi adını yazarsın
    Zamanla, özellik geliştirmeden ayrı olarak bu kural ihlallerini düzeltmeye yönelik bir kültür oluşturulabilir
  • Böyle bir şey olduğunda sadece bir TODO ticket’ı eklemek yeterli. Prodüksiyon blokajı kalkar ve sistem de daha kötüye gitmez

• Doğru. Çoğu şirketteki code review süreci kıl kırk yarma ve önemsiz yorumlarla dolu
  Eskiden bu tür yorumları azaltmak ve geri bildirimi hızlandırmak için bunların statik analiz araçlarıyla değiştirilmesini önermiştim, ama bana böyle code review’ların herkes için gerekli olduğu söylendi. Çünkü insanların terfi almasına yardımcı oluyor, kod sorunlarını engelledikleri hissini veriyor ve üst düzey yöneticiler yorumcu yorumlarının sayısına bakınca code review metrikleri iyi görünmüş oluyor

  • Bu tür araçların aşırı kullanımından hoşlanmıyorum. Aptal araçları memnun etmek uğruna kodu daha kötü hale getirmek az görülen bir şey değil
    Gerçek çözüm, her kodun sanki benim elimden çıkmış gibi görünmesi gerekmediğini kabul etmek ve kendine “Bu yorum koddaki nesnel bir hatayı mı ele alıyor?” diye sormak. Çoğu zaman cevap “hayır” oluyor
  • Burada bazen gerçek bir mahkum ikilemi var. Bir kıdemli, bir junior’ın PR’ını incelerken daha iyi olabilecek yerler görebilir ama bunlar çoğu zaman önemli değildir
    Değişken adının biraz fazla uzun olması ya da metodlar arasındaki boşlukların eşit olmaması gibi şeyler idealde “bu bir örüntü haline gelirse bir dahaki sefere dikkate alınacak geri bildirim” olmalı. Ama yorumcu açısından, PR başına yorum sayısı ne kadar koçluk yaptığının metriği olarak görülebiliyor ya da “bunun merge edilmesine kim izin verdi?” tepkisinden çekiniliyor; bu yüzden sonunda yorum bırakılıyor
    İnceleme alan kişi de yorumu ele almazsa geri bildirime kapalı görünmekten ya da itiraz ederse yorumcunun kötü değerlendirme vermesinden çekinip değişiklik yapıyor. Sonra güncellenmiş sürümün yeniden onay alması gerekiyor ve gecikme döngüsü yeniden başlıyor
  • Bazı ortamlarda doğru. Ama inceleme süreci, değişiklikler ve kod tabanı hakkında paylaşılan bilgi ve anlayış oluşturmaya da yardımcı olur
  • Kıl kırk yarma kesinlikle gerçek bir şey. Muhtemelen kodda mutlaka yanlış bir şey bulmak gerektiği hissinden kaynaklanıyor olabilir
    Ama birinin önemsiz bir takıntı gibi gördüğü şey, aslında hiç de önemsiz olmayan bir sorun olabilir. Kişi sorunu kendi gözüyle göremediği, anlamadığı ya da duygularını geri çekip yazdığı kodu yeniden değerlendiremediği için böyle olabilir
    Hepimiz yazdığımız koda bağlandık ve onun dünyadaki en zarif kod olduğunu düşündük. Ama bazen yanıldığımı, kodun okunmasının zor olduğunu, kusurlu olduğunu ve kod tabanına zarar verdiğini kabul etmek gerekir
    Benden daha kıdemli birinin kodunda gerçekten sorun yaratabilecek bir race condition’ı işaret ettiğimde bana kıl kırk yaran dendiği oldu. Benim için race condition, yazılmış kodun düzeltilmesi gereken temel bir sorunu; onun içinse henüz doğal biçimde bozulduğunu görmediği için kabul edilebilir bir durumdu
  • Statik analiz araçlarıyla akran incelemesi farklı türden sorunları yakalayabilir. Bu, statik derlemeli bir dilin dinamik bir dilin yakalayamadığı bazı hataları yakalamasına ama hepsini yakalayamamasına benzer
    Akran incelemesini çok seviyorum ve genelde şunlara odaklanıyorum: “Bu kod beklendiği gibi çalışmayacak”, “Bunu böyle yapmak uygulamayı kilitleyecek ya da çok daha pahalı hale getirecek”, “Çalışıyor ama anlaması zor; bakımını olumsuz etkileyecek. Farklı bir yaklaşım ya da ek açıklama düşün”, “Kod fena değil ama daha iyi okunabilir ya da çalışabilir. İncelemeyi başarısız kılacak bir şey değil ama sonraki kod için akılda tutulabilir”

• “Julie: BT güvenlik ekibindeki Joe ile iletişime geçin. Size yetki verecek. 2 saat sonra.” tamamen gerçek dışı. Güvenlik ekibi o kadar hızlı yanıt vermez

  • İstisna, npm install çalıştırıp P1 güvenlik alarmı tetiklediysenizdir
  • Bizim güvenlik ekibi aslında daha hızlı yanıt veriyor. Tüm talepleri otomatik olarak reddediyorlar ama anında reddediyorlar
  • Benim çalıştığım yerde deneyim oldukça farklı. Birine belirli bir sisteme erişim yetkisi istemek için ticket açarsanız, hangi önceliği verirseniz verin genelde birkaç dakika içinde işleniyor
    Bazen helpdesk çalışanları kişisel metriklerini yükseltmek için hızlıca kapatabilecekleri ticket’ları gelir gelmez kapıyorlar mı diye düşündüğüm bile oluyor
  • Birini wiki düzenleme yetkisi için gereken AD grubuna eklemek haftalar sürüyor

• Başlıktaki gibi tek satır kodu değiştirmek 6 gün sürüyor derseniz korkunç görünüyor
  Ama sistem birkaç yönden iyileşti. Ayar, hardcode yerine parametre tablosundan yapılandırılabilir hale geldi ve o ayar değişikliğini izleyen bir denetim özelliği de eklendi
  Bürokrasi savunusu yapmak istemiyorum. Büyük organizasyonların o yönünden içtenlikle nefret ediyorum. Sadece, ilk hedeflenen şeyin dışında da 6 gün boyunca ek değer üretildiğini belirtmek istiyorum
  Bu yüzden tahminlere belli miktarda ek maliyet koymak gerekir ve story point veriliyorsa bu tür prosedür maliyetleri de hesaba katılmalıdır

  • Parametre tablosunun yararlı olmasının tek nedeni, kod değişikliğini engelleyen fazla şey olmasıydı. Aynı şekilde bu ayara yönelik denetim de gereksiz görünüyor. Eskiden kodun içindeydi, yani kaynak yönetimi zaten denetim iziydi
    Sonuçta iki “başarı” vardı: kod değişikliği etrafındaki ek ritüellerden kaçınmış olmak ve bu değişiklik artık koda girmeyeceği için ilk “başarı”yla kaybedilen işlevi geri kazanmış olmak
  • Doğru, ama başlangıçtaki talepten çok daha riskli bir iş de yapıldı. Anlık kesinti ya da gerçek bir prodüksiyon sorunu varken hardcode değeri parametreye taşımak bana göre aptallık. Potansiyel tuzak çok daha fazla
    Burada şöyle denmeliydi: “Acil olduğu için tek karakterlik PR’ı kabul edin. İstediğiniz iyileştirmeleri takip ticket’ına dönüştürdük. Önce prodüksiyon sorununu çözelim, geri kalanını sonra ele alırız.”
    Reviewer’ın yapması gereken tek şey “LGTM!” demekti. Mühendislerin çoğu kurallar ile yönergeler arasında yol bulamıyorsa o organizasyon delirmiş demektir ve kıdem tam da burada değer üretir
  • 1. adım gerçek önceliği belirlemektir. Bu işin ne kadar gecikmesinin insanların işini etkileyeceğini herkes biliyor olmalı
       Bir hafta sürse bile kimsenin işi etkilenmiyorsa süreç izlenebilir ya da minimum değişiklik yapılabilir. BT yüzünden insanlar ücretsiz izindeyse, sorun çözülene kadar gereken herkes aynı odada, fiziksel ya da sanal, olmalıdır
       Burada o bağlam yok. Ama Ed ve tüm onay zinciri bu bağlamı bilmiyorsa bu bir sistem arızasıdır. Birinin kirasının tehlikede olduğunu bilselerdi, kıdemli biri muhtemelen hemen arkasından düzeltilecek ikinci bir ticket açılmasını önerirdi. Bilmiyorlarsa bu da yönetimin çözmesi gereken bir sorundur
  • “Tek satır kodu değiştirmek 6 gün sürdü” sadece bir olguyu ifade ediyor. Bu arada sistemin iyileştirilmiş olması gibi kısımlar zorunlu gereksinim değildi
  • Denetim gereksinimi, o hardcode değerin bulunduğu dosyanın sürüm geçmişi ile karşılanabilirdi gibi görünüyor. Sürüm kontrolü yoksa zaten daha büyük bir sorun var demektir

• Bu hikâye, hardcode bir değerde tek satırlık değişikliğin aslında iyi sonuçlandığı bir örnek
  Birinin akıllı ve kurnaz görünmek için backlog ayı sayısını 2 bitlik bir değer olarak sakladığı bir senaryo hayal edebilirsiniz. Yani yalnızca 0, 1, 2, 3 mümkün. Test sırasında bu, birkaç katman aşağıda, test edilmeyen alt bir servis ya da low-code otomasyon servisinde saklı olduğu için ortaya çıkmayabilir
  O değeri 4 yaparsanız backlog 0 olabilir. Sonucun ne olacağını bilemezsiniz. O servis prodüksiyon kuyruğundaki tüm işleri iptal edebilir ya da müşterilere işlerinin iptal edildiğine dair e-posta gönderebilir
  Görünüşte kolay bir değişiklik gibi dursa da, politika değişikliği acil bir sorun olarak yazılım ekibine iletildiyse yönetim daha iyi plan yapmalı, issue önceliğini keyfi biçimde sarsmamalıdır

  • İstenen değişiklikte ek test ya da risk azaltmayla ilgili hiçbir şey yoktu
    Tam tersine, değişikliğin “maliyeti” olarak çevresindeki çeşitli parçaların refactor edilmesi istenerek risk artırıldı
  • İşlerin ters gitmesinin sayısız yolu var. Asıl soru, ters gittiğinde sorumluluğun nereye gideceği olabilir
    Keşke büyük patron “Riski üstlenip bunu ilerletmeye ben karar verdim ve sonucunu da kabul ediyorum” diyebilse. Programcıların suçlanması iyi değil
  • Doğru kişiler ve süreç izlendi diye düşünüyorum. Yine de lead’ler bir araya getirilip işin önemi ve önceliği konusunda hizalanacak bir toplantı yapılsaydı çok zaman kazanılabilirdi
    Temel işleve dair zamana duyarlı ve önemli bir güncellemeyse, operasyonlardan sorumlu kişi yazılımın ortalama dağıtım süresini biliyor olmalı ve bunu normal geliştirme pipeline’ına yüksek öncelikle sokmak yerine hızlı işleme için özel bir ekip kurmalıydı
  • Knight Capital aklıma geliyor

• Kod incelemesi iyi niyetle başlar. Ama sonunda bir kapı bekçisi ortaya çıkar ve önemsiz sebeplerle her şeyi reddetmeye başlar
  Kendisinin “kod kalitesi”ni korumaya önem verdiğini söyler. Ama düzeltilmeye hazır hatalı kodu uzun süre ortada bırakmaktan ya da kimsenin kullanamayacağı şekilde özellikleri geciktirmekten daha kötü çok az şey vardır
  Yorumlara izin veren ama reviewer’ın commit’i engelleyemediği bir süreç öneririm. Her geliştiricinin dikkatli davranacağına ve işe uygun değişiklik yapacağına güvenmek gerekir. CI da kullanılabilir ve takıma bağlı olarak bunların hepsi gayet iyi çalışabilir

  • O zaman mühendislik lideri o kişiyi durdurmalı. İşlev bozukluğu birçok şekilde ortaya çıkar ve aşırı hevesli inceleme de bunlardan biridir
    Süreci, patolojik reviewer’ı görmezden gelmeye izin verecek şekilde değiştirmek olsa olsa yarım bir önlemdir
    Engelleme konusunda kararsızım. Kocaman kırmızı bir engel işaretinin can sıkıcı olduğunu anlıyorum; bu yüzden çoğu durumda engellemek yerine değişiklik isteyen “soft block” yapıyorum. Ama PR tamamen raydan çıktıysa, özellikle de junior geliştiricilerde, net bir mesaj vermek uygun olabilir
  • Bu yaklaşım, test kapsamı ve test kalitesi yüksek olduğunda iyi çalışır. Bu da geliştiricilerin yöneticinin o anda istediğini düşündüğü hızda hareket etmesine izin verince sihirli biçimde ortaya çıkmaz
  • “Her kod değişikliğinde reviewer gerekir” kuralından nefret ediyorum. Muazzam bir engel ve mutlaka daha iyi koda da yol açmıyor

• Bu, fabrika işçileri ve yazılım geliştiriciler hakkında meta bir hikâye.
  Bu şirketin lideri, %10 düşük kullanım yüzünden fabrika işçilerini işten çıkarmaya istekli. Birkaç değişken ayarlanarak verimlilik artırılabilir, ama nihayetinde seçenek tam kullanım ya da işsizlik. Muhtemelen bu, bu işçilerin ikame edilebilir olması, yoğun sezonda yeniden işe alınabilmesi ve çalışan başına yaratılan kârın verimsizliğe izin vermemesi nedeniyle mümkün.
  Ben yazılım geliştiricisi olarak çalışıyorum. Bizim tarafta birini göndermeyi düşünmek için düşük kullanımın %90'ın çok üstüne çıkması gerekir. Birçok kişi haftada yalnızca 4 saat çalışıyor. Kimse bizim dakikalık zamanımızı ya da tuvalet molalarımızı takip etmiyor.
  Şu an yazılım için büyük ölçekli sermayeleşme dönemindeyiz. Bu sonsuza kadar sürmeyecek. Bir gün BT dünyasının ana altyapısı kurulmuş olacak ve sektör bakım moduna geçecek. Çoğumuza ihtiyaç kalmayacak, ikame edilebilir hale geleceğiz ve bakım modunda yarattığımız kâr bugün gördüğümüze kıyasla çok küçük olacak.
  Fabrika işçileri, bireysel üretkenliklerinin düşük olduğu algılandığında genellikle dakikalar ya da saatler içinde işten çıkarılıyor. Yazılım geliştiricileri için de bunun bizim ömrümüz içinde başlayacağını düşünüyorum.

  • “Bu işçiler ikame edilebilir ve yoğun sezonda yeniden işe alınabilir” kısmı tam da farkın kendisi. Fabrika, her bir kişiden karar almayı ve değişkenliği çıkarmak için tasarlanmış bir süreçler sistemi.
    Kendi beceri setin için de bunun ne ölçüde mümkün olduğunu değerlendirmelisin.
    Yazılımın büyük ölçekli sermayeleşmesinin sonsuza kadar sürmeyeceği şeklindeki temel teze katılıyorum. Her şirketin her zaman yeni yazılım geliştirecek mühendislere ihtiyacı olmaz. Bu, IT'den çok, film yapımı gibi iniş çıkışları olan yaratıcı bir işe daha yakın. Geliştirmeyi IT yerine seçiyorsan bu riski kabul etmen gerekir. Ama neden zirvenin tam da şimdi olması gerektiğini bilmiyorum.

• Kişisel deneyim olarak, birkaç yıl resmi kod incelemesi olan bir ekipte çalıştıktan sonra kod incelemesi olmayan bir ekip/şirkete geçtim. Herkes istediği branch'e serbestçe commit atıp merge edebiliyordu.
  İşe girerken biraz karmaşık duygularım vardı, ama pratikte bu çok ferahlatıcı ve yetki verilmiş hissettirdi; birkaç gün içinde üretken şekilde çalışmaya başladım.

  • Eskiden “Katolik kod incelemesi”, yani push and pray yapan bir ekipte çalışmıştım.
    Ekip hedefleri düşünüldüğünde, kod incelemesi olmayan yaklaşım çok iyi uyuyordu. Çünkü ana hedef, yöneticilere “havalı yeni özellikler” göstermek olan bir Ar-Ge grubuydu. Kısa bildirimle gelen çok sayıda istek vardı ama çöpe giden kod da çoktu.
    Demo yapardık, yönetici de “Güzel görünüyor ama ticari açıdan uygulanabilir değil” derdi ve depoya bir daha dokunulmazdı. Tabii bazen yaptığımız şeyler gerçekten ürüne dönüşürdü; o zaman da alt ekipler karalama gibi kodu production kalitesine dönüştürmekten sorumlu olurdu. O insanlar bizden alevli bir nefretle nefret ederdi.
  • Yüksek güvenin ve yaklaşık %80 test kapsamının olduğu küçük bir ekipte bunun çok iyi çalıştığını gördüm. PR olmayan bir süreçti; testler geçiyorsa, uygunsa paydaşlara UX demosu başarılı olmuşsa ve kişi kendisi memnunsa master'a merge ediyordu.
    Yeni ekip üyelerine ilk 2-3 ay boyunca yanlarında oturan, sık sık pair yapan ve koda bakan bir mentor atanıyordu.
    Bu 2,5 yıllık bir projeydi; 20. ayda canlıya alındı, takvim ve bütçeye uyuldu, ayrıca başlangıç kapsamından daha fazla özellik teslim edildi. Birçok gün whiteboard önünde 2-3 saat tartışırdık. Süreç gayriresmiydi ve her zaman herkes katılmazdı.
    Tuhaf şekilde bu proje boyunca üç PM değişti. Stand-up dışında e-posta ya da iletişim kurmamak gibi katı bir kural vardı ve üç kişiden ikisi bu düzende “çalışabildi”. Havalimanının BT sorumlusu, iki yıl sonra bizim aslında PM'e ihtiyaç duymadığımızı fark etti.
    Kod tabanında yeni bir iş yapıyorsan en az bir başka geliştiriciyle konuşman gerektiğine dair bir kural vardı. Büyük bir whiteboard bulunan geniş özel ofislerde, birbirimize birkaç adım mesafede oturuyorduk. Story'leri özel bir whiteboard'a asılan indeks kartlarıyla yönetiyorduk; özü orada anlatamıyorsan daha küçük parçalara bölmen gerekiyordu.
    Herkes kendi makinesini kendisi topluyor ve istediği kadar monitör kullanabiliyordu. Bu, büyük bir uluslararası havalimanının faturalama ve ücretlendirme sistemiydi; muhasebe müdürü, direktör ve diğer kullanıcılar birkaç ofis kapısı ötedeydi. Stand-up'ları neredeyse hiç kaçırmazlardı ve gerçek zamanlı sorulara her an açık olma politikaları vardı.
    Stand-up'lar genellikle durum raporu değil, gayriresmî tartışma, demo ve soru-cevap olurdu. Durum güncellemeleri için whiteboard'daki kartlara bakmak yeterliydi.
    Nihai sistem, ilk aydan başlayarak sonraki her ay geliri %8 artırdı. Muhasebe direktörü bunu havalimanı otoritesinin yönetim kuruluna açıklamak zorundaydı. Havayollarıyla faturalama anlaşmazlıkları ve mutabakatlar ayda 9 günden 1 güne düştü, aylık faturalama iş yükü ise 18 günden 5 güne indi. Ana kullanıcı rolü, kıdemli muhasebeciden 3 yıllık deneyimi olan tek bir junior muhasebeciye devredilebildi.
    Production bug sayısı ilk yıl 6'ydı, yanlış fatura sayısı ise 0'dı. Sonrası için veri yok. Önceki yeniden yazma girişimi 3 yılın sonunda başarısız olmuştu.
  • Açıkçası güvenlik ve denetim açısından kulağa kâbus gibi geliyor. Yine de küçük projeler yapan bir ajans ya da benzeri bir yerde olabilir.

• Kod inceleme sürecini, yüksek değişim içeren ve sürekli evrilen ekiplerin uymasına kadar değişiklikleri rehin almak için kullanmak işlev bozukluğudur.
  “Giderken yükselt” politikası, yarım kalmış geçişin uzun kuyruğunu bırakır ve yeni geliştiricilerin kod tabanına alışmasını daha zor hale getirir. Ürün odağı, kod tabanının her bölümünden düzenli olarak geçileceğini garanti etmez; bu yüzden geçiş de asla tamamlanmaz. Bazı ürün alanları yıllarca ihmal edilir.
  Yeni politikaya geçmek önemliyse bunu tek bir odaklı proje olarak ayırıp yapmak gerekir; değilse zaten önemli değildir.

  • Evet. Yönetimin planı fiilen terk etmesi yüzünden bu korkunç.
    Kod tabanının her yanındaki plansız iş zaman bombalarının, rastgele alakasız işler üzerinden patlamasını umuyorlar.
    Yeni standart önemliyse kodu güncellemelisin; değilse hiç yapmamalısın. Rastgeleliğe güvenip acil işi geciktirmek plan değildir.

• Bunu bir kod inceleme sorunu olarak okumak yanlış. Sorun, şirketin ilkelerin önüne iç engellerden oluşan bir süreci koymuş olması.
  Her sürecin bir kaçış kapısı olmalı. Eğer değişiklik işten çıkarmayı önlüyorsa, bütün kaçış kapıları devreye girmeli.