Ketika saya melakukan desain untuk suatu tugas, saya terus berjuang dengan perasaan mengomel ini bahwa selain menjadi garis besar secara umum, hal itu akan sedikit banyak diabaikan pada akhirnya. Saya akan memberi Anda sebuah contoh:
Saya sedang menulis antarmuka untuk perangkat yang memiliki operasi baca / tulis. Masuk akal di diagram kelas untuk memberinya fungsi baca dan tulis. Namun ketika turun untuk benar-benar menulisnya, saya menyadari bahwa mereka secara harfiah memiliki fungsi yang sama dengan hanya satu baris kode yang diubah (read vs write function call), jadi untuk menghindari duplikasi kode saya akhirnya mengimplementasikan fungsi do_io dengan parameter yang membedakan antara operasi. Selamat tinggal desain aslinya.
Ini bukan perubahan yang sangat mengganggu, tapi itu sering terjadi dan bisa terjadi di bagian yang lebih kritis dari program ini juga, jadi saya tidak bisa tidak bertanya-tanya apakah ada titik untuk merancang lebih detail daripada garis besar umum, setidaknya ketika itu datang ke arsitektur program (jelas ketika Anda menentukan API Anda harus mengeja semuanya).
Ini mungkin hanya hasil dari pengalaman saya dalam melakukan desain, tetapi di sisi lain kita memiliki metodologi lincah yang semacam mengatakan "kita menyerah pada perencanaan jauh ke depan, bagaimanapun juga semuanya akan berubah dalam beberapa hari", yang sering kali bagaimana saya merasa.
Jadi, bagaimana tepatnya saya harus "menggunakan" desain?
do_iotampaknya menjadi detail implementasi internal dari kelas itu. Antarmuka publik akan dan mungkin masih harusread(...)danwrite(...)karena jauh lebih banyak tentang maksud panggilan.Jawaban:
Jika masuk akal untuk menyediakan operasi baca dan tulis, mengapa menghapusnya?
Dari sudut pandang pengguna masih masuk akal. Detail implementasi tidak boleh mengganggu antarmuka yang disediakan.
Yang dapat Anda lakukan adalah membuat do_io internal yang dipanggil dengan membaca dan menulis.
Pada akhirnya proses desain mengikuti langkah-langkah ini:
sumber
Desain arsitektur suatu program berkembang seiring waktu. Saya tidak berpikir pada awalnya Anda memiliki setiap informasi yang Anda perlukan untuk memiliki desain yang benar.
Jadi, jika Anda tetap pada desain yang Anda pikir di awal, Anda mungkin akan membatasi diri.
Kecuali jika Anda membuat api publik saya pikir itu OK untuk membuat perubahan pada desain di sepanjang jalan.
Juga salah satu hal terbaik untuk dilakukan adalah berinvestasi pada alat yang dapat mengekstrak desain dari kode (seperti NDepend for C #)
sumber
Agile mengklaim untuk menjawab masalah ini, dengan beberapa keberhasilan, Namun Fred Brooks memiliki jawaban 40 tahun yang lalu, ketika ia menulis "Tulis satu untuk dibuang, karena Anda akan tetap melakukannya". Mereka yang tidak mempelajari sejarah ditakdirkan untuk mengulanginya.
Jadi yang harus dilakukan adalah memperlakukan desain sebagai rencana, yang dibuat hanya untuk mengubahnya. Desain yang tidak dapat diubah akan hancur. Anda harus siap untuk membuang yang buruk.
Jika desain adalah salah satu API publik, antarmuka atau sejenisnya, banyak kehati-hatian yang perlu diambil karena biaya perubahan tinggi, namun, ketidakmampuan untuk mengubah akan menyebabkan kegagalan.
Jangan selama satu detik menganggap Anda cukup baik, dan cukup tahu untuk memperbaikinya pertama kali, kedua atau bahkan ketiga.
sumber
Ini adalah fakta kehidupan di sebagian besar proyek kehidupan nyata yang berubah:
Inilah mengapa metode Agile menentang Big Design Up Front, karena itu hanya memberikan rasa aman yang salah, melibatkan banyak upaya yang tidak berguna, dan membuat beradaptasi dengan perubahan yang tak terelakkan menjadi lebih sulit.
Namun, Agile tidak sama dengan "menyerah pada perencanaan jauh ke depan" . Metode lincah memang melibatkan sejumlah perencanaan yang cermat dan bijaksana, hanya saja tidak lagi. Mereka sangat disiplin, dan berbeda dari "koboi coding". Melakukan jumlah desain yang tepat adalah upaya terus menerus untuk menemukan keseimbangan yang tepat antara desain yang berlebihan dan yang kurang. Tetapi IMHO lebih baik untuk melakukan kesalahan sedikit di sisi terlalu banyak, daripada melakukan terlalu sedikit.
Desain awal seharusnya tidak mencoba untuk mencakup semuanya, tetapi harus memberi Anda perasaan aman bahwa Anda tahu bagaimana untuk melanjutkan implementasi, Anda memiliki jawaban untuk pertanyaan mendasar tentang arsitektur, dan Anda memiliki model mental tentang bagaimana penggunaan diketahui. kasus akan bekerja dalam kehidupan nyata. Dalam tampilan Agile, tes sebenarnya dari desain adalah implementasi, jadi tidak apa-apa untuk mulai menulis kode bahkan selama fase desain, hanya untuk mendapatkan perasaan tentang bagaimana desain yang dibayangkan akan terlihat seperti, atau dengan cepat prototipe / validasi beberapa asumsi . Catat bahwa sebagian besar pekerjaan awal ini harus dibuang begitu jawaban untuk pertanyaan yang diberikan ditentukan. Hampir selalu merupakan hal yang buruk untuk mulai membangun aplikasi produksi nyata dari prototipe awal.
Dan juga OK untuk kembali dan memodifikasi desain jika Anda membuat realisasi penting baru selama implementasi. Ini adalah umpan balik penting pada dua level:
sumber
Selalu penting ketika Anda membuat dokumen apa pun untuk memahami apa tujuannya.
Saya pikir kita harus berhati-hati dengan apa yang kita sebut dokumen "arsitektur". Ini semua masalah ruang lingkup.
Jika Anda berbicara tentang sistem yang memerlukan beberapa tim atau grup tim, maka Anda berbicara tentang dokumen yang tujuannya adalah untuk menjabarkan minimal:
Jika dokumen Anda adalah untuk sistem yang lebih kecil maka Anda dapat mengurangi jumlah item yang perlu Anda sertakan karena beberapa asumsi akan melekat pada sistem yang ada. Misalnya, jika Anda menggabungkan fitur yang harus diselesaikan di situs web dan beberapa panggilan baru dalam API, maka dokumen Anda akan berfungsi sebagai cara untuk menyelesaikan hal-hal berikut:
Dokumen garis besar ini berfungsi untuk membawa percakapan ke depan tentang siapa yang harus melakukan apa dan bagaimana mereka harus mengintegrasikan. Setelah keputusan itu dibuat maka tim dapat beroperasi secara otonom dengan peluang masalah integrasi yang jauh lebih rendah.
Semakin banyak masalah integrasi yang Anda rasakan, semakin rinci Anda seharusnya mendokumentasikan.
sumber
Anda tampaknya telah menemukan teka-teki umum dalam Pengembangan Perangkat Lunak. Tidak mungkin untuk merencanakan seluruh sistem sebelum Anda mulai membangunnya, karena ada terlalu banyak hal yang belum Anda ketahui.
Ini adalah alasan mengapa metodologi Agile menggunakan pengembangan berulang, karena memungkinkan umpan balik teratur untuk mengubah arah perangkat lunak, daripada membiarkan hal-hal semakin jauh dari apa yang sebenarnya dibutuhkan. Setiap perubahan akan memengaruhi desain.
Jadi setelah mengatakan semua ini, saya sebenarnya akan menulis dua metode untuk skenario spesifik yang Anda jelaskan di atas, tetapi saya akan merangkum logika bersama dalam metode pribadi ketiga yang dapat digunakan oleh dua metode. Dengan cara ini, metode publik hanya bertanggung jawab untuk satu hal dan mudah disebutkan,
read_filedanwrite_filemengatakan apa yang mereka lakukan, sedangkando_fileambigu.Buku-buku seperti Clean Code , Robert C Martin dan Emergent Design , Scott L Bain akan memberi Anda wawasan yang lebih rinci tentang subjek ini.
sumber
Tidak mungkin merencanakan setiap detail di muka. Sangat dapat diterima untuk melakukan perubahan di sana-sini.
Namun, penting untuk merencanakan ke depan. Melakukan lincah tidak berarti tidak ada desain dan perencanaan sama sekali , tetapi itu berarti Anda mengharapkan perubahan.
Anda harus menggunakan desain Anda apa adanya. Karena tidak tertulis di batu, mudah untuk mengubahnya.
sumber
Jumlah waktu yang Anda habiskan untuk arsitektur harus ditentukan oleh tingkat risiko di bagian sistem itu.
Secara umum Anda akan ingin membuat keputusan lebih awal pada gaya arsitektur - berlapis, komponen, pub-sub, dll, dll sebuah proyek.
Melakukan hal itu akan memberi Anda ide dasar tentang blok bangunan yang berbeda dalam sistem Anda dan apa peta jalannya ketika sistem dan persyaratan Anda berkembang seiring waktu.
Setelah Anda menggunakan case bekas, saya yakin Anda harus melakukan desain yang cukup untuk memastikan Anda memahami masalah dan solusinya sepenuhnya. Jika itu adalah kode pelat ketel yang telah Anda lakukan berulang kali, maka risiko kesalahan itu (dalam artian arsitektural - Anda masih perlu mengujinya tentu saja) cukup rendah sehingga jumlah desain di muka kemungkinan besar cukup minim. Jika ini adalah masalah baru, atau solusi yang tidak jelas atau yang berpotensi berisiko bagi bisnis, maka akan lebih layak untuk berpikir lebih lama.
Tentu saja ada berbagai cara untuk melakukan hal ini - UML, prototipe, sketsa papan tulis, dll. Metode apa pun yang Anda gunakan - hal utama yang perlu diingat adalah tujuannya adalah untuk membantu Anda berpikir dan berkomunikasi tentang desain Anda.
sumber