🐵 🍻 👨🏽‍🔧 Hukum pemrograman 💕 👃🏻 🧒🏽

Hukum, teori, prinsip, dan pola yang bermanfaat bagi pengembang

pengantar

Terjemahan repositori github.com/dwmkerr/hacker-laws

Dalam diskusi yang terkait dengan pengembangan perangkat lunak, orang sering berbicara tentang undang-undang yang berbeda. Repositori ini menyimpan tautan dan deskripsi dari beberapa yang paling terkenal di antaranya.

Ini berisi penjelasan dari beberapa hukum, prinsip dan hukum, tetapi tidak ada agitasi yang menguntungkan mereka. Untuk menggunakannya atau tidak selalu menjadi titik perdebatan, dan itu semua tergantung pada apa yang sedang Anda kerjakan.

Hukum

Hukum Amdahl

Hukum Amdahl adalah formula yang menunjukkan potensi untuk mempercepat tugas komputasi yang dapat dicapai dengan peningkatan jumlah sumber daya sistem. Ini biasanya digunakan dalam komputasi paralel, dan dapat memprediksi manfaat nyata dari peningkatan jumlah prosesor, dengan mempertimbangkan keterbatasan paralelisme program.

Kami memberi contoh. Jika program terdiri dari dua bagian - bagian A, yang harus dijalankan pada satu prosesor, dan bagian B, yang dapat diparalelkan, jelas bahwa keuntungan menambahkan beberapa prosesor ke sistem yang menjalankan program terbatas. Secara potensial, ini dapat sangat mempercepat bagian B - tetapi kecepatan bagian A tidak akan berubah.

Diagram berikut menunjukkan contoh-contoh peningkatan kecepatan potensial:

Seperti yang Anda lihat, bahkan jika 50% dari program dapat diparalelkan, manfaat penambahan lebih dari 10 prosesor terpisah akan diabaikan. Jika program dapat diparalelkan dengan 95%, perbaikan akan terlihat bahkan setelah menambahkan ribuan prosesor.

Dengan Hukum Moore yang melambat dan prosesor yang semakin cepat, paralelisasi menjadi kunci untuk meningkatkan efisiensi. Pemrograman grafik adalah contoh yang bagus - pemrograman modern berbasis shader memungkinkan Anda untuk menggambar fragmen gambar secara paralel, sehingga dalam kartu grafis modern Anda dapat menemukan ribuan inti prosesor (GPU atau modul shader).

Teori Windows Rusak

Teori jendela pecah mengklaim bahwa tanda-tanda nyata kejahatan (atau kurangnya kepedulian terhadap lingkungan) memerlukan peningkatan jumlah dan tingkat keparahan kejahatan (dan semakin memburuknya lingkungan).

Teori ini telah diterapkan pada pengembangan perangkat lunak, menunjukkan bahwa kualitas kode yang buruk (atau yang disebut " utang teknis ") dapat menyebabkan perasaan bahwa semua upaya untuk meningkatkan kualitas akan diabaikan atau diremehkan, yang akan menyebabkan munculnya kode buruk baru. Efek ini berkembang dalam kaskade, itulah sebabnya kualitas menurun dari waktu ke waktu.

Hukum Brooks

Menambahkan sumber daya manusia tambahan ke proyek yang terlambat bahkan menunda produksinya.

Hukum Brooks mengatakan bahwa dalam banyak kasus, upaya untuk mempercepat pelepasan proyek yang sudah terlambat dengan menambahkan orang-orang tambahan menyebabkan fakta bahwa proyek tersebut dirilis lebih lambat dari yang seharusnya. Namun, Brooks menekankan bahwa ini adalah penyederhanaan masalah yang berlebihan. Dia beralasan sebagai berikut: mengingat biaya waktu yang diperlukan untuk komisi sumber daya baru, dan komunikasi orang di antara mereka sendiri, dalam jangka pendek tingkat pengembangan proyek turun. Selain itu, banyak tugas mungkin tidak dapat dipisahkan, yaitu, mereka tidak dapat dengan mudah didistribusikan antar sumber daya, yang jumlahnya telah meningkat, sehingga potensi peningkatan kecepatan tidak begitu signifikan.

Pepatah umum "sembilan wanita tidak bisa melahirkan bayi dalam satu bulan" mengacu pada hukum Brooks, khususnya karena beberapa jenis pekerjaan tidak dapat dibagi atau diparalelkan.

Ini adalah tema utama buku Mythical Man-Month.

Hukum Conway

Hukum Conway mengatakan bahwa batasan teknis dari sistem yang dirancang akan mencerminkan struktur organisasi. Ia sering diingat ketika berusaha meningkatkan organisasi. Hukum mengatakan bahwa jika suatu organisasi disusun menjadi banyak modul kecil yang tidak terkait, maka program yang dibuatnya akan sama. Jika organisasi akan dibangun berdasarkan vertikal, berdasarkan fitur atau layanan tertentu, maka perangkat lunaknya akan mencerminkan fakta ini.

Hukum Cunningham

Cara terbaik untuk menemukan jawaban yang benar di Internet adalah bukan dengan mengajukan pertanyaan, tetapi dengan memposting jawaban yang sengaja salah.

