Kriteria untuk seni bina perisian yang baik

Kecekapan

Pengaturcara yang berpengalaman boleh dengan mudah membezakan seni bina yang baik daripada yang buruk, tetapi jika diminta untuk menerangkannya dalam beberapa perkataan, mereka tidak mungkin dapat melakukannya. Tiada kriteria tunggal untuk seni bina yang baik dan tiada definisi tunggal.

Walau bagaimanapun, jika anda memikirkannya, anda boleh menulis beberapa kriteria yang harus dipenuhi oleh seni bina yang baik. Seni bina yang baik adalah, pertama sekali, seni bina logik yang menjadikan proses pembangunan dan penyelenggaraan program lebih mudah dan lebih cekap.

Apabila program mempunyai seni bina yang baik, ia sentiasa cukup mudah untuk memahami cara ia berfungsi dan tempat untuk menulis kod. Program yang direka bentuk dengan baik adalah lebih mudah untuk diubah, diuji, nyahpepijat dan dibangunkan. Orang pintar telah merumuskan kriteria berikut untuk seni bina yang baik:

• Kecekapan;
• Fleksibiliti;
• Kebolehkembangan;
• Kebolehskalaan;
• kebolehujian;
• Kebolehselenggaraan kod.

Kecekapan sistem. Program ini, sudah tentu, mesti menyelesaikan tugas yang diberikan dan melaksanakan fungsinya dengan baik, dan dalam pelbagai keadaan. Nampaknya mana-mana program melakukan apa yang sepatutnya dilakukan (jika ia ditulis), tetapi selalunya ini tidak berlaku sama sekali.

Anda akan sentiasa menjumpai program yang tidak melakukan apa yang mereka dakwa lakukan.

• Libre Office ialah pengganti penuh untuk Microsoft Office (bukan sebenarnya);
• Pelayar Edge menyokong semua piawaian web (tidak sebenarnya);
• Bank mengambil berat tentang keselamatan data peribadi penggunanya (sebenarnya tidak).

Dan kami masih belum menyentuh prestasi, kebolehpercayaan, pembetulan pepijat tepat pada masanya atau penerbitan maklumat tentang kelemahan yang diketahui.

Sudah jelas bahawa tiada siapa yang sempurna, tetapi program mesti menyelesaikan tugas utamanya. Oleh itu, tanpa kecekapan, tiada tempat.

Fleksibiliti

Satu-satunya perkara yang lebih penting daripada kecekapan pada pendapat saya ialah fleksibiliti. Sebarang aplikasi perlu berubah dari semasa ke semasa, apabila keperluan berubah, yang baharu ditambah. Lebih cepat dan lebih mudah untuk membuat perubahan pada fungsi sedia ada, lebih sedikit masalah dan ralat yang ditimbulkan, lebih fleksibel seni bina sistem.

Selalunya, pengaturcara / arkitek pemula berfikir bahawa mereka memerlukan seni bina yang ideal untuk tugas semasa. Tidak. Anda memerlukan seni bina yang ideal untuk tugasan yang akan diumumkan kepada anda dalam setahun. Anda, yang kini tidak mengetahui tugas masa depan, sepatutnya tahu apa yang akan dilakukan.

Tidak masuk akal untuk cuba meramalkan mereka, kerana akan sentiasa ada sesuatu yang tidak dijangka. Tetapi anda mesti mengambil kira bahawa tugas sedemikian akan muncul. Oleh itu, dalam proses pembangunan, cuba menilai apa yang diperoleh dari segi bagaimana ia perlu diubah.

Tanya diri anda: "Apa yang berlaku jika keputusan seni bina semasa ternyata salah?", "Berapa banyak kod yang akan diubah?". Menukar satu serpihan sistem seharusnya tidak menjejaskan serpihannya yang lain.

