-2000 satır kod

 (folklore.org)
14 puan yazan GN⁺ 2025-06-26 | 1 yorum | WhatsApp'ta paylaş
  • 1982'de Apple'ın Lisa yazılım ekibi, yazılımı yayımlamak için her geliştiricinin haftalık kod satırı sayısını takip eden bir politika uygulamaya koydu.
  • Bill Atkinson, kod satırı sayısının yazılım üretkenliği için yanlış bir ölçüt olduğunu savundu.
  • Quickdraw'ın bölge hesaplama motorunu tamamen yeniden yazarak yaklaşık 2.000 satır kodu azalttı ve performansı 6 kat artırdı.
  • Atkinson, kod sayısını raporladığı yönetim formuna -2000 yazdı.
  • Sonunda yöneticiler Bill'den artık form göndermesini istemedi.

1982'de Lisa yazılım ekibi ve kod satırı takibi politikası

  • 1982'nin başlarında Lisa yazılım ekibi, yazılımı önümüzdeki 6 ay içinde yayımlama hedefiyle yoğun çalışmaya başladı.
  • Bazı yöneticiler, her mühendisin her hafta yazdığı kod satırı sayısını izlemenin ilerlemeye yardımcı olacağını düşündü.
  • Bunun için her cuma, mühendislerin yazdığı kod satırı sayısını kaydedip teslim ettiği bir form uygulamaya alındı.

Bill Atkinson'ın üretkenlik ölçütüne bakışı

  • Quickdraw ve kullanıcı arayüzünü tasarlayan Bill Atkinson, kod satırı sayısının yazılım üretkenliğinin ölçütü olamayacağını düşünüyordu.
  • Programları olabildiğince küçük ve hızlı yapmanın asıl hedef olduğunu vurguluyordu.
  • Kod satırı sayısını ölçmenin, tersine, dağınık ve verimsiz kodu teşvik edebileceği sorununu görüyordu.

Quickdraw bölge motorunun yeniden düzenlenmesi ve optimizasyonu

  • Atkinson, kısa süre önce Quickdraw'ın bölge hesaplama motorunu daha basit ve daha genel amaçlı bir algoritmayla tamamen yeniden yazdı.
  • Optimizasyon sonucunda bölge işlemlerinin hızını 6 kata kadar artırdı.
  • Bu süreçte 2.000 satıra denk gelen kod da doğal olarak ortadan kalktı.

