Yanlışlıkla Yük Taşıyan Hale Gelen Şey

• Başta önemsiz ya da geçici görünen yapıların veya kodların bile zamanla sistemi ayakta tutan bir rol üstlenebileceği için, değişiklikten önce mevcut bağımlılık ilişkileri de kontrol edilmeli
• Chesterton's Fence, kaldırmadan önce neden konduğunu anlamayı söyleyen faydalı bir ilke; ancak yalnızca ilk niyete bakmak, sonradan oluşan rolleri gözden kaçırmaya yol açabilir
• Evde banyo tadilatı sırasında engel gibi görünen dikey stud, dolap bölmesi olma amacı ortadan kalktıktan sonra bile hatalı bir yapısal değişiklik yüzünden ikinci kat yükünün bir kısmını taşıyordu
• Karmaşık bilgisayar sistemlerinde de değişiklik geçmişi ve tasarım belgeleri yalnızca bir başlangıç noktasıdır; bileşenin şu anda sisteme nasıl entegre olduğuna da bakmak gerekir
• Eski bileşenleri kaldırırken veya değiştirirken geçmişteki tasarım gerekçesiyle bugünkü gizli rol birlikte doğrulanmazsa beklenmedik arızalar ortaya çıkabilir

---

Chesterton's Fence'in Gözden Kaçırabilecekleri

• Chesterton's Fence, bir şeyi değiştirmeden veya kaldırmadan önce onun neden yapıldığını önce anlamak gerektiği fikridir
• Çit ya da kapı gibi insan yapımı şeylerin, büyük olasılıkla biri için yararlı olduğuna karar verilmiş bir nedeni vardır
• Tamamen anlamsız görünen bir tasarımda bile, onu değiştirmek isteyen kişi sorunun bir yönünü gözden kaçırmış olabilir
• Ancak bu bakış açısı, ilk yapan kişinin amaçladığı role odaklanmaya neden olarak sonradan oluşan yeni bağımlılıkları gözden kaçırabilir

Ev Onarımında Keşfedilen Tesadüfi Yük Taşıma

• Birkaç yıl önce evde banyoyu yeniden yaparken çalışmayı engelleyen bir dikey stud vardı
• Bu stud aslında bir dolap bölmesinin parçasıydı ve dolap bölmesi işlevi artık gerekli görünmüyordu
• Yalnızca Chesterton's Fence açısından bakıldığında kaldırılması güvenli görünebilirdi, ama gerçekte zamanla yük taşıyan bir yapı elemanı haline gelmişti
  • Geçirdiği başka hatalı yapısal değişiklikler sonucunda bu stud, evin ikinci katını taşımaya katkı sağlıyordu
• Bir şeyin yalnızca başlangıçta neden yapıldığını değil, sonrasında hangi ek rolleri üstlendiğini de doğrulamak gerekir

Karmaşık Bilgisayar Sistemlerine Uygulanan Ders

• Karmaşık bilgisayar sistemlerini değiştirirken de aynı sorun tekrar eder
• Değişiklik geçmişini incelemek, ilk tasarım belgelerini okumak ve belirli bir bileşenin neden o şekilde yapıldığını anlamak hâlâ faydalıdır
• Ancak güvenli olmak için, o bileşenin şu anda sistem içinde nasıl bağlandığını ve kullanıldığını da incelemek gerekir
• Bileşenler zamanla, ilk amaçlarından farklı ek roller üstlenmeye yatkındır
• Güvenli değişiklik, geçmiş tasarım niyetiyle bugünkü gerçek rolün birlikte doğrulanmasıyla başlar

[GN⁺]

Hacker News yorumları