Stephen McGeady mengatakan bahwa pada awal 1980-an, Ward Cunningham memberinya nasihat: "Cara terbaik untuk menemukan jawaban yang benar di Internet bukan dengan mengajukan pertanyaan, tetapi dengan mengirim jawaban yang sengaja salah." McGeady menyebutnya "Hukum Cunningham," meskipun Cunningham sendiri membantahnya dan mengatakan bahwa ia "dikutip secara salah." Meskipun frasa awalnya merujuk pada komunikasi di Usenet, undang-undang tersebut sejak saat itu digunakan untuk menggambarkan pekerjaan dan komunitas lain (Wikipedia, Reddit, Twitter, Facebook).

Nomor Dunbar

Jumlah Dunbar adalah batas jumlah ikatan sosial permanen yang dapat dipertahankan seseorang. Ini mengacu pada hubungan yang melibatkan pengetahuan tentang ciri-ciri khas individu tertentu, hubungan yang dengannya harus dipertahankan, karakternya, serta status sosialnya, dan hubungannya dengan orang lain.

Jumlah pasti hubungan tersebut tidak diketahui. Dunbar sendiri menyarankan agar seseorang dapat dengan nyaman mendukung tidak lebih dari 150 koneksi semacam itu. Dia menggambarkannya dalam konteks yang lebih sosial: "Jumlah orang yang Anda tidak ragu untuk bergabung tanpa undangan untuk minum bersama jika Anda secara tidak sengaja bertemu dengan mereka di bar." Biasanya, perkiraan angka ini bervariasi dari 100 hingga 250.

Seperti hubungan yang stabil antara orang-orang, mempertahankan hubungan programmer dengan kode membutuhkan banyak usaha. Ketika dihadapkan dengan proyek-proyek besar dan kompleks atau dengan kepemilikan banyak yang kecil, kami mengandalkan perjanjian, kebijakan, dan prosedur tertentu. Penting untuk mempertimbangkan nomor Dunbar tidak hanya ketika meningkatkan jumlah karyawan, tetapi juga ketika menentukan skala tim atau saat ketika sistem harus memperoleh alat bantu untuk pemodelan dan otomatisasi logistik. Dalam konteks teknik, ini adalah jumlah proyek (atau kompleksitas yang dinormalisasi dari satu proyek) yang Anda yakin akan dimasukkan dalam kelompok dukungan kode.

Hukum Goll

Sistem kompleks kerja tentu saja berasal dari sistem sederhana yang berfungsi. Sistem rumit yang dirancang dari bawah ke atas tidak pernah berfungsi, dan tidak mungkin untuk memperbaikinya sehingga berfungsi. Anda harus memulai dari awal dengan sistem kerja yang sederhana.

Hukum Goll menunjukkan bahwa upaya untuk mengembangkan sistem yang sangat kompleks kemungkinan besar akan gagal. Sistem dengan kompleksitas tinggi jarang dibuat dalam satu kesempatan - mereka berevolusi dari yang lebih sederhana.

Contoh klasik adalah jaringan di seluruh dunia. Dalam kondisi saat ini, ini adalah sistem dengan kompleksitas tinggi. Namun, pada awalnya diidentifikasi sebagai cara sederhana untuk bertukar konten antar institusi. Dia sangat berhasil mengatasi tujuan-tujuan ini dan berevolusi, mengubah dari waktu ke waktu menjadi tujuan yang lebih kompleks.

Hukum Goodhart

Setiap pola statistik yang diamati cenderung runtuh segera setelah tekanan diberikan untuk mengendalikannya.

Ini juga sering dirumuskan sebagai:

Ketika ukuran menjadi tujuan, itu tidak lagi menjadi ukuran yang baik.
Strain Marilyn

Undang-undang menyatakan bahwa optimalisasi berdasarkan langkah-langkah tertentu dapat menyebabkan depresiasi langkah-langkah ini. Pengukuran terlalu selektif (KPI) diterapkan secara membabi buta pada proses yang mengakibatkan distorsi. Orang-orang berusaha untuk mengoptimalkan proses secara lokal, “menipu” sistem untuk memenuhi metrik tertentu, alih-alih memperhatikan hasil global dari tindakan mereka.

Contoh:

Tes tanpa klaim memenuhi harapan untuk cakupan kode, meskipun fakta bahwa metrik tersebut dibuat sehingga program diuji dengan baik.
Menilai efektivitas pengembang berdasarkan jumlah baris yang berkontribusi pada proyek menyebabkan pembengkakan kode yang tidak dapat dibenarkan.

Hanlon Razor

Jangan pernah mengaitkan kedengkian dengan apa yang sepenuhnya dijelaskan oleh kebodohan.

Prinsip tersebut menyatakan bahwa tindakan yang mengarah pada hasil negatif dapat dilakukan bukan dengan niat buruk. Hasil negatif lebih mungkin karena fakta bahwa tindakan ini dan konsekuensinya tidak dipahami dengan baik.

Hukum Hofstader

Selalu dibutuhkan lebih banyak waktu untuk menyelesaikan tugas daripada yang Anda harapkan, bahkan jika Anda memperhitungkan hukum Hofstader.

Anda dapat menemukan referensi untuk undang-undang ini ketika berhadapan dengan perkiraan waktu yang dihabiskan untuk suatu proyek. Di bidang pengembangan perangkat lunak, tampaknya disangkal bahwa kita tidak dapat memperkirakan waktu yang dibutuhkan untuk menyelesaikan proyek secara akurat.

