Hiçbir Şey Yapmayacaksanız, En Azından Doğru Şekilde Hiçbir Şey Yapmanın Yolu

API hiçbir şey yapmayacaksa, doğru şekilde hiçbir şey yapmamak

• Bir API’nin hiçbir şey yapmaması gerektiğinde, bunu doğru şekilde hiçbir şey yapmayacak biçimde sağlamak önemlidir.
• Örneğin Windows’ta kapsamlı bir yazdırma altyapısı vardır, ancak Xbox’ta böyle bir altyapı yoktur.
• Xbox’ta bir uygulama yazdırmayı denediğinde NotSupportedException fırlatmak yanlış bir yöntemdir.
• Uygulama ağırlıklı olarak PC’de test edilmiş olabileceği için, Xbox’ta çalıştığında bu özel durum ele alınmayabilir ve uygulama çökebilir.
• Xbox’ta yazdırma özelliğini “desteklemenin” daha iyi bir tasarımı, yazdırma işlevinin başarılı olması ama yüklü yazıcı olmadığını bildirmesidir.
• Kullanıcı yazdırmayı denerse yazıcı seçmesi istenir, ancak liste boş olduğu için kullanıcı “Demek ki yazıcı yokmuş” diye fark eder ve yazdırma isteğini iptal eder.
• Yazıcı yüklemeye çalışan uygulamalar için, yazıcı yükleme işlevi “kullanıcı işlemi iptal etti” sonuç koduyla hemen dönebilir.
• Amaç, yazdırma özelliği tamamen destekleniyormuş gibi davranmak ama gerçekte yazıcı yokmuş gibi davranmaktır.
• Yazdırmanın hiç çalışmadığı sistemlerde, UI’de yazdırma düğmesini gizlemek için yazdırmanın mümkün olup olmadığını denetleyen bir işlev eklenebilir.
• Bu davranışa “eylemsiz (inert)” denir.
• API yüzeyi hâlâ vardır ve belirtime uygun şekilde çalışır, ama gerçekte hiçbir şey yapmaz.
• Önemli olan, belgelenmiş yöntemle tutarlı biçimde hiçbir şey yapmayarak mevcut kodla yaşanacak sorunları en aza indirmektir.

API’yi devre dışı bırakma örneği

• Widget tanıtıcısı oluşturan çeşitli işlevleri, widget tanıtıcısı alan işlevleri ve widget tanıtıcısını kapatan işlevleri içeren bir API’yi devre dışı bırakmaya dair bir örnek vardır.
• Ekip başlangıçta CreateWidget işlevinin başarılı olup null pointer döndürmesini önerdi.
• Ancak bu yaklaşım uygulamanın kafasını karıştırabilir. “Çağrı başarılı oldu ama geçerli bir tanıtıcı alamadım mı?”
• EnableWidget işlevinin “geçersiz tanıtıcı” döndürmesi de kafa karışıklığı yaratabilir.
• Mevcut belgelerde, widget oluşturmanın kullanıcı tarafından iptal edildiği anlamına gelen ERROR_CANCELLED adlı bir dönüş değeri bulundu.
• Bu nedenle uygulama ne zaman widget oluşturmaya çalışsa, “Hayır, kullanıcı iptal etti” demek mümkün olur.

GN⁺ görüşü

• Bu yazıdaki en önemli nokta, bir API hiçbir şey yapmadığında, bunu kullanıcı deneyimine zarar vermeden ve mevcut kodla uyumluluğu koruyarak yapması gerektiğidir.
• Bu yaklaşım, geliştiricilere API tasarımının önemini vurgular ve kullanıcı dostu bir yazılım deneyimi sunmaya katkı sağlar.
• Yazı, yazılım mühendisliğinin incelikli bir yönünü gösteriyor ve uygulamaların beklenmedik ortamlarda bile nasıl zarif biçimde başarısız olabileceğini inceleyen ilginç bir örnek sunuyor.

[GN⁺]

Hacker News görüşü