• Nihayet buna verecek bir adın ortaya çıktığını hissettiriyor
  Kontrol sistemleri destek işlerinde çok çalışıyorum; bazı fiziksel ekipmanları alışılmadık şekilde ele alan PLC kodlarının istemeden sorun çıkarması pek de nadir değil
  Sık sık “Yazılımla elektrik/mekanik sorunlarını her düzelttiğinde bir gremlin doğar” sözünü tekrar ederken buluyorum kendimi
  Bir bug’ın kök nedenini ya da kaldırmak istediğim programlanmış bir kısıtı bulsam bile, o kodun neden orada olduğunu öğrenene kadar bunu hep reddederim. Sebepsiz yere eklenmiş kod yoktur; bu yüzden önce o zamanlayıcının ya da override’ın neden gerekli olduğunu anlamak gerekir
  Bazen bu, artık ortadan kalkmış bir sorunu çözmek için yazılmış koddur ve bu iyi bir şeydir; ama çoğu zaman da belli bir kazayı önlemek için eklenmiş bir koddur ve personel değiştikçe asıl amacı kaybolur. Dokümantasyon yoksa başkasının yaptığı işi hemen geri almaya karşı çok temkinli oluyorsunuz
  Bir de iş arkadaşlarına güvenme meselesi var. Genelde insanlar sebepsiz yere bir şey yapmaz; dolayısıyla kod varsa bir amacı olduğunu ve başta yeterince incelendiğini varsayıp buna güvenmek gerekir. O güven yıkıldığında tüm karar alma süreçleri zorlaşır

  • Bu yüzden hiç de apaçık olmayan kod satırlarına her zaman nedenini açıklayan yorum bırakırım
    İşletim sistemi, dosya sistemi, veritabanı, HTTP endpoint’i, donanım gibi kod tabanının dışındaki şeylerle etkileşimin nedeniyse, basit bir API ya da kütüphane çağrısı değilse %100 yorum eklerim
    Başka bir servisin rate limit’i yüzünden sleep koyduysam, bunu kimin talep ettiğini, o sırada bildiğim kadarıyla limit değerini, tam emin değilsem “tahmin ama çalışıyor gibi görünüyor” olduğunu ve aşılırsa sistemin nasıl görünebileceğini yazarım
    Dosya sistemiyle de yapılabilecek önemsiz bir iş için veritabanı kullanıyorsam ama gerçekte o ortamda dosya sistemine gereken şekilde erişince yük altında kontrolden çıkan sistem çağrıları yüzünden kaynaklar tükeniyorsa, buna da yorum bırakırım
    Ubuntu’nun LTS sürümünde düzeltmediği, yaygın kullanılan bir kütüphane bug’ı için workaround da yorumluk bir konudur. “Bunun kötü olduğunun farkındayım ama sebebi şu” tarzında gerçekten çok fazla yorum yazdım
    Şu an ölçeklenebilir yapmakla uğraşmak istemediğim ve mevcut beklentiye göre buna gerek de olmadığı halde, büyük ölçekte iyi çalışmayacak kod yazdığımda da yorum bırakırım. Belki biraz egoyu koruma gibi ama, “Tüm dosyayı belleğe aldığımı biliyorum ama bu seyrek ve öngörülebilir bir batch işi, ayrıca dosya da küçük olacak, o yüzden sorun değil. Bellek yetersiz kalırsa önce buraya bakın. Bunu on-demand çağrıya çevirecekseniz baştan yazın” gibi şeyler
  • Bu aslında genel Chesterton’ın çiti mantığı değil mi?
    Yazının işaret etmeye çalıştığı şey, bunun tek başına yeterli olmadığı. Çünkü o kodun var olduğu varsayımı üzerine başka nelerin inşa edildiğini de bilmek gerekiyor
  • Allen Bradley PLC’nin derinliklerinde gördüğüm en ürkütücü yorum şuydu
    “Bu rung’ın neden gerekli olduğunu bilmiyorum ama silip kendiniz deneyin”
    Boşuna kurcalamadım, deneyip de bakmadım
  • Bunun bir kısmı kültürel de
    Elektrik mühendisleri ve makine mühendisleri tarihsel olarak yazılımı elektrik/mekanik sistemlerden daha az ciddiye aldı; bunun sonucu olarak da EE/ME’nin baskın olduğu mühendislik kültürlerinde berbat kod ortaya çıkması daha olası
    Dışarıdan bakınca Professional Engineer olan insanlar arasında bile kabul etmesi zor derecede olgunlaşmamış yazılım mühendisliği hâlâ yaygın
  • Bir daha asla PLC işi yapacağımı sanmıyorum
    Dokümantasyonsuz kod bir yana, çoğu zaman üzerinde çalıştığınız ekipman 30 yıl önce özel üretilmiş donanım oluyor ve elinizde o ekipmanın devre şeması bile bulunmuyor

