- 2007, 2000 satır kod

The Original Macintosh: 36 of 123 - 2000 Lines Of Code

• 1982'nin başlarında Lisa yazılım ekibi, yazılımı önümüzdeki 6 ay içinde yayımlayabilmek için son aşama çalışmalara yoğunlaşmıştı.

• Yöneticilerden bazıları, her mühendisin her hafta yazdığı kod miktarını takip etmenin iyi bir fikir olduğunu düşündü ve her cuma teslim edilmesi gereken bir form hazırladı; bu formda o hafta yazılan kod satırı sayısının girileceği bir alan da vardı.

• Quickdraw'un yazarı ve ana kullanıcı arayüzü tasarımcısı olan Bill Atkinson, kod satırı sayısının yazılım üretkenliğini ölçmek için saçma bir yöntem olduğunu düşünüyordu; bunun yalnızca dağınık, şişirilmiş ve hatalı kod yazmayı teşvik ettiğine inanıyordu.

• Atkinson kısa süre önce Quickdraw'un bölge hesaplama mekanizmasını optimize etmek üzerinde çalışıyordu ve daha basit, daha genel bir algoritma kullanarak bölge motorunu baştan sona yeniden yazdı; birkaç ince ayardan sonra bu değişiklik bölge işlemlerini neredeyse 6 kat hızlandırdı.

• Bu yeniden yazım çalışması aynı zamanda yaklaşık 2000 satır kod tasarrufu sağlamış oldu.

• Optimizasyon çalışmasının son aşamasında yönetim formunu ilk kez doldurma zamanı geldiğinde, kod satırı sayısı bölümüne geldi, kısa bir süre düşündü ve oraya -2000 sayısını yazdı.

• Yöneticilerin buna tam olarak nasıl tepki verdiği bilinmiyor, ancak birkaç hafta daha geçtikten sonra Atkinson'dan form doldurmasını istemeyi bıraktılar ve o da buna memnuniyetle uydu.

GN⁺ görüşü

• Bu yazı, yazılım geliştirmede kod miktarının gerçek üretkenliği göstermediğine dair önemli bir ders veriyor. Performansı kod satırı sayısına göre ölçmenin yalnızca verimsiz değil, bazen ters etki yaratabileceğini de gösteriyor.
• Bill Atkinson örneği, yazılım optimizasyonunun önemini vurguluyor. Daha az kodla daha hızlı performans elde etmek, yazılım mühendisliğinin temel ilkelerinden biridir.
• Bu hikâye, modern geliştirme pratiklerinin, özellikle çevik metodolojiler ile sürekli entegrasyon/dağıtım (CI/CD) gibi yaklaşımların neden önemli olduğunu anlamaya yardımcı oluyor. Bu metodolojiler, kod miktarından çok kaliteye, bakım yapılabilirliğine ve kullanıcı deneyimine değer verir.
• Sektörde kod kalitesini ölçmek ve iyileştirmek için çeşitli araçlar ve metrikler kullanılır. Örneğin statik kod analizi araçları, kod inceleme süreçleri ve test kapsamı takibi buna dahildir.
• Bu yazı, geliştiricilere kod miktarından çok kaliteye odaklanmanın, gereksiz karmaşıklıktan kaçınmanın ve performansı optimize etmenin ne kadar önemli olduğunu hatırlatıyor.

[GN⁺]

Hacker News görüşleri

• Microsoft ve IBM'in kod satırı sayısı çatışması

  • PBS TV dizisi "Accidental Empires"ta Steve Ballmer'ın OS/2'nin ortak geliştirilmesi sırasındaki deneyimini anlattığı bir sahne var. Microsoft işlerini küçük bir şirket zihniyetiyle yürütürken, IBM'in içeride kod satırı sayısına (bin satır birimiyle, KLoC) programcı üretkenliğinin ölçüsü olarak odaklandığı söyleniyor. Ballmer, IBM'i kodun niteliğinden çok niceliğiyle ilgilenmekle eleştiriyor.