• "Hataları yutmak" hakkında görüş:

  • Hataları gizlemek iyi bir pratik değildir.
  • Sorunu çözmeden yazılımdaki kusurları gizleyerek bug bulmayı ve test etmeyi daha zor hale getirir.
  • Go dilindeki panic, test sırasında programcının hatalarını yüksek sesle duyurmanın iyi bir yoludur.
  • Sistem içindeki aktörler kendi kusurlarını gizlemeye çalıştığında, sorunu tespit etmek ve çözmek çok daha zorlaşır.

• Geriye dönük uyumluluk hakkında görüş:

  • Geriye dönük uyumluluk her zaman dağınık bir iştir ve seçim, ya mükemmel olmadan yapmak ya da hiç yapmamak arasındadır.
  • Word '97 ya da MS-DOS oyun dosyalarına tıkladığınızda bunların bugün de bilgisayarda beklendiği gibi açılması bu yüzdendir.

• UI tasarımına dair şikayet:

  • Var olabilecek cihazlar öneren bir UI son derece sinir bozucudur.
  • Gerçekte desteklenmeyen cihazları keşfetmek için zaman kaybettirir.

• Microsoft'un ders almamasına dair eleştiri:

  • Microsoft 30 yıl geçmesine rağmen hâlâ aynı hataları tekrarlıyor.
  • Uygulama yazıcı aramaya çalışırken boş bir liste göstermek, geçmişteki sorunları yeniden üretmektir.

• Xbox'ın yazdırmayı desteklememesi hakkında görüş:

  • Xbox'ın yazdırmayı desteklememesi, Microsoft'un bunu böyle tanımlamış olmasındandır.
  • Donanım açısından diğer Windows cihazlarıyla aynı yazdırma yeteneğine sahiptir.
  • Bu tür bir "çözüm", Microsoft'un mantıksız kararlarının yol açtığı bir sorundur.

• API kullanımı hakkında tavsiye:

  • Bileşenin kullanıcıdan önce sorun yaşaması gerektiği doğru, ancak yazarın bunu ifade etme biçimine katılmıyorum.
  • Yazdırma fonksiyonunun NotSupported­Exception fırlatması yanlış değildir.
  • Yazarın anlattığı şey, sorunlu istemcileri desteklemek için yapılan bir hack'tir.

• "Kötücül uyum" hakkındaki hisler:

  • Sorunun ele alınış biçimini hem seviyorum hem de sevmiyorum.
  • Ancak amaç platformda daha fazla kullanıcının daha fazla yazılım çalıştırabilmesi ise, bu yöntem iyidir.

• Güvenlik hakkında olumlu görüş:

  • API çağrılarını doğru şekilde yok saymak, programın daha zararlı davranışlarda bulunmasını engeller.

• Tarayıcı stratejisine dair bir değerlendirme:

  • HTML kodunda hata olsa bile sayfayı elden geldiğince göstermeye çalışma stratejisi bir zamanlar iyi bir strateji sayılıyordu.
  • Kullanıcılar hata görmek istemez ve bu deneyimden ders alınmış olmalıydı.

• İstisna işleme konusundaki eleştirmenlerin yanlış anlaması:

  • İstisna fırlatmaya gerek olmayan durumlarda eleştirmenlerin gözden kaçırdığı bir nokta var.
  • Cihaz (yazıcı) bağlı değilse uygulama bu durumu temiz biçimde ele almalı, çökmemelidir.

[GN⁺]

Lobste.rs görüşleri