• Benzer bir şey yaşamıştım
  Birkaç yıl önce eski bir ev satın aldım; önceki ev sahipleri 1960’lardan beri işlerin çoğunu kendileri yapmış
  Çinko yağmur oluğu muhtemelen onlarca yıl sızdırmış ve çatı iskeletinin bir kısmını bozmuştu; çatı da 70’lerde iç tarafı kapatmak için eklenen ahşap panel tarafından taşınıyordu. Yani o ahşap panel gerçekten yük taşıyormuş
  Bu evde bundan çok daha fazlasını da buldum. Mesela çatının kenarında kiremit genişliği yetmeyince, ek kiremit almak yerine arayı çimento ve kırılmış seramik saksı parçalarıyla doldurmuşlar

  • 1900’lerin başlarına giderseniz, dış kaplama diyagonal yerleştirildiği için yapının burulmasını ciddi ölçüde engelliyordu
    Şimdi o işi deprem ve fırtınalarda alçıpan ve kontrplağa bırakıyoruz
    Bir evi iskelete kadar soyup yeniden yaptığınızda birkaç ek destek parçası görürsünüz. Amaç duvarların yıkılmasını önlemek değil, duvarlar yeniden yükselene kadar dik açılarını ve düzlemini korumaktır
  • Benim garajım da tam öyle hissettiriyor
    İlk bakışta biri garaj kapısına çarpmış ve onu fena halde ezmiş gibi görünüyor ama dikkatli bakınca çatının, kapının bağlı olduğu rayların üzerinde zar zor durduğu ve neredeyse göçmek üzere olduğu anlaşılıyor
    Başta sadece mertek uçlarını ekleyip, daha önce birilerinin öbür tarafta da aynısını yaptığına göre işe yarar diyerek garaj kapısını değiştirmeyi düşünmüştüm ama şimdi tüm çatıyı yenilemem gerekecek gibi görünüyor
    Asıl endişe verici olan, bodrumun tamamına yayılmış şüpheli kablolama. Nispeten yeni kablolar, eski bez yalıtımlı kablolar ve bunları birleştiren elektrik bandı birbirine karışmış durumda. Neyse ki kablolardan yük taşıyan görünmüyor
  • Yük taşıyan boyaya da sadece birkaç adım kaldı
  • Termit hasarı çok ağır olan bir ev görmüştüm; müteahhit buna taşıyıcı stucco diyordu