Kutipan dari buku " Gödel, Escher, Bach: This Endless Garland ."

Hukum palu

Peningkatan setara dengan kehancuran.

Undang-undang ini menyatakan bahwa peningkatan satu bagian sistem mengarah pada penghancuran bagian lain, atau menyembunyikan jenis perusakan lainnya, yang umumnya mengarah pada degradasi sistem dibandingkan dengan kondisi saat ini.

Misalnya, mengurangi waktu respons di bagian tertentu dari sistem dapat menyebabkan peningkatan throughput, dan, sebagai akibatnya, ke masalah dengan kapasitas di suatu tempat di jalur aliran permintaan, yang dapat mempengaruhi subsistem lain.

Siklus hype dan hukum Amar

Kita cenderung melebih-lebihkan dampak teknologi dalam jangka pendek dan meremehkannya dalam jangka panjang.

Siklus hype adalah visualisasi dari antusiasme dan pengembangan teknologi dari waktu ke waktu, awalnya dibangun oleh Gartner. Paling baik digambarkan oleh grafik:

Setelah munculnya teknologi, popularitasnya mencapai puncak harapan yang membengkak, kemudian menyelam ke dalam depresi, naik di sepanjang lereng pencerahan dan mencapai puncak produktivitas.

Singkatnya, siklus berpendapat bahwa sumber antusiasme biasanya muncul di sekitar teknologi baru dan konsekuensi potensial. Tim seringkali cepat kecanduan teknologi ini dan sering kecewa dengan hasilnya. Mungkin ini karena teknologinya belum dikembangkan secara memadai, atau metode penerapannya belum dipikirkan. Setelah waktu tertentu, kemampuan teknologi meningkat, dan jumlah aplikasi praktis tumbuh, setelah itu tim akhirnya bisa menjadi produktif.

Hukum Hiram

Saat Anda mencapai jumlah pengguna API yang cukup, tidak masalah fitur apa yang Anda janjikan kepada semua orang: untuk fitur apa pun yang mungkin dari perilaku sistem Anda, akan ada pengguna yang bergantung padanya.

Hukum Hiram mendalilkan bahwa jika API Anda memiliki cukup pengguna, akan ada pengguna yang bergantung padanya untuk setiap perilaku yang mungkin dari sistem Anda (bahkan tidak dijelaskan dalam kontrak publik). Contoh sepele adalah fitur API non-fungsional, seperti waktu respons. Contoh yang lebih halus adalah konsumen yang mengandalkan penentuan jenis kesalahan dengan menerapkan fungsi regex ke deskripsinya. Bahkan jika kontrak publik tidak mengatakan apa-apa tentang konten pesan, dan menyiratkan bahwa pengguna harus menggunakan kode kesalahan, beberapa dari mereka mungkin memutuskan untuk menggunakan pesan, dan mengubah pesan akan merusak API untuk pengguna ini.

Hukum Kernigan

Kode debug dua kali lebih sulit daripada menulisnya. Karena itu, jika Anda menulis kode hingga batas kemampuan mental Anda, Anda, menurut definisi, tidak akan memiliki kecerdasan yang cukup untuk melakukan debug.

Hukum Kernigan dinamai Brian Kernigan dan diambil dari sebuah buku yang ditulis olehnya dan Plauger: "Elemen gaya pemrograman."

Semua orang tahu bahwa kode debug dua kali lebih sulit daripada menulisnya. Karena itu, jika Anda melakukan semua upaya mental saat menulis kode, bagaimana Anda akan men-debug-nya?

Meskipun undang-undang itu hiperbola, ia mengklaim bahwa lebih baik menggunakan kode sederhana daripada kompleks, karena men-debug setiap masalah yang muncul dalam kode kompleks mungkin terlalu mahal atau bahkan mustahil.

Hukum Metcalf

Dalam teori jaringan, kegunaan jaringan tumbuh kira-kira sebagai kuadrat dari jumlah penggunanya.

Hukum didasarkan pada jumlah kemungkinan koneksi berpasangan dalam sistem, dan terkait erat dengan hukum Reed. Odlyzhko dan yang lain berpendapat bahwa hukum Reed dan Metcalf melebih-lebihkan nilai sistem, tidak memperhitungkan keterbatasan pemahaman manusia tentang jaringan; lihat nomor Dunbar.

Hukum Moore

Jumlah transistor yang ditempatkan pada chip sirkuit terintegrasi berlipat ganda kira-kira setiap 24 bulan.

Prediksi Moore , yang sering digunakan untuk menunjukkan kecepatan luar biasa meningkatkan teknologi manufaktur semikonduktor dan chip, secara mengejutkan akurat, dan bekerja dari tahun 1970 hingga akhir 2000-an. Dalam beberapa tahun terakhir, tren telah berubah sedikit, khususnya, karena keterbatasan fisik dari miniaturisasi komponen. Namun, kemajuan paralelisasi dan perubahan revolusioner yang berpotensi dalam teknologi semikonduktor dan komputer kuantum dapat berarti bahwa hukum Moore mungkin tetap berlaku untuk beberapa dekade mendatang.

hukum Murphy

Segala sesuatu yang bisa salah akan salah.