Seboleh-bolehnya, keputusan seni bina tidak sepatutnya ditetapkan, dan akibat daripada kesilapan seni bina hendaklah dihadkan dengan munasabah. "Seni bina yang baik membolehkan anda MENANGGUHKAN keputusan penting" (Bob Martin) dan meminimumkan "kos" kesilapan.

Salah satu pendekatan ini ialah membahagikan aplikasi kepada perkhidmatan mikro: mudah untuk memecahkan logik yang sedia ada kepada bahagian yang berasingan. Tetapi masalah terbesar ialah membuat perubahan masa depan kepada sedozen perkhidmatan sekaligus untuk melaksanakan satu ciri kecil.

Kebolehskalaan

Skalabiliti ialah keupayaan untuk mengurangkan masa pembangunan dengan menambah orang baru ke projek. Seni bina harus membenarkan proses pembangunan diselaraskan supaya ramai orang boleh bekerja pada program pada masa yang sama.

Nampaknya peraturan ini dijalankan dengan sendirinya, tetapi dalam praktiknya semuanya adalah sebaliknya. Malah terdapat sebuah buku yang sangat popular, The Mythical Man-Month , yang menerangkan mengapa apabila orang baharu ditambahkan pada projek, masa pembangunan meningkat.

Kebolehkembangan

Kebolehlanjutan ialah keupayaan untuk menambah ciri dan entiti baharu pada sistem tanpa memecahkan struktur terasnya. Pada peringkat awal, masuk akal untuk meletakkan hanya fungsi asas dan paling diperlukan ke dalam sistem.

Inilah yang dipanggil prinsip YAGNI - anda tidak akan memerlukannya , "anda tidak akan memerlukannya". Pada masa yang sama, seni bina sepatutnya membolehkan anda meningkatkan fungsi tambahan dengan mudah mengikut keperluan. Dan supaya pengenalan perubahan yang paling mungkin memerlukan usaha yang paling sedikit.

Keperluan bahawa seni bina sistem menjadi fleksibel dan boleh diperluaskan (iaitu, mampu berubah dan berevolusi) adalah sangat penting sehingga ia dirumuskan sebagai prinsip yang berasingan - "Prinsip Terbuka/ Tertutup " . Prinsip Terbuka-Tertutup ialah yang kedua daripada lima prinsip SOLID: entiti perisian (kelas, modul, fungsi) harus dibuka untuk sambungan, tetapi ditutup untuk pengubahsuaian .

Dalam erti kata lain: adalah mungkin untuk mengubah dan melanjutkan tingkah laku sistem tanpa menulis semula bahagian sedia ada sistem .

Ini bermakna bahawa aplikasi harus direka bentuk sedemikian rupa sehingga mengubah tingkah laku dan menambah fungsi baharu akan dicapai dengan menulis kod baharu (sambungan), tanpa perlu menukar kod sedia ada.

Dalam kes ini, kemunculan keperluan baharu tidak akan melibatkan pengubahsuaian logik sedia ada, tetapi boleh dilaksanakan terutamanya dengan mengembangkannya. Prinsip ini adalah asas kepada "seni bina plug-in" (Plugin Architecture). Teknik untuk mencapai ini akan dibincangkan kemudian.

Ingat servlet dan penapis? Mengapa penapis diperlukan, dan walaupun dengan antara muka yang berasingan, jika, sebenarnya, semua logik yang sama boleh dilaksanakan menggunakan servlet?

Ia adalah ciptaan konsep penapis (servlet perkhidmatan) yang memungkinkan untuk memindahkan pelbagai fungsi perkhidmatan ke lapisan yang berasingan. Dan pada masa hadapan, apabila menukar tingkah laku penapis, tidak perlu menukar servlet.

Sebelum penciptaan penapis, semua logik perkhidmatan yang bertanggungjawab untuk mengubah hala permintaan terletak dalam servlet itu sendiri. Dan selalunya satu perubahan kecil dalam logik akan membawa kepada keperluan untuk melalui semua servlet dan membuat pelbagai perubahan kepada semua.