• Bu yazı ve neredeyse tüm yorumlar asıl meseleyi kaçırıyor gibi görünüyor. Kilit nokta test eksikliği
  Yazılım, diğer tüm üretim araçlarının aksine, değişiklikler gerçek dünyaya yansımadan önce gerçekten test edilebilir
  İyi testler varsa niyetin ne olduğu, o özelliğe yeni bir kullanım alanı ya da yeni kullanıcıların eklenip eklenmediği önemli değildir. Düzeltir ve testleri çalıştırırsınız; size o düzeltmenin iyi olup olmadığını söyler
  İyi testler varsa yazılım arkeolojisine, her çatlağı bilen deneyimli veteranlara, karmaşık sistemi kafasında modelleyen dâhilere, kapsamlı gereksinim belgelerine ya da bazı kullanıcı gruplarını deney faresi yapan temkinli dağıtım sistemlerine ihtiyaç yoktur
  İyi testler varsa sistemi rastgele değiştirip bir iyileşme gördüğünüzde durmanız bile mümkündür. Google'ın yapay zekanın sıralama iyileştirmesini “geliştirdiğini” bildirdiği yöntemle tam olarak aynıdır
  Buna rağmen test geliştiricileri yarıdan az ücret alıyor, test departmanları görece küçük kalıyor, QA sabit ve kısıtlı takvimlerin baskısı altında çalışıyor ve QA kökenli teknik kahramanlar neredeyse hiç yok. Muhtemelen türev ve tepkisel bir iş olarak görüldüğü için

  • Testler kodun tasarlanan davranışını doğrulasa bile, başka sistemlerin kodun gerçekte yaptığı davranışa bağımlı hâle geldiği durumlar olabilir
    Kullanılmayan kodu ve testlerini kaldırırsınız ama aslında hâlâ kullanılıyor olabilir
    Bir değişiklikten sonra test başarısız olur, ama test kırılgandır diye yeni duruma göre testi düzeltirsiniz; sonra da bir şeyin eski davranışa bağımlı olduğunu fark edebilirsiniz
    Testler harikadır ve yeterince kendi içinde kapalı sistemlerde tek başına yeterli olabilir. Ama daha büyük sistemlerde bazen telemetri ya da kademeli dağıtım da gerekir
  • Testlerin belirli bir kapsamı vardır. Kodun sorumlu olması gereken kapsam; ama aylar ya da yıllar boyunca kullanılırken artık beklenir hâle gelen her şeyi kapsamayabilir
    Başlangıçta kod, alışveriş listesindeki KDV'yi hesaplamak içindi; ama zamanla ürün kategorisine göre KDV önbelleğini zorla yenilemenin bir yolu hâline gelmiş ve ilk başta öngörülmeyen bağlamlarda çağrılıyor olabilir
    Yorumlar da aynıdır. İlk niyeti ve yan etkileri ele alırlar, ama çok daha sonra o metodun ya da sınıfın nerede kullanıldığını, fiilen ne yapar hâle geldiğini ele alamazlar
    İdeal bir dünyada çevredeki dünya değiştiğinde yorumlar da güncellenir, ama pratikte iç kod da birlikte değişmedikçe bu neredeyse hiç olmaz
  • Çok uzun ömürlü projelerde çalıştıysanız, testlerin ya da yeterli bütçeye sahip QA'nın örgütsel sorunları engelleyemediğini görürsünüz
    Genelde testler çürür. Sanki testlerin de bir raf ömrü varmış gibi görünür ve sonunda bazı testler ölmeye başlar
    Bağımlılık sorunları, API beklentilerindeki değişiklikler, güvenlik güncellemeleri, hesap ve kimlik bilgilerinin süresinin dolması, makine uç noktaları ve durum değişiklikleri birbirine karışır; test sonuçları artık programın doğruluğunu göstermemeye başlar
    Tek tek bozuk testleri düzeltmenin doğrudan iş değeri çoğu zaman çok düşüktür; bu yüzden testler tamamen kapatılır ya da hata vermesi gerekirken zorla “geçti” durumuna getirilir
    Bu 10, 20 yıl tekrarlandığında çok geçmeden “gerçekten güvendiğimiz testler” ile “düzeltmeye ya da temizlemeye çok meşgul olduğumuz testler” diye bir ayrım oluşur
    Hangi testin iyi, hangisinin kötü olduğuna dair bilgi; görev ve rol değişimleriyle kaybolan bir kabile bilgisine dönüşür ve bir noktada “çalıştığını söyleyerek yalan söyleyen testler” ile “başarısızlığın gerçek olup olmadığını artık sorgulamadığımız testler” yığını da kazara yük taşımaya başlar
  • İlk kısım test güdümlü geliştirme tarzı bir iyimserliği tekrar ediyor gibiydi, sonra birden test departmanlarından söz etmeye başladı; bu yüzden tutarsız duruyor
    Onun yerine programcıların test yazması, onları kodla birlikte saklaması ve derleme sürecinde otomatik çalıştırması gerektiğini söylemek daha iyi olur
    Ama düzgün bir test güdümlü geliştirme bile iyi tasarımın ve iyi pratiklerin yerini alamaz diye düşünüyorum. En basit bir spesifikasyon bile testlerle ikame edilemez
    Eğer f(S) yalnızca bir string'i kendisiyle birleştirip döndürüyor diye belirtilmişse, f'yi bir kara kutu olarak ele alan bariz testlerle f'nin doğru olduğunu doğrulamak zordur. Biçimsel spesifikasyon da önemlidir
    Birkaç noktayı deneyebilirsiniz, ama sihirli şekilde tek bir yanlış değer bile ölümcülse testler bunu gösteremez
    Yazılım arkeolojisi, deneyimli veteranlar, sistemi kafasında modelleyen dâhiler, kapsamlı gereksinim belgeleri ve bazı kullanıcıları kobay yapan dağıtım sistemleriyle alay edebilirsiniz; ama bunların hepsi yazılım zor olduğu için ortaya çıkmış karşılıklardır. Ve yazılım gerçekten zordur
  • Test geliştiricileri, test departmanları ve QA ekipleri gibi ayrımların kendisi, çoğu yazılım organizasyonu için neredeyse lükstür
    Genelde yazılım ekipleri kendi işlerinin kalitesinden doğrudan sorumlu olmak zorundadır ve sorunları organizasyon şemasında aşağıya ya da yana devredemez