Hukum Murphy, ditulis oleh Edward A. Murphy, mendalilkan bahwa apa pun yang bisa salah pasti akan salah.

Ungkapan ini sering digunakan oleh pengembang. Terkadang hal-hal tak terduga terjadi selama pengembangan, pengujian, atau bahkan dalam produksi. Ini dapat dikaitkan dengan hukum kekejaman, yang lebih sering digunakan di Inggris [pada kenyataannya, itu juga dikenal di Rusia / kira-kira. diterjemahkan.]:

Jika ada yang tidak beres, itu akan terjadi, dan pada saat yang paling buruk.

Biasanya "hukum" ini digunakan dalam arti humor. Namun, fenomena seperti bias konfirmasi dan kesalahan pemilihan sistematis dapat menyebabkan orang terlalu tertarik pada undang-undang ini (dalam kebanyakan kasus, ketika semuanya berjalan sebagaimana mestinya, tidak ada yang memperhatikan hal ini, tetapi kegagalan lebih terlihat dan menarik lebih banyak diskusi).

pisau cukur Occam

Anda seharusnya tidak melipatgandakan hal-hal yang tidak perlu.

Pisau cukur Occam mengklaim bahwa dari beberapa solusi yang mungkin, solusi yang mengandung paling sedikit konsep dan asumsi akan menjadi yang paling mungkin. Solusi ini akan menjadi yang paling sederhana dan hanya akan menyelesaikan masalah yang diberikan tanpa menimbulkan kesulitan acak dan kemungkinan konsekuensi negatif.

Hukum Parkinson

Pekerjaan mengisi waktu yang diberikan padanya.

Dalam konteks aslinya, hukum didasarkan pada studi tentang birokrasi. Secara pesimis, ini dapat diterapkan pada pengembangan perangkat lunak, dengan anggapan bahwa tim akan bekerja secara tidak efisien sampai batas waktu proyek mulai mendekati, dan kemudian akan terburu-buru untuk mengirimkannya tepat waktu, yang membuat tanggal akhir spesifik agak sewenang-wenang.

Jika Anda menggabungkannya dengan hukum Hofstader, Anda mendapatkan pandangan yang bahkan lebih pesimistis: pekerjaan akan meluas sampai mengisi semua waktu yang diperlukan untuk menyelesaikannya, dan masih membutuhkan lebih dari yang diharapkan.

Efek dari optimasi prematur

Optimalisasi prematur adalah akar dari semua kejahatan.

Dalam karya Donald Knuth “Structured Programming with GoTo,” ia menulis: “Programmer menghabiskan banyak waktu untuk berpikir dan khawatir tentang kecepatan eksekusi bagian-bagian yang tidak penting dari program, dan mencoba membuatnya lebih efektif memiliki efek negatif yang kuat jika Anda berpikir tentang debugging dan mendukungnya. Kita perlu melupakan efisiensi yang tidak penting dari 97% waktu: optimasi prematur adalah akar dari semua kejahatan. Namun, dalam 3% kasus kritis kritis, kita seharusnya tidak kehilangan kesempatan. ”

Namun, pengoptimalan prematur juga dapat digambarkan sebagai upaya untuk mengoptimalkan sesuatu sebelum kita memahami apa yang perlu kita lakukan.

Hukum patt

Sektor teknologi didominasi oleh dua jenis orang: mereka yang mengerti bahwa mereka tidak mengendalikan, dan mereka yang mengendalikan apa yang tidak mereka mengerti.

Untuk hukum Patta harus sering menyimpulkan Patta:

Dalam hierarki teknis apa pun, inversi kompetensi dikembangkan seiring waktu.

Pernyataan-pernyataan ini menunjukkan bahwa karena kriteria seleksi yang berbeda dan tren organisasi kelompok, akan selalu ada sejumlah orang berpengalaman di tingkat kerja organisasi teknis, dan akan selalu ada orang di tingkat manajemen yang tidak tahu tentang kompleksitas dan masalah pekerjaan yang mereka kelola.

Namun, perlu ditekankan bahwa undang-undang tersebut adalah generalisasi yang sangat kasar, dan mungkin berlaku untuk beberapa jenis organisasi, dan tidak berlaku untuk yang lain.

Hukum Reed

Utilitas jaringan besar, terutama jejaring sosial, tumbuh secara eksponensial dengan pertumbuhan ukuran jaringan.

Ini hukum berdasarkan teori grafik, di mana skala utilitas sebagai jumlah kemungkinan subkelompok, tumbuh lebih cepat dari jumlah peserta atau koneksi berpasangan mungkin. Odlyzhko dan yang lainnya berpendapat bahwa hukum Reed dan Metcalf melebih-lebihkan nilai sistem, tidak memperhitungkan keterbatasan kemampuan manusia untuk memahami jaringan; lihat nomor Dunbar.

Hukum kekekalan kompleksitas (Hukum Tesler)

Undang-undang menyatakan bahwa sistem memiliki kompleksitas tertentu, yang tidak dapat dikurangi.

Bagian dari kompleksitas sistem dapat terjadi secara tidak sengaja. Ini adalah hasil dari struktur yang buruk, kesalahan atau pemodelan masalah yang tidak berhasil diselesaikan. Kompleksitas yang tidak disengaja dapat dikurangi atau dihilangkan. Namun, beberapa jenis kompleksitas merupakan konsekuensi integral dari kompleksitas tugas itu sendiri. Kompleksitas ini dapat dipindahkan, tetapi tidak dihilangkan.

