Kriteria kanggo desain ala

Urip iku cukup prasaja: asring, dadi pinter, sampeyan mung kudu ora nindakake perkara bodho. Iki uga ditrapake kanggo pangembangan piranti lunak: ing pirang-pirang kasus, supaya bisa nindakake kanthi apik, sampeyan mung kudu ora nindakake kanthi ala.

Paling programer wis pengalaman karo bagéan saka sistem sing kanti awon dirancang. Nanging sing luwih sedhih, umume sampeyan bakal ngalami pengalaman sedih amarga ngerti yen sampeyan minangka penulis sistem kasebut. We wanted sing paling apik, nanging diaktifake metu minangka tansah.

Umume pangembang ora pengin arsitektur ala, lan kanggo akeh sistem ana titik ngendi padha miwiti kanggo ngomong sing arsitektur iku elek. Yagene iki kedadeyan? Apa desain arsitektur ala saka wiwitan, utawa wis dadi ala liwat wektu?

Oyod saka masalah iki yaiku kekurangan definisi desain "ala".

Iku misale jek kula sing pangerten saka kualitas desain lan alasan kanggo "bosok" iku kuwalitas paling penting kanggo programmer sembarang. Kaya ing kasus liyane, sing utama yaiku ngenali masalah kasebut, lan bakal dadi masalah teknologi kanggo ngatasi.

Definisi saka "desain ala"

Yen sampeyan mutusake kanggo gumunggung babagan kode sampeyan ing ngarepe programmer liyane, sampeyan bakal bisa dipoyoki: "Sapa sing nindakake iki?", 'Yagene kaya ngono?' lan "Aku bakal nindakake perkara sing beda." Iki kedadeyan asring banget.

Java webinar

Kabeh wong beda-beda, nanging sampeyan isih nulis kode kanggo kanca-kanca programer, supaya ing proses ngembangake saben fitur, sampeyan kudu tansah fase review nalika wong liya ndeleng kode sampeyan.

Nanging sanajan akeh perkara sing bisa ditindakake kanthi cara sing beda-beda, ana sawetara kritéria sing kabeh pangembang bakal setuju. Sembarang potongan kode sing nyukupi syarate nanging isih nuduhake siji (utawa luwih) karakteristik desain sing ala.

Desain ala:

  • Angel diganti amarga owah-owahan apa wae mengaruhi akeh banget bagean sistem liyane. ( Kaku , Kaku).
  • Nalika owah-owahan digawe, bagean liyane saka sistem break ndadak. ( Rapuh , Rapuh).
  • Kode kasebut angel digunakake maneh ing aplikasi liyane amarga angel banget kanggo metu saka aplikasi sing saiki. ( Imobilitas , Imobilitas).

Lan sing lucu yaiku meh ora bisa nemokake potongan sistem sing ora ngemot karakteristik kasebut (yaiku, fleksibel, dipercaya lan bisa digunakake maneh), nyukupi syarat, lan ing wektu sing padha desaine ala. .

Dadi, kita bisa nggunakake telung ciri kasebut kanggo nemtokake manawa desain "ala" utawa "apik".

Panyebab "Desain ala"

Apa sing nggawe desain kaku, rapuh, lan ora bisa diobahake? Interdependensi kaku saka modul.

A desain kaku yen ora bisa gampang diganti. Kaku iki amarga kasunyatan sing owah-owahan siji menyang Piece saka kode ing sistem tenunan nyebabake owah-owahan cascading ing modul gumantung. Iki mesthi kedadeyan nalika ana wong sing nggarap kode kasebut.

Iki langsung complicates kabeh proses pembangunan komersial: nalika jumlah owahan cascading ora bisa diprediksi dening desainer utawa pangembang, iku mokal kanggo ngira impact saka owah-owahan kuwi. Mulane, dheweke nyoba nundha owah-owahan kasebut tanpa wates.

Lan iki ndadekake biaya owah-owahan ora bisa ditebak. Ngadhepi kahanan sing durung mesthi, manajer ora gelem nggawe owah-owahan, mula desain kasebut resmi dadi kaku.