• Sonradan önemsiz görünen bir studun yük taşımaya başlamasını anlıyorum ama deneyimime göre bu, tembel tasarımın işareti gibi görünüyor
  En azından yazılım yaparken, evin bir kısmını dekoratif bir studa taşıtmaya çalıştığını fark edebilirsin; daha iyi yeni bir yapı kurmak yerine buna razı olursan geliştirme ekibi sonra epey moral bozukluğu yaşar
  Yazıya katılıyorum ama bu tür keşifleri sık yapmayacağını umabileceğin bir yerde çalışmak çok daha iyi

  • “Senin” yaptığında “sen” bunu biliyor olabilirsin ama benim kariyerimde çok daha sık başkalarının yaptığını ele alıp yeniden yapmak zorunda kaldım
    Bu yazının özü, dekoratif studları yük taşıyan eleman olarak kullanma demekten çok, senden önce birinin bunu yapmış olabileceğini fark et demeye daha yakın
    Bu, Chesterton'ın Çiti ilkesinin temel yorumundan bile daha muhafazakâr bir yaklaşım; o temel yorumu bile birçok kişi aşırı kısıtlayıcı diye kenara itiyor
    Bana bu yazı çok tanıdık geliyor. Yazılım açısından söylemek gerekirse, “dekoratif” bir kaplamayı kaldırınca tavanın başıma çöktüğü bir durumu gerçekten yaşadım
  • Bu her zaman kötü anlamda tembellik mi? Yazılımda “yük taşısın diye yapılmış şey” ile “alçıpan tutturmak için yapılmış şey” arasında keskin bir ayrım yok
    Bir sistemin sağlam mı yoksa tehlikeli biçimde ölçeklenemez mi olduğu bağlama bağlı
    “Satış ekibi iki katına çıkıp pazarın %100'ünü ele geçirene kadar müşterileri olabildiğince hızlı satıp sisteme alırsak ne olur?” gibi düşünce deneyleri her zaman yapılabilir ve böyle koşullarda veritabanını mesaj kuyruğu gibi kullanmak bile makul olabilir
    Sonuçta geliştirme ekibi zorlandıysa bu bir hatadır. Bakımı zorlaşmış ya da operasyonel cehenneme dönüşmüştür
    Ama yazılımdaki dekoratif studları yük taşıyan unsur olarak kullanmak her zaman buna yol açmaz. Doğru çözümü üretmek için gereken birkaç ayı kurtarırken görünmeden mutlu mutlu işini yapan çok sistem vardır
  • Diyelim ki kodu savunmacı yazıyorsun. Bir fonksiyona hatalı girdi işleme ekliyorsun
    Kod tabanının geri kalanı asla hatalı girdi göndermediği için o dal ölü koddur ve yük taşımaz
    Sonra bir noktada bir bug girer ve hatalı girdi gönderir; o dal da görevini yapıp toparlar. O anda o dal yük taşıyan dal olur
  • Önemsiz bir servisi gayet iyi çalıştırdığımı sanıyordum ama bir kesinti olduğunda, aslında önemsiz olması gereken bir şeye başka bir ekibin iş açısından kritik bir özellik olarak bağımlı hale geldiğini fark ettiğim oldu
  • Daha sık gördüğüm şey, bunun aslında kimse bilmediği için olduğudur

• Gördüğüm “kazara yük taşıyan” eserler arasında favorim yanlış yapılandırılmış sudo idi
  find komutuna parolasız sudo izni verilmişti; bu da -exec ile root yetkisiyle keyfi kod çalıştırmayı kolaylaştırıyordu ve ürünün önemli birkaç destek betiği bunun üzerine yazılmıştı
  Adeta yük taşıyan yetki yükseltmeydi