Salah satu elemen yang menarik dari undang-undang ini adalah asumsi bahwa meskipun dengan penyederhanaan seluruh sistem, kompleksitas internalnya tidak berkurang, tetapi masuk ke pengguna, yang memiliki waktu lebih sulit berperilaku.

Hukum Abstraksi Yang Mengalir

Semua abstraksi non-trivial tunduk pada batas tertentu.

Undang-undang ini menyatakan bahwa abstraksi, yang biasanya digunakan dalam TI untuk menyederhanakan pekerjaan dengan sistem yang kompleks, dalam situasi tertentu bocor, membiarkan elemen-elemen sistem yang mendasari mereka mengalir ke atas, yang mengapa abstraksi mulai berperilaku tak terduga.

Contohnya adalah mengunduh file dan membaca isinya. API sistem file adalah abstraksi dari sistem kernel level rendah, yang juga merupakan abstraksi dari proses fisik yang terkait dengan perubahan data pada pelat magnetik (atau dalam memori flash SSD). Dalam kebanyakan kasus, abstraksi yang mewakili file sebagai aliran data biner akan berfungsi. Namun, pembacaan berurutan data dari disk magnetik akan lebih cepat daripada akses acak ke mereka, tetapi SSD tidak akan memiliki masalah seperti itu. Anda perlu memahami detail yang ada di kedalaman untuk menangani kasus-kasus ini (misalnya, file database indeks disusun untuk mengurangi waktu akses acak), ketika abstraksi memberikan kebocoran detail implementasi yang perlu diketahui pengembang.

Contoh di atas mungkin menjadi lebih rumit ketika menambahkan abstraksi baru. Linux memungkinkan Anda untuk mengakses file melalui jaringan, tetapi mereka dapat dilihat secara lokal sebagai "normal." Abstraksi ini akan bocor jika terjadi masalah jaringan. Jika pengembang memperlakukan mereka sebagai "normal", tidak memperhitungkan fakta bahwa mereka rentan terhadap masalah dengan keterlambatan dan kegagalan jaringan, solusinya akan menjadi suboptimal dan buggy.

Dalam artikel yang menggambarkan undang-undang tersebut, diasumsikan bahwa kecanduan berlebihan terhadap abstraksi, ditambah dengan pemahaman yang buruk tentang proses yang mendasarinya, dalam beberapa kasus bahkan mempersulit proses penyelesaian masalah.

Contoh: Startup Photoshop yang lambat. Saya mengalami masalah inidi masa lalu. Photoshop dimulai dengan sangat lambat, kadang-kadang butuh beberapa menit. Rupanya, masalahnya adalah saat startup membaca informasi tentang printer saat ini secara default. Tetapi jika printer ini adalah printer jaringan, itu bisa memakan waktu yang sangat lama. Abstraksi, yang menurutnya printer jaringan mirip dengan yang lokal, menyebabkan masalah pengguna dalam hal komunikasi yang buruk.

Hukum hal-hal sepele

Undang-undang menyatakan bahwa kelompok menghabiskan lebih banyak waktu dan perhatian untuk membahas masalah kosmetik atau sepele daripada yang serius dan ekstensif.

Biasanya, contohnya adalah pekerjaan komite yang menyetujui rencana untuk pembangkit listrik tenaga nuklir, yang sebagian besar waktu membahas struktur parkir sepeda, daripada masalah yang lebih penting dari desain stasiun itu sendiri. Mungkin sulit untuk memberikan kontribusi yang berharga pada diskusi topik yang sangat besar dan kompleks tanpa memiliki pengetahuan yang luas tentang subjek ini. Namun, orang ingin diperhatikan karena membuat komentar yang berharga. Dari sini muncul kecenderungan untuk berkonsentrasi pada detail kecil, yang mudah untuk dibicarakan, tetapi yang belum tentu penting untuk proyek secara keseluruhan.

Contoh fiktif yang diberikan di atas memunculkan istilah "efek gudang sepeda", yang menggambarkan hilangnya waktu dalam membahas rincian sepele. Ada istilah yang sama, "potong rambut yak," yang menggambarkan kegiatan yang tampaknya tidak terkait yang merupakan bagian dari rantai panjang langkah persiapan yang diperlukan.

Filsafat Unix

Filosofi Unix adalah bahwa komponen perangkat lunak harus kecil dan fokus melakukan satu tugas khusus dengan baik. Ini memfasilitasi proses membangun sistem dengan merekrut dari modul-modul kecil, sederhana dan terdefinisi dengan baik, daripada menggunakan program-program besar, kompleks, dan multifungsi.

Praktik modern, seperti "arsitektur layanan mikro", dapat dianggap sebagai penerapan filosofi ini - layanannya kecil, berfokus pada satu tugas khusus, yang memungkinkan Anda membuat perilaku kompleks dari blok bangunan sederhana.

Model Spotify

Pendekatan terhadap struktur tim dan organisasi yang dipromosikan Spotify . Dalam model ini, tim disusun berdasarkan fungsi program, bukan teknologi.

Model ini juga mempromosikan konsep suku, guild, cabang - komponen lain dari struktur organisasi.