• Burada kastedilen, yazdırma işlevlerinin yazdırma tamamen destekleniyormuş gibi tutarlı biçimde çalıştığı, ama tuhaf bir şekilde gerçekte hiç yazıcı bulunmadığı; bu da birçok şeyi açıklıyor
  Şakayı bir kenara bırakırsak, bu kadar aşırı savunmacı programlama ve kullanıcı deneyimi yaklaşımına katılmıyorum. Böyle olunca yazılım nedenini bile bilmeden görevini yapmaz hale geliyor ve nedenini öğrenmenin de bir yolu kalmıyor. Uygulama hataları yakalayıp mümkünse kullanıcı dostu bir mesaj üretmeli; bunu yapamıyorsa en azından özgün hata mesajını kullanıcıya göstermeli. Arka plan işi ise bir hata günlüğü olmalı
  Bu yazının uygulama geliştiricisinden çok API geliştiricisinin bakış açısından yazıldığını kabul ediyorum. O yüzden API hatalarını belgelendirmeli ve çağıran tarafın harekete geçebileceği hata mesajları sağlamalısınız
  Ayrıca erişim izni yok diye UI'da düğmeleri gizlemekten de hoşlanmıyorum. Yer varsa düğmeyi gösterip devre dışı bırakmak ve kullanıcı üstüne geldiğinde onu nasıl etkinleştirebileceğini anlatan bir mesaj göstermek daha iyi bence
  • Bunun sıradan bir API geliştiricisinin değil, bir Windows API geliştiricisinin bakış açısı olduğunu da hesaba katmak gerekir. Windows API'lerinde sürüm değişse bile geriye dönük uyumluluğu bozmamak, Microsoft'un uzun süredir benimsediği bir tutum
  • Bu, klasik bir Postel yasası / sağlamlık ilkesi tartışması. Artık sağlamlık ilkesinin eskidiğini ve HTML gibi ya da düzgün bir ayrıştırıcı yazmayı zorlaştıran devasa protokoller ve dosya biçimleri gibi canavarlar ürettiğini hepimiz biliyoruz
    Genel olarak doğruluğu talep etmek daha iyidir. Ama mevcut kullanıcı tabanınız 1 milyar kişiyse, mümkün olduğunca bir şeyleri bozmamak çok akıllıcadır ve kullanıcı açısından sadece çalıştığı için sistem düzeyinde gerçek bir değer de üretir. Sonuçta tavır şu olmalı: erken başarısız ol, ama çok sayıda şeyi başarısız hale getirme
  • Bu durumda mevcut API'lerden birinin belgelenmiş bir hatası yok, dolayısıyla baştan hata işleme de olmayabilir. Mevcut yazılımların hepsini bozmak istemiyorsanız iyi niyetli bir yalan söylemeniz gerekir
    Bu, API'den çok ABI kararlılığına yakın bir konu. Windows'ta 15 yıl önce derlenmiş yazılımlar da mümkün olduğunca yeni işletim sistemlerinde çalışmaya devam etmelidir. Fonksiyon imzasını değiştiremezsiniz; bu yüzden artık anlamı kalmamış API'leri bile çalışır tutmak için iyi niyetli yalanlar söylemek gerekir
    Örneğin API hâlâ Active Desktop varmış gibi davranır. Çünkü alternatif, çok sayıda eski yazılımı kırmaktır
  • Kesinlikle katılıyorum. Herhangi bir nedenle benim ekranımda görünmeyen ama yanımda anlatan kişinin ya da eğitim içeriğinin ekranında görünen bir düğmeyi arayıp durmak kadar sinir bozucu bir şey yok
    Özelliğin kaldırılıp kaldırılmadığını mı, yoksa bu arada başka bir ekranın altına mı gömüldüğünü anlayamıyorsunuz
  • Uygulamanın hataları yakalayıp kullanıcıya göstermesi gerektiği doğru.
    Ama uygulama bunu yapmazsa, o uygulamayı kullananlar uygulamayı değil Windows'u suçlar. Hatta uygulama çökse bile yine Windows'u suçlarlar
    Bu yüzden Microsoft geçici çözümler üretiyor. Yazdırma işinin sessizce yok olmasına izin vermek çok daha kolay; kullanıcı da kısa bir duraksamadan sonra “aa doğru ya, yazıcı yoktu” deyip durumu kabulleniyor
• Yazıcı kurulum fonksiyonu hemen dönüp sonuç kodu olarak kullanıcı işlemi iptal etti döndürebiliyorsa, uygulama desteği açısından bu neredeyse kesin olarak, yazdırma API'sinin en baştan istisna fırlatmasından daha zor yönetilen ve istenmeyen davranışlara yol açar
• Son zamanlarda çok fazla AI destekli programlama yapıyorum ve ajanın sık sık null olup olmadığını kontrol eden if denetimleri eklediğini görüyorum. Bunu her gördüğümde bu yazı aklıma geliyor
  Bu yüzden ajana null denetimlerini tekrar tekrar eklememesini, bunun yerine zararsız fonksiyonlar kullanmasını ve değerin asla null olmadığını bildirim anında bir kez doğrulamasını söyledim