Kebolehujian

Jika anda seorang Pembangun Java Backend, maka aplikasi pelayan anda sering mendedahkan satu set kaedah sebagai API REST. Dan untuk memastikan semua kaedah anda berfungsi seperti yang dimaksudkan, mereka perlu diliputi dengan ujian.

Secara umum, liputan ujian API ialah gaya yang baik. Ia membolehkan anda memastikan bahawa API anda benar-benar melakukan perkara yang dimaksudkan untuk dilakukan. Dan juga, yang lebih penting, anda boleh membuat perubahan pada logik pelayan dan dengan mudah menyemak sama ada anda tidak melanggar apa-apa secara tidak sengaja .

Sebaik sahaja anda mula menulis ujian, anda akan menyedari bahawa kebanyakan kod tidak boleh diuji sama sekali: kaedah persendirian, gandingan kuat, kelas statik dan pembolehubah.

"Mengapa kita memerlukan ujian jika kod itu berfungsi?", Pemula akan bertanya.

"Mengapa kita memerlukan kod kerja jika ia tidak boleh diuji?", profesional akan bertanya.

Kod yang mudah diuji akan mengandungi lebih sedikit pepijat dan lebih dipercayai. Tetapi ujian bukan sahaja meningkatkan kualiti kod. Hampir semua pembangun akhirnya membuat kesimpulan bahawa keperluan "kebolehujian yang baik" juga merupakan daya panduan yang secara automatik membawa kepada reka bentuk yang baik.

Berikut ialah petikan daripada buku Seni Bina Ideal: "Gunakan prinsip "kebolehujian" kelas sebagai "ujian litmus" reka bentuk kelas yang baik. Walaupun anda tidak menulis satu baris kod ujian, jawab soalan ini dalam 90 % kes akan membantu untuk memahami bagaimana semuanya baik" atau "buruk" dengan reka bentuknya."

Terdapat keseluruhan metodologi untuk membangunkan program berdasarkan ujian, yang dipanggil Pembangunan Dipacu Ujian (TDD). Ini sudah tentu melampau yang lain: tulis kod sebelum anda menulis kod.

Kebolehselenggaraan kod

Sebagai peraturan, ramai orang bekerja pada program ini - ada yang cuti, yang baru datang. Purata masa bekerja pengaturcara dalam syarikat IT ialah satu setengah tahun. Jadi jika anda datang ke projek yang berusia 5 tahun, maka hanya 20% daripada rakan sekerja anda yang mengerjakannya dari awal lagi.

Mengekalkan dan membangunkan program yang ditulis oleh orang lain adalah sangat sukar. Walaupun program itu sudah ditulis, selalunya perlu untuk terus mengekalkannya: betulkan ralat dan buat pembetulan kecil. Dan selalunya ini perlu dilakukan oleh orang yang tidak mengambil bahagian dalam menulisnya.

Oleh itu, seni bina yang baik harus menjadikannya agak mudah dan cepat untuk orang baharu memahami sistem . Projek itu mestilah:

• tersusun dengan baik.
• Jangan mengandungi pendua.
• Mempunyai kod yang diformat dengan baik.
• Adalah wajar untuk memasukkan dokumentasi.
• Ia adalah perlu untuk menggunakan penyelesaian standard dan biasa untuk pengaturcara.

Anda boleh menilai projek yang sedang anda kerjakan dengan mudah pada skala 5 mata . Hanya kira dua mata untuk setiap keperluan ini . Dan jika anda mendapat 5 atau lebih, maka anda bertuah.

Pengaturcara malah mempunyai prinsip yang paling tidak mengejutkan : sistem yang lebih eksotik, lebih sukar untuk orang lain fahami. Biasanya, ia digunakan berhubung dengan antara muka pengguna, tetapi ia boleh digunakan untuk menulis kod juga.