Kriteria kanggo arsitektur piranti lunak sing apik

Efisiensi

Programer sing berpengalaman bisa kanthi gampang mbedakake arsitektur sing apik saka sing ala, nanging yen dijaluk njlèntrèhaké kanthi sawetara tembung, mesthine ora bisa nglakoni. Ora ana kritéria tunggal kanggo arsitektur sing apik lan ora ana definisi tunggal.

Nanging, yen sampeyan mikir babagan, sampeyan bisa nulis sawetara kritéria sing arsitektur apik kudu gawe marem. Arsitèktur sing apik yaiku, pisanan, arsitektur logis sing ndadekake proses ngembangake lan njaga program luwih gampang lan luwih efisien.

Nalika program nduweni arsitektur apik, iku tansah cukup gampang kanggo ngerti cara kerjane lan ngendi kanggo nulis kode. Program sing dirancang kanthi apik luwih gampang diganti, dites, debug, lan dikembangake. Wong pinter wis ngrumusake kritéria ing ngisor iki kanggo arsitektur sing apik:

• Efisiensi;
• Fleksibilitas;
• Expandability;
• Skalabilitas;
• testability;
• Kode maintainability.

Efisiensi sistem. Program kasebut, mesthine kudu ngrampungake tugas sing ditugasake lan nindakake fungsine kanthi apik, lan ing macem-macem kahanan. Iku misale jek program apa wae sing kudu ditindakake (yen ditulis), nanging asring iki ora kedadeyan.

Sampeyan bakal terus-terusan nemoni program sing ora nindakake apa sing diklaim.

• Libre Office minangka panggantos lengkap kanggo Microsoft Office (ora bener);
• Browser Edge ndhukung kabeh standar web (ora bener);
• Bank peduli babagan keamanan data pribadhi para pangguna (sajatine ora).

Lan kita durung nyentuh babagan kinerja, linuwih, koreksi bug pas wektune utawa publikasi informasi babagan kerentanan sing dikenal.

Cetha yen ora ana sing sampurna, nanging program kasebut kudu ngrampungake tugas utamane. Mulane, tanpa efisiensi, ora ana.

Fleksibilitas

Siji-sijine sing luwih penting tinimbang efisiensi ing pendapatku yaiku keluwesan. Sembarang aplikasi kudu diganti wektu, amarga syarat ganti, sing anyar ditambahake. Sing luwih cepet lan luwih trep kanggo nggawe owah-owahan ing fungsi sing wis ana, luwih sithik masalah lan kesalahan sing disebabake, arsitektur sistem luwih fleksibel .

Asring banget, programer / arsitek pemula mikir yen dheweke butuh arsitektur sing cocog kanggo tugas saiki. Ora. Sampeyan butuh arsitektur sing cocog kanggo tugas sing bakal diumumake ing setaun. Sampeyan, saiki ora ngerti tugas sing bakal teka, kudu ngerti apa sing bakal ditindakake.

Ora ana gunane kanggo nyoba prédhiksi, amarga mesthi ana sing ora dikarepke. Nanging sampeyan kudu nyathet yen tugas kasebut bakal katon. Mulane, ing proses pangembangan, coba evaluasi apa sing dipikolehi babagan carane kudu diganti.

Takon dhewe: "Apa sing kedadeyan yen keputusan arsitektur saiki dadi salah?", "Pinten kode sing bakal diganti?". Ngganti siji fragmen sistem ngirim ora mengaruhi fragmen liyane.

Yen bisa, pancasan arsitektur ora kudu disetel ing watu, lan akibat saka kasalahan arsitektur kudu cukup diwatesi. "Arsitektur apik ngijini sampeyan kanggo DELAY pancasan tombol" (Bob Martin) lan minimalake "biaya" kesalahane.

Salah sawijining pendekatan kasebut yaiku pamisah aplikasi dadi layanan mikro: gampang kanggo ngilangi logika sing wis ana dadi bagean sing kapisah. Nanging masalah sing paling gedhe yaiku nggawe owah-owahan ing mangsa ngarep menyang puluhan layanan sekaligus kanggo ngetrapake siji fitur cilik.

Skalabilitas

Skalabilitas minangka kemampuan kanggo nyuda wektu pangembangan kanthi nambahake wong anyar ing proyek kasebut. Arsitektur kudu ngidini proses pangembangan paralel supaya akeh wong bisa nggarap program kasebut bebarengan.

Iku misale jek sing aturan iki digawa metu dhewe, nanging ing laku kabeh iku persis ngelawan. Malah ana buku sing paling populer, The Mythical Man-Month , sing nerangake kenapa nalika wong anyar ditambahake menyang proyek, wektu pangembangan saya mundhak.

Expandability

Ekstensibilitas minangka kemampuan kanggo nambah fitur lan entitas anyar menyang sistem tanpa ngrusak struktur inti. Ing tataran wiwitan, iku ndadekake pangertèn kanggo sijine mung fungsi dhasar lan paling perlu menyang sistem.

Iki minangka prinsip YAGNI - sampeyan ora butuh , "sampeyan ora butuh". Ing wektu sing padha, arsitektur kudu ngidini sampeyan kanthi gampang nambah fungsi tambahan yen perlu. Lan supaya introduksi saka owah-owahan paling kamungkinan mbutuhake gaweyan paling.

