Yazılımı Biz Bozuyoruz

• Özellik eklerken veya belirli bölümleri optimize ederken karmaşıklığı artık hesaba katmayarak yazılımı bozuyoruz
• Karmaşık build sistemleriyle yazılımı bozuyoruz
• Saçma bağımlılık zincirleriyle her şeyi şişirip kırılgan hale getirerek yazılımı bozuyoruz
• Yeni programcılara "Don’t reinvent the wheel!" diyerek yazılımı bozuyoruz. Oysa tekerleği yeniden icat etmek, şeylerin nasıl çalıştığını öğrenmenin bir yolu ve yeni, farklı tekerlekler üretmenin ilk adımıdır
• API'lerde geriye dönük uyumluluğu artık dikkate almayarak yazılımı bozuyoruz
• Zaten çalışan şeylerin yeniden yazılmasını teşvik ederek yazılımı bozuyoruz
• Ortaya çıkan her yeni dil, paradigma ve framework'e atlayarak yazılımı bozuyoruz
• Mevcut karmaşık kütüphanelerle uğraşmanın zorluğunu, bunu doğrudan kendimiz uygulamakla kıyasladığımızda sürekli küçümseyerek yazılımı bozuyoruz
• XYZ'nin fiili standardının, bizim özel kullanım alanımız için doğrudan uygulayabileceğimiz bir şeyden her zaman daha iyi olduğunu varsayarak yazılımı bozuyoruz
• Kod yorumlarının işe yaramaz olduğunu iddia ederek yazılımı bozuyoruz
• Yazılımı yalnızca saf bir mühendislik disiplini sanarak yazılımı bozuyoruz
• Artık küçültülemeyen sistemler inşa ederek yazılımı bozuyoruz: herhangi bir sistemde basit olan şeyler basitçe gerçekleştirilebilmelidir
• Mümkün olduğunca hızlı kod üretmeye çalışırken, mümkün olduğunca iyi tasarlanmış kod yazmak için çaba göstermeyerek yazılımı bozuyoruz
• Yazılımı bozuyoruz ve geriye kalacak olan şey artık hackleme keyfi vermeyecek

[dohyun682]

Tekerleği yeniden icat etmek <-> zaten yazılmakta olan şeyi yeniden icat etmek

Bu ikisi birbirine tamamen zıt kavramlar değil mi?

[roxie]

Yorum patlaması geliyor

[tujuc]

Gerçekten çarpıcı haha Kıdemsizler her geldiğinde... nasıl anlatmalıyım diye düşünüyorum. İyi bir yöntem olabilir..

[ilikeall]

Lütfen artık vurmayın ağlama

[bus710]

....Sadece sessiz kalacağım...

[laeyoung]

Han Feizi'nin sözünü ettiği "bir ülkenin çöküşünün 10 işareti" ile örtüşen çok şey var gibi görünüyor.

[GN⁺]

Hacker News görüşü

• Jonathan Blow’un konuşmasını hatırlatıyor. Yazılım, bakımı yapılmazsa diğer her şey gibi zamanla bozulur

  • Yazılım teknolojisi dışarıdan ilerliyormuş gibi görünse de gerçekte geriliyor
  • Donanımdaki iyileşmeler ve makine öğrenmesi ilerleme yanılsaması yaratıyor, ancak yazılımın temel sağlamlığı ve güvenilirliği kötüleşiyor
  • Modern yazılım geliştirme gereksiz yere karmaşıklaştı ve basit işleri bile zorlaştırıyor
  • Bu karmaşıklık programcıların üretkenliğini azaltıyor ve kuşaklar arasında bilgi aktarımını engelliyor
  • Toplum, bol hatalı ve güvenilmez yazılımları normal kabul etmeye başladı
  • İşletim sistemlerinden geliştirme araçlarına kadar her seviyede yazılım sistemlerini sadeleştirmezsek, uygarlık tarihsel çöküşlere benzer bir teknolojik gerileme riskiyle karşı karşıya kalır

• Dieter Rams’ın "İyi tasarımın 10 ilkesi"ni hatırlatıyor

  • İyi tasarım yenilikçidir
  • İyi tasarım ürünü kullanışlı hale getirir
  • İyi tasarım estetiktir
  • İyi tasarım ürünü anlaşılır kılar
  • İyi tasarım göze batmaz
  • İyi tasarım dürüsttür
  • İyi tasarım uzun ömürlüdür
  • İyi tasarım son ayrıntısına kadar titizdir
  • İyi tasarım çevre dostudur
  • İyi tasarım mümkün olduğunca az tasarımdır

