Kriteria untuk reka bentuk yang buruk
Kehidupan berfungsi dengan mudah: selalunya, untuk menjadi pintar, anda hanya perlu tidak melakukan perkara bodoh. Ini juga terpakai kepada pembangunan perisian: dalam kebanyakan kes, untuk melakukan sesuatu dengan baik, anda hanya perlu tidak melakukannya dengan teruk.
Kebanyakan pengaturcara mempunyai pengalaman dengan bahagian sistem yang direka bentuk dengan teruk. Tetapi lebih menyedihkan, kebanyakan anda akan mengalami pengalaman sedih apabila menyedari bahawa anda adalah pengarang sistem sedemikian. Kami mahukan yang terbaik, tetapi ternyata seperti biasa.
Kebanyakan pemaju tidak bercita-cita untuk seni bina yang buruk, dan untuk kebanyakan sistem terdapat satu titik di mana mereka mula mengatakan bahawa seni binanya adalah dahsyat. Kenapa ini terjadi? Adakah reka bentuk seni bina buruk dari awal, atau adakah ia menjadi buruk dari semasa ke semasa?
Punca masalah ini adalah kekurangan definisi reka bentuk "buruk".
Nampaknya pada saya bahawa pemahaman tentang kualiti reka bentuk dan sebab-sebab untuk "reput" adalah kualiti yang paling penting bagi mana-mana pengaturcara. Seperti dalam kebanyakan kes lain, perkara utama adalah untuk mengenal pasti masalah, dan ia akan menjadi masalah teknologi untuk menyelesaikannya.
Definisi "reka bentuk buruk"
Jika anda memutuskan untuk membual tentang kod anda di hadapan rakan pengaturcara, kemungkinan besar anda akan mendapat ejekan sebagai tindak balas: "Siapa yang melakukan ini?", 'Mengapa ia begitu?' dan "Saya akan melakukan perkara secara berbeza." Ini berlaku sangat kerap.
Semua orang adalah berbeza, tetapi anda masih menulis kod untuk rakan pengaturcara anda, jadi dalam proses membangunkan setiap ciri, anda sentiasa memerlukan fasa semakan apabila orang lain melihat kod anda.
Tetapi walaupun banyak perkara boleh dilakukan dengan cara yang berbeza, terdapat satu set kriteria yang semua pembangun akan bersetuju. Mana-mana sekeping kod yang memenuhi keperluannya tetapi masih mempamerkan satu (atau lebih) ciri adalah reka bentuk yang buruk.
Reka Bentuk Buruk:
- Sukar untuk diubah kerana sebarang perubahan menjejaskan terlalu banyak bahagian lain sistem. ( Ketegaran , Ketegaran).
- Apabila perubahan dibuat, bahagian lain sistem pecah secara tidak dijangka. ( Fragility , Fragility).
- Kod ini sukar untuk digunakan semula dalam aplikasi lain kerana terlalu sukar untuk mengeluarkannya daripada aplikasi semasa. ( Ketidakupayaan , Ketidakupayaan).
Dan perkara yang lucu ialah hampir mustahil untuk mencari sekeping sistem yang tidak mengandungi mana-mana ciri ini (iaitu, fleksibel, boleh dipercayai dan boleh digunakan semula), memenuhi keperluan, dan pada masa yang sama reka bentuknya adalah buruk .
Oleh itu, kita boleh menggunakan ketiga-tiga ciri ini untuk menentukan dengan jelas sama ada reka bentuk itu "buruk" atau "baik".
Punca "Reka Bentuk Buruk"
Apakah yang menjadikan reka bentuk tegar, rapuh dan tidak boleh alih? Saling bergantungan tegar modul.
Reka bentuk adalah tegar jika ia tidak boleh diubah dengan mudah. Ketegaran ini disebabkan oleh fakta bahawa satu perubahan kepada sekeping kod dalam sistem tenunan mengakibatkan perubahan melata dalam modul bergantung. Ini selalu berlaku apabila seseorang sedang mengusahakan kod tersebut.
Ini serta-merta merumitkan keseluruhan proses pembangunan komersial: apabila bilangan perubahan lata tidak dapat diramalkan oleh pereka bentuk atau pembangun, adalah mustahil untuk menganggarkan kesan perubahan tersebut. Oleh itu, mereka cuba menangguhkan perubahan sedemikian selama-lamanya.
Dan ini seterusnya menjadikan kos perubahan tidak dapat diramalkan. Menghadapi ketidakpastian sedemikian, pengurus enggan membuat perubahan, jadi reka bentuk secara rasmi menjadi tegar.
Pada satu ketika, projek anda melepasi "ufuk peristiwa" dan ditakdirkan untuk jatuh ke dalam "lubang hitam" seni bina tegar.
Kerapuhan ialah kecenderungan sistem untuk rosak di beberapa tempat selepas satu perubahan. Biasanya masalah baru berlaku di tempat yang secara konsepnya tidak berkaitan dengan tempat perubahan. Kerapuhan sedemikian menjejaskan keyakinan terhadap reka bentuk dan penyelenggaraan sistem dengan serius.
Ini biasanya berlaku apabila tiada kaedah peribadi. Ia cukup untuk membuat semua kaedah awam, dan anda akan ditakdirkan untuk penampilan seni bina yang rapuh. Enkapsulasi membantu menangani perkara ini di peringkat mikro. Tetapi pada peringkat makro, anda memerlukan seni bina modular.
Apabila projek mempunyai seni bina yang rapuh, pemaju tidak dapat menjamin kualiti produk.
Perubahan mudah dalam satu bahagian aplikasi membawa kepada pepijat di bahagian lain yang tidak berkaitan. Membetulkan kesilapan ini membawa kepada lebih banyak masalah, dan proses pengiring bertukar menjadi anjing terkenal yang mengejar ekornya sendiri.
Reka bentuk tidak bergerak apabila bahagian sistem yang diperlukan terikat kuat dengan butiran lain yang tidak diingini. Terlalu banyak kod mereka sendiri, pendekatan dan penyelesaian unik mereka sendiri.
Adakah anda masih ingat pembalak JUL, yang pembangunnya menghasilkan tahap pembalakan mereka sendiri tanpa sebab yang kukuh? Ini hanya kesnya.
Untuk memberi pereka idea betapa mudahnya untuk menggunakan semula reka bentuk sedia ada, cukup untuk memikirkan betapa mudahnya ia akan digunakan dalam aplikasi baharu.
Jika reka bentuk digandingkan dengan ketat, maka pereka ini akan terkejut dengan jumlah kerja yang diperlukan untuk memisahkan bahagian sistem yang diperlukan daripada butiran yang tidak diperlukan. Dalam kebanyakan kes, reka bentuk sedemikian tidak boleh digunakan semula, kerana kos mengasingkannya lebih besar daripada membangunkannya dari awal.
Perkaitan
Semuanya berubah, tetapi semuanya tetap sama. (Peribahasa Cina)
Soalan yang sangat bagus telah dibangkitkan di atas. Apakah bahaya sistem yang rapuh dan tegar? Ya, kerana proses menguruskan projek sedemikian menjadi tidak dapat diramalkan dan tidak terkawal. Dan harganya terlalu tinggi.
Bagaimanakah pengurus boleh memberi kebenaran atau tidak untuk menambah beberapa ciri jika dia tidak tahu berapa lama masa yang diperlukan? Bagaimana untuk mengutamakan tugas jika anda tidak dapat menganggarkan masa dan kerumitan pelaksanaannya dengan secukupnya?
Dan bagaimana pemaju boleh membayar hutang teknikal yang sama apabila kita akan mengaut dalam membayarnya, dan kita tidak dapat memahami berapa banyak yang kita akan mengaut sehingga kita mengaut?
Masalah dengan penggunaan semula atau ujian kod juga sangat berkaitan. Ujian unit berfungsi bukan sahaja untuk menguji beberapa andaian tentang unit yang diuji, tetapi juga untuk menentukan tahap perpaduannya dan boleh berfungsi sebagai penunjuk penggunaan semula.
Berikut ialah petikan daripada Bob Martin untuk kes ini: "Untuk menggunakan semula kod anda, anda perlu berusaha untuk menggunakannya semula kurang daripada kos pembangunan dari awal . " Jika tidak, tiada siapa yang akan menyusahkan perkara ini.
Penggunaan prinsip dan corak reka bentuk mempunyai satu tujuan - untuk membuat reka bentuk yang baik. Jika penggunaannya tidak memberi anda apa-apa faedah (atau sebaliknya, melanggar prinsip "reka bentuk yang baik"), maka sesuatu dalam konservatori anda tidak betul dan, mungkin, alat itu telah mula digunakan untuk tujuan lain.