Keperluan supaya arsitektur sistem dadi fleksibel lan bisa diperluas (yaiku, bisa owah-owahan lan evolusi) pancen penting banget nganti dirumusake minangka prinsip sing kapisah - "Prinsip Terbuka / Tertutup " . Prinsip Open-Closed minangka nomer loro saka limang prinsip SOLID: entitas piranti lunak (kelas, modul, fungsi) kudu mbukak kanggo ekstensi, nanging ditutup kanggo modifikasi .

Ing tembung liyane: iku kudu bisa kanggo ngganti lan ngluwihi prilaku sistem tanpa rewriting ana bagéan saka sistem .

Iki tegese aplikasi kudu dirancang kanthi cara sing ngganti prilaku lan nambah fungsi anyar bakal digayuh kanthi nulis kode anyar (ekstensi), tanpa kudu ngganti kode sing wis ana.

Ing kasus iki, munculé syarat anyar ora mbutuhake modifikasi logika sing ana, nanging bisa dileksanakake utamane kanthi ngembangake. Prinsip iki minangka dhasar "arsitektur plug-in" (Arsitektur Plugin). Teknik-teknik kanggo nggayuh iki bakal dibahas mengko.

Elinga servlet lan saringan? Napa saringan dibutuhake, lan malah kanthi antarmuka sing kapisah, yen, nyatane, kabeh logika sing padha bisa ditindakake kanthi nggunakake servlet?

Iki minangka panemuan konsep saringan (servlet layanan) sing bisa mindhah macem-macem fungsi layanan menyang lapisan sing kapisah. Lan ing mangsa ngarep, nalika ngganti prilaku saringan, iku ora perlu kanggo ngganti servlets.

Sadurunge panemuan saringan, kabeh logika layanan sing tanggung jawab kanggo pangalihan panjalukan dumunung ing servlets dhewe. Lan asring siji owah-owahan cilik ing logika bakal mimpin kanggo kudu mbukak liwat kabeh servlets lan nggawe macem-macem owah-owahan kanggo kabeh.

Testability

Yen sampeyan minangka Java Backend Developer, mula aplikasi server sampeyan asring mbukak sakumpulan metode minangka REST API. Lan kanggo mriksa manawa kabeh cara sampeyan bisa digunakake kaya sing dikarepake, kudu dites.

Umumé, jangkoan tes API minangka gaya sing apik. Iki ngidini sampeyan mesthekake yen API sampeyan pancen nindakake apa sing dikarepake. Lan uga, sing luwih penting, sampeyan bisa ngganti logika server lan mriksa kanthi gampang manawa sampeyan ora sengaja ngrusak apa-apa .

Sanalika sampeyan miwiti nulis tes, sampeyan bakal ngerti sing paling kode ora bisa dites ing kabeh: cara pribadi, kopling kuwat, kelas statis lan variabel.

"Napa kita butuh tes yen kode kasebut bisa digunakake?", Pamula bakal takon.

"Napa kita butuh kode sing bisa digunakake yen ora bisa dites?", Profesional bakal takon.

Kode sing gampang dites bakal ngemot luwih sithik bug lan luwih dipercaya. Nanging tes ora mung nambah kualitas kode. Meh kabeh pangembang pungkasanipun teka menyang kesimpulan sing requirement "testability apik" uga pasukan panuntun sing otomatis ndadékaké kanggo desain apik.

Punika kutipan saka buku Ideal Architecture: "Gunakake prinsip "testability" kelas minangka "test litmus" saka desain kelas apik. Sanajan sampeyan ora nulis baris siji saka kode test, njawab pitakonan iki ing 90 % kasus bakal mbantu ngerti carane kabeh apik" utawa "ala" karo rancangane.

Ana metodologi kabeh kanggo ngembangake program adhedhasar tes, sing diarani Test-Driven Development (TDD). Iki mesthi nemen liyane: nulis kode sadurunge sampeyan nulis kode.

Kode maintainability

Minangka aturan, akeh wong sing nggarap program kasebut - sawetara ninggalake, sing anyar teka. Wektu kerja rata-rata programmer ing perusahaan IT yaiku siji setengah taun. Dadi, yen sampeyan teka ing proyek sing umure 5 taun, mula mung 20% ​​saka kolega sampeyan sing nyambut gawe wiwit wiwitan.

Njaga lan ngembangake program sing ditulis wong liya angel banget. Sanajan program kasebut wis ditulis, asring perlu kanggo terus njaga: ndandani kesalahan lan nggawe koreksi cilik. Lan asring iki kudu ditindakake dening wong sing ora melu nulis.

Mulane, arsitektur sing apik kudu nggawe gampang lan cepet kanggo wong anyar ngerti sistem kasebut . Proyek kasebut kudu:

• Ditata apik.
• Ora ngemot duplikasi.
• Nduwe kode sing diformat kanthi apik.
• Iku seng di pengeni kanggo kalebu dokumentasi.
• Sampeyan perlu kanggo aplikasi solusi standar lan akrab kanggo programer.

Sampeyan bisa kanthi gampang menehi rating proyek sing lagi ditindakake kanthi skala 5 poin . Cukup etung rong poin kanggo saben syarat kasebut . Lan yen sampeyan entuk 5 utawa luwih, sampeyan bakal begja.

Programer malah duwe prinsip sing paling ora kaget : sistem sing luwih eksotis, luwih angel dingerteni wong liya. Biasane, iki digunakake ing hubungane karo antarmuka panganggo, nanging uga ditrapake kanggo nulis kode.