Hukum Wadler

Dalam mendesain bahasa apa pun, total waktu yang dihabiskan untuk membahas fitur dari daftar ini sebanding dengan kekuatan jumlah posisi fitur ini dalam daftar.
0. Semantik.
1. Sintaksnya.
2. Sintaks leksikal.
3. Sintaksis leksikal dari komentar.

Artinya, untuk setiap jam yang dihabiskan untuk semantik, ada 8 jam yang dihabiskan untuk sintaks komentar.

Seperti hukum trivialitas, hukum Wadler mendalilkan bahwa ketika mendesain bahasa, jumlah waktu yang dihabiskan untuk struktur bahasa sangat besar dibandingkan dengan pentingnya struktur ini.

Hukum Wheaton

Jangan jadi kambing.

Hukum singkat, sederhana dan komprehensif ini, yang dirumuskan oleh Will Wheatan, bertujuan untuk meningkatkan keharmonisan dan rasa hormat dalam organisasi profesional. Ini dapat digunakan dalam percakapan dengan kolega, ketika melakukan evaluasi ahli terhadap kode, dalam mencari keberatan terhadap sudut pandang lain, dalam kritik, dan secara umum, dalam komunikasi profesional antara orang-orang.

Prinsip

Prinsip-prinsip paling sering dikaitkan dengan saran tentang merancang program.

Prinsip Dilbert

Di perusahaan, ada kecenderungan untuk meningkatkan karyawan yang tidak kompeten menjadi manajer untuk menghilangkan mereka dari proses kerja.

Konsep manajemen yang dikembangkan oleh Scott Adams (pencipta komik Dilbert), terinspirasi oleh prinsip Peter. Menurut prinsip Dilbert , karyawan yang tidak dapat dianggap kompeten dipromosikan menjadi manajer untuk membatasi kemungkinan kerusakan pada perusahaan. Adams pertama-tama menjelaskan prinsip ini dalam sebuah artikel untuk Wall Street Journal pada 1995, dan kemudian menjabarkannya secara terperinci dalam bukunya tahun 1996, The Dilbert Principle.

Prinsip pareto (aturan 80/20)

Sebagian besar, segala sesuatu dalam hidup didistribusikan secara tidak merata.

Prinsip Pareto menyatakan bahwa dalam beberapa kasus sebagian kecil dari investasi bertanggung jawab atas sebagian besar hasil:

80% dari program dapat ditulis dalam 20% dari waktu (dan 20% yang paling sulit mengambil 80% sisanya).
20% dari upaya memberikan 80% dari hasilnya.
20% dari pekerjaan menciptakan 80% dari keuntungan.
20% kesalahan menyebabkan 80% crash program.
20% dari fungsi digunakan 80% dari waktu.

Pada 1940-an, seorang insinyur Amerika asal Rumania, Joseph Juran, yang sering disebut sebagai bapak manajemen kualitas, mulai menerapkan prinsip Pareto untuk masalah kualitas.

Juga, prinsip ini diketahui, biasanya 80/20, hukum kecil yang paling penting, prinsip defisiensi faktor.

Contoh: Pada tahun 2002, Microsoft melaporkan bahwa setelah memperbaiki 20% dari kesalahan paling umum, 80% dari masalah terkait dan crash Windows dan Office akan diperbaiki.

Prinsip Peter

Dalam sistem hierarkis, setiap individu memiliki kecenderungan untuk naik ke tingkat ketidakmampuannya.

Konsep manajerial yang dibuat oleh Lawrence Johnston Peter mencatat fakta bahwa orang yang melakukan pekerjaan dengan baik dipromosikan sampai mereka mencapai tingkat di mana mereka tidak lagi mengatasinya (“tingkat ketidakmampuan”). Karena mereka naik cukup tinggi, mereka sudah cenderung kecil untuk dipecat (kecuali mereka membuat semacam omong kosong), sehingga mereka akan tetap dalam posisi ini, di mana mereka tidak memiliki keterampilan yang diperlukan, karena keterampilan perilaku mereka dalam organisasi tidak selalu bersamaan. dengan keterampilan yang diperlukan untuk keberhasilan pekerjaan di posisi ini.

Prinsip ini sangat menarik bagi insinyur yang mulai bekerja dengan peran teknis murni, tetapi sering membangun karir yang mengarah ke manajemen insinyur lain - yang membutuhkan serangkaian keterampilan yang sama sekali berbeda.

Prinsip keandalan (hukum Postel)

Jadilah konservatif tentang aktivitas Anda, dan liberal tentang kontribusi orang lain.

Prinsip ini sering diterapkan pada pengembangan aplikasi server. Menurutnya, data yang Anda kirim ke orang lain harus sekecil mungkin dan sebaik mungkin untuk mematuhi standar, tetapi Anda sendiri harus menerima data yang tidak sepenuhnya standar jika Anda berhasil memprosesnya.

Tujuan dari prinsip ini adalah untuk menciptakan sistem yang andal yang dapat mencerna data yang diformat dengan buruk, yang artinya masih dapat dipahami. Namun, menerima data input non-standar dapat memiliki konsekuensi yang terkait dengan pelanggaran keamanan, terutama jika penerimaan data tersebut belum diuji dengan baik.

