Programlama Python Gündem Haber Ekonomi Komikli Caps Karikatür Futbol Teknoloji Sinema & Film Film Önerisi gelir mi Oyun Yazılım Yazılım Öğren Android Bitcoin Machine Learning Magazin Müzik Listeleri Tatil Düğün Kolpaçino Yabancı Magazin Fitness bilmem PUBG Psikoloji güzellik & makyaj C++ Database şarkı sözleri Overwatch sağlık korona meta korkunç web tasarım sanat din moda bilim doğa tarih sosyal medya nostalji komikli veri madenciliği haber belgesel araba etkinlik umut sarıkaya fragman spor matematik edebiyat windows politik vr iş font hayvan iphone yemek girişim dizayn eğitim wordpress growth hacking çocuk röportaj televizyon teknik musiki serin hikaye geek yaşam reklam dizi seo saat kitap iğrenç tatlış (aww) Kripto para haberleri Yatırım Yatırım Öğren COVID19 (Korona Virus)

  • push_pin Her yazılımcının bilmesi gereken teoriler ve kurallar (github.com)
    by crn     4 yıl önce        2 Yorum       

    • Sunumlarda çok işe başlıyor.

    Kaynak: https://github.com/dwmkerr/hacker-laws # 💻📖 hacker-laws Geliştiricilerin faydalı bulacağı Kanunlar, Teoriler, Prensipler ve Kalıplar.

    Giriş

    İnsanların geliştirme hakkında konuşurken tartıştığı birçok yasa vardır. Bu havuz, en yaygın olanlardan bazılarının bir referansı ve genel bakışıdır. Lütfen paylaşın ve PR'leri gönderin!

    ❗: Bu depo bazı yasaların, ilkelerin ve kalıpların açıklamasını içerir, ancak bunların hiçbirini savunmaz. Bunların uygulanıp uygulanmaması her zaman tartışma konusu olacaktır ve büyük ölçüde ne yaptığınıza bağlıdır üzerinde çalışılıyor.

    Yasalar

    Ve işte başlıyoruz!

    90–9–1 İlkesi (%1 Kuralı)

    Vikipedi'de %1 Kuralı)

    T90-9-1 ilkesi, bir wiki gibi bir internet topluluğunda katılımcıların %90'ının yalnızca içerik tükettiğini, %9'unun içeriği düzenlediğini veya değiştirdiğini ve katılımcıların %1'inin içerik eklediğini ileri sürer.

    Gerçek dünya örnekleri:

    • Dört dijital sağlık sosyal ağına ilişkin 2014 tarihli bir çalışma, en üstteki %1'in gönderilerin %73'ünü oluşturduğunu, sonraki %9'un ortalama %25'ini ve kalan %90'ın ortalama %2'sini oluşturduğunu buldu (Referans)

    Ayrıca Bakınız:

    Amdahl Yasası

    Vikipedi'de Amdahl Yasası

    Amdahl Yasası, bir sistemin kaynaklarını artırarak elde edilebilecek bir hesaplama görevinin potansiyel hızlanmasını gösteren bir formüldür. Normalde paralel hesaplamada kullanılır, işlemci sayısını artırmanın gerçek faydasını tahmin edebilir, bu da programın paralel hale getirilebilirliğiyle sınırlıdır.

    En iyi bir örnekle açıklanabilir. Bir program iki parçadan oluşuyorsa, tek bir işlemci tarafından yürütülmesi gereken A parçası ve paralel hale getirilebilen B parçası, o zaman programı yürüten sisteme birden fazla işlemci eklemenin yalnızca sınırlı bir faydası olabileceğini görürüz. Potansiyel olarak B parçasının hızını büyük ölçüde artırabilir - ancak A parçasının hızı değişmeden kalacaktır.

    Aşağıdaki diyagram, hızda olası iyileştirmelere dair bazı örnekleri göstermektedir:

    Diyagram: Amdahl Yasası

    (Görsel Kaynağı: Daniels219 tarafından İngilizce Wikipedia'da, Creative Commons Atıf-Benzer Paylaşım 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)

    Gördüğünüz gibi, %50 paralelleştirilebilir bir program bile 10 işlem biriminin ötesinde çok az fayda sağlarken, %95 paralelleştirilebilir bir program binin üzerinde işlem birimiyle bile önemli hız iyileştirmeleri elde edebilir.

    Moore Yasası yavaşladıkça ve bireysel işlemci hızının ivmesi yavaşladıkça, paralelleştirme performansı iyileştirmenin anahtarıdır. Grafik programlama mükemmel bir örnektir - modern Shader tabanlı bilgi işlemle, tek tek pikseller veya parçalar paralel olarak işlenebilir - bu nedenle modern grafik kartları genellikle binlerce işlem çekirdeğine (GPU veya Shader Birimi) sahiptir.

    Ayrıca bakınız:

    Kırık Pencereler Teorisi

    Vikipedi'de Kırık Pencereler Teorisi

    Kırık Pencereler Teorisi, görünür suç belirtilerinin (veya bir ortama özen gösterilmemesinin) daha fazla ve daha ciddi suçlara (veya ortamın daha fazla bozulmasına) yol açtığını öne sürer.

    Bu teori, yazılım geliştirmeye uygulanmıştır ve düşük kaliteli kodun (veya Teknik Borç) kaliteyi iyileştirme çabalarının göz ardı edilebileceği veya hafife alınabileceği algısına yol açabileceğini ve böylece daha fazla düşük kaliteli koda yol açabileceğini öne sürmektedir. Bu etki zamanla kalitede büyük bir düşüşe yol açarak kademeli olarak artar.

    Ayrıca bakınız:

    Örnekler:

    Brooks Yasası

    Vikipedi'de Brooks Yasası

    Geç bir yazılım geliştirme projesine insan kaynakları eklemek onu daha geç hale getirir.

    Bu yasa, birçok durumda, daha fazla insan ekleyerek zaten gecikmiş bir projenin teslimatını hızlandırmaya çalışmanın teslimatı daha da geciktireceğini öne sürer. Brooks bunun aşırı bir basitleştirme olduğunu açıkça belirtir, ancak genel mantık, yeni kaynakların hızlandırma süresi ve iletişim giderleri göz önüne alındığında, kısa vadede hızın azalmasıdır. Ayrıca, birçok görev bölünemeyebilir, yani daha fazla kaynak arasında kolayca dağıtılabilir, bu da potansiyel hız artışının da daha düşük olduğu anlamına gelir.

    Teslimattaki yaygın ifade "Dokuz kadın bir ayda bebek yapamaz" Brooks Yasası ile ilgilidir, özellikle bazı iş türlerinin bölünemez veya paralel hale getirilemez olduğu gerçeğiyle.

    Bu, 'Efsanevi Adam Ayı' kitabının temel temasıdır.

    Ayrıca bakınız:

    CAP Teoremi (Brewer Teoremi)

    CAP Teoremi (Eric Brewer tarafından tanımlanmıştır) dağıtılmış bir veri deposu için aşağıdaki üç garantiden yalnızca ikisinin (en fazla) yapılabileceğini belirtir:

    • Tutarlılık: veri okurken, her istek en son veriyi alır veya bir hata döndürülür
    • Kullanılabilirlik: veri okurken, her istek en son veri olduğu garantisi olmaksızın bir hata olmayan yanıt alır
    • Bölümleme Toleransı: düğümler arasındaki keyfi sayıda ağ isteği başarısız olduğunda, sistem beklendiği gibi çalışmaya devam eder

    Mantığın özü
    aşağıdaki gibidir. Bir ağ bölümünün oluşmayacağını garanti etmek imkansızdır (bkz. Dağıtık Hesaplamanın Yanılgıları). Bu nedenle bir bölümleme durumunda işlemi iptal edebilir (tutarlılığı artırarak ve kullanılabilirliği azaltarak) veya devam edebiliriz (kullanılabilirliği artırarak ancak tutarlılığı azaltarak).

    Adı, garantilerin ilk harflerinden gelir (Tutarlılık, Kullanılabilirlik, Bölümleme Toleransı). Bunun, farklı bir tutarlılık tanımı olan ACID ile ilişkili olmadığının farkında olmanın çok önemli olduğunu unutmayın. Daha yakın zamanda, ağ bölünmediğinde (yani sistem beklendiği gibi çalıştığında) gecikme ve tutarlılık için kısıtlamalar ekleyen PACELC teoremi geliştirilmiştir.

    Çoğu modern veritabanı platformu, veritabanı kullanıcısına yüksek düzeyde kullanılabilir bir işlem ('kirli okuma' içerebilir) veya yüksek düzeyde tutarlı bir işlem (örneğin 'çoğunluk tarafından onaylanmış yazma') arasında seçim yapma seçeneği sunarak bu teoremi örtük olarak kabul eder.

    Gerçek dünya örnekleri:

    • Google Cloud Spanner ve CAP Teoreminin İçinde - İlk bakışta CAP'nin tüm garantilerine sahip bir platform gibi görünen ancak perde arkasında esasen bir CP sistemi olan Cloud Spanner'ın nasıl çalıştığına dair ayrıntılara girer.

    Ayrıca bakınız:

    Conway Yasası

    Vikipedi'de Conway Yasası

    Bu yasa, bir sistemin teknik sınırlarının organizasyonun yapısını yansıtacağını ileri sürer. Organizasyon iyileştirmelerine bakıldığında sıklıkla başvurulan Conway Yasası, bir organizasyon birçok küçük, bağlantısız birimden oluşuyorsa ürettiği yazılımın da öyle olacağını ileri sürer. Bir organizasyon, özellikler veya hizmetler etrafında yönlendirilmiş 'dikeyler' etrafında daha fazla inşa edilmişse, yazılım sistemleri de bunu yansıtacaktır.

    Ayrıca bakınız:

    Cunningham Yasası

    Vikipedi'de Cunningham Yasası

    İnternette doğru cevabı almanın en iyi yolu soru sormak değil, yanlış cevabı yayınlamaktır.

    Steven McGeady'ye göre, Ward Cunningham ona 1980'lerin başında şu tavsiyede bulunmuş: "İnternette doğru cevabı almanın en iyi yolu soru sormak değil, yanlış cevabı yayınlamaktır." McGeady buna Cunningham yasası adını vermiş, ancak Cunningham bunu "yanlış alıntı" olarak adlandırarak sahipliğini reddediyor. Başlangıçta Usenet'teki etkileşimlere atıfta bulunsa da, yasa diğer çevrimiçi toplulukların nasıl çalıştığını tanımlamak için kullanılmıştır (örneğin, Wikipedia, Reddit, Twitter, Facebook).

    Ayrıca bakınız:

    Dunbar Sayısı

    Vikipedi'de Dunbar Sayısı

    "Dunbar sayısı, bir kişinin istikrarlı sosyal ilişkiler sürdürebileceği kişi sayısına ilişkin önerilen bir bilişsel sınırdır; bir bireyin her bir kişinin kim olduğunu ve her bir kişinin diğer her bir kişiyle nasıl ilişki kurduğunu bildiği ilişkiler." Tam sayı konusunda bazı anlaşmazlıklar var. "... [Dunbar] insanların rahatça yalnızca 150 istikrarlı ilişki sürdürebileceğini öne sürdü." Sayıyı daha sosyal bir bağlama oturttu, "bir barda onlarla karşılaşırsanız davetsizce bir içki içmek için katılmaktan utanmayacağınız kişi sayısı." Sayı için tahminler genellikle 100 ile 250 arasındadır.

    Bireyler arasındaki istikrarlı ilişkiler gibi, bir geliştiricinin bir kod tabanıyla ilişkisini sürdürmek çaba gerektirir. Büyük ve karmaşık projelerle veya birçok projenin sahipliğiyle karşı karşıya kaldığımızda ölçeklendirmek için geleneklere, politikalara ve modellenmiş prosedürlere yaslanırız. Dunbar'ın sayısı yalnızca bir ofis büyüdükçe akılda tutulması gereken önemli bir şey değildir, aynı zamanda ekip çalışmaları için kapsamı belirlerken veya bir sistemin lojistik genel giderleri modellemeye ve otomatikleştirmeye yardımcı olacak araçlara ne zaman yatırım yapması gerektiğine karar verirken de önemlidir. Sayıyı bir mühendislik bağlamına koyarsak, destek için bir nöbet rotasyonuna katılmaktan emin hissedeceğiniz proje sayısıdır (veya tek bir projenin normalleştirilmiş karmaşıklığıdır).

    Ayrıca bakınız:

    Dunning-Kruger Etkisi

    Wikipedia'da Dunning-Kruger Etkisi

    Eğer yetersizseniz, yetersiz olduğunuzu bilemezsiniz... Doğru bir cevap üretmek için ihtiyaç duyduğunuz beceriler, doğru bir cevabın ne olduğunu anlamak için ihtiyaç duyduğunuz becerilerle aynıdır.

    (David Dunning)

    Dunning-Kruger etkisi, David Dunning ve Justin Kruger tarafından 1999'da yapılan bir psikolojik çalışma ve makalede açıklanan teorik bir bilişsel önyargıdır. Çalışma, bir görevde düşük seviyede yeteneğe sahip kişilerin Görevin yeteneklerini abartma olasılıkları yüksektir. Bu önyargının önerilen nedeni, bir kişinin o alanda çalışma yeteneği hakkında bilgili bir görüş oluşturabilmesi için bir sorunun veya alanın karmaşıklığı hakkında yeterli farkındalığa sahip olması gerektiğidir.

    Dunning-Kruger etkisi bazen, "Bir kişi bir alanı ne kadar az anlarsa, o alandaki sorunları kolayca çözebileceğine inanma olasılığı o kadar artar, çünkü alanı basit olarak görme olasılıkları daha yüksektir" şeklinde tanımlanabilecek ilgili ancak zorunlu olarak ima edilmeyen bir etkiyi tanımlamak için kullanılmıştır. Bu daha genel etki teknolojide oldukça önemlidir. Bu, teknik olmayan ekip üyeleri veya daha az deneyimli ekip üyeleri gibi bir alana daha az aşina olan kişilerin, bu alandaki bir sorunu çözmek için gereken çabayı küçümseme olasılığının daha yüksek olduğunu göstermektedir.

    Bir kişinin bir alandaki anlayışı ve deneyimi arttıkça, başka bir etkiyle karşılaşabilirler, bu da başkalarının yeteneklerini aşırı tahmin etme veya kendi yeteneklerini küçümseme eğiliminde olmalarıdır, çünkü alanda çok deneyimli hale gelmişlerdir. Her durumda bu etkiler bilişsel önyargılardır. Herhangi bir önyargıda olduğu gibi, bunun mevcut olabileceğinin anlaşılması, zorluklardan kaçınmaya yardımcı olmak için genellikle yeterli olacaktır - çünkü bir önyargının farkındalığı olduğunda, bu önyargıları ortadan kaldırmaya çalışmak için daha fazla girdi ve görüş dahil edilebilir. Yakından ilişkili olanlardan biri İllüsory superiority önyargısıdır.

    Gerçek dünya örnekleri:

    • Apple ve FBI: Bu Terörle Mücadele Şahini Neden Taraf Değiştirdi - 2016'da Senatör Lindsey Graham, Apple'ın cihazlarının şifrelenmesinde bir 'arka kapı' oluşturması konusundaki tutumunu değiştirdi. Graham, başlangıçta Apple'ın olası terörist komplolarını araştırmak için gerekli gördüğü bir 'arka kapı' oluşturma talebine itiraz etmesini eleştirmişti. Ancak Graham'ın kendi itirafına göre, alanın teknik karmaşıklığı hakkında daha fazla şey öğrendikçe, bunun farkına vardığından çok daha basit olduğunu varsaydığını ve böyle bir arka kapının ciddi olumsuz sonuçları olabileceğini fark etti. Bu, potansiyel olarak Dunning-Kruger etkisinin bir örneği olarak düşünülebilir - bir siber güvenlik uzmanı, bu tür bir arka kapının nasıl istismar edilebileceğini muhtemelen hemen anlayacaktır, çünkü alan hakkında derin bir anlayışa sahiptir, sıradan bir kişi telefon güvenliğinin, kolluk kuvvetleri için bir 'ana anahtar' bulundurma uygulamasının mümkün olduğu fiziksel güvenliğe daha çok benzediğini varsayabilir, ancak bu benzetme siber güvenlikteki modern şifrelemeyi tanımlamak için yeterince iyi uygulanmaz.

    Fitts Yasası

    Fitts Yasası Wikipedia'da

    Fitts yasası, bir hedef bölgeye hareket etmek için gereken sürenin, hedefe olan mesafenin hedefin genişliğine bölünmesinin bir fonksiyonu olduğunu öngörür.

    Diyagram: Fitts Yasası

    (Görsel Kaynağı: Foobar628 tarafından İngilizce Wikipedia'da, Creative Commons Atıf-Benzer Paylaşım 3.0 Unported, https://en.wikipedia.org/wiki/Fitts%27s_law#/media/File:Fitts_Law.svg)

    Bu yasanın sonuçları, UX veya UI tasarlarken etkileşimli öğelerin mümkün olduğunca büyük ve kullanıcının dikkat alanı ile etkileşimli öğe arasındaki mesafenin mümkün olduğunca küçük olması gerektiğini belirtir. Bunun, genellikle birbirine yakın kullanılan görevleri gruplamak gibi tasarım üzerinde sonuçları vardır.

    Ayrıca, kullanıcının faresini kolayca vurmak için 'süpürebileceği' ekranın köşeleri olan 'sihirli köşeler' kavramını da resmileştirir - bu, temel UI öğelerinin yerleştirilebileceği yerdir. Windows Başlat düğmesi sihirli bir köşededir ve bu da seçmeyi kolaylaştırır ve ilginç bir tezat olarak, MacOS'un 'pencereyi kapat' düğmesi sihirli bir köşede değildir ve yanlışlıkla basılması zordur.

    Ayrıca bkz.:

    Gall Yasası

    Vikipedi'de Gall Yasası#Gall's_law)

    Çalışan karmaşık bir sistemin, çalışan basit bir sistemden evrimleştiği her zaman görülür. Sıfırdan tasarlanan karmaşık bir sistem asla işe yaramaz ve onu çalışır hale getirmek için yama yapılamaz. Çalışan basit bir sistemle baştan başlamanız gerekir.

    (John Gall))

    Gall Yasası, son derece karmaşık sistemler tasarlamaya yönelik girişimlerin başarısız olma olasılığının yüksek olduğunu ima eder. Son derece karmaşık sistemler nadiren tek seferde inşa edilir, bunun yerine daha basit sistemlerden evrimleşir.

    Klasik örnek, dünya çapındaki web'dir. Mevcut haliyle son derece karmaşık bir sistemdir. Ancak, başlangıçta akademik kurumlar arasında içerik paylaşmanın basit bir yolu olarak tanımlanmıştır. Bu hedeflere ulaşmada oldukça başarılı olmuş ve daha karmaşık hale gelmiştirr zamanı.

    Ayrıca bakınız:

    Goodhart Yasası

    Vikipedi'de Goodhart Yasası

    Herhangi bir gözlemlenen istatistiksel düzenlilik, kontrol amaçlı olarak üzerine baskı uygulandığında çökme eğiliminde olacaktır.

    Charles Goodhart

    Genellikle şu şekilde de anılır:

    Bir ölçüm hedef haline geldiğinde, iyi bir ölçüm olmaktan çıkar.

    Marilyn Strathern

    Yasa, ölçüm odaklı optimizasyonların ölçüm sonucunun kendisinin değersizleşmesine yol açabileceğini belirtir. Bir sürece körü körüne uygulanan aşırı seçici ölçüm kümesi (KPI'lar) çarpık bir etkiyle sonuçlanır. İnsanlar eylemlerinin bütünsel sonuçlarına dikkat etmek yerine belirli metrikleri karşılamak için sistemi "oynatarak" yerel olarak optimize etme eğilimindedir.

    Gerçek dünya örnekleri:

    • Metriğin amacı iyi test edilmiş bir yazılım oluşturmak olmasına rağmen, iddiasız testler kod kapsamı beklentisini karşılar.
    • İşlenen satır sayısıyla belirtilen geliştirici performans puanı, haksız yere şişkin bir kod tabanına yol açar.

    Ayrıca bakınız:

    Hanlon'un Usturası

    Hanlon'un Usturası Wikipedia'da

    Aptallıkla yeterince açıklanabilen bir şeyi asla kötü niyete bağlamayın.

    Robert J. Hanlon

    Bu ilke, olumsuz bir sonuçla sonuçlanan eylemlerin kötü niyetin bir sonucu olmadığını öne sürer. Bunun yerine, olumsuz sonuç daha çok bu eylemlere ve/veya etkinin tam olarak anlaşılmamasına atfedilir.

    Hick Yasası (Hick-Hyman Yasası)

    Vikipedi'de Hick yasası

    Karar süresi, seçebileceğiniz seçenek sayısıyla logaritmik olarak artar.

    William Edmund Hick ve Ray Hyman

    Aşağıdaki denklemde, T karar verme süresi, n seçenek sayısı ve b verilerin analiziyle belirlenen bir sabittir.

    Hicks yasası

    (Görsel Kaynağı: Creative Commons Atıf-Benzer Paylaşım 3.0 Unported, https://en.wikipedia.org/wiki/Hick%27s_law)

    Bu yasa yalnızca seçenek sayısı sıralı olduğunda, örneğin alfabetik olarak uygulandığında geçerlidir. Bu, karar vericinin esasen ikili bir arama gerçekleştirdiğini ima eden taban iki logaritmada ima edilir. Seçenekler iyi sıralanmamışsa, deneyler geçen sürenin doğrusal olduğunu gösterir.

    Bunun kullanıcı arayüzü tasarımında önemli bir etkisi vardır; kullanıcıların seçenekler arasında kolayca arama yapabilmesini sağlamak daha hızlı karar almaya yol açar.

    Ayrıca Hick Yasası'nda IQ ile tepki süresi arasında bir korelasyon gösterilmiştir; Bilgi İşleme Hızı: Gelişimsel Değişim ve Zeka Bağlantıları'da gösterilmiştir.

    Ayrıca bakınız:

    Hofstadter Yasası

    Hofstadter Yasası Wikipedia'da

    Hofstadter Yasasını hesaba kattığınızda bile, her zaman beklediğinizden daha uzun sürer.

    (Douglas Hofstadter)

    Bir şeyin ne kadar süreceğine dair tahminlere bakarken bu yasaya atıfta bulunulduğunu duyabilirsiniz. Yazılım geliştirmede bir şeyin teslim edilmesinin ne kadar süreceğini doğru bir şekilde tahmin etmede pek iyi olmadığımız bir gerçek gibi görünüyor.

    Bu, 'Gödel, Escher, Bach: An Eternal Golden Braid' kitabından alınmıştır.

    Ayrıca bakınız:

    Hutber Yasası

    Vikipedi'de Hutber Yasası

    İyileştirme, bozulma anlamına gelir.

    (Patrick Hutber)

    Bu yasa, bir sistemdeki iyileştirmelerin diğer parçalarda bozulmaya yol açacağını veya diğer bozulmaları gizleyeceğini ve genel olarak sistemin mevcut durumundan bir bozulmaya yol açacağını ileri sürer.

    Örneğin, belirli bir uç nokta için yanıt gecikmesinde bir azalma, bir istek akışında daha ileride artan verim ve kapasite sorunlarına neden olabilir ve tamamen farklı bir alt sistemi etkileyebilir.

    Hype Döngüsü ve Amara Yasası

    Wikipedia'da Hype Döngüsü

    Kısa vadede bir teknolojinin etkisini abartma ve uzun vadede etkisini küçümseme eğilimindeyiz.

    (Roy Amara)

    Hype Döngüsü, başlangıçta Gartner tarafından üretilen, zaman içinde teknolojinin heyecanını ve gelişimini gösteren görsel bir temsildir. En iyi şekilde bir görselle gösterilir:

    Hype Döngüsü

    (Görsel Kaynağı: Jeremykemp tarafından İngilizce Wikipedia'da, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)

    Kısacası, bu döngü genellikle yeni teknoloji ve potansiyel etkisi etrafında bir heyecan patlaması olduğunu gösterir. Ekipler genellikle bu teknolojilere atlarlar

    ogies hızla ve bazen sonuçlardan hayal kırıklığına uğrayarak bulurlar. Bunun nedeni teknolojinin henüz yeterince olgunlaşmamış olması veya gerçek dünya uygulamalarının henüz tam olarak gerçekleştirilememiş olması olabilir. Belirli bir süre sonra, teknolojinin yetenekleri artar ve onu kullanmak için pratik fırsatlar artar ve ekipler sonunda üretken hale gelebilir. Roy Amara'nın sözü bunu en özlü şekilde özetler - "Kısa vadede bir teknolojinin etkisini abartma ve uzun vadede küçümseme eğilimindeyiz".

    Hyrum Yasası (Gizli Arayüzler Yasası)

    Hyrum Yasası Çevrimiçi

    Bir API'nin yeterli sayıda kullanıcısı varsa,
    sözleşmede ne vaat ettiğiniz önemli değildir:
    sisteminizin tüm gözlemlenebilir davranışları
    birileri tarafından güvenilecektir. >
    (Hyrum Wright)

    Hyrum Yasası, bir API'nin yeterince büyük sayıda tüketicisi olduğunda, API'nin tüm davranışlarının (genel bir sözleşmenin parçası olarak tanımlanmamış olanlar bile) sonunda birileri tarafından güvenilmeye başlanacağını belirtir. Basit bir örnek, bir API'nin yanıt süresi gibi işlevsel olmayan öğeler olabilir. Daha incelikli bir örnek, bir API'nin hata türünü belirlemek için bir hata mesajına bir regex uygulamaya güvenen tüketiciler olabilir. API'nin genel sözleşmesi mesajın içeriği hakkında hiçbir şey belirtmese bile, kullanıcıların ilişkili bir hata kodu kullanması gerektiğini belirtse bile, bazı kullanıcılar mesajı kullanabilir ve mesajı değiştirmek esasen bu kullanıcılar için API'yi bozar.

    Ayrıca bakınız:

    Kernighan Yasası

    Hata ayıklama, kodu ilk başta yazmaktan iki kat daha zordur. Bu nedenle, kodu mümkün olduğunca akıllıca yazarsanız, tanım gereği, onu hata ayıklamak için yeterince akıllı değilsinizdir. >
    (Brian Kernighan)

    Kernighan Yasası, Brian Kernighan'dan adını almıştır ve Kernighan ve Plauger'ın Programlama Stilinin Öğeleri kitabındaki bir alıntıdan türetilmiştir:

    Herkes hata ayıklamanın, ilk etapta bir program yazmaktan iki kat daha zor olduğunu bilir. Dolayısıyla, onu yazarken olabildiğince akıllıysanız, onu nasıl hata ayıklayabilirsiniz?

    Kernighan Yasası, abartılı olsa da, karmaşık kodda ortaya çıkan herhangi bir sorunu ayıklamanın maliyetli veya hatta uygulanamaz olabileceği için, basit kodun karmaşık koddan tercih edilmesi gerektiği argümanını öne sürer.

    Ayrıca bakınız:

    Linus Yasası

    Vikipedi'de Linus Yasası

    Yeterince göz önünde bulundurulduğunda, tüm hatalar yüzeyseldir.

    Eric S. Raymond

    Bu yasa basitçe, bir sorunu görebilen kişi sayısı arttıkça, birinin sorunu daha önce görmüş ve çözmüş olma olasılığının veya buna çok benzer bir şeyin daha yüksek olduğunu belirtir.

    Başlangıçta projeler için açık kaynaklı modellerin değerini tanımlamak için kullanılmış olsa da, her türlü yazılım projesi için kabul edilebilir. Ayrıca süreçlere de genişletilebilir - daha fazla kod incelemesi, daha fazla statik analiz ve çok disiplinli test süreçleri sorunları daha görünür ve tanımlanması kolay hale getirecektir.

    Daha resmi bir ifade şu şekilde olabilir:

    Yeterince büyük bir beta testçisi ve ortak geliştirici tabanı verildiğinde, hemen hemen her sorun hızla karakterize edilecek ve daha önce benzer bir sorunla karşılaşmış biri tarafından çözülebilecektir.

    Bu yasa, Eric S. Raymond'un "Katedral ve Çarşı" adlı kitabında Linus Torvalds onuruna adlandırılmıştır.

    Metcalfe Yasası

    Metcalfe Yasası Wikipedia'da

    Ağ teorisinde, bir sistemin değeri, sistemin kullanıcı sayısının yaklaşık karesi kadar büyür.

    Bu yasa, bir sistem içindeki olası çift bağlantı sayısına dayanır ve Reed Yasası ile yakından ilişkilidir. Odlyzko ve diğerleri, hem Reed Yasası'nın hem de Metcalfe Yasası'nın, ağ etkileri üzerindeki insan bilişinin sınırlarını hesaba katmayarak sistemin değerini abarttığını ileri sürmüşlerdir; bkz. Dunbar Sayısı.

    Ayrıca bkz.:

    Moore Yasası

    Wikipedia'da Moore Yasası

    Entegre bir devredeki transistör sayısı yaklaşık olarak her iki yılda bir iki katına çıkar.

    Yarı iletken ve çip teknolojisinin ne kadar hızlı geliştiğini göstermek için sıklıkla kullanılan Moore'un tahmini, 1970'lerden 2000'lerin sonuna kadar oldukça doğru olduğunu kanıtladı. Daha yakın yıllarda, eğilim kısmen bileşenlerin ne kadar minyatürleştirilebileceğine ilişkin fiziksel sınırlamalar nedeniyle biraz değişti. Ancak, paralelleştirmedeki ilerlemeler ve yarı iletkenlerdeki potansiyel olarak devrim niteliğindeki değişikliklerctor teknolojisi ve kuantum hesaplaması, Moore Yasası'nın önümüzdeki on yıllar boyunca geçerliliğini sürdürebileceği anlamına gelebilir.

    Murphy Yasası / Sod Yasası

    Wikipedia'da Murphy Yasası

    Yanlış gidebilecek her şey yanlış gidecektir.

    Edward A. Murphy, Jr ile ilgili Murphy Yasası, bir şey yanlış gidebilecekse yanlış gideceğini belirtir.

    Bu, geliştiriciler arasında yaygın bir atasözüdür. Bazen geliştirme, test etme veya hatta üretim sırasında beklenmedik şeyler olur. Bu, (İngiliz İngilizcesinde daha yaygın olan) Sod Yasası ile de ilişkilendirilebilir:

    Bir şey yanlış gidebilecekse, en kötü zamanda yanlış gidecektir.

    Bu 'yasalar' genellikle komik bir anlamda kullanılır. Ancak, Doğrulama Önyargısı ve Seçim Önyargısı gibi olgular, insanların bu yasaları belki de aşırı vurgulamasına yol açabilir (işler çalıştığında çoğu zaman fark edilmezler, ancak başarısızlıklar daha belirgindir ve daha fazla tartışmaya yol açar).

    Ayrıca Bakınız:

    Occam'ın Usturası

    Occam'ın Usturası Wikipedia'da

    Varlıklar zorunluluk olmadan çoğaltılmamalıdır.

    Ockham'lı William

    Ockham'ın usturası, olası birkaç çözüm arasında en olası çözümün, en az sayıda kavram ve varsayıma sahip olan çözüm olduğunu söyler. Bu çözüm en basit olanıdır ve yalnızca verilen sorunu çözer, kazara karmaşıklık ve olası olumsuz sonuçlar ortaya çıkarmaz.

    Ayrıca bakınız:

    Örnek:

    Parkinson Yasası

    Vikipedi'de Parkinson Yasası

    İş, tamamlanması için mevcut zamanı dolduracak şekilde genişler.

    Orijinal bağlamında, bu Yasa bürokrasiler üzerine yapılan çalışmalara dayanıyordu. Yazılım geliştirme girişimlerine karamsar bir şekilde uygulanabilir, teoriye göre takımlar son tarihler yaklaşana kadar verimsiz olacak, sonra işi son tarihte tamamlamak için acele edecek ve böylece gerçek son tarihi biraz keyfi hale getirecek.

    Bu yasa Hofstadter Yasası ile birleştirilirse, daha da kötümser bir bakış açısına ulaşılır - iş, tamamlanması için mevcut zamanı dolduracak şekilde genişler ve yine de beklenenden daha uzun sürer.

    Ayrıca bakınız:

    Erken Optimizasyon Etkisi

    WikiWikiWeb'de Erken Optimizasyon

    Erken optimizasyon tüm kötülüklerin köküdür. >
    (Donald Knuth)

    Donald Knuth'un Go To Statements ile Yapılandırılmış Programlama adlı makalesinde şöyle yazmıştır: "Programcılar programlarının kritik olmayan kısımlarının hızı hakkında düşünerek veya endişelenerek muazzam miktarda zaman harcıyorlar ve bu verimlilik girişimleri hata ayıklama ve bakım düşünüldüğünde aslında güçlü bir olumsuz etkiye sahip. Küçük verimlilikleri, diyelim ki %97'sini unutmalıyız: erken optimizasyon tüm kötülüklerin köküdür. Yine de bu kritik %3'lük fırsatlarımızı kaçırmamalıyız."

    Ancak, Erken Optimizasyon (daha az yüklü terimlerle) ihtiyacımız olduğunu bilmeden önce optimizasyon yapmak olarak tanımlanabilir.

    Putt Yasası

    Vikipedi'de Putt Yasası

    Teknoloji, iki tür insan tarafından yönetilir: Yönetmediklerini anlayanlar ve anlamadıklarını yönetenler.

    Putt Yasası'nı genellikle Putt'un Sonucu izler:

    Zamanla her teknik hiyerarşi bir yetkinlik tersine çevirme geliştirir.

    Bu ifadeler, çeşitli seçim kriterleri ve grupların nasıl organize edildiğine ilişkin eğilimler nedeniyle, teknik bir organizasyonun çalışma seviyelerinde bir dizi yetenekli insan ve yönettikleri işin karmaşıklıklarının ve zorluklarının farkında olmayan bir dizi yönetici rolünde insan olacağını öne sürmektedir. Bu, Peter İlkesi veya Dilbert İlkesi gibi olgulardan kaynaklanabilir.

    Ancak, bu tür Yasaların büyük genellemeler olduğu ve bazı organizasyon türlerine uygulanabileceği, diğerlerine uygulanmayabileceği vurgulanmalıdır.

    Ayrıca bkz.:

    Reed Yasası

    Reed Yasası Wikipedia'da

    Büyük ağların, özellikle sosyal ağların faydası, ağın büyüklüğüyle üssel olarak artar.

    Bu yasa, faydanın olası alt grupların sayısına göre ölçeklendiği grafik teorisine dayanır; bu, katılımcı sayısından veya olası çiftler arası bağlantı sayısından daha hızlıdır. Odlyzko ve o

    Diğerleri, Reed Yasası'nın, ağ etkileri üzerindeki insan bilişinin sınırlarını hesaba katmayarak sistemin faydasını abarttığını ileri sürmüşlerdir; bkz. Dunbar Sayısı.

    Ayrıca bakınız:

    Karmaşıklığın Korunumu Yasası (Tesler Yasası)

    Wikipedia'da Karmaşıklığın Korunumu Yasası

    Bu yasa, bir sistemde azaltılamayan belirli miktarda karmaşıklık olduğunu belirtir.

    Bir sistemdeki bazı karmaşıklıklar 'istemsiz'dir. Bu, zayıf yapı, hatalar veya çözülmesi gereken bir sorunun kötü modellenmesinin bir sonucudur. İstenmeyen karmaşıklık azaltılabilir (veya ortadan kaldırılabilir). Ancak, bazı karmaşıklıklar, çözülen problemin doğasında bulunan karmaşıklığın bir sonucu olarak 'içsel'dir. Bu karmaşıklık taşınabilir, ancak ortadan kaldırılamaz.

    Bu yasanın ilginç bir unsuru, tüm sistemi basitleştirerek bile içsel karmaşıklığın azaltılmadığı, daha karmaşık bir şekilde davranması gereken kullanıcıya taşındığı önerisidir.

    Demeter Yasası

    Vikipedi'de Demeter Yasası

    Yabancılarla konuşmayın.

    "En Az Bilgi İlkesi" olarak da bilinen Demeter Yasası, özellikle nesne yönelimli dillerde önemli olan yazılım tasarımı için bir ilkedir.

    Bir yazılım biriminin yalnızca yakın işbirlikçileriyle konuşması gerektiğini belirtir. B nesnesine bir referansı olan A nesnesi yöntemlerini çağırabilir, ancak B nesnesine C nesnesine bir referansı varsa, A Cnin yöntemlerini çağırmamalıdır. Yani, C bir doThing() yöntemine sahipse, A bunu doğrudan çağırmamalıdır; B.getC().doThis().

    Bu ilkeyi takip etmek, değişikliklerin kapsamını sınırlar ve bunları gelecekte daha kolay ve güvenli hale getirir.

    Sızdıran Soyutlamalar Yasası

    Joel on Software'de Sızdıran Soyutlamalar Yasası

    Tüm önemsiz olmayan soyutlamalar, bir dereceye kadar, sızdırır. >
    (Joel Spolsky)

    Bu yasa, genellikle karmaşık sistemlerle çalışmayı basitleştirmek için hesaplamada kullanılan soyutlamaların, belirli durumlarda altta yatan sistemin öğelerini 'sızdıracağını' ve bunun da soyutlamanın beklenmedik şekilde davranmasına neden olacağını belirtir.

    Bir örnek, bir dosyanın yüklenmesi ve içeriğinin okunması olabilir. Dosya sistemi API'leri, kendileri manyetik bir tepsideki (veya bir SSD için flash bellekteki) verileri değiştirmeyle ilgili fiziksel süreçler üzerinde bir soyutlama olan alt düzey çekirdek sistemlerinin bir soyutlamasıdır. Çoğu durumda, bir dosyayı ikili veri akışı gibi ele alma soyutlaması işe yarayacaktır. Ancak, manyetik bir sürücü için, verileri sıralı olarak okumak, rastgele erişimden önemli ölçüde daha hızlı olacaktır (sayfa hatalarının artan yükü nedeniyle), ancak bir SSD sürücüsü için bu yük mevcut olmayacaktır. Bu durumla başa çıkmak için altta yatan ayrıntıların anlaşılması gerekecektir (örneğin, veritabanı dizin dosyaları rastgele erişimin yükünü azaltmak için yapılandırılmıştır), soyutlama, geliştiricinin farkında olması gereken uygulama ayrıntılarını 'sızdırır'.

    Yukarıdaki örnek, daha fazla soyutlama tanıtıldığında daha karmaşık hale gelebilir. Linux işletim sistemi, dosyalara bir ağ üzerinden erişilmesine izin verir ancak yerel olarak 'normal' dosyalar olarak temsil edilir. Bu soyutlama, ağ arızaları varsa 'sızdırır'. Bir geliştirici, ağ gecikmesine ve arızalarına maruz kalabilecekleri gerçeğini dikkate almadan bu dosyaları 'normal' dosyalar olarak ele alırsa, çözümler hatalı olacaktır.

    Yasayı açıklayan makale, soyutlamalara aşırı güvenmenin, altta yatan süreçlerin zayıf anlaşılmasıyla birleştiğinde, aslında bazı durumlarda eldeki sorunla başa çıkmayı daha karmaşık hale getirdiğini öne sürüyor.

    Ayrıca bakınız:

    Gerçek dünya örnekleri:

    • Photoshop Yavaş Başlatma - geçmişte karşılaştığım bir sorun. Photoshop'un başlatılması yavaş olurdu, bazen dakikalar alırdı. Görünüşe göre sorun, başlatma sırasında geçerli varsayılan yazıcı hakkında bazı bilgileri okumasıydı. Ancak, bu yazıcı gerçekten bir ağ yazıcısıysa, bu son derece uzun sürebilir. Bir ağ yazıcısının yerel bir yazıcıya benzer şekilde sisteme sunulmasının soyutlanması, zayıf bağlantı durumlarındaki kullanıcılar için bir soruna neden oldu.

    Önemsizlik Yasası

    Vikipedia'da Önemsizlik Yasası

    Bu yasa, grupların ciddi ve önemli olanlardan ziyade önemsiz veya kozmetik sorunlara çok daha fazla zaman ve dikkat ayıracağını öne sürüyor.

    Yaygın olarak kullanılan kurgusal örnek, nükleer santral planlarını onaylayan bir komitenin, santralin kendisi için çok daha önemli olan tasarım yerine, zamanlarının çoğunu bisiklet kulübesinin yapısını tartışarak geçirmesidir. Çok büyük, cYüksek düzeyde konu uzmanlığı veya hazırlığı olmayan karmaşık konular. Ancak, insanlar değerli girdiler sağladığının görülmesini ister. Bu nedenle, kolayca akıl yürütülebilen ancak mutlaka özel bir öneme sahip olmayan küçük ayrıntılara çok fazla zaman ayırma eğilimi vardır.

    Yukarıdaki kurgusal örnek, önemsiz ayrıntılara zaman harcamak için bir ifade olarak 'Bisiklet Atma' teriminin kullanılmasına yol açtı. İlgili bir terim olan 'Yak Tıraşı', ana göreve yönelik uzun bir önkoşullar zincirinin parçası olan görünüşte alakasız bir aktiviteyi ifade eder.

    Unix Felsefesi

    Wikipedia'da Unix Felsefesi

    Unix Felsefesi, yazılım bileşenlerinin küçük olması ve belirli bir şeyi iyi yapmaya odaklanması gerektiğidir. Bu, büyük, karmaşık, çok amaçlı programlar kullanmak yerine, küçük, basit, iyi tanımlanmış birimleri bir araya getirerek sistemler oluşturmayı kolaylaştırabilir.

    'Mikrohizmet Mimarisi' gibi modern uygulamalar, hizmetlerin küçük, odaklanmış ve belirli bir şey yaptığı, karmaşık davranışların basit yapı taşlarından oluşmasına izin veren bu yasanın bir uygulaması olarak düşünülebilir.

    Spotify Modeli

    Spotify Labs'daki Spotify Modeli

    Spotify Modeli, 'Spotify' tarafından popüler hale getirilen bir ekip ve organizasyon yapısı yaklaşımıdır. Bu modelde, ekipler teknolojiler yerine özellikler etrafında organize edilir.

    Spotify Modeli ayrıca, organizasyon yapılarının diğer bileşenleri olan Kabileler, Loncalar, Bölümler kavramlarını da popüler hale getirir.

    Organizasyon üyeleri, bu grupların gerçek anlamının değiştiğini, geliştiğini ve devam eden bir deney olduğunu açıklamışlardır. Modelin sabit bir model olmaktan ziyade hareket halindeki bir süreç olması, konferanslarda çalışanların yaptığı sunumlara dayalı olabilen yapının farklı yorumlanmasına yol açmaya devam ediyor. Bu, 'anlık görüntülerin' üçüncü taraflarca sabit bir yapı olarak 'yeniden paketlenebileceği' ve modelin dinamik olduğu gerçeğinin kaybolacağı anlamına gelir.

    İki Pizza Kuralı

    Bir ekibi iki pizzayla besleyemiyorsanız, çok büyüktür.

    (Jeff Bezos)

    Bu kural, şirketin büyüklüğünden bağımsız olarak ekiplerin iki pizzayla beslenebilecek kadar küçük olması gerektiğini öne sürer. Jeff Bezos ve Amazon'a atfedilen bu inanç, büyük ekiplerin doğası gereği verimsiz olduğunu öne sürer. Bu, ekip boyutu doğrusal olarak arttıkça, insanlar arasındaki bağlantıların karesel olarak artması ve dolayısıyla koordinasyon ve iletişimin maliyetinin de karesel olarak artması gerçeğiyle desteklenir. Bu koordinasyon maliyeti esasen genel giderse, o zaman daha küçük ekipler tercih edilmelidir.

    İnsanlar arasındaki bağlantı sayısı n = insan sayısı olmak üzere n(n-1)/2 olarak ifade edilebilir.

    Tam grafik; İnsanlar arasındaki bağlantılar

    Wadler Yasası

    wiki.haskell.org'daki Wadler Yasası

    Herhangi bir dil tasarımında, bu listedeki bir özelliği tartışmak için harcanan toplam zaman, konumunun kuvvetine yükseltilmiş iki ile orantılıdır.

    1. Anlambilim
    2. Sözdizimi
    3. Sözcüksel sözdizimi
    4. Yorumların sözcüksel sözdizimi

    (Kısacası, anlambilime harcanan her saat için, yorumların sözdizimine 8 saat harcanacaktır).

    The Law of Triviality ile benzer şekilde, Wadler Yasası, bir dil tasarlarken, dil yapılarına harcanan zaman miktarının, bu özelliklerin önemine kıyasla orantısız bir şekilde yüksek olduğunu belirtir.

    Ayrıca bakınız:

    Wheaton Yasası

    The Link

    The Official Day

    Piç olma.

    Wil Wheaton

    Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory) tarafından ortaya atılan bu basit, öz ve güçlü yasa, profesyonel bir organizasyon içinde uyum ve saygının artmasını hedefler. İş arkadaşlarınızla konuşurken, kod incelemeleri yaparken, diğer bakış açılarına karşı çıkarken, eleştirirken ve genel olarak insanların birbirleriyle olan profesyonel etkileşimlerinin çoğunda uygulanabilir.

    İlkeler

    İlkelerin genellikle tasarımla ilgili kılavuzlar olma olasılığı daha yüksektir.

    Tüm Modeller Yanlıştır (George Box Yasası)

    Tüm Modeller Yanlıştır

    Tüm modeller yanlıştır, ancak bazıları yararlıdır.

    George Box

    Bu ilke, tüm sistem modellerinin hatalı olduğunu, ancak çok hatalı olmadıkları sürece yararlı olabileceklerini öne sürer. Bu ilkenin kökleri istatistiktedir, ancak bilimsel ve hesaplama modelleri için de geçerlidir.

    Çoğu yazılımın temel gereksinimi, bir tür sistemi modellemektir. Modellenen sistemin bir bilgisayar ağı, bir kütüphane, sosyal bağlantıların bir grafiği veya başka bir sistem olması fark etmeksizin, tasarımcının uygun bir düzeyde tasarıma karar vermesi gerekecektir.tail to model. Aşırı ayrıntı çok fazla karmaşıklığa yol açabilir, çok az ayrıntı ise modelin işlevsel olmasını engelleyebilir.

    Ayrıca bakınız:

    Chesterson'ın Çiti

    Vikipedi'de Chesterson'ın Çiti

    Mevcut durumun ardındaki mantık anlaşılana kadar reformlar yapılmamalıdır.

    Bu ilke, teknik borcu kaldırırken yazılım mühendisliğinde önemlidir. Bir programın her satırı başlangıçta bir nedenden ötürü biri tarafından yazılmıştır. Chesterson'ın Çiti, ilk bakışta gereksiz veya yanlış görünse bile, kodu değiştirmeden veya kaldırmadan önce bağlamını ve anlamını tam olarak anlamaya çalışmanız gerektiğini öne sürer.

    Bu ilkenin adı G.K. Chesterson. Bir adam yolun ortasından geçen bir çitle karşılaşır. Belediye başkanına bu işe yaramaz çitin yoluna engel olduğunu söyler ve çitin kaldırılmasını ister. Belediye başkanı çitin neden orada olduğunu sorar. Adam bilmediğini söylediğinde, belediye başkanı, "Eğer amacını bilmiyorsan, kesinlikle kaldırmana izin vermem. Git ve çitin kullanımını öğren, sonra onu yok etmene izin verebilirim." der.

    Ölü Deniz Etkisi

    Bruce F. Webster Üzerindeki Ölü Deniz Etkisi

    "... [Daha yetenekli ve etkili BT mühendisleri, ayrılma - buharlaşma - olasılığı en yüksek olanlardır... [geride kalma eğiliminde olanlar] 'kalıntıdır' - en az yetenekli ve etkili BT mühendisleridir."

    Bruce F. Webster

    "Ölü Deniz Etkisi", herhangi bir organizasyonda mühendislerin becerilerinin/yeteneklerinin/etkinliklerinin genellikle şirketteki zamanlarıyla ters orantılı olduğunu öne sürer.

    Genellikle, yüksek becerili mühendisler başka bir yerde iş bulmayı kolay bulurlar ve bunu yapan ilk kişilerdir. Eski veya zayıf becerilere sahip mühendisler, başka bir yerde iş bulmak zor olduğu için şirkette kalma eğilimindedir. Bu, özellikle şirkette geçirdikleri süre boyunca kademeli olarak maaş artışı elde etmişlerse belirgindir, çünkü başka bir yerde eşdeğer bir ücret almak zor olabilir.

    Dilbert İlkesi

    Vikipedi'de Dilbert İlkesi

    Şirketler, iş akışından çıkarmak için yetersiz çalışanları sistematik olarak yöneticiliğe terfi ettirme eğilimindedir.

    Scott Adams

    Scott Adams (Dilbert çizgi romanının yaratıcısı) tarafından geliştirilen bir yönetim konsepti olan Dilbert İlkesi, Peter İlkesi'nden esinlenmiştir. Dilbert İlkesi uyarınca, hiçbir zaman yetenekli olmamış çalışanlar, verebilecekleri zararı sınırlamak için yöneticiliğe terfi ettirilir. Adams, ilkeyi ilk olarak 1995 tarihli bir Wall Street Journal makalesinde açıklamış ve 1996 tarihli iş kitabı Dilbert İlkesi'nde genişletmiştir.

    Ayrıca Bakınız:

    Pareto İlkesi (80/20 Kuralı)

    Wikipedia'da Pareto İlkesi

    Hayattaki çoğu şey eşit olarak dağıtılmamıştır.

    Pareto İlkesi, bazı durumlarda sonuçların çoğunluğunun girdilerin azlığından geldiğini ileri sürer:

    • Belirli bir yazılım parçasının %80'i, ayrılan toplam zamanın %20'sinde yazılabilir (tersine, kodun en zor %20'si zamanın %80'ini alır)
    • Çabanın %20'si sonucun %80'ini üretir
    • İşin %20'si gelirin %80'ini oluşturur
    • Hataların %20'si çökmelerin %80'ine neden olur
    • Özelliklerin %20'si kullanımın %80'ine neden olur

    Kalite kontrolünün babası olarak kabul edilen Amerikalı-Rumen mühendis Dr. Joseph Juran, 1940'larda Pareto ilkesini kalite sorunlarına uygulamaya başladı.

    Bu ilke ayrıca şu adlarla da bilinir: 80/20 Kuralı, Hayati Azınlığın Yasası ve Faktör Seyrekliği İlkesi.

    Gerçek dünya örnekleri:

    • Microsoft, 2002'de en çok bildirilen hataların ilk %20'sini düzelterek, Windows ve Office'teki ilgili hataların ve çökmelerin %80'inin ortadan kaldırılacağını bildirdi (Referans).

    Shirky İlkesi

    Shirky İlkesi açıklandı

    Kurumlar, çözümü oldukları sorunu korumaya çalışacaklardır. >
    Clay Shirky

    Shirky İlkesi, karmaşık çözümlerin - bir şirket, bir endüstri veya bir teknoloji - çözmekte oldukları soruna o kadar odaklanabileceğini ve istemeden sorunun kendisini devam ettirebileceğini öne sürer. Bu, kasıtlı (bir şirketin bir çözümün sürekli geliştirilmesini haklı çıkaracak yeni nüanslar bulmaya çalışması) veya istemeden (sorunu tamamen çözen veya ortadan kaldıran bir çözümü kabul edememe veya inşa etmeme) olabilir.

    Şununla ilgili:

    -Upton Sinclair'in ünlü dizesi, "Bir adamın bir şeyi anlamasını sağlamak zordur, maaşı onu anlamamasına bağlıysa!"

    • Clay Christensen'in The Innovator's Dilemma

    Ayrıca bakınız:

    Peter İlkesi

    Wikipedia'da Peter İlkesi

    Bir hiyerarşideki insanlar genellikle "yetersizlik seviyelerine" yükselme eğilimindedir.

    Laurence J. Peter

    Laurence J. Peter tarafından geliştirilen bir yönetim kavramı olan Peter İlkesi, işlerinde iyi olan insanların artık başarılı olmadıkları bir seviyeye ("yetersizlik seviyelerine") ulaşana kadar terfi ettirildiğini gözlemler. Bu noktada, daha kıdemli oldukları için, organizasyondan çıkarılma olasılıkları daha düşüktür (çok kötü performans göstermedikleri sürece) ve kendilerini başarılı kılan orijinal becerileri yeni işleri için gereken beceriler olmadığı için, çok az içsel beceriye sahip oldukları bir rolde kalmaya devam edeceklerdir.

    Bu, başlangıçta derinlemesine teknik rollerde başlayan ancak genellikle diğer mühendisleri yönetmeye giden bir kariyer yoluna sahip olan mühendisler için özellikle ilgi çekicidir - bu da temelde farklı bir beceri seti gerektirir.

    Ayrıca Bakınız:

    Sağlamlık İlkesi (Postel Yasası)

    Wikipedia'da Sağlamlık İlkesi

    Yaptığınız işte muhafazakar olun, başkalarından kabul ettiğiniz şeylerde liberal olun.

    Genellikle sunucu uygulama geliştirmede uygulanan bu ilke, başkalarına gönderdiğiniz şeyin mümkün olduğunca asgari ve uyumlu olması gerektiğini, ancak işlenebiliyorsa uyumsuz girdiye izin vermeyi amaçlamanız gerektiğini belirtir.

    Bu ilkenin amacı, niyet hala anlaşılabiliyorsa kötü biçimlendirilmiş girdileri işleyebilecekleri için sağlam sistemler oluşturmaktır. Ancak, özellikle bu tür girdilerin işlenmesi iyi test edilmemişse, kötü biçimlendirilmiş girdileri kabul etmenin potansiyel olarak güvenlik etkileri vardır. Bu etkiler ve diğer sorunlar Eric Allman tarafından The Robustness Principle Reconsidered adlı kitapta açıklanmıştır.

    Zamanla uyumsuz girdiye izin vermek, uygulayıcılar sonunda özelliklerini oluşturmak için bu özgürlüğe güvenecekleri için protokollerin evrimleşme yeteneğini zayıflatabilir.

    Ayrıca Bakınız:

    SOLID

    Bu, şu anlama gelen bir kısaltmadır:

    Bunlar Nesne Yönelimli Programlama'daki temel ilkelerdir. Bu tür tasarım ilkeleri, geliştiricilerin daha sürdürülebilir sistemler oluşturmasına yardımcı olmalıdır.

    Tek Sorumluluk İlkesi

    Vikipedi'de Tek Sorumluluk İlkesi

    Her modül veya sınıfın yalnızca tek bir sorumluluğu olmalıdır.

    'SOLID' ilkelerinin ilki. Bu ilke, modüllerin veya sınıfların yalnızca bir şey yapması gerektiğini öne sürer. Daha pratik terimlerle, bu, bir programın bir özelliğinde yapılan tek bir küçük değişikliğin yalnızca bir bileşende değişiklik gerektirmesi anlamına gelir. Örneğin, bir parolanın karmaşıklık açısından nasıl doğrulandığını değiştirmek, programın yalnızca bir bölümünde değişiklik gerektirmelidir.

    Teorik olarak, bu kodu daha sağlam ve değiştirilmesi daha kolay hale getirmelidir. Değiştirilen bir bileşenin yalnızca tek bir sorumluluğu olduğunu bilmek, bu değişikliği test etmenin daha kolay olması gerektiği anlamına gelir. Önceki örneği kullanarak, parola karmaşıklığı bileşenini değiştirmek yalnızca parola karmaşıklığıyla ilgili özellikleri etkileyebilmelidir. Birçok sorumluluğu olan bir bileşende yapılan bir değişikliğin etkisi hakkında akıl yürütmek çok daha zor olabilir.

    Ayrıca bakınız:

    Açık/Kapalı İlkesi

    Wikipedia'da Açık/Kapalı İlkesi

    Varlıklar genişlemeye açık ve değişikliğe kapalı olmalıdır.

    'SOLID' ilkelerinin ikincisi. Bu ilke, varlıkların (sınıflar, modüller, işlevler vb. olabilir) davranışlarının genişletilebilmesi gerektiğini, ancak mevcut davranışlarının değiştirilememesi gerektiğini belirtir.

    Varsayımsal bir örnek olarak, bir Markdown belgesini HTML'ye dönüştürebilen bir modül hayal edin. Şimdi Markdown spesifikasyonuna matematiksel denklemler için destek ekleyen yeni bir sözdizimi eklendiğini düşünün. Modül, yeni matematiksel sözdizimini uygulamak için genişletmeye açık olmalıdır. Ancak, varSözdizimi uygulamaları (paragraflar, madde işaretleri vb. gibi) değişiklik için kapatılmalıdır. Zaten çalışıyorlar, insanların bunları değiştirmesini istemiyoruz.

    Bu ilke, nesneleri kolayca genişletilebilecek şekilde tasarlayabileceğimiz, ancak var olan davranışları beklenmedik şekillerde değiştirilebilecek nesneleri tasarlamaktan kaçınacağımız nesne yönelimli programlama için özellikle önemlidir.

    Ayrıca bkz.:

    Liskov İkame İlkesi

    Vikipedi'de Liskov İkame İlkesi

    Sistemi bozmadan bir türü bir alt türle değiştirmek mümkün olmalıdır.

    'SOLID' ilkelerinin üçüncüsü. Bu ilke, bir bileşen bir türe dayanıyorsa, sistemin başarısız olması veya bu alt türün ayrıntılarını bilmesi gerekmeden, o türün alt türlerini kullanabilmesi gerektiğini belirtir.

    Örneğin, bir dosyayı temsil eden bir yapıdan bir XML belgesi okuyan bir yöntemimiz olduğunu düşünün. Yöntem bir temel tür olan 'dosya' kullanıyorsa, o zaman 'dosya'dan türetilen her şey işlevde kullanılabilmelidir. 'Dosya' ters aramayı destekliyorsa ve XML ayrıştırıcısı bu işlevi kullanıyorsa, ancak türetilen tür olan 'ağ dosyası' ters arama denendiğinde başarısız oluyorsa, o zaman 'ağ dosyası' ilkeyi ihlal ediyor olur.

    Bu ilke, nesne yönelimli programlama için özellikle önemlidir; burada tür hiyerarşileri, bir sistemin kullanıcılarını karıştırmamak için dikkatlice modellenmelidir.

    Ayrıca bakınız:

    Arayüz Ayrım İlkesi

    Wikipedia'da Arayüz Ayrım İlkesi

    Hiçbir istemci kullanmadığı yöntemlere bağımlı olmaya zorlanmamalıdır.

    'SOLID' ilkelerinin dördüncüsü. Bu ilke, bir bileşenin tüketicilerinin aslında kullanmadığı bileşenin işlevlerine bağımlı olmaması gerektiğini belirtir.

    Örneğin, bir dosyayı temsil eden bir yapıdan bir XML belgesi okuyan bir yöntemimiz olduğunu düşünün. Yalnızca baytları okuması, dosyada ileri veya geri hareket etmesi gerekir. Dosya yapısının ilgisiz bir özelliği değiştiği için (örneğin dosya güvenliğini temsil etmek için kullanılan izin modelinde bir güncelleme) bu yöntemin güncellenmesi gerekiyorsa, ilke geçersiz kılınmıştır. Dosyanın bir 'arama akışı' arayüzü uygulaması ve XML okuyucusunun bunu kullanması daha iyi olurdu.

    Bu ilke, arayüzlerin, hiyerarşilerin ve soyut tiplerin farklı bileşenler arasındaki bağlantıyı en aza indirmek için kullanıldığı nesne yönelimli programlama için özellikle önemlidir. Ördek yazma, açık arayüzleri ortadan kaldırarak bu ilkeyi uygulayan bir metodolojidir.

    Ayrıca bakınız:

    Bağımlılık Ters Çevirme İlkesi

    Vikipedi'de Bağımlılık Ters Çevirme İlkesi

    Üst düzey modüller, alt düzey uygulamalara bağımlı olmamalıdır.

    'SOLID' prensiplerinin beşincisi. Bu prensip, daha üst düzey orkestralama bileşenlerinin bağımlılıklarının ayrıntılarını bilmesi gerekmediğini belirtir.

    Örneğin, bir web sitesinden meta verileri okuyan bir programımız olduğunu düşünün. Ana bileşenin web sayfası içeriğini indirmek için bir bileşen hakkında bilgi sahibi olması gerektiğini, ardından meta verileri okuyabilen bir bileşen hakkında bilgi sahibi olması gerektiğini varsayarız. Bağımlılık tersine çevirmeyi hesaba katarsak, ana bileşen yalnızca bayt verilerini alabilen soyut bir bileşene ve ardından bir bayt akışından meta verileri okuyabilen soyut bir bileşene bağlı olacaktır. Ana bileşen TCP/IP, HTTP, HTML vb. hakkında bilgi sahibi olmayacaktır.

    Bu prensip karmaşıktır, çünkü bir sistemin beklenen bağımlılıklarını 'tersine çeviriyor' gibi görünebilir (bu nedenle adı). Uygulamada, bu aynı zamanda ayrı bir düzenleme bileşeninin soyut türlerin doğru uygulamalarının kullanılmasını sağlaması gerektiği anlamına gelir (örneğin, önceki örnekte, bir şey meta veri okuyucu bileşenine bir HTTP dosya indiricisi ve HTML meta etiket okuyucusu sağlamaya devam etmelidir). Bu daha sonra Kontrolün Tersine Çevrilmesi ve Bağımlılık Enjeksiyonu gibi kalıplara değinir.

    Ayrıca bkz.:

    DRY İlkesi

    Vikipedi'de DRY İlkesi

    Her bilgi parçasının bir sistem içinde tek, belirsiz olmayan, yetkili bir temsili olmalıdır.

    DRY, Don't Repeat Yourself ifadesinin kısaltmasıdır. Bu ilke, geliştiricilerin kod tekrarını azaltmalarına ve bilgileri tek bir yerde tutmalarına yardımcı olmayı amaçlamaktadır ve 1999 yılında Andrew Hunt ve Dave Thomas tarafından Pragmatik Geliştirici adlı kitapta alıntılanmıştır.tic_Programmer)

    DRY'nin tersi WET (Write Everything Twice or We Enjoy Typing) olurdu.

    Uygulamada, aynı bilgi parçası iki (veya daha fazla) farklı yerdeyse, bunları tek bir yerde birleştirmek ve istediğiniz/ihtiyaç duyduğunuz her yerde yeniden kullanmak için DRY'yi kullanabilirsiniz.

    Ayrıca bkz.:

    KISS ilkesi

    Wikipedia'da KISS

    Basit tut, aptal

    KISS ilkesi, çoğu sistemin karmaşık hale getirilmek yerine basit tutulduğunda daha iyi çalıştığını belirtir; bu nedenle, basitlik tasarımda temel bir hedef olmalı ve gereksiz karmaşıklıktan kaçınılmalıdır. 1960 yılında ABD Donanması'nda ortaya çıkan bu ifade, uçak mühendisi Kelly Johnson ile ilişkilendirilmiştir.

    Bu ilke, Johnson'ın bir tasarım mühendisleri ekibine bir avuç alet vermesiyle en iyi şekilde örneklendirilebilir. Bu durumda, tasarladıkları jet uçağının savaş koşullarında yalnızca bu aletlerle sahadaki ortalama bir tamirci tarafından tamir edilebilir olması gerekir. Dolayısıyla, "aptal" ifadesi, şeylerin kırılma şekli ile onları tamir etmek için mevcut aletlerin karmaşıklığı arasındaki ilişkiyi ifade eder, mühendislerin kendi yetenekleriyle değil.

    Ayrıca bakınız:

    YAGNI

    YAGNI Wikipedia'da

    Bu, You Ain't Gonna Need It ifadesinin kısaltmasıdır.

    Her zaman gerçekten ihtiyaç duyduğunuzda bir şeyleri uygulayın, asla sadece ihtiyaç duyacağınızı öngördüğünüzde uygulamayın. >
    (Ron Jeffries) (XP'nin kurucu ortağı ve "Extreme Programming Installed" kitabının yazarı)

    Bu Extreme Programming (XP) ilkesi, geliştiricilerin yalnızca acil gereksinimler için gereken işlevleri uygulamaları ve daha sonra ihtiyaç duyulabilecek işlevleri uygulayarak geleceği tahmin etme girişimlerinden kaçınmaları gerektiğini önermektedir.

    Bu ilkeye bağlı kalmak, kod tabanındaki kullanılmayan kod miktarını azaltmalı ve hiçbir değer getirmeyen işlevlere zaman ve emek harcanmasını önlemelidir.

    Ayrıca bakınız:

    Dağıtık Bilişimin Yanılgıları

    Vikipedi'de Dağıtık Bilişimin Yanılgıları

    Ayrıca Ağ Bilişiminin Yanılgıları olarak da bilinen Yanılgılar, yazılım geliştirmede başarısızlıklara yol açabilen dağıtık bilişim hakkındaki varsayımların (veya inançların) bir listesidir. Varsayımlar şunlardır:

    • Ağ güvenilirdir
    • Gecikme sıfırdır
    • Bant genişliği sonsuzdur
    • Ağ güvenlidir
    • Topoloji değişmez
    • Tek bir yönetici vardır
    • Taşıma maliyeti sıfırdır
    • Ağ homojendir

    İlk dört madde Bill Joy ve Tom Lyon tarafından 1991 civarında listelenmiş ve ilk olarak James Gosling tarafından "Ağ Bilgisayarcılığının Yanılgıları" olarak sınıflandırılmıştır. L. Peter Deutsch 5., 6. ve 7. yanılgıları eklemiştir. 90'ların sonlarında Gosling 8. yanılgıyı eklemiştir.

    Grup, o sırada Sun Microsystems içinde olup bitenlerden ilham aldı.

    Bu yanılgılar, dayanıklı kod tasarlarken dikkatlice düşünülmelidir; bu yanılgılardan herhangi birinin dağıtılmış sistemlerin gerçekleri ve karmaşıklıklarıyla başa çıkamayan hatalı mantığa yol açabileceğini varsayarsak.

    Ayrıca bakınız:

    Okuma Listesi

    Bu kavramları ilginç bulduysanız, aşağıdaki kitaplardan hoşlanabilirsiniz.

    Çevrimiçi Kaynaklar

    Bazı yararlı kaynaklar ve okumalar.

    PDF eKitabı

    Proje PDF eKitabı olarak mevcuttur, en son PDF eKitabını bu bağlantıdan indirin veya daha eski sürümler için sürüm sayfasını kontrol edin.

    Yeni bir sürüm etiketi itildiğinde eKitabın yeni bir sürümü otomatik olarak oluşturulur.

    Kaydol ya da oturum aç

    Yorumlar