• Birkaç yıl önce mutfağı yeniledim
  Eski mutfağın bir ucundan büyük bir kiriş geçiyordu; evi almamızdan önce yapılan bir tadilatta ikinci katı eklemek için konmuştu. Mutfağı büyütmek için bunun kaldırılması gerekiyordu
  Tavanı açınca, o kirişin üst kattaki duvarı taşıması gereken yerin yaklaşık 2 fit sağına yerleştirildiğini gördük
  Sonunda düzelttik, kirişi üst kattaki duvarın içine aldık ve sorun çözüldü; ama ilk konumu sorulduğunda müteahhit kabaca şöyle dedi
  “Biri işi doğru yapmak istiyordu, biri umursamıyordu. Kalite sonunda en düşük ayara gelir”

• Yazılımın fiziksel sistemlere göre iyi yanlarından biri, niyeti daha açık kılmak için bunu kod içinde yorumlar ve tiplerle kolayca belgeleyebilmesidir
  Özellikle Python gibi dinamik dillerde kusursuz değil ama çok yardımcı oluyor
  Yük taşıyan studa karşılık gelen benzetme, aslında prod'a çıkması beklenmeyen bir hackathon projesi olabilir
  Gerçekte yaptığımız işlerin çoğu, bir şeyi zar zor çalışana kadar hack'lemek ve sonra sıradaki işe geçmektir

  • Evet. Havacılık ve savunmada sistem mühendisliğinin ortaya çıkmasının nedeni tam olarak bu tür sorunlardı
    Çünkü bakım planı, her değiştirilebilir parçanın veya montajın ne tür “yük”ler taşıdığını bilmek zorundadır
    Ne yazık ki bugünün sistem mühendisliği ilk hedefinden çok uzaklaştı ama başlangıçtaki fikir buydu
    Günümüzde sistem mühendisliği bölümlerinin görece güç kaybetmesinin nedenlerinden biri, bakım planlamasına finansın girmiş olmasıdır. Stok amortismanı acımasızdır ve “hangi parçalar yedekte tutulmalı” sorusu, en azından benim deneyimimde, artık nadiren sistem mühendisliğinin kararı oluyor
    Sonuç tahmin edilebilir ama havacılık bakım personelinin çıtası çok yüksektir; örneğin çamaşır makinesi tamircileriyle karşılaştırıldığında oldukça üst düzeydedirler
    Tabii finans o çıtayı da birkaç kademe aşağı çekmek ister
  • Kasıtlı olduğunda bunu yapmak kolaydır
    Ama görünüşte “dekoratif” olan üst akış bileşeninin aslında hız sınırlaması koyduğunu ve onu kaldırınca geri kalan her şeyin kontrolden çıktığı sistemleri ne kadar sık gördüğüme hep şaşarım

• Kullanıcıların, yazılımdaki bir bug'ı farkında olmadan kullanıp bunu normal iş akışlarının parçası haline getirmesi aklıma geliyor
  Sonra bug düzeltilince iş akışı bozuluyor ve şikayetler geliyor

  • https://xkcd.com/1172/

• “Neden orada olduğunu anlamak kolaydı. Dolap bölmesinin bir parçasıydı” denmiş ama zamanla kazara yük taşımaya başlamış ve başka bir hatalı yapısal değişiklik sonucunda o stud artık evin ikinci katını taşımaya yardım eder hale gelmiş
  Ama neden orada olduğunun açıkça kolay anlaşılır olduğu söylenemez. Üstelik kazara yük taşımaya başladığına da pek ikna olmadım
  Sana yanlış bir gerekçe gibi görünse de, o dönemdeki insanlar için geçerli olan nedenlerle kasten yük taşıyacak şekilde yapılmış olması gayet mümkün görünüyor

  • Neden orada olduğunu biliyorduk
    Sadece başta neden orada olduğunu bilmek, şimdi ne yaptığını söylemiyor

• Eskiden birlikte çalıştığım bir fizik doktora sonrası araştırmacısı bazen ekipman düzeneklerinin üstüne şu tür işaretler yapıştırırdı
  “Dokunmayın. Gizli tehlike var”
  Laboratuvar akıllı insanlarla doluydu ve onlar bir şeye bakıp bunu değiştirmenin güvenli olup olmadığına kendi başlarına makul bir şekilde karar vermeye alışkındı
  Bu işaret, böyle bir yargıya fazla hızlı varmaman için bir uyarıydı