• 2000’lerde bir şirkette çalıştığı deneyimi paylaşıyor

  • Onlarca bilgisayarla işler yürütüyor, bir sunucu odası kuruyor ve 3 TB veri saklayacak bir SAN inşa ediyorlardı
  • Kendi geliştirdikleri bir VB6 iş zamanlayıcısıyla, bilgisayarlar arası işleri koordine etmek için Object Rexx script’leri çalıştırıyorlardı
  • Dahili load balancer, web sunucusu, mail sunucusu ve FTP sunucusuyla dosya alıp gönderiyor, kendi yazılımlarını kullanıyorlardı
  • Artık tüm bu kurulumu yaml dosyaları ve bulut servisleriyle bir hafta içinde yeniden oluşturmak mümkün
  • Sunucu mimarisi "soyutlandı"
  • Geriye dönük uyumluluk eleştiriliyor; bunun Windows’un sorunlarından biri olduğu söyleniyor
  • Apple, geriye dönük uyumluluğu bozdu, beş işlemci geçişi yaptı ve ARM çiplerde 32 bit kod uyumluluğunu kaldırdı

• Birçok karşıt görüş var

  • Geriye dönük uyumluluğu korurken karmaşıklıktan kaçınmak gerekiyor
  • Devasa bağımlılık ağaçlarından kaçınıp tekerleği kendin yeniden icat etmek gerekiyor
  • Tüm gereksinimleri karşılamanın tek yolu, herkesin kod yazmaması olabilir
  • Günde bir kez bunun gerçekleşmesini dilediğim oluyor ama bununla gurur duymuyorum

• İlk işindeki deneyimini paylaşıyor

  • Yazılımı C ile yazıyordu ve o dönemde ticari yazılımı gerçekçi biçimde yazmaya uygun tek dil buydu
  • Build alabilen yalnızca bir kişi vardı; ticari bir build aracı kullanılıyordu ve o aracı kullanabilen de sadece oydu
  • Build saatler sürüyordu
  • Bunu iyi yaptıklarını düşünüyorlardı

• Yazılımı neden bozduğumuza dair bir görüş

  • XYZ’nin fiili standardının, bize özel çözümlerden her zaman daha iyi olduğunu varsayarak yazılımı bozuyoruz
  • Genel yaklaşım, birçok probleme yönelik yüzeysel çözümler arasında kolayca geçiş yapılmasına yol açıyor
  • Mühendisler bu yaklaşımı seviyor; özellikle de sık iş değiştirdikleri için ellerinde birkaç tane oluyor
  • Oysa özel çözümler çoğu zaman genel çözümlerden çok daha iyi performans veriyor

• Her ifade bir takastır

  • Her durumda bir şeyi feda edip başka bir şey kazanırsın
  • Bazen tekerleği yeniden icat etmemek mantıklıdır
  • Bazen öğrenmek için tekerleği yeniden icat etmek gerekir
  • Genel olarak, yıktığımızdan daha fazlasını inşa ediyoruz
  • Bu kadar olumsuz bir tutum alma gereği hissetmiyorum

• antirez’e saygı duyuyorum ama bu gönderinin, tartışmada ayakta kalmayacak kulağa hoş gelen kısa cümlelerle dolu olduğunu düşünüyorum

  • Örneğin: yeni başlayanlar tekerleği yeniden icat etmemeli
  • Ellerindeki bağlamda mevcut araçları kullanmalılar
  • Deney yapmak istiyorlarsa kendi derleyicilerini yazmalılar
  • Ama bunu üretimde kullanmamalılar
  • Geriye dönük API uyumluluğu çoğu durumda bir iş kararıdır
  • Her cümleye "Yazılımı bozuyoruz" diye başlamak yardımcı olmuyor
  • Bu, gerçekte olduğundan çok daha karanlık bir tablo çiziyor

• Karmaşıklık/bağımlılık grafiği üzerine bir görüş

  • Rastgele bir uygulamanın karmaşıklık/bağımlılık grafiği tamamen çılgınca
  • Firmware ve OS dahil değil ama yine de yeterince yakın
  • Geçişli bağımlılık sorununu çözmemiz gerekiyor
  • OS’yi (Win32 API, Linux syscalls), C ile yazılan her şeyin tek gerçek hard dependency’si olarak görüyorum
  • Java/Python’a geçtiğinizde bu katmanı kontrol edemezsiniz
  • Her kütüphaneye bağımlı olmak yerine, belirli durumlara uygun birkaç yüz satırlık kod yazmak gerekli
  • Bu bakım yükünü artırır ama bağımlılıkların da bakıma ihtiyacı vardır
  • Yanlış API’ye sahip olabilirler, uyumluluğu rastgele bozabilirler, terk edilebilirler ya da kötü amaçlı yazılıma dönüşebilirler
  • Kullanışlı projeler için kişisel üst sınırım 5-10KLOC Java/JS/Python
  • Bunlar birkaç saat içinde gözden geçirilebilir ve yıllar sonra bile kolayca değiştirilebilir

• Yazılımı bozan unsurlar

  • Leetcode mülakatları, özgeçmiş odaklı geliştirme, sık iş değiştirme, büyüme yatırımı dolandırıcılığı, metrik oyunları, terfi kovalamacası, sprint tiyatrosu, organizasyon şemasının her seviyesindeki blöfler, sektörün umursamazlığı