-2000 satır kod raporu ve yöneticilerin tepkisi

  • İlk hafta yönetim formunu doldururken Atkinson, kod satırı sayısı hanesine -2000 yazdı.
  • Yöneticilerin bu sayıya tam olarak nasıl tepki verdiği net değil.
  • Birkaç hafta sonra Bill'e artık form göndermemesi söylendi; o da bunu memnuniyetle karşıladı.

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-26
Hacker News görüşü

  • En iyi commit’im olarak hatırladığım şey, yaklaşık 60 bin satır kodu silip tüm durumu bellekte tutan "sunucu"nun tamamını yaklaşık 5 bin satırlık hafif bir mantıkla değiştirdiğim deneyimdi

    • Bu kodun, diğer servislere doğal biçimde entegre edilebilecek kadar hafif olması ve bellek durumu gerektirmemesi, bana bunun algoritmik bir başarı olduğunu düşündürüyor
    • Belirli bir ağaç için yönlendirilmiş altgraf izomorfizmi problemini çözebileceğimizi fark ettik; bu sayede genel bir yönlü çiftli grafı tek geçişte dolaşıp başlangıç kökünden itibaren yalnızca yolu küçük bir yığınla izleyerek çıktı grafını (ağaç) oluşturabildik
    • "-60.000 satırlık commit" gerçekten unutulmaz bir andı ve o günden beri algoritmik olarak bu kadar etkileyici bir iş yapamamış olmaktan biraz hüzün duyuyorum
      • İş ortamında bolca script yazan ve programlamanın bazı kısımlarında kendini yetkin hisseden bir hobi programcısıyım; böyle hikâyeler duydukça bilmediğim dünyanın ne kadar büyük olduğunu ve ömür boyu öğrensem de yetmeyeceğini yeniden fark edip tevazu hissediyorum
      • Daha fazla bağlam duymak isterim. Durum tutan bir programı durumsuz hale getirme tekniği bana sihir gibi geliyor; gerçekten öğrenmek isterim
      • Grafik teorisi ve algoritmalar geçmişi olan bir matematikçiyim; bu tür gerçek işlerde becerilerimin uygulanıp uygulanamayacağını merak ediyorum. Biraz daha ayrıntı paylaşabilir misiniz?
      • Hedef grafın ağaç olması çok da önemli değil gibi geliyor. Asıl nokta, "guided" kısmının tek geçişi mümkün kılması bence
        • Özgün grafta belirli bir düğümden başlıyorsunuz ve eğer izomorfizm varsa hedef ağacın kökünün de mutlaka o düğüme karşılık geldiğini varsayıyorsunuz
        • Özgün grafı hedef ağaç desenine göre dolaşıp uyuşmazlıkta false, her şey uyuşursa true dönen bir problem olarak yorumlayabilirsiniz. Ağaç olmasa bile başlangıç noktası açıkça belirtilirse bu yaklaşımın herhangi bir altgrafa uygulanabileceği sonucu çıkıyor
      • Bugünlerdeki "ikili ağacı ters çevir" tarzı kodlama mülakatı sorularının atalarının herhalde tam da bu tür programcılardan çıktığına dair bir şaka
        • Grafik teorisini merak eden ama terimleri zor bulan sıradan geliştiriciler için daha kolay bir açıklama rica ediliyor

  • Üniversite yıllarında, birinci sınıf öğrencilerinin iyi kod yazabileceğine dair yönetim politikasına sahip bir şirkette çalışmıştım; sonunda bunun kanıtlanmamış bir başarısızlık örneği olduğunu gördüler

    • Koddaki bir hatayı düzelttiğimiz halde aynı hata tekrar çıkıyordu; inceleyince mevcut fonksiyona parametre eklemek yerine onun kopyasını oluşturup çok az değiştirerek tekrar tekrar kullandıklarını gördüm. Sonuç olarak kod tabanının dörtte üçünden fazlasını, yani binlerce satır Turbo Pascal kodunu sildim
    • Projenin müşterisi Energy departmanıydı ve nükleer madde envanterini yöneten bir program olduğu için uykusuz geceler yaşadığımı hatırlıyorum
      • Mevcut kodu kopyalamanın avantajı olarak, eski kodun kararlılığını bozmadan yöneticinin "katkı" metriğini de koruyabilmek gibi alaycı bir nokta yapılıyor. Geri alma gerektiğinde de sadece kopyayı silersiniz, diye şaka yapılıyor
      • Bizim ekipte de kod tekrarını sık yapan bir ekip arkadaşım var; bence bu, acil talepler ya da sesi çok çıkan kişiler için hızlı sonuç üretme alışkanlığı. Oysa asıl ihtiyaç, ortak fonksiyonları refactor etmek ve yeterli test yazmak ama insanlar buna zaman ayırmak istemiyor
      • Geçmişte birlikte çalıştığım dış kaynak geliştiricilerde de aynı alışkanlığı gördüm; bunun kafa karıştırabileceğini söylediğimde "O zaman Ctrl+F kullanırsınız" diye cevap vermişlerdi
      • Acaba yukarıdaki olay Blacksburg bölgesinde mi yaşandı diye soruluyor
      • Benim deneyimim de benzerdi; Güneydoğu Asya’daki birkaç ülkede neredeyse aynı portalı işleten bir şirkette çalıştım. Her portalın kaynak kodu ayrı bir Git deposundaydı ve tüm portallara ortak uygulanması gereken özellik ya da hata düzeltmelerini kaynak kodunun pek çok kopyasına tek tek elle backport etmek zorundaydık
        • "Hepsini tek depoya alıp portal bazlı özelleştirmeyi feature flag ile yapamaz mıyız?" diye sordum ama bunun imkânsız olduğu söylendi
        • Sonunda iki üç ay içinde 4-5 portalın kodunu tek depoda birleştirip feature flag’ler ve framework yükseltmeleriyle birlikte dağıtımı da sorunsuz tamamladım. Artık tüm portallarda aynı anda hata düzeltebildiğimiz için, tekrar eden manuel işkenceden kurtulmanın büyük rahatlığını yaşadım

  • İlgili bir konu olarak, "-2000 satır kod" hakkındaki popüler Hacker News başlıklarını bağlantıda derlemişler

    • Geçmişteki klasikleri düzenli aralıklarla yeniden paylaşmanın hem yeni hem de eski kullanıcılar için faydalı bir gelenek olduğu belirtiliyor
      • "-2k lines of code" görünce otomatik olarak oy veren basit bir insanım, diyor biri
        • Verimliliği tek eksenli bir metrikle ölçmek isteyen müşterilere sık sık Atkinson örneğini anlatıyorum. Gerçek verimlilik ölçütünün fayda olması gerekir; bunu gerçekten nicelleştirebilen biri bence Nobel Ekonomi Ödülü’ne aday olur

  • Üzerinde çalıştığım web UI projesi, backend hariç 250 bin satır koddandı

    • Önceki geliştirici zekiydi ama JS’ye yeniydi; tüm durumu DOM’un custom attribute’larında saklıyor, yapıyı da addEventListener ile baştan sona dolduruyordu. Hatta bunun için "Bir keşişe bir JavaScript kitabı ve 10 yıllık hücre cezası verin, ortaya böyle kod çıkar" diye şaka yapıyordum
    • Birkaç ay boyunca yapıyı web component’lere dönüştürürken 50 bin satır sildim; sonra tam yeniden yazıma başladım ve şu anda işlevin yaklaşık %80’ine ulaşmış durumdayım ama toplam kod yalnızca 17 bin satır kadar hafif (Vue/pinia gibi kütüphaneler hariç)
    • Yakında 200 binden fazla satırı silmiş olacağım; muhtemelen hayatım boyunca bundan daha büyüğünü yaşamam, emekli olma isteği bile uyandırıyor
      • Benim de benzer bir deneyimim oldu; ilk yazan kişi neredeyse junior seviyesindeydi ama şirketin kurucusuydu ve üretkenlik konusunda olağanüstüydü. Ekip çalışması ya da başkasının koduyla birlikte geliştirme deneyimi olmadan ilerlediği için akla gelebilecek her kod kokusu yapıya girmişti
        • Binlerce satırlık tek fonksiyonlar, 10 seviye iç içe switch/case/if/else/ternary operator, SQL ile JS/HTML/JS gömülü HTML’in birbirine karıştığı ve hiç otomatik testin olmadığı bir PHP/Dojo dönemi frontend yapısı diye açıklıyor
      • "İşlevin %80’ini karşılayan hafif kod" ifadesinin kendisi bile bu tür karşılaştırmaların zaafını gösteriyor. Sonuçta tüm işlevsellik henüz yoksa, orijinal kod kadar satıra ihtiyaç duyulmaması normal

  • Dilbert çizgi romanında sonsuz ödül yapısını anlatan bir kare var; Dilbert’in patronu düzeltilen her bug için para ödülü vaat edince Wally "Bugün ben de bir minivan’lık kod yazayım bari!" diyor

    • Bu duruma "Perverse incentive" deniyor; referans bağlantısı ile açıklanmış
    • Benim yöneticim de bu çizgi romanı ( görsel ) dinlenme odasının duvarına asmıştı
    • "Minivan"ın burada tam olarak ne anlama geldiğine dair gayet gerçekçi bir merak da var

  • dotnet/runtime deposunda 64 bin satırın silindiği gerçek bir örnek paylaşılıyor

    • Yerleşik C# + WinRT interop desteği, kaynak üretim aracıyla değiştirilmiş; tek seferde kararlı biçimde yapılması gereken bir mimari değişimdi. PR bağlantısı

  • LLM’lerin geliştirici verimliliğini ne kadar artırdığına dair istatistikleri her gördüğümde bu klasik hikâye aklıma geliyor

    • AI’ın kod silme konusunda da epey iyi olduğuna dair karşı çıkışla birlikte, Cursor topluluğundan "AI bilgisayarımdaki her şeyi sildi" diye komik bir örnek paylaşılıyor: topluluk
    • Bugünlerde "Yeni kodumuzun X%’ini AI yazıyor!" ifadesi sektörün sevdiği sloganlardan biri oldu
    • Yeni nükleer santral inşası ve bakım maliyetlerini de hesaba katsaydık, geliştirici verimliliği rakamlarının ne kadar gerçek dışı şişirildiği daha iyi görünürdü diye taşlama yapılıyor

  • Ben CS mezunu değilim; işi çalışarak ve sahada öğrenerek yapan biriyim

    • Üzerinde çalıştığımız projelerin amacı, canlı nesneleri insanların okuyabileceği şekilde yeniden yapılandırmak
      • Nihai gösterim çok karmaşık ve birçok tür gerektiriyor, başlangıç gösterimi ise görece basit
      • Benzer veri düğümleri olduğunda, onları karşılaştırıp birleştirerek, yani metotlara çıkartıp parametreleri bularak okunabilirliği artırmamız gerekiyordu
        • İlk zamanlarda önce nihai tiplere dönüştürüp sonra karşılaştırma yapıyorduk; bu yüzden tip kombinasyonları patladı, yönetmek neredeyse imkânsız hale geldi ve yıllar boyunca mühendislerin yapıyı anlayamadığı bir karmaşıklık seviyesine ulaşıldı
      • Daha sonra hashmap tabanlı bir yaklaşım öğrendim; aynı iskelete sahip düğümleri hash değerleriyle ayırıp karşılaştırıp birleştirdikten sonra nihai tiplere dönüştüren iki aşamalı yapıyı uyguladık
      • Tip durumuna değil veri merkezli soyutlamaya geçtiğimiz için, tuhaf sınıf hiyerarşileri bile basit özellikler olarak kolayca yönetilebilir oldu
      • Kısacası aptalca çok aşamalı bir decompiler yapısıydı ama işleme hızı ve okunabilirlik ciddi biçimde iyileşti. Her duruma uyan sihirli çözüm yok ama bizim için asıl sorun "tip"ti ve bu yaklaşım projede çok işe yaradı

  • Yıl sonu performans değerlendirmesi öncesi şirket içi monorepo’daki istatistiklerime baktığımda net kod değişimi açısından eksiye düşmüş biri olduğumu fark ettim

    • Bunun sebebi API kodu ve tipler için otomatik üretilmiş kodu kaldırmak, eski API sürümlerini emekliye ayırmak gibi işlerdi; ama her gün işe gelip sadece kod siliyormuşum gibi hissetmek tuhaf biçimde keyifliydi

  • Uzun zaman önce büyük bir projede ekip liderlerinin geliştirici başına bug sayılarını, yani düzelttiği ve sebep olduğu bug’ları elle yazıp duvara astığı berbat bir KPI örneğiyle karşılaşmıştım

    • Ben ilişkili projede olduğum için kurtuldum ama bir ekip arkadaşım, Lars von Trier’in Danimarka bayrağının haç kısmını kesip kırmızı komünist bayrak gibi yeniden dikerek bürokratların "yazarlar listesi"nden çıkarılmasından esinlenip kendi bug sayısı satırını kesip tekrar yapıştırarak açıktan protesto etmişti. Ertesi gün bu liste sonsuza dek kayboldu; benim için kıymetli bir anı olarak kaldı
      • "Çünkü ben bu listede olmak istemiyorum!" şeklindeki basit ve doğrudan cevabı, tüm durumu mükemmel özetliyordu
      • Bayrağın ve listenin nasıl görselleştirildiğini zihinde canlandırmanın zor olduğu da ayrıca paylaşılıyor