"Just Enough Software Architecture" yang diterbitkan pada 2010
(georgefairbanks.com)- Just Enough Software Architecture karya George Fairbanks berangkat dari kesadaran bahwa pengetahuan tata bahasa pemrograman atau UML saja tidak cukup untuk merancang sistem dan arsitektur berorientasi objek yang baik
- Intinya adalah risk-driven architecting, yaitu menghindari desain berlebihan saat risikonya kecil, dan menerapkan teknik yang lebih ketat pada risiko yang mengancam keberhasilan
- Buku ini memperlakukan arsitektur bukan sebagai ranah eksklusif segelintir ahli, melainkan sebagai kapabilitas yang harus dipahami semua pengembang, serta menjelaskan dampak batasan dan perubahan kecil terhadap properti sistem
- Alih-alih berfokus pada proses pengembangan atau pengelolaan organisasi, buku ini menitikberatkan pada teknik rekayasa, sehingga pembaca dapat menangani trade-off desain untuk masalah menengah hingga besar melalui pemodelan dan analisis arsitektur
- Susunannya terdiri dari dua bagian, yaitu arsitektur perangkat lunak berbasis risiko dan pemodelan arsitektur, mencakup abstraksi seperti model domain, model desain, model kode, enkapsulasi, komponen, dan konektor
Kemampuan desain yang tidak cukup hanya dengan pengetahuan bahasa dan UML
- Penulis memulai dari gagasan untuk membuat buku yang dulu ia butuhkan saat mulai mengembangkan perangkat lunak
- Pada masa itu sudah ada buku tentang bahasa pemrograman atau pemrograman berorientasi objek, tetapi buku yang membahas desain masih sedikit
- Mengetahui fitur bahasa C++ saja tidak cukup untuk merancang sistem berorientasi objek yang baik, dan mengetahui UML saja juga tidak cukup untuk merancang arsitektur sistem yang baik
Architecting yang disesuaikan dengan risiko
- Inti buku ini adalah risk-driven architecting
- Saat risikonya kecil, desain yang sangat rinci tidak diperlukan; tetapi ketika ada risiko yang mengancam keberhasilan, desain asal-asalan tidaklah memadai
- Banyak pendukung Agile melihat bahwa sebagian desain awal bisa membantu, dan buku ini membahas cara melakukan “arsitektur secukupnya”
- Buku ini menghindari proses bergaya “one size fits all” dan memandu pembaca menyesuaikan upaya arsitektur dan desain berdasarkan risiko yang dihadapi
- Sebagian besar teknik dapat disesuaikan intensitasnya, mulai dari tingkat quick-and-dirty hingga tingkat yang sangat ketat
Menjadikan arsitektur sebagai bahasa semua pengembang
- Buku ini memiliki tujuan untuk mendemokratisasi arsitektur
- Dalam sebuah organisasi mungkin ada software architect, dan bisa juga pembacanya sendiri adalah architect
- Banyak architect ingin semua pengembang memahami arsitektur
- Jika pengembang tidak memahami alasan di balik batasan serta dampak perubahan kecil terhadap properti sistem, penilaian desain mereka bisa goyah
- Arsitektur bukan topik khusus milik architect saja, melainkan topik yang relevan bagi semua pengembang perangkat lunak
Pengetahuan prosedural dan pengetahuan deklaratif
- Buku ini berfokus pada pengembangan pengetahuan deklaratif
- Kemampuan memukul bola tenis dan mengetahui mengapa kita bisa melakukannya adalah hal yang berbeda, dan itu sejalan dengan perbedaan antara pengetahuan prosedural dan pengetahuan deklaratif
- Jika Anda sudah menjadi ahli dalam merancang dan membangun sistem, mungkin Anda sudah menggunakan banyak teknik dalam buku ini
- Buku ini membantu Anda lebih sadar terhadap apa yang selama ini Anda lakukan dan memberi nama pada konsep-konsep tersebut
- Pengetahuan deklaratif seperti ini membantu meningkatkan kemampuan membimbing pengembang pemula
Berfokus pada rekayasa, bukan proses
- Orang yang merancang dan membangun sistem perangkat lunak harus menangani banyak hal sekaligus, seperti jadwal, komitmen sumber daya, dan kebutuhan pemangku kepentingan
- Banyak buku arsitektur perangkat lunak sudah membahas proses pengembangan dan struktur organisasi
- Berbeda dari itu, buku ini berfokus pada bagian teknis dari pengembangan perangkat lunak dan pada rekayasa yang membuat sistem benar-benar bekerja
- Buku ini memungkinkan pembaca membuat model dan menganalisis arsitektur agar dapat melakukan trade-off desain yang berprinsip
- Buku ini menjelaskan teknik yang digunakan untuk menalar masalah skala menengah hingga besar, serta menunjukkan ke mana harus belajar lebih dalam tentang teknik-teknik khusus
Desain praktis yang bergerak melintasi berbagai tingkat abstraksi
- Buku ini memperlakukan arsitektur sebagai aktivitas desain yang praktis
- Arsitektur perangkat lunak adalah salah satu jenis desain perangkat lunak; keputusan desain memengaruhi arsitektur, dan arsitektur juga memengaruhi desain
- Pengembang hebat menggali hambatan secara mendetail untuk memahaminya, lalu menghubungkan sifat hambatan itu dengan keseluruhan arsitektur
- Dengan mencerminkan perilaku drill-down/pop-up ini, buku ini membahas model pada berbagai tingkat abstraksi, dari arsitektur hingga desain struktur data
Susunan dan format yang disediakan
- Buku ini terdiri dari dua bagian
- Part I: Risk-Driven Software Architecture
- Part II: Architecture Modeling
- Beberapa sample chapter dapat diunduh sebagai satu PDF
- E-book dijual di Google Play, mencakup tiga format bebas DRM yaitu ePub, Mobi, dan PDF, dengan harga $9.99
- Versi hardcover tersedia di Amazon
- Google Books dan Amazon Search Inside menyediakan versi yang dapat ditelusuri teks penuhnya
Cakupan yang dibahas dan yang tidak dibahas
- Buku ini berfokus pada arsitektur perangkat lunak yang berkaitan dengan pembangunan perangkat lunak
- Buku ini menjelaskan teknik untuk membuat perangkat lunak memenuhi kebutuhan rekayasa
- Karena teknik rekayasa itu sendiri pada umumnya independen terhadap proses, buku ini juga sebagian besar tidak terikat pada proses tertentu
- Buku ini tidak membahas saran terkait aktivitas manajerial seperti berikut
- tanggung jawab politik seorang architect
- kapan harus mengadakan jenis rapat tertentu
- cara mengumpulkan kebutuhan dari para pemangku kepentingan
Part I: Arsitektur perangkat lunak berbasis risiko
- Sulit mendefinisikan arsitektur perangkat lunak secara tepat, tetapi beberapa sifatnya jelas
- Pengembang perangkat lunak, seperti insinyur di bidang teknik lain, menggunakan abstraksi dan model untuk menyelesaikan masalah yang besar dan kompleks
- Arsitektur perangkat lunak bekerja seperti kerangka sistem dan memengaruhi atribut kualitas, bersifat ortogonal terhadap fungsionalitas, dan memengaruhi properti sistem melalui batasan
- Arsitektur sangat penting terutama dalam situasi berikut
- ketika ruang solusi kecil
- ketika risiko kegagalan tinggi
- ketika menghadapi kebutuhan atribut kualitas yang sulit
- Pendekatan desain dapat dipilih dari architecture-indifferent design, architecture-focused design, dan architecture hoisting
- Prosedur inti model berbasis risiko bersifat sederhana
- mengidentifikasi dan memprioritaskan risiko
- memilih lalu menerapkan sekumpulan teknik
- mengevaluasi pengurangan risiko
- Bab 4 menunjukkan penerapan model berbasis risiko dengan contoh sistem Home Media Player
- komunikasi tim
- integrasi komponen COTS
- memastikan konsistensi metadata
- Part I ditutup dengan saran penggunaan model dan arsitektur perangkat lunak
- menggunakan model untuk memecahkan masalah
- menambahkan batasan dengan hati-hati
- berfokus pada risiko
- menyebarkan kapabilitas arsitektur ke seluruh tim
Part II: Pemodelan arsitektur
- Part II berfokus membantu pembaca membentuk model konseptual tentang arsitektur perangkat lunak
- Struktur model dasarnya ada tiga
- model domain: berkorespondensi dengan hal-hal di dunia nyata
- model desain: merepresentasikan desain perangkat lunak yang sedang dibangun
- model kode: berkorespondensi dengan source code
- Dapat dibuat model tambahan berupa view yang menampilkan detail terpilih, dan view seperti ini dapat dikelompokkan dalam viewtype
- Membuat batas enkapsulasi adalah teknik penting dalam arsitektur perangkat lunak
- pengguna komponen atau modul dapat mengabaikan cara kerja internalnya dan fokus pada masalah sulit lainnya
- penulis komponen atau modul yang dienkapsulasi memperoleh kebebasan untuk mengubah implementasi tanpa mengganggu pengguna
- kebebasan ini hanya mungkin jika enkapsulasi efektif, sehingga buku ini membahas teknik untuk menjaminnya
- Buku ini mengintegrasikan teknik arsitektur perangkat lunak dari berbagai sumber
- teknik yang menekankan atribut kualitas
- teknik yang menekankan fungsionalitas
- cara praktis membuat model yang efektif
- cara melakukan debugging pada model
- Part II juga membahas jebakan yang dapat ditemui dalam teknologi tersebut, bersama saran untuk menggunakan model secara efektif
- Tujuan akhirnya adalah agar pembaca memiliki model konseptual yang kaya tentang abstraksi dan relasi, lalu dapat melihat sistem perangkat lunak seperti pelatih yang mengamati pertandingan
1 komentar
Opini Hacker News
Ada yang bilang risiko manajemen proyek adalah “pengembang utama tertabrak bus” sedangkan risiko rekayasa perangkat lunak adalah “server mungkin tidak bisa diskalakan sampai 1000 pengguna”, jadi keduanya harus dibedakan, tetapi dalam pengalaman saya keduanya jarang benar-benar terpisah seperti itu
Kualitas dan struktur kode, pengujian dan dokumentasi, serta penggunaan alat yang standar dan dikenal luas membantu di kedua sisi
Karena itu saya berkali-kali mengangkat asumsi “bagaimana kalau tertabrak bus?” kepada rekan kerja atau atasan, dan itu menjadi semacam tekanan untuk membuat perangkat lunak yang bisa direproduksi dan dipahami
Jika ingin menghindari nuansa negatif soal cedera atau kematian, lebih baik pakai “bagaimana kalau menang lotre?”
Inti dari “tertabrak bus” adalah sama sekali tidak ada waktu untuk bersiap, terlepas dari kepribadian, dan dari situlah muncul tekanan untuk membagikan informasi hari ini
Sayangnya, saya belum menemukan ungkapan positif yang membawa implikasi yang sama
Keduanya kembali sekitar seminggu kemudian, jadi kami jadi butuh contoh bencana standar yang lain
Saat menyampaikan poinnya, saya lebih sering memakai ungkapan “orang berikutnya”
Situasi yang lebih buruk adalah burnout, karena jumlah orangnya tetap sama tetapi secara mental dia sebenarnya sudah pergi
Saya sudah melihat banyak perusahaan yang bahkan tidak bisa bertahan menghadapi itu, bukan hanya saat orang keluar permanen
Atau bisa juga memakai ungkapan seperti “meningkatkan bus factor”, yang berfokus pada motivasi menghilangkan single point of failure
Jika melakukan analisis akar masalah, kita tidak boleh berhenti di “Larry tertabrak bus / menang lotre”, karena itu bukan masalah yang sebenarnya
Arsitektur demi arsitektur adalah yang terburuk karena secara tidak perlu menambah kompleksitas
Tujuan akhir arsitektur yang baik adalah mengurangi biaya
Jika arsitektur membuat pengembangan dan pemeliharaan kode memakan lebih banyak waktu, maka arsitektur itu gagal
Ini selalu soal mencari keseimbangan
Jadi tidak ada satu arsitektur yang selalu benar; pilihan bergantung pada konteks dan kadang perlu dievaluasi ulang
Fleksibilitas sangat berguna karena memungkinkan arsitektur disesuaikan sampai batas tertentu dan tetap efisien saat keadaan berubah
Pengurangan biaya bisa menjadi salah satunya
“Model berbasis risiko menuntun pengembang untuk menerapkan teknik arsitektur seminimal mungkin demi mengurangi risiko yang paling mendesak. Ini adalah proses yang terus-menerus menanyakan: ‘Apa risiko saya? Teknik terbaik apa untuk menguranginya? Apakah risikonya sudah dimitigasi dan sekarang saya bisa mulai atau melanjutkan coding?’ Model berbasis risiko dapat diringkas dalam tiga langkah: 1. Identifikasi dan prioritaskan risiko 2. Pilih dan terapkan sekumpulan teknik 3. Evaluasi pengurangan risiko”
Kita tentu tidak ingin membuang waktu pada teknik yang dampaknya rendah, tetapi juga tidak ingin mengabaikan risiko yang mengancam proyek
Untuk membangun sistem yang sukses, kita harus memilih jalur penggunaan waktu yang paling efektif, dan itu berarti menangani risiko dengan menerapkan teknik arsitektur dan desain hanya ketika risikolah yang menjadi pendorongnya
Sebagai contoh, “arsitektur” juga mencakup penggunaan gaya client-server di mana server tidak bertindak lebih dulu dan hanya merespons permintaan klien
Pendekatan ini bisa sangat cocok untuk masalahnya, atau tidak
https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
Para arsitek teknis bergaji tinggi yang nyaris tidak melakukan apa-apa lalu memaksakan pola-pola buruk yang harus diselesaikan para software engineer di bawah batasan tidak masuk akal seperti tenggat waktu
Arsitektur yang baik memungkinkan lebih banyak orang ikut berkontribusi pada produk
Jika terbit pada 2010, saya penasaran seberapa baik buku ini bertahan sejak itu
Saya suka Design It karena punya lokakarya dan aktivitas yang bagus untuk orang teknis yang perlu berinteraksi dengan pemangku kepentingan atau pelanggan
Ini lebih relevan karena perannya konsultatif, dan juga bagus karena tidak terlalu bergantung pada gaya arsitektur teknologi tertentu yang sering berubah
Ini saya katakan berdasarkan prinsip nyata, bukan tren
Penulis menghabiskan banyak waktu pada prosa tentang pola pikir dan hanya membahas detail teknis secara ringan, tetapi menyediakan bahan bacaan lanjutan
Buku itu membuat tim menangani ide arsitektur melalui aktivitas konkret, dan pada akhirnya menyingkap apa yang benar-benar penting
Buku saya mencoba membahas ide-ide besar seperti itu secara langsung, tetapi karena topiknya sangat abstrak, ternyata secara pedagogis sulit
Ide apa yang bertahan sejak 2010? Beberapa sistem operasi bersifat mikrokernel, dan beberapa lainnya monolitik
Beberapa basis data bersifat relasional, dan beberapa lainnya berpusat pada dokumen
Beberapa aplikasi berbentuk klien-server, dan beberapa lainnya peer-to-peer
Pembedaan seperti ini mungkin bersifat permanen, dan jika kita kembali 100 tahun lagi, meskipun contoh seperti Windows, Oracle, dan Salesforce mungkin sudah hilang, kita tetap akan melihat sistem dengan rancangan seperti itu
Dan kita juga akan tetap membicarakan kualitas seperti kemudahan modifikasi atau latensi
Bidang arsitektur perangkat lunak adalah pekerjaan mengidentifikasi abstraksi yang bertahan lama ini
Ada penjelasan ringkas di [2]
“Abstrak: arsitektur perangkat lunak adalah sekumpulan abstraksi yang membantu kita menalar perangkat lunak yang akan kita bangun atau yang sudah kita bangun. Bidang kita telah lama memiliki abstraksi kecil, tetapi butuh beberapa dekade sebelum abstraksi yang lebih besar seperti atribut kualitas, penyembunyian informasi, komponen dan konektor, berbagai sudut pandang, serta gaya arsitektur terakumulasi. Saat merancang sistem, kita merangkai abstraksi ini untuk menjaga rantai intensionalitas dan memastikan sistem yang kita rancang melakukan hal yang kita inginkan. Dua puluh tahun lalu, Martin Fowler menerbitkan artikel berpengaruh ‘Who Needs an Architect?’ di majalah ini. Kini saatnya para pengembang melihat kembali arsitektur perangkat lunak dan memahaminya sebagai sekumpulan abstraksi yang memungkinkan kita menalar perangkat lunak”
[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/
[2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...
A Philosophy of Software Design karya John Ousterhout berguna
Banyak saran yang solid dan mudah dipahami, juga banyak contoh
Saya tidak tahu buku ini sendiri, tetapi saya tahu tulisan penulis tentang Intellectual Control, dan itu sangat berwawasan
https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...
https://johnwhiles.com/posts/programming-as-theory
Di perusahaan sebelumnya kami sempat membaca bergiliran buku Software Architecture for Developers karya Simon Brown: https://leanpub.com/b/software-architecture
Itu masih hanya ada di daftar bacaan saya, dan saya juga sudah pindah dari perusahaan itu, tetapi saya mendapat rekomendasi yang sangat kuat
Perusahaan itu juga mendokumentasikan arsitekturnya dengan model C4
Saya penasaran apakah ada orang di sini yang sudah membacanya
Kuliah [1] dan lokakaryanya tentang arsitektur sangat efektif, dan bahasa pemodelan arsitektur C4 [2] juga benar-benar sedang mendapat momentum
Saya juga punya video YouTube [3], tetapi tidak seefektif itu
[1] https://www.youtube.com/results?search_query=simon+brown+arc...
[2] https://c4model.com/
[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...
Saya rasa metodologi ini akan jauh lebih baik jika namanya “bergantung pada risiko”
Kenapa para programmer begitu menyukai ungkapan “[X]-driven”?
Poros ini menggerakkan roda gigi itu, dan roda gigi itu menggerakkan roda
Ini cara singkat untuk mengatakan “mekanisme apa yang paling kuat dalam mesin berpikir yang rumit ini”
Beberapa tahun lalu kami mengadakan klub buku di kantor dengan buku ini, dan saya merasa isinya sangat berulang
Saya penasaran apakah buku ini merupakan sumber yang baik bagi orang yang memulai proyek open source yang tidak sepele
Atau apakah ada nilai yang bisa didapat pendiri solo, dan saya ingin mendapat rekomendasi buku atau sumber lain yang berguna untuk pengembang solo
Arsitektur perangkat lunak mirip dengan arsitektur bangunan pada umumnya, tetapi di perangkat lunak belum ada sosok seperti Isaac Newton, jadi rasanya seperti belum ada teknik sipil
Menurut saya, tokoh yang paling mendekati sejauh ini adalah Claude Shannon
Karena kita bahkan tidak punya satuan ukur
Dalam rekayasa perangkat lunak, kita masih berada pada tahap “semoga ini tidak runtuh”
Ini sangat memengaruhi produktivitas yang dilaporkan sendiri
Misalnya, sepeda bisa terasa lebih cepat daripada mengemudi dengan jendela terbuka pada kecepatan 30 mil per jam di jalan kecil pinggiran kota yang penuh rambu berhenti
Tetapi biasanya pengemudi tetap tiba jauh lebih cepat di tempat yang berjarak 20 blok
Jika tidak ada satuan ukur, semua orang akan berdebat bahwa sepeda lebih cepat
Begitulah keadaan rekayasa perangkat lunak saat ini
Membuat perangkat lunak sama sekali tidak seperti membangun jembatan atau gedung pencakar langit, melainkan lebih dekat dengan mendesain hal-hal itu
Dalam proyek konstruksi besar, orang mendesain dulu lalu membangun, dan desain ini adalah pekerjaan yang sangat besar
Anda harus memikirkan segalanya, menjalankan simulasi, berdiskusi dengan para pemangku kepentingan, memahami kebutuhan dan batasan, serta mempertimbangkan biaya material, berat, dan sebagainya
Dalam proyek konstruksi besar, berbulan-bulan atau bahkan bertahun-tahun bisa habis hanya untuk membuat desain yang hasilnya berupa cetak biru yang sangat rinci dan mencakup hampir semua aspek konstruksi
Sebenarnya ini sangat mirip dengan pembuatan perangkat lunak
Proyek desain seperti ini memiliki ketidakpastian dan risiko yang tinggi
Meski begitu, lebih baik mengetahui bahwa semuanya salah sebelum mulai menghabiskan banyak tenaga kerja dan sumber daya mahal seperti beton dan baja
Tetapi pernahkah Anda mendengar arsitek berkata bahwa untuk mengurangi risiko ini mereka membuat desain untuk desain? Tidak ada yang seperti itu
Paling banter, pada suatu titik mungkin ada sketsa atau coretan di serbet
SpaceX memasukkan beberapa unsur agile ke dalam rekayasa, dan itu dipelajari dari pengembangan perangkat lunak
Dalam perangkat lunak, cetak biru yang sudah selesai dapat dieksekusi
Proses membuat cetak biru itu dikerjakan manual, tetapi proses membuat perangkat lunak dari cetak biru tersebut biasanya diotomatisasi oleh compiler dan alat lain, sehingga sangat murah, dan karena itu para pengembang selalu melakukannya
Tentu saja, dulu tidak selalu seperti itu
Proses membuat cetak biru yang dapat dijalankan tentu mengandung banyak risiko, dan bisa saja ada desain di serbet atau papan tulis di mana-mana
Tetapi gagasan untuk terlebih dahulu membuat desain lengkap lalu implementasi lengkap, yaitu model waterfall, tidak pernah benar-benar berhasil dalam perangkat lunak
Kecuali beberapa pengecualian, biasanya tidak ada cetak biru untuk cetak biru
Jika Anda membaca makalah asli Royce tentang waterfall, sebenarnya istilah waterfall sama sekali tidak muncul, dan ia hanya secara samar menyarankan bahwa iterasi mungkin ide yang bagus
Semacam anjuran untuk setidaknya melakukannya lebih dari sekali
Ia sepenuhnya memahami bahwa desain pertama kemungkinan besar salah
Agile mengoptimalkan lalu menghilangkan tahap bernilai rendah berupa membuat desain untuk cetak biru, sesuatu yang menjadi jelas ketika iterasi dilakukan berkali-kali
Hanya saja, di luar area tertentu, kita umumnya mengabaikannya
Misalnya, jika melihat ringkasan dan daftar isi ini sepintas, tampaknya hampir tidak ada atau sama sekali tidak ada pembahasan tentang metrik kinerja
Jika tidak mempertimbangkan apa yang sebenarnya dilakukan komputer, apa gunanya arsitektur?
Bahkan dari sisi produktivitas pengembang atau antarmuka pengguna, mengapa tidak ada model matematis yang menjelaskan mental stack yang dibutuhkan untuk mengembangkan, mengubah, memperluas, dan yang lebih penting lagi, menggunakan perangkat lunak?
Sumber daya komputasi, baik manusia maupun mesin, memiliki dampak nyata dan terukur terhadap interaksi dengan perangkat lunak sebagai pengembang maupun pengguna, jadi mengapa hal itu hanya jarang dipertimbangkan?
Misalnya, Westminster Palace jelas memiliki unsur teknik sipil, tetapi ciri-ciri penentunya seperti tekstur yang mewah, menara jam yang ikonik, dan tata letak interior sebagian besar ditentukan oleh pilihan fungsional dan estetis
Banyak bagian dari perangkat lunak juga demikian