• Önceki tartışma bağlantıları

  • Kod satırı sayısının üretkenlik metriği olarak kullanılmasına dair tartışmalar sık sık ortaya çıkıyor. 2010'dan 2022'ye kadar çeşitli tartışmaların yapıldığını gösteren bağlantılar veriliyor.

• Kod satırı sayısını üretim metriği yapmak son derece saçma

  • Tek satırlık bir kodla 20 yıllık bir hatayı çözmekten ya da order by ile 3 yıllık bir hatayı gidermekten söz edilerek, tek bir satırın etkisinin nasıl ölçülebileceği sorgulanıyor. Kötü programcıların daha fazla kod yazdığına dair deneyimler paylaşılıyor ve bir Microsoft geliştiricisinin IBM'in 33.000 karakterlik kodunu 220 karaktere yeniden yazdığı bir örnek anlatılıyor. Bunun sonucunda Microsoft'un yaptığı işin "negatif" değerlendirildiği bir durum ortaya çıktığı söyleniyor.

• Basit bir soru bazen en büyük etkiyi yaratır

  • Hangi özelliğin uygulanacağına dair basit bir soru ("X nasıl ele alınacak?") o özelliği hiç yapmama kararına yol açabilir ve bu da denemenin tüm maliyetini ortadan kaldırır. Bu tür katkılar sayısal olarak ölçülemez, hatta bazen düşman da kazandırabilir; buna rağmen bunu göze alanlara saygı duyulduğu ifade ediliyor.

• Kariyerin başlarında yaşanan kod optimizasyonu deneyimi

  • 10.000 satırdan uzun bir C programını 500 satırın altına indirme deneyimi paylaşılıyor. Önceki geliştiricinin fonksiyon kullanmayı ya da SQL sorgularına değişken veriyi nasıl vereceğini bilmiyor olabileceği varsayımıyla, aynı SQL ifadesinin tekrar tekrar inline yazıldığı fark ediliyor. SQL çağrıları fonksiyon çağrılarına dönüştürülüyor ve değişen bind değerleri bir diziden alınıp döngü içinde fonksiyon çağrılarak yinelenen kodun yerini alıyor.

• Proje başlangıcında net yön eksikliği

  • Bir projeye başlarken tam olarak hangi yöne gidileceği bilinmeyebilir; projeye daldıkça problem ve istenen yanıt daha iyi anlaşılır, bunun sonucunda büyük parçalar çıkarılıp yerlerine daha küçük ve daha iyi çözümler konabilir. Böyle durumlarda her şeyi 64KB ROM'a sığdırmak zorunda olan geliştiriciler, kodu küçültmek için güçlü bir baskı hissediyordu.

• Kodu silmeyi metrik yapmak üzerine düşünce deneyi

  • Bir yöneticinin bu yazıyı okuyup basitçe silinen kod satırı sayısını ölçü olarak kullanmaya karar vermesi halinde durumun iyileşip iyileşmeyeceği ya da daha kötüye gidip gitmeyeceği üzerine bir düşünce deneyi öneriliyor.

• Bill Atkinson'ın Atkinson Dither'ı

  • Bill Atkinson ve onun Atkinson Dither tekniğine ilişkin bir bağlantı veriliyor.

• Kod satırı sayısına bakış

  • Kod yazarken "eklenen satır sayısı - silinen satır sayısı" yaklaşımını kullanmaya dair kuşku dile getiriliyor. Aynı yerde başlayıp aynı yerde biten 10 km'lik bir koşuya 0 km koşu denmediği gibi, kod satırı sayısında da durumun benzer olduğu görüşü ifade ediliyor.

• Çalışan olarak rol

  • Einstein kadar zeki olsanız bile hâlâ bir çalışansınızdır ve çalışan olarak yapmanız gereken işler vardır şeklinde bir ders paylaşılıyor.