Hello kawan-kawan. Dalam jangkaan pelancaran kursus , secara tradisinya berkongsi dengan anda terjemahan bahan berguna.
Perisian menyelesaikan lebih banyak tugas harian, sambil menjadi lebih dan lebih kompleks. Seperti yang pernah dikatakan oleh Marc Andressen, ia memakan dunia.
Akibatnya, cara aplikasi dibangunkan dan dihantar telah berubah secara dramatik sejak beberapa tahun lalu. Ini adalah anjakan skala tektonik yang menghasilkan satu set prinsip. Prinsip ini telah terbukti membantu dalam pembinaan pasukan, mereka bentuk, membangunkan dan menyampaikan aplikasi anda kepada pengguna akhir.
Prinsip-prinsip tersebut boleh diringkaskan seperti berikut: aplikasi itu hendaklah kecil, berasaskan web, dan mempunyai seni bina berteraskan pembangun. Dengan mengambil kira ketiga-tiga prinsip ini, anda boleh mencipta aplikasi hujung ke hujung yang mantap yang boleh dihantar dengan cepat dan selamat kepada pengguna akhir, serta mudah berskala dan boleh diperluaskan.
Setiap prinsip yang dicadangkan mempunyai beberapa aspek yang akan kita bincangkan untuk menunjukkan bagaimana setiap prinsip menyumbang kepada matlamat utama, iaitu penyampaian pantas aplikasi yang boleh dipercayai yang mudah diselenggara dan digunakan. Kami akan melihat prinsip berhubung dengan pertentangannya untuk menjelaskan maksudnya, katakan, "Pastikan anda menggunakan prinsip kekecilan'.
Kami berharap artikel ini akan menggalakkan anda menggunakan prinsip yang dicadangkan untuk membina aplikasi moden, yang akan menyediakan pendekatan bersepadu untuk mereka bentuk dalam konteks timbunan teknologi yang semakin berkembang.
Dengan menggunakan prinsip ini, anda akan mendapati diri anda mengambil kesempatan daripada trend terkini dalam pembangunan perisian, termasuk kepada pembangunan dan penghantaran aplikasi, penggunaan bekas (contohnya, ) dan rangka kerja orkestrasi kontena (contohnya, ), penggunaan perkhidmatan mikro (termasuk Seni Bina Perkhidmatan Mikro ΠΈ untuk aplikasi perkhidmatan mikro.
Apakah aplikasi moden?
Aplikasi moden? Timbunan moden? Apa sebenarnya maksud "moden"?
Kebanyakan pembangun hanya mempunyai idea umum tentang apa yang terdiri daripada aplikasi moden, jadi perlu untuk mentakrifkan konsep ini dengan jelas.
Apl moden menyokong berbilang pelanggan, sama ada antara muka pengguna perpustakaan React JavaScript, apl mudah alih Android atau iOS atau apl yang bersambung ke API lain. Aplikasi moden membayangkan bilangan pelanggan yang tidak ditentukan yang mana ia menyediakan data atau perkhidmatan.
Aplikasi moden menyediakan API untuk mengakses data dan perkhidmatan yang diminta. API hendaklah tidak berubah dan tetap, dan tidak ditulis secara khusus untuk permintaan khusus daripada pelanggan tertentu. API tersedia melalui HTTP(S) dan menyediakan akses kepada semua fungsi yang tersedia dalam GUI atau CLI.
Data mesti tersedia dalam format saling kendali yang diterima umum seperti JSON. API mendedahkan objek dan perkhidmatan dengan cara yang bersih dan teratur, seperti RESTful API atau GraphQL menyediakan antara muka yang baik.
Aplikasi moden dibina pada tindanan moden, dan tindanan moden ialah tindanan yang menyokong aplikasi sedemikian, masing-masing. Tindanan ini membolehkan pembangun membuat aplikasi dengan mudah dengan antara muka HTTP dan titik akhir API yang jelas. Pendekatan yang dipilih akan membolehkan aplikasi anda menerima dan menghantar data dalam format JSON dengan mudah. Dalam erti kata lain, timbunan moden sepadan dengan elemen Aplikasi Dua Belas Faktor untuk .
Versi popular bagi jenis tindanan ini adalah berdasarkan , , , , ΠΈ . Seni Bina Perkhidmatan Mikro mewakili contoh susunan moden yang dilaksanakan dalam setiap bahasa yang disebut.
Sila ambil perhatian bahawa kami tidak menyokong pendekatan perkhidmatan mikro secara eksklusif. Ramai daripada anda bekerja dengan monolit yang perlu berkembang, manakala yang lain berurusan dengan aplikasi SOA yang berkembang dan berkembang untuk menjadi aplikasi perkhidmatan mikro. Yang lain sedang bergerak ke arah aplikasi tanpa pelayan, dan ada yang melaksanakan kombinasi di atas. Prinsip yang digariskan dalam artikel digunakan untuk setiap sistem ini dengan hanya beberapa pengubahsuaian kecil.
Prinsip
Memandangkan kita mempunyai pemahaman yang sama tentang aplikasi moden dan timbunan moden, sudah tiba masanya untuk menyelami prinsip seni bina dan pembangunan yang akan membantu anda dengan baik dalam membangunkan, melaksanakan dan mengekalkan aplikasi moden.
Salah satu prinsip berbunyi seperti "buat aplikasi kecil", sebut sahaja prinsip kekecilan. Terdapat aplikasi yang sangat kompleks yang terdiri daripada banyak bahagian yang bergerak. Sebaliknya, membina aplikasi daripada komponen yang kecil dan diskret menjadikannya lebih mudah untuk mereka bentuk, menyelenggara dan bekerja dengannya secara keseluruhan. (Perhatikan bahawa kami berkata "memudahkan" bukan "membuat mudah").
Prinsip kedua ialah kita boleh meningkatkan produktiviti pembangun dengan membantu mereka menumpukan pada ciri yang mereka bangunkan, sambil membebaskan mereka daripada kebimbangan infrastruktur dan CI/CD semasa pelaksanaan. Jadi, secara ringkasnya, pendekatan kami tertumpu kepada pemaju.
Akhir sekali, segala-galanya tentang aplikasi anda mesti disambungkan ke rangkaian. Sepanjang 20 tahun yang lalu, kami telah membuat kemajuan besar ke arah masa depan rangkaian apabila rangkaian menjadi lebih pantas dan aplikasi lebih kompleks. Seperti yang telah kita lihat, aplikasi moden mesti digunakan melalui rangkaian oleh banyak pelanggan yang berbeza. Menggunakan pemikiran rangkaian pada seni bina mempunyai faedah penting yang sesuai dengannya prinsip kekecilan dan konsep pendekatan, berorientasikan pemaju.
Jika anda mengingati prinsip ini semasa mereka bentuk dan melaksanakan aplikasi, anda akan mempunyai kelebihan yang tidak dapat dinafikan dalam pembangunan dan penghantaran produk anda.
Mari kita lihat tiga prinsip ini dengan lebih terperinci.
Prinsip kekecilan
Sukar bagi otak manusia untuk melihat sejumlah besar maklumat pada masa yang sama. Dalam psikologi, istilah beban kognitif merujuk kepada jumlah usaha mental yang diperlukan untuk mengekalkan maklumat dalam ingatan. Mengurangkan beban kognitif pada pembangun adalah keutamaan kerana ia membolehkan mereka menumpukan pada menyelesaikan masalah dan bukannya mengekalkan model kompleks semasa bagi keseluruhan aplikasi dan ciri yang dibangunkan dalam kepala mereka.
Aplikasi terurai atas sebab berikut:
- Mengurangkan beban kognitif pada pembangun;
- Pecutan dan pemudahan ujian;
- Penghantaran cepat perubahan dalam aplikasi.
Terdapat beberapa cara untuk mengurangkan beban kognitif pada pembangun, dan di sinilah prinsip kekecilan dimainkan.
Jadi berikut adalah tiga cara untuk mengurangkan beban kognitif:
- Kurangkan tempoh masa yang perlu mereka pertimbangkan semasa membangunkan ciri baharu β lebih pendek tempoh masa, lebih rendah beban kognitif.
- Kurangkan jumlah kod yang mana kerja sekali dijalankan - kurang kod - kurang beban.
- Permudahkan proses membuat perubahan tambahan pada aplikasi.
Mengurangkan jangka masa pembangunan
Mari kita kembali ke zaman ketika metodologi waterfall adalah standard untuk proses pembangunan, dan tempoh masa enam bulan hingga dua tahun untuk membangunkan atau mengemas kini aplikasi adalah amalan biasa. Lazimnya, jurutera akan terlebih dahulu membaca dokumen yang berkaitan seperti keperluan produk (PRD), dokumen rujukan sistem (SRD), pelan tindakan seni bina, dan mula menggabungkan semua perkara ini bersama-sama menjadi satu model kognitif, mengikut yang mereka kodkan. Oleh kerana keperluan dan, akibatnya, seni bina berubah, usaha yang serius perlu dibuat untuk memaklumkan kepada seluruh pasukan tentang kemas kini kepada model kognitif. Pendekatan sedemikian, paling teruk, hanya boleh melumpuhkan kerja.
Perubahan terbesar dalam proses pembangunan aplikasi ialah pengenalan metodologi tangkas. Salah satu ciri utama metodologi agile adalah perkembangan berulang. Seterusnya, ini membawa kepada pengurangan beban kognitif pada jurutera. Daripada memerlukan pasukan pembangunan untuk melaksanakan aplikasi dalam satu kitaran panjang, agile pendekatan membolehkan anda menumpukan pada sejumlah kecil kod yang boleh diuji dan digunakan dengan cepat, sambil turut menerima maklum balas. Muatan kognitif apl telah beralih daripada jangka masa enam bulan kepada dua tahun dengan sejumlah besar spesifikasi untuk penambahan dua minggu atau perubahan ciri yang menyasarkan pemahaman yang lebih kabur tentang aplikasi besar.
Mengalihkan fokus daripada aplikasi besar-besaran kepada ciri kecil tertentu yang boleh dilengkapkan dalam pecut dua minggu, dengan tidak lebih daripada satu ciri sebelum pecut seterusnya dalam fikiran, adalah perubahan yang ketara. Ini membolehkan kami meningkatkan produktiviti pembangunan sambil mengurangkan beban kognitif, yang sentiasa berubah-ubah.
Dalam metodologi agile aplikasi akhir dijangka menjadi versi yang diubah suai sedikit daripada konsep asal, jadi titik akhir pembangunan semestinya tidak jelas. Hanya keputusan setiap pecut tertentu boleh jelas dan tepat.
Pangkalan kod kecil
Langkah seterusnya dalam mengurangkan beban kognitif ialah mengurangkan pangkalan kod. Sebagai peraturan, aplikasi moden adalah besar - aplikasi perusahaan yang teguh boleh terdiri daripada beribu-ribu fail dan ratusan ribu baris kod. Bergantung pada cara fail disusun, pautan dan kebergantungan antara kod dan fail mungkin jelas, atau sebaliknya. Malah pelaksanaan kod penyahpepijatan itu sendiri boleh menjadi masalah, bergantung pada perpustakaan yang digunakan dan sejauh mana alat penyahpepijatan membezakan antara perpustakaan/pakej/modul dan kod tersuai.
Membina model mental yang berfungsi bagi kod aplikasi boleh mengambil masa yang mengagumkan, dan sekali lagi meletakkan beban kognitif yang besar kepada pembangun. Ini adalah benar terutamanya untuk asas kod monolitik, di mana terdapat sejumlah besar kod, interaksi antara komponen fungsi yang tidak ditakrifkan dengan jelas, dan pemisahan objek perhatian sering kabur kerana sempadan fungsi tidak dihormati.
Salah satu cara yang berkesan untuk mengurangkan beban kognitif pada jurutera ialah beralih kepada seni bina perkhidmatan mikro. Dalam pendekatan perkhidmatan mikro, setiap perkhidmatan memfokuskan pada satu set ciri; manakala makna perkhidmatan biasanya ditakrifkan dan difahami. Sempadan perkhidmatan juga jelas - ingat bahawa komunikasi dengan perkhidmatan dilakukan melalui API, jadi data yang dijana oleh satu perkhidmatan boleh dihantar ke perkhidmatan lain dengan mudah.
Interaksi dengan perkhidmatan lain biasanya terhad kepada beberapa perkhidmatan pengguna dan beberapa perkhidmatan pembekal yang menggunakan panggilan API yang mudah dan bersih, seperti menggunakan REST. Ini bermakna beban kognitif pada jurutera dikurangkan dengan serius. Cabaran terbesar kekal memahami model interaksi perkhidmatan dan cara perkara seperti transaksi berlaku merentas pelbagai perkhidmatan. Akibatnya, penggunaan perkhidmatan mikro mengurangkan beban kognitif dengan mengurangkan jumlah kod, mentakrifkan sempadan perkhidmatan yang jelas dan memberikan pemahaman tentang hubungan antara pengguna dan pembekal.
Perubahan tambahan kecil
Elemen terakhir prinsip kekecilan ialah pengurusan perubahan. Ini adalah godaan khusus bagi pembangun untuk melihat asas kod (walaupun mungkin kod lama mereka sendiri) dan berkata, "Ini omong kosong, kita perlu menulis semula semuanya." Kadang-kadang ini adalah keputusan yang betul, dan kadang-kadang tidak. Ia meletakkan beban perubahan model global kepada pasukan pembangunan, yang seterusnya membawa kepada beban kognitif yang besar. Adalah lebih baik untuk jurutera memberi tumpuan kepada perubahan yang boleh mereka lakukan semasa pecut, supaya mereka boleh melancarkan fungsi yang diperlukan tepat pada masanya, walaupun secara beransur-ansur. Produk akhir harus menyerupai yang telah dirancang, tetapi dengan beberapa pengubahsuaian dan ujian untuk memenuhi keperluan pelanggan.
Apabila menulis semula sebahagian besar kod, kadangkala tidak mungkin untuk menyampaikan perubahan dengan cepat kerana kebergantungan sistem lain turut dimainkan. Untuk mengawal aliran perubahan, anda boleh menggunakan penyembunyian ciri. Pada dasarnya, ini bermakna fungsi itu sedang dalam pengeluaran, tetapi ia tidak tersedia menggunakan tetapan pembolehubah persekitaran (env-var) atau beberapa mekanisme konfigurasi lain. Jika kod tersebut telah melepasi semua proses kawalan kualiti, maka ia mungkin berakhir dalam pengeluaran dalam keadaan terpendam. Walau bagaimanapun, strategi ini hanya berfungsi jika ciri itu akhirnya didayakan. Jika tidak, ia hanya akan mengacaukan kod dan menambah beban kognitif yang perlu ditangani oleh pembangun untuk menjadi produktif. Pengurusan perubahan dan perubahan tambahan itu sendiri membantu mengekalkan beban kognitif pembangun pada tahap yang berpatutan.
Jurutera perlu mengatasi banyak kesukaran walaupun dengan pengenalan mudah fungsi tambahan. Di pihak pengurusan, adalah bijak untuk mengurangkan beban yang tidak perlu kepada pasukan supaya ia boleh memberi tumpuan kepada elemen fungsi utama. Terdapat tiga perkara yang boleh anda lakukan untuk membantu pasukan pembangunan anda:
- Gunakan metodologi
agileuntuk mengehadkan jangka masa di mana pasukan mesti memberi tumpuan kepada ciri-ciri utama. - Laksanakan aplikasi anda sebagai berbilang perkhidmatan mikro. Ini akan mengehadkan bilangan ciri yang boleh dilaksanakan dan mengukuhkan sempadan yang mengekalkan beban kognitif di tempat kerja.
- Lebih suka perubahan tambahan daripada besar dan sukar digunakan, tukar kepingan kecil kod. Gunakan penyembunyian ciri untuk melaksanakan perubahan walaupun perubahan itu tidak akan kelihatan serta-merta selepas ditambah.
Jika anda menggunakan prinsip kekecilan dalam kerja anda, pasukan anda akan menjadi lebih gembira, lebih fokus pada pelaksanaan ciri yang diperlukan dan lebih berkemungkinan melancarkan perubahan kualitatif dengan lebih cepat. Tetapi ini tidak bermakna kerja itu tidak boleh menjadi lebih rumit, kadangkala, sebaliknya, pengenalan fungsi baharu memerlukan pengubahsuaian beberapa perkhidmatan, dan proses ini boleh menjadi lebih sukar daripada yang serupa dalam seni bina monolitik. Walau apa pun, faedah mengambil pendekatan kekecilan adalah berbaloi.
Akhir bahagian pertama.
Tidak lama lagi kami akan menerbitkan bahagian kedua terjemahan, dan kini kami sedang menunggu komen anda dan menjemput anda , yang akan berlangsung hari ini pada jam 20.00.
Sumber: www.habr.com