Ing sawetara titik, proyek sampeyan ngliwati "cakrawala acara" lan bakal tiba ing "bolongan ireng" arsitektur kaku.

Fragility minangka kecenderungan sistem rusak ing pirang-pirang panggonan sawise owah-owahan siji. Biasane masalah anyar dumadi ing panggonan sing sacara konseptual ora ana hubungane karo panggonan owah-owahan. Fragility kuwi serius ngrusak kapercayan ing desain lan pangopènan sistem.

Iki biasane kedadeyan nalika ora ana cara pribadi. Iku cukup kanggo nggawe kabeh cara umum, lan sampeyan bakal pinasthi katon arsitektur rapuh. Enkapsulasi mbantu ngatasi iki ing tingkat mikro. Nanging ing tingkat makro, sampeyan butuh arsitektur modular.

Nalika proyek nduweni arsitektur sing rapuh, pangembang ora bisa njamin kualitas produk kasebut.

Owah-owahan prasaja ing salah sawijining bagean aplikasi nyebabake kewan omo ing bagean liyane sing ora ana gandhengane. Mbenerake kasalahan iki ndadékaké kanggo malah luwih masalah, lan proses ngiringan dadi asu misuwur nguber buntut dhewe.

Desain kasebut ora bisa ditindakake nalika bagean sistem sing dibutuhake banget diikat karo rincian liyane sing ora dikarepake. Kakehan kode dhewe, pendekatan lan solusi sing unik.

Apa sampeyan ngelingi logger JUL, sing pangembang nggawe tingkat logging dhewe tanpa alesan sing apik? Iki mung kasus.

Kanggo menehi desainer babagan carane gampang nggunakake maneh desain sing wis ana, cukup kanggo mikir babagan carane gampang digunakake ing aplikasi anyar.

Yen desain digandhengake kanthi rapet, mula desainer iki bakal nggegirisi amarga jumlah karya sing dibutuhake kanggo misahake bagean sistem sing dibutuhake saka rincian sing ora perlu. Ing sawetara kasus, desain kasebut ora bisa digunakake maneh, amarga biaya pamisahan luwih gedhe tinimbang ngembangake saka awal.

Relevansi

Kabeh owah, nanging kabeh tetep padha. (Pepatah Cina)

Pitakonan sing apik banget wis diajukake ing ndhuwur. Apa bebaya sistem sing rapuh lan kaku? Ya, amarga proses ngatur proyek kasebut dadi ora bisa ditebak lan ora bisa dikendhaleni. Lan rega exorbitant.

Kepiye manajer bisa menehi utawa ora menehi idin kanggo nambah sawetara fitur yen dheweke ora ngerti suwene wektu sing bakal ditindakake? Kepiye carane nggawe prioritas tugas yen sampeyan ora bisa ngira wektu lan kerumitan implementasine?

Lan carane gawe bisa mbayar utang technical padha nalika kita bakal rake ing mbayar, lan kita ora bisa ngerti carane akeh kita bakal rake nganti kita rake?

Masalah karo nggunakake maneh kode utawa testing uga cocog banget. Tes unit ora mung kanggo nguji sawetara asumsi babagan unit sing diuji, nanging uga kanggo nemtokake tingkat kohesi lan bisa dadi indikator panggunaan maneh.

Mangkene kutipan saka Bob Martin kanggo kasus iki: "Supaya bisa nggunakake maneh kode sampeyan, sampeyan kudu ngupayakake nggunakake maneh kurang saka biaya ngembangake saka awal . " Yen ora, ora ana sing bakal ngganggu perkara iki.

Panggunaan prinsip lan pola desain nduweni tujuan siji - kanggo nggawe desain apik. Yen panggunaan kasebut ora menehi sampeyan entuk manfaat (utawa kosok balene, nglanggar prinsip "desain sing apik"), mula ana sing ana ing konservatori sampeyan ora bener lan, mbok menawa, alat kasebut wiwit digunakake kanggo tujuan liyane.