Seiring waktu, praktik menerima data non-standar dapat mengarah pada fakta bahwa protokol akan berhenti berkembang, karena mereka yang menerapkan pertukaran data akan mulai bergantung pada kebebasan program, menciptakan fungsi-fungsi baru.

PADAT

Singkatan dari 5 prinsip berikut:

S: Prinsip Tanggung Jawab Tunggal
O: Prinsip Terbuka / Tertutup
L: Prinsip Pergantian Liskov
I: Prinsip Segregasi Antarmuka [ Prinsip Pemisahan Antar Muka]
D: Prinsip Ketergantungan Pembalikan

Ini adalah prinsip-prinsip kunci pemrograman berorientasi objek. Prinsip desain seperti itu akan membantu pengembang menciptakan sistem yang lebih mudah dipelihara.

Prinsip tanggung jawab tunggal

Setiap objek harus memiliki satu tanggung jawab, dan tanggung jawab ini harus dirangkum dalam kelas.

Yang pertama dari prinsip-prinsip SOLID. Prinsipnya menyatakan bahwa setiap modul atau kelas harus melakukan hanya satu hal. Dalam praktiknya, ini berarti bahwa perubahan kecil, tunggal dalam fungsi program harus memerlukan perubahan hanya dalam satu komponen. Misalnya, untuk mengubah prosedur untuk memeriksa kompleksitas kata sandi, program hanya perlu diperbaiki di satu tempat.

Secara teoritis, ini memberikan keandalan kode dan menyederhanakan perubahannya. Fakta bahwa komponen yang diubah memiliki tanggung jawab tunggal harus berarti bahwa akan lebih mudah untuk menguji perubahan ini. Mengubah komponen pemeriksaan kompleksitas kata sandi dari contoh sebelumnya seharusnya hanya memengaruhi fungsi yang terkait dengan kompleksitas kata sandi. Jauh lebih sulit untuk berbicara tentang apa yang akan dipengaruhi oleh perubahan komponen dengan banyak tanggung jawab.

Prinsip keterbukaan / kedekatan

Entitas harus terbuka untuk ekspansi, tetapi tertutup untuk perubahan.

Yang kedua dari prinsip-prinsip SOLID. Prinsip menyatakan bahwa entitas (kelas, modul, fungsi, dll.) Harus memungkinkan perilaku mereka diperluas, tetapi perilaku mereka saat ini tidak boleh diubah.

Contoh hipotetis: bayangkan sebuah modul yang dapat mengubah dokumen markdown Markdown menjadi dokumen markup HTML. Jika modul dapat diperluas sehingga belajar menangani fitur-fitur baru dari format Penurunan harga tanpa mengubah fungsi internalnya, maka modul tersebut terbuka untuk ekspansi. Jika modul tidak dapat mengubah pemrosesan fungsi Penurunan harga saat ini, maka modul ditutup untuk modifikasi.

Prinsipnya terutama terkait erat dengan pemrograman berorientasi objek, di mana Anda dapat mendesain objek yang mudah diperluas, tetapi Anda tidak boleh mendesain objek yang interiornya akan berubah secara tak terduga.

Prinsip Pergantian Barbara Liskov

Seharusnya dimungkinkan untuk mengganti jenis dengan subtipe tanpa merusak sistem.

Yang ketiga dari prinsip-prinsip SOLID. Prinsipnya menyatakan bahwa jika suatu komponen bergantung pada suatu jenis, maka dimungkinkan untuk menggunakan subtipe jenis ini sehingga sistem tidak menolak untuk bekerja atau tidak memerlukan perincian dari subtipe ini.

Misalnya, kami memiliki metode yang membaca dokumen XML dari struktur yang menunjukkan file. Jika metode ini menggunakan file tipe dasar, maka fungsinya harus dapat menggunakan semua yang berasal dari file tersebut. Jika file mendukung pencarian terbalik, dan parser XML menggunakan fungsi ini, tetapi tipe turunan "file jaringan" menolak untuk bekerja dengan pencarian terbalik, maka "file jaringan" melanggar prinsip ini.

Prinsip ini terutama terkait erat dengan pemrograman berorientasi objek, di mana hierarki jenis harus dimodelkan dengan sangat hati-hati untuk menghindari kebingungan bagi pengguna sistem.

Prinsip pemisahan antarmuka

Entitas perangkat lunak tidak boleh bergantung pada metode yang tidak mereka gunakan.

Keempat prinsip SOLID. Prinsip tersebut menyatakan bahwa konsumen suatu komponen tidak boleh bergantung pada fungsi-fungsi komponen yang tidak digunakannya.

Misalnya, kami memiliki metode yang membaca dokumen XML dari struktur yang menunjukkan file. Hanya perlu membaca byte, bergerak maju atau mundur melalui file. Jika metode ini harus diperbarui karena perubahan dalam struktur file yang tidak terkait dengannya (misalnya, karena pembaruan model kontrol akses yang mewakili keamanan file), maka prinsip ini akan dilanggar. Lebih baik file mengimplementasikan antarmuka "aliran yang dapat ditelusuri", dan metode XML untuk menggunakannya.

Prinsip ini terutama terkait erat dengan pemrograman berorientasi objek, di mana antarmuka, hierarki, dan tipe abstrak digunakan untuk meminimalkan koneksi antar komponen. Prinsip ini memaksa penggunaan mengetik bebek , metodologi yang menghilangkan antarmuka eksplisit.

