Yazılım dünyasının saçma kanunları

Yazılım geliştiriciler gibi zeki insanların neden bu kadar sık ​​batırdığını hiç merak ettiniz mi? Yapan insanlar var. Bu yazıda inceliyoruz profesyonellerin davranışlarını tanımlayan bazı yazılı olmayan yasalar bilgi işlem.

İlk bilgisayarım bir Commodore 64'tü. Neredeyse 30 kb RAM sistem içindi, geriye kelime işlem, oyun, aile şirketi muhasebesi ve sahip olduğum 32 gb bilgisayarla yaptığım hemen hemen her şey için 6 kb kaldı. Bu soruyu açık bırakır Günümüz ekipmanı yazılım ihtiyaçlarına yanıt veriyor mu yoksa yazılım mevcut olduğu için daha fazla donanım kaynağı mı kullanıyor?

Doğrusu, oyunlar aynı değil, grafikler aynı kalitede değil ve film izlemek ve müzik dinlemek imkansız olurdu. Ancak, kimse yardım edemez ama şunu düşünür Gerçekten yeni hiçbir şeye katkıda bulunmadan sürümleri yayınlayan ve giderek daha fazla kaynak tüketen programlar var.

İşte nedenleri.

Zawinsky Yasası

Netscape geliştiricisi Jamie Zawinsky şunu savundu: Her program, e-postaları okuyabilene kadar özellikler içerir. Başaramazsa, bunu yapabilecek başka biriyle değiştirilir.

Bunu söylediğinde şaka, aslında e-posta istemcileri olarak tasarlanmamış programlardan bahsetmesiydi. Google Play'deki birçok uygulamanın, işlerini yapmaları gerekmeyen telefon bileşenlerine ve kullanıcı verilerine erişmek için izin istediği keşfedilince komik olmaktan çıktı.

Bazıları bunu, kullanıcıları gözetleme girişimlerinin bir parçası olarak yorumladı. Ama bir şeyi sadece yapılabileceği için yapmak muhtemelen insan doğasıdır.

Peter'ın yazılıma uygulanan ilkesi

Lawrence Peter, bir hiyerarşide, bir kişinin fena halde yetersiz olduğu bir konuma yükseldiğini belirtmesiyle ünlendi. Ancak karmaşık projeler hakkında bir şeyler söyleyecek zamanı da vardı:

"Karmaşık bir proje, kendi geliştiricileri tarafından bile anlaşılamayacak kadar karmaşık hale gelecektir."

En az şaşkınlık ilkesi

1984 yılında IBM Systems Journal'da yayınlanan bu ilke şunu belirtir:

"Gerekli bir özellik büyük bir sürpriz yaratırsa, özelliğin yeniden tasarlanması gerekebilir."

En otras palabras, Yazılımın bir kısmı veya tamamı kullanıcının alışkın olduğundan çok farklıysa, en iyisi yeniden tasarımdır. İdeal olarak, başarmaya çalışın Etkileyici olacak kadar büyük, ancak aşina kalabilecek kadar küçük olan artımlı iyileştirmeler kullanıcı için.

Shuttleworth'un Unity'yi başlatırken bunu hesaba katmaması çok kötü.

Sibernetik Entomoloji Yasası

Bilgisayar tarihindeki ilk hata gerçekti. MARK II bilgisayarındaki rölelerden birine bir güve uçarak arızaya neden oldu.

Metaforla devam edersek, sibernetik entomoloji yasası, her zaman bir hata daha olacaktır.

Bu, tüm bilgisayar kullanıcılarının bildiği bir şeydir. Bir işletim sistemi ne kadar test edilirse edilsin, her zaman çok geç olduğunda keşfedilen bir hata vardır.

Kernighan Yasası

Linux Adictos Yazarlarımızın arama motoru dostu bir şekilde yazmasını sağlamak için yüklü bir eklenti var. İlk günden nefret ettim. Biraz edebi uçuşmayla yazmaya yönelik her türlü girişim, hemen kırmızı bir daireyle kınanıyor. Zaman geçtikçe alıştım ve nadiren rötuş yapmak zorunda kalıyorum.

Aynı şey programcılar için de geçerlidir, çoğu zaman kodlama yeteneklerini göstermekle, anlaşılması ve bakımı daha kolay olan daha basit bir kod yazmaktan daha çok ilgilenirler.

Dolayısıyla Kernighan yasası şunu kabul eder:

Hata ayıklama, ilk etapta kodu yazmaktan iki kat daha zordur. Dolayısıyla, kodu olabildiğince akıllıca yazarsanız, tanım gereği hata ayıklayacak kadar akıllı değilsiniz. '

90/90 kuralı

Gerçek hayatta kar amacı gütmeyen bir proje başlatan herkes bilir ki, beklenen kârın yarısını elde etmek için her proje iki kat daha uzun sürer ve bütçenin iki katı maliyete mal olur.

Bilgisayar dünyasında bu yasanın farklı biçimleri vardır. Örneğin, bir Tom Cargill şunları söyledi:

Kodun ilk yüzde 90'ı, geliştirme süresinin ilk yüzde 90'ını temsil ediyor. Kodun kalan yüzde 10'u, geliştirme süresinin diğer yüzde 90'ını temsil ediyor. "

Net değil mi? Belki Hofstadter Yasası yardımcı olabilir:

"Hofstadter yasası aklınızda olsa bile, her zaman beklediğinizden daha uzun sürer."

Sanırım Ubuntu ve Fedora geliştiricilerinin bilmesi gerekiyor. Ya da en azından 6 ayda bir hatırlayın.

Brook Yasası

Açık kaynaklı yazılım projelerinin genellikle iki sorunu vardır; finansman ve işbirlikçi eksikliği. İkincisi sorun olmadığı sürece. Brook'a göre:

"Programın gerisinde kalan bir yazılım projesine iş gücü eklemek, onu daha da geciktirecektir."

Anlaşılır bir şekilde, sadece yeni kodlayıcıları güncellemeniz gerekmez. Daha fazlasının belgelenmesi gerekecek, herkesi senkronize tutmak için daha fazla bürokrasi gerekecek ve muhtemelen kavgalar olacak.

Ve elbette arkadaş Parkinson'u ve onun iddiasını unutamayız. Ne kadar boş alanla başladığınız önemli değil. Her zaman daha fazlasına ihtiyacın olacak. Ofis alanından bahsediyordu, ancak aynı şey RAM ve disk alanı için de geçerli.