Halo kanca-kanca. Ing nunggu Bukak saka mesthi , tradisional nuduhake karo sampeyan terjemahan materi migunani.
Piranti lunak ngrampungake tugas saben dina, lan dadi luwih rumit. Minangka Marc Andressen tau ngandika, iku nganggo donya.
Akibaté, cara aplikasi dikembangake lan dikirim wis owah sacara dramatis sajrone sawetara taun kepungkur. Iki minangka owah-owahan skala tektonik sing ngasilake sakumpulan prinsip. Prinsip kasebut wis kabukten mbiyantu mbangun tim, ngrancang, ngembangake, lan ngirim aplikasi sampeyan menyang pangguna pungkasan.
Prinsip kasebut bisa diringkes kaya ing ngisor iki: aplikasi kudu cilik, basis web, lan duwe arsitektur pangembang-sentris. Kanthi telung prinsip kasebut, sampeyan bisa nggawe aplikasi sing kuat lan lengkap sing bisa dikirim kanthi cepet lan aman menyang pangguna pungkasan, lan gampang diukur lan bisa ditambah.
Saben prinsip sing diusulake duwe sawetara aspek sing bakal kita rembug kanggo nuduhake kepiye saben prinsip menehi kontribusi kanggo tujuan utama, yaiku pangiriman aplikasi sing dipercaya kanthi cepet lan gampang dijaga lan digunakake. Kita bakal nliti prinsip sing ana hubungane karo opposites kanggo njlentrehake apa tegese, ucapake, "Priksa manawa sampeyan nggunakake prinsip cilik".
Muga-muga artikel iki bakal nyengkuyung sampeyan nggunakake prinsip sing diusulake kanggo mbangun aplikasi modern, sing bakal nyedhiyakake pendekatan terpadu kanggo ngrancang ing konteks tumpukan teknologi sing terus berkembang.
Kanthi ngetrapake prinsip kasebut, sampeyan bakal entuk manfaat saka tren paling anyar babagan pangembangan piranti lunak, kalebu kanggo pangembangan lan pangiriman aplikasi, panggunaan wadah (contone, ) lan kerangka orkestrasi wadah (contone, ), panggunaan layanan mikro (kalebu Arsitektur Microservice и kanggo aplikasi microservice.
Apa aplikasi modern?
Aplikasi modern? Tumpukan modern? Apa tegese "modern"?
Umume pangembang mung duwe gagasan umum babagan apa aplikasi modern, mula perlu kanggo nemtokake konsep iki kanthi jelas.
Aplikasi modern ndhukung macem-macem klien, apa iku antarmuka pangguna perpustakaan React JavaScript, aplikasi seluler Android utawa iOS, utawa aplikasi sing nyambung menyang API liyane. Aplikasi modern nuduhake jumlah klien sing ora ditemtokake sing nyedhiyakake data utawa layanan.
Aplikasi modern nyedhiyakake API kanggo ngakses data lan layanan sing dijaluk. API kudu immutable lan pancet, lan ora ditulis khusus kanggo panjalukan tartamtu saka klien tartamtu. API kasedhiya liwat HTTP (S) lan menehi akses menyang kabeh fungsi kasedhiya ing GUI utawa CLI.
Data kasebut kudu kasedhiya ing format interoperable sing umum ditampa kayata JSON. API nyedhiyakake obyek lan layanan kanthi cara sing resik lan teratur, kaya RESTful API utawa GraphQL nyedhiyakake antarmuka sing apik.
Aplikasi modern dibangun ing tumpukan modern, lan tumpukan modern minangka tumpukan sing ndhukung aplikasi kasebut. Tumpukan iki ngidini pangembang kanthi gampang nggawe aplikasi kanthi antarmuka HTTP lan titik pungkasan API sing cetha. Pendekatan sing dipilih bakal ngidini aplikasi sampeyan gampang nampa lan ngirim data ing format JSON. Ing tembung liyane, tumpukan modern cocog karo unsur Aplikasi rolas-Faktor kanggo .
Versi populer saka jinis tumpukan iki adhedhasar , , , , и . Arsitektur Microservice nuduhake conto tumpukan modern sing diimplementasikake ing saben basa sing kasebut.
Elinga yen kita ora nyengkuyung pendekatan layanan mikro khusus. Akeh sing nggarap monolith sing kudu berkembang, dene liyane ngurusi aplikasi SOA sing berkembang lan berkembang dadi aplikasi layanan mikro. Isih ana liyane sing pindhah menyang aplikasi tanpa server, lan sawetara sing ngleksanakake kombinasi ing ndhuwur. Prinsip sing digarisake ing artikel kasebut ditrapake kanggo saben sistem kasebut kanthi mung sawetara modifikasi cilik.
Prinsip
Saiki kita duwe pangerten umum babagan apa aplikasi modern lan tumpukan modern, wektune kanggo nyilem arsitektur lan prinsip pangembangan sing bakal mbantu sampeyan ngembangake, ngetrapake, lan njaga aplikasi modern.
Salah sawijining prinsip kaya "gawe aplikasi cilik", ayo diarani prinsip cilik. Ana aplikasi sing luar biasa rumit sing digawe saka akeh bagean obah. Sabanjure, mbangun aplikasi saka komponen cilik lan diskrit nggampangake kanggo ngrancang, njaga, lan nggarap kanthi sakabehe. (Elinga yen kita ngomong "nyederhanakake" ora "nggawe prasaja").
Prinsip kapindho yaiku kita bisa nambah produktivitas pangembang kanthi mbantu dheweke fokus ing fitur sing dikembangake, nalika mbebasake saka prasarana lan masalah CI/CD sajrone implementasine. Dadi, kanthi ringkes, pendekatan kita fokus ing pangembang.
Pungkasan, kabeh babagan aplikasi sampeyan kudu disambungake menyang jaringan. Sajrone 20 taun kepungkur, kita wis nggawe langkah gedhe menyang masa depan jaringan amarga jaringan dadi luwih cepet lan aplikasi luwih rumit. Kaya sing wis dingerteni, aplikasi modern kudu digunakake ing jaringan dening akeh klien sing beda. Nerapake pamikiran jaringan ing arsitektur nduweni keuntungan sing signifikan prinsip cilik lan konsep pendekatan, pangembang oriented.
Yen sampeyan ngelingi prinsip kasebut nalika ngrancang lan ngetrapake aplikasi, sampeyan bakal duwe kauntungan sing ora bisa dipungkiri ing pangembangan lan pangiriman produk sampeyan.
Ayo ndeleng telung prinsip kasebut kanthi luwih rinci.
Prinsip cilik
Pancen angel kanggo otak manungsa ngerteni akeh informasi ing wektu sing padha. Ing psikologi, istilah beban kognitif nuduhake jumlah total gaweyan mental sing dibutuhake kanggo nahan informasi ing memori. Ngurangi beban kognitif ing pangembang minangka prioritas amarga ngidini dheweke fokus kanggo ngrampungake masalah tinimbang njaga model kompleks saiki saka kabeh aplikasi lan fitur sing dikembangake ing sirahe.
Aplikasi decompose amarga alasan ing ngisor iki:
- Ngurangi beban kognitif ing pangembang;
- Percepatan lan nyederhanakake tes;
- Pangiriman cepet owah-owahan ing aplikasi.
Ana sawetara cara kanggo nyuda beban kognitif ing pangembang, lan ing kene ana prinsip cilik.
Mangkene telung cara kanggo nyuda beban kognitif:
- Ngurangi pigura wektu sing kudu ditimbang nalika ngembangake fitur anyar - sing luwih cendhek pigura wektu, sing luwih murah beban kognitif.
- Ngurangi jumlah kode sing ditindakake siji-wektu - kurang kode - kurang muatan.
- Nyederhanakake proses nggawe owah-owahan tambahan menyang aplikasi.
Ngurangi pigura wektu pangembangan
Ayo bali menyang dina nalika metodologi waterfall minangka standar kanggo proses pangembangan, lan pigura wektu nem sasi nganti rong taun kanggo ngembangake utawa nganyari aplikasi minangka praktik umum. Biasane, insinyur bakal maca dokumen sing relevan kayata syarat produk (PRD), dokumen referensi sistem (SRD), cetak biru arsitektur, lan wiwit nggabungake kabeh iki dadi siji model kognitif, miturut kode kasebut. Minangka syarat lan, akibate, arsitektur diganti, upaya serius kudu ditindakake kanggo ngandhani kabeh tim babagan nganyari model kognitif. Pendekatan kasebut, paling awon, mung bisa nglumpukake karya.
Owah-owahan paling gedhe ing proses pangembangan aplikasi yaiku introduksi metodologi tangkas. Salah sawijining fitur utama metodologi agile minangka pangembangan iteratif. Sabanjure, iki nyebabake nyuda beban kognitif ing insinyur. Tinimbang mbutuhake tim pangembang kanggo ngetrapake aplikasi ing siji siklus sing dawa, agile pendekatan ngijini sampeyan kanggo fokus ing jumlah cilik saka kode sing bisa cepet dites lan tugasaken, nalika uga nampa saran. Muatan kognitif app wis owah saka pigura wektu nem sasi nganti rong taun kanthi spek sing akeh kanggo nambah rong minggu utawa owah-owahan fitur sing ngarahake pemahaman sing luwih burem babagan aplikasi gedhe.
Ngalih fokus saka aplikasi massive kanggo fitur cilik tartamtu sing bisa rampung ing sprint rong minggu, karo ora luwih saka siji fitur ahead saka sprint sabanjuré ing atine, iku owah-owahan sing signifikan. Iki ngidini kita nambah produktivitas pangembangan nalika ngurangi beban kognitif, sing terus-terusan fluktuatif.
Ing metodologi agile aplikasi final wis samesthine kanggo versi rada dipunéwahi saka konsep asli, supaya titik pungkasan pembangunan mesthi ambigu. Mung asil saben sprint tartamtu bisa cetha lan tepat.
Basis kode cilik
Langkah sabanjure kanggo nyuda beban kognitif yaiku nyuda basis kode. Minangka aturan, aplikasi modern gedhe banget - aplikasi perusahaan sing kuat bisa kalebu ewonan file lan atusan ewu baris kode. Gumantung carane file diatur, pranala lan dependensi antarane kode lan file bisa ketok, utawa kosok balene. Malah eksekusi kode debugging dhewe bisa dadi masalah, gumantung saka perpustakaan sing digunakake lan carane alat debugging mbedakake antarane perpustakaan / paket / modul lan kode khusus.
Mbangun model mental sing bisa digunakake kanggo kode aplikasi bisa njupuk wektu sing nyengsemake, lan maneh nggawe beban kognitif sing gedhe kanggo pangembang. Iki utamané bener kanggo basis kode monolitik, ing ngendi ana akeh kode, interaksi antarane komponen fungsi ora ditetepake kanthi cetha, lan pamisahan obyek manungsa waé asring burem amarga wates fungsi ora dihormati.
Salah sawijining cara sing efektif kanggo nyuda beban kognitif ing insinyur yaiku pindhah menyang arsitektur microservice. Ing pendekatan microservice, saben layanan fokus ing siji set fitur; nalika makna layanan biasane ditetepake lan dingerteni. Watesan layanan uga cetha - elinga yen komunikasi karo layanan ditindakake liwat API, saengga data sing digawe dening siji layanan bisa gampang ditransfer menyang layanan liyane.
Interaksi karo layanan liyane biasane diwatesi kanggo sawetara layanan pangguna lan sawetara layanan panyedhiya sing nggunakake telpon API prasaja lan resik, kayata nggunakake REST. Iki tegese beban kognitif ing insinyur wis suda banget. Tantangan paling gedhe tetep ngerti model interaksi layanan lan kepiye kedadeyan kaya transaksi ing macem-macem layanan. Akibaté, panggunaan layanan mikro nyuda beban kognitif kanthi nyuda jumlah kode, nemtokake wates layanan sing jelas, lan menehi pemahaman babagan hubungan antarane pangguna lan panyedhiya.
Owah-owahan tambahan cilik
Unsur pungkasan saka prinsip cilikane yaiku manajemen owah-owahan. Iku godaan tartamtu kanggo pangembang dipikir ing basis kode (malah mbok menawa dhewe, kode lawas) lan ngomong, "Iki omong kosong, kita kudu nulis maneh kabeh." Kadhangkala iki minangka keputusan sing bener, lan kadhangkala ora. Iki ndadekake beban owah-owahan model global ing tim pangembangan, sing banjur nyebabake beban kognitif sing akeh. Iku luwih apik kanggo engineers kanggo fokus ing owah-owahan sing bisa digawe sak sprint, supaya padha bisa muter metu fungsi perlu ing proses pas wektune, sanajan mboko sithik. Produk pungkasan kudu meh padha karo sing wis direncanakake, nanging kanthi sawetara modifikasi lan tes sing cocog karo kabutuhan klien.
Nalika nulis ulang bagean gedhe saka kode, iku kadhangkala ora bisa kanggo cepet ngirim owah-owahan amarga dependensi sistem liyane teka menyang muter. Kanggo ngontrol aliran owah-owahan, sampeyan bisa nggunakake fitur ndhelikake. Ing asas, iki tegese fungsi ing produksi, nanging ora kasedhiya nggunakake setelan variabel lingkungan (env-var) utawa sawetara mekanisme konfigurasi liyane. Yen kode wis liwati kabeh pangolahan kontrol kualitas, iku bisa mungkasi munggah ing produksi ing negara laten. Nanging, strategi iki mung bisa digunakake yen fitur kasebut pungkasane diaktifake. Yen ora, mung bakal ngrusak kode lan nambah beban kognitif sing kudu ditindakake pangembang supaya bisa produktif. Pangowahan manajemen lan owah-owahan tambahan dhewe mbantu njaga beban kognitif pangembang ing tingkat sing terjangkau.
Engineers kudu ngatasi akeh kangelan malah karo introduksi prasaja saka fungsi tambahan. Ing bagean manajemen, bakal dadi wicaksana kanggo nyuda beban sing ora perlu ing tim supaya bisa fokus ing unsur fungsional utama. Ana telung perkara sing bisa ditindakake kanggo mbantu tim pangembangan:
- Gunakake metodologi
agilekanggo matesi pigura wektu kang tim kudu fokus ing fitur tombol. - Ngleksanakake aplikasi sampeyan minangka macem-macem layanan mikro. Iki bakal mbatesi jumlah fitur sing bisa dileksanakake lan nguatake wates sing njaga beban kognitif ing karya.
- Luwih milih owah-owahan tambahan tinimbang gedhe lan ora bisa digunakake, ganti kode cilik. Gunakake ndhelikake fitur kanggo ngleksanakake owah-owahan sanajan ora katon sanalika sawise ditambahake.
Yen sampeyan ngetrapake prinsip cilik ing karya, tim sampeyan bakal luwih seneng, luwih fokus kanggo ngetrapake fitur sing dibutuhake, lan luwih cepet ngowahi owah-owahan kualitatif. Nanging iki ora ateges karya ora bisa dadi luwih rumit, kadhangkala, ing nalisir, introduksi saka fungsi anyar mbutuhake modifikasi sawetara layanan, lan proses iki bisa dadi luwih angel tinimbang padha ing arsitektur monolithic. Ing kasus apa wae, keuntungan saka njupuk pendekatan smallness worth iku.
Pungkasan bagean pisanan.
Ora suwe, kita bakal nerbitake bagean kapindho terjemahan, lan saiki ngenteni komentar lan ngajak sampeyan , sing bakal ditindakake dina iki jam 20.00.
Source: www.habr.com