Prinsip Pembalikan Ketergantungan

Modul tingkat atas tidak harus bergantung pada modul tingkat bawah.

Kelima prinsip SOLID. Prinsip tersebut menyatakan bahwa komponen kontrol pada level yang lebih tinggi tidak boleh mengetahui detail implementasi dependensinya.

Misalnya, kami memiliki program yang membaca metadata dari situs web. Mungkin, komponen utamanya harus mengetahui komponen yang mengunduh konten halaman web, dan komponen yang membaca metadata. Jika kita mempertimbangkan prinsip inversi dependensi, maka komponen utama hanya akan bergantung pada komponen abstrak yang menerima data byte, dan pada gilirannya, pada komponen abstrak yang mampu membaca metadata dari aliran byte. Komponen utama tidak akan tahu apa-apa tentang TCP / IP, HTTP, HTML, dll.

Prinsipnya agak rumit, karena membalikkan ketergantungan yang diharapkan dalam sistem. Dalam praktiknya, itu juga berarti bahwa komponen kontrol terpisah harus menjamin implementasi yang benar dari tipe abstrak (dalam contoh sebelumnya, sesuatu harus memasok pembaca metadata komponen untuk mengunduh file melalui HTTP dan untuk membaca data dari tag HTML meta).

Jangan Ulangi Prinsip Anda Sendiri

Setiap pengetahuan harus memiliki representasi yang unik, konsisten, dan otoritatif dalam sistem.

Jangan ulangi diri Anda , atau KERING, membantu pengembang mengurangi pengulangan kode dan menyimpan informasi di satu tempat. Itu disebutkan pada tahun 1999 oleh Andy Hunt dan Dave Thomas dalam buku mereka Pragmatic Programmer.

Kebalikan dari prinsip KERING kering] harus menjadi prinsip WET wet] - “Write Everything Twice” atau “We Like Typing” [We Enjoy Typing].

Dalam praktiknya, jika informasi yang sama digandakan pada Anda di dua tempat atau lebih, gunakan prinsip KERING, gabungkan mereka ke satu tempat dan gunakan kembali seperlunya.

Prinsip CIUMAN

Jaga agar tetap sederhana, bodoh [Jangan rumit, bodoh]

Prinsip KISS mengatakan bahwa kebanyakan sistem bekerja lebih baik jika tidak rumit; oleh karena itu, kesederhanaan harus menjadi tujuan utama dalam pembangunan, dan kompleksitas yang tidak perlu harus dihindari. Itu berasal dari Angkatan Laut AS pada tahun 1960, dan frasa ini dikaitkan dengan desainer pesawat Clarence Johnson.

Yang terbaik adalah membayangkannya menggunakan contoh ketika Johnson memberikan satu set alat kecil kepada tim insinyur desain dan menginstruksikan mereka untuk merancang pesawat sehingga mekanik rata-rata dapat memperbaikinya di medan pertempuran hanya menggunakan set ini. Di sini bodoh menunjukkan hubungan antara bagaimana hal-hal rusak dan kompleksitas alat yang tersedia untuk memperbaikinya, bukan kemampuan mental insinyur.

YAGNI

Akronim untuk Anda Tidak Akan Membutuhkannya [Anda tidak akan membutuhkannya].

Selalu terapkan fungsi hanya saat Anda benar-benar membutuhkannya, dan bukan saat Anda berpikir Anda membutuhkannya di masa depan.

Penulis pemrograman ekstrim (XP) dan buku "Installed Extreme Programming" Ron Jeffries menyarankan agar pengembang hanya mengimplementasikan fungsionalitas yang diperlukan saat ini, dan jangan mencoba memprediksi masa depan, mengimplementasikan fungsionalitas yang mungkin diperlukan nanti.

Mengikuti prinsip ini harus mengurangi jumlah kode yang tidak digunakan dalam database, serta membuang-buang waktu dan energi pada fungsionalitas yang tidak membawa manfaat.

Kesalahpahaman Komputasi Terdistribusi

Juga dikenal sebagai kekeliruan komputasi jaringan. Ini adalah daftar asumsi tentang komputasi terdistribusi yang dapat menyebabkan kegagalan perangkat lunak. Berikut adalah asumsi-asumsi berikut:

Jaringannya andal.
Penundaannya nol.
Bandwidth tidak terbatas.
Jaringan aman.
Topologi tidak berubah.
Hanya ada satu administrator.
Biaya pengiriman nol.
Jaringannya homogen.

Empat yang pertama didaftar oleh Bill Joy dan Tom Lyon pada tahun 1991, dan James Gosling pertama mengklasifikasikannya sebagai "Kesalahpahaman Komputasi Jaringan". Peter Deutsch menambahkan khayalan ke-5, ke-6 dan ke-7. Pada akhir 90-an, Gosling menambahkan 8.

Sekelompok insinyur terinspirasi oleh proses yang terjadi pada waktu itu di Sun Microsystems.

Kesalahan ini harus dipertimbangkan dengan hati-hati ketika mengembangkan kode yang dapat diandalkan. Setiap kesalahan dapat menyebabkan logika yang salah, tidak mampu mengatasi kenyataan dan kompleksitas sistem terdistribusi.

Hukum pemrograman