Ini adalah pengungkapan ulang gratis dan sangat singkat dari buku baru oleh Robert Martin (Paman Bob) "Arsitektur Bersih", dirilis pada tahun 2018.
Pendahuluan
Arsitektur perangkat lunak agak mirip arsitektur bangunan. Bangunan-bangunan juga memiliki struktur fraktal: bangunan terdiri dari kompartemen, kompartemen terdiri dari kamar, kamar terdiri dari dinding, dinding terbuat dari batu bata. Program, di sisi lain, terdiri dari modul, yang terdiri dari paket, yang terdiri dari kelas, yang terdiri dari fungsi, dll. Namun, keragaman struktur program jauh lebih luas daripada bangunan, sehingga Paman Bob menganggap arsitektur perangkat lunak "lebih arsitektur" daripada arsitektur bangunan.
Selain itu, arsitektur bangunan lebih mudah divisualisasikan di kepala daripada perangkat lunak, karena kita melihat bangunan setiap hari, dan arsitektur program disembunyikan dari kita di dalam kode sumber. Arsitektur perangkat lunak tidak seperti apa pun.
Di sisi lain, arsitektur perangkat lunak juga harus mengingat keterbatasan fisik, karena program berjalan pada perangkat keras nyata dengan kinerja terbatas, memori, bandwidth jaringan, dll.
Apa itu arsitektur yang baik? Ini adalah arsitektur yang memenuhi kebutuhan pengguna, pemilik bisnis dan pemrogram, tidak hanya pada saat ini,
tetapi juga seiring waktu .
"Jika Anda berpikir arsitektur yang baik itu mahal, maka cobalah yang buruk."
"Satu-satunya cara untuk cepat adalah dengan baik."
Kata Pengantar
Paman Bob telah menulis kode selama lebih dari 50 tahun. Dia menulis berbagai program: besar, kecil, GUI, konsol, web, dll. Dan saya sampai pada kesimpulan bahwa aturan arsitektur adalah sama di mana-mana! Dan bahkan lebih dari 50 tahun mereka tidak berubah meskipun peningkatan produktivitas besi sangat besar.
Bahasa pemrograman juga menjadi jauh lebih baik, tetapi konstruksi dasarnya tetap sama: jika, tugas, loop, dll. Jika Anda menempatkan seorang programmer dari pertengahan abad terakhir untuk MacBook modern, maka pada awalnya ia menjadi gila, tetapi kemudian akan normal untuk menulis kode Java di Ide.
Tetapi lebih dari setengah abad telah memperoleh banyak pengalaman, yang belum 50 tahun lalu. Aturan dirumuskan, yang didedikasikan untuk buku ini.
Pendahuluan
Menulis program kerja itu mudah. Sulit untuk
menulis program dengan benar . Ini membutuhkan pengetahuan, pengalaman dan keterampilan, yang perkembangannya membutuhkan banyak waktu dan disiplin.
Ketika program dilakukan dengan benar, mudah untuk mempertahankan dan membuat perubahan padanya. Ada persentase cacat yang sangat rendah. Tidak perlu gerombolan programmer, banyak dokumen dengan persyaratan dan pelacak canggih.
Kedengarannya utopis, tetapi Paman Bob berhasil mengerjakan proyek semacam itu. Namun sayangnya, dalam banyak kasus kita harus bekerja dalam desain yang mengerikan.
Apa itu desain dan arsitektur?
Mari kita asumsikan bahwa desain dan arsitektur adalah satu dan sama.
Arsitektur tidak hanya tingkat atas, itu adalah rincian tingkat atas dan tingkat rendah secara keseluruhan. Satu tanpa yang lain tidak ada.
Tujuan dari arsitektur perangkat lunak adalah untuk
meminimalkan sumber daya manusia yang dibutuhkan untuk membangun dan memelihara sistem yang diperlukan.
Jika usahanya kecil dan
tetap demikian sepanjang hidup , maka desainnya bagus. Jika upaya meningkat dengan setiap rilis, maka desainnya buruk.
Sebagai contoh, Paman Bob menunjukkan grafik proyek nyata, di mana jumlah karyawan meningkat 50 kali, tetapi jumlah baris kode hanya meningkat 2,3 kali (3M -> 7M). Bagan yang lebih menakutkan adalah peningkatan biaya satu baris kode ~ 40 kali. Yaitu produktivitas turun dari 100% menjadi hampir nol. Pemrogram bekerja keras sebaik mungkin, tetapi pada dasarnya tidak ada yang bisa dilakukan. Dan sekarang yang terburuk: jika dalam rilis pertama kami harus membayar karyawan beberapa ratus ribu dolar sebulan, maka pada akhirnya angka ini menjadi 20 juta dolar sebulan!
Selanjutnya, Paman Bob mengingat perumpamaan tentang kelinci dan kura-kura. Di dalamnya, kura-kura memenangkan perlombaan karena kelinci terlalu percaya diri, pergi tidur dan tidur sepanjang lomba.
Hal yang sama dengan pengembangan: programmer menghibur dirinya sendiri dengan keyakinan bahwa ia akan dapat dengan cepat meluncurkan produk, dan mengembalikan pesanan nanti. Namun, masalahnya adalah bahwa setelah rilis ia perlu melakukan fitur berikutnya, jika tidak, ia akan tertinggal dari pesaing di pasar. Pada akhirnya, dalam beberapa bulan produktivitasnya akan turun menjadi nol dan dia akan kehilangan.
Dia kemudian memberikan contoh percobaan yang dilakukan oleh Jason Gorman tertentu, di mana dia menulis program sederhana beberapa kali. Dan ternyata dengan TDD pertama kali lebih cepat daripada ketiga kalinya tanpa TDD. Artinya, jika Anda menulis dengan benar, maka hasilnya lebih cepat.
Pengembang harus
bertanggung jawab atas kekacauan yang ia perkenalkan ke dalam proyek. Kualitas arsitektur harus ditanggapi dengan serius. Tetapi untuk ini Anda perlu tahu apa itu arsitektur yang baik.
Sebuah cerita tentang dua nilai
Ada dua nilai - perilaku dan arsitektur.
Perilaku berarti bahwa program tersebut memenuhi persyaratan fungsional dan dengan demikian membawa uang kepada pemilik bisnis. Masalahnya adalah bahwa banyak programmer percaya bahwa ini adalah pekerjaan mereka.
Nilai kedua adalah kualitas di mana program tetap dalam keadaan terjaga. Artinya, mudah diubah. Kompleksitas perubahan harus proporsional dengan skala perubahan ini, tetapi bukan bentuknya. Arsitektur tidak boleh membuat preferensi beberapa bentuk daripada yang lain, jika tidak, permintaan pemilik akan semakin sulit diimplementasikan setiap kali.
Apa yang lebih penting - perilaku atau arsitektur? Manajer percaya bahwa sistem itu berfungsi lebih penting. Tetapi programmer harus mempertimbangkan sebaliknya, bahwa arsitektur lebih penting.
Matriks Eisenhower mengatakan bahwa yang penting dan tidak mendesak memiliki prioritas yang lebih tinggi daripada yang mendesak dan tidak penting. Dan arsitektur selalu penting berbeda dengan perilaku, sehingga lebih diprioritaskan.
Programmer harus berjuang untuk arsitektur. Seorang programmer juga merupakan anggota bisnis. Arsitektur adalah tanggung jawabnya.
Dilanjutkan ...