Halo teman teman. Untuk mengantisipasi peluncuran kursus , secara tradisional berbagi dengan Anda terjemahan materi yang bermanfaat.
Perangkat lunak menyelesaikan lebih banyak tugas sehari-hari, sekaligus menjadi semakin kompleks. Seperti yang pernah dikatakan Marc Andressen, itu menghabiskan dunia.
Akibatnya, cara aplikasi dikembangkan dan disampaikan telah berubah secara dramatis selama beberapa tahun terakhir. Ini adalah pergeseran skala tektonik yang menghasilkan serangkaian prinsip. Prinsip-prinsip ini telah terbukti membantu dalam membangun tim, merancang, mengembangkan, dan mengirimkan aplikasi Anda ke pengguna akhir.
Prinsip-prinsip tersebut dapat diringkas sebagai berikut: aplikasi harus kecil, berbasis web, dan memiliki arsitektur yang berpusat pada pengembang. Dengan mempertimbangkan ketiga prinsip ini, Anda dapat membuat aplikasi end-to-end yang tangguh yang dapat dikirimkan dengan cepat dan aman ke pengguna akhir, serta mudah diskalakan dan diperluas.
Setiap prinsip yang diusulkan memiliki sejumlah aspek yang akan kita bahas untuk menunjukkan bagaimana setiap prinsip berkontribusi pada tujuan akhir, yaitu pengiriman cepat aplikasi andal yang mudah dipelihara dan digunakan. Kami akan melihat prinsip-prinsip dalam kaitannya dengan kebalikannya untuk mengklarifikasi apa artinya, katakanlah, "Pastikan Anda menggunakan prinsip kekecilan'.
Kami berharap artikel ini akan mendorong Anda untuk menggunakan prinsip-prinsip yang diusulkan untuk membangun aplikasi modern, yang akan memberikan pendekatan terpadu untuk mendesain dalam konteks tumpukan teknologi yang terus berkembang.
Dengan menerapkan prinsip-prinsip ini, Anda akan mendapatkan keuntungan dari tren terbaru dalam pengembangan perangkat lunak, termasuk untuk pengembangan dan pengiriman aplikasi, penggunaan wadah (misalnya, ) dan kerangka orkestrasi wadah (misalnya, ), penggunaan layanan mikro (termasuk Arsitektur Layanan Mikro ΠΈ untuk aplikasi layanan mikro.
Apa itu aplikasi modern?
Aplikasi modern? Tumpukan modern? Apa sebenarnya yang dimaksud dengan "modern"?
Sebagian besar pengembang hanya memiliki gambaran umum tentang apa yang terdiri dari aplikasi modern, jadi konsep ini perlu didefinisikan dengan jelas.
Aplikasi modern mendukung banyak klien, baik itu antarmuka pengguna perpustakaan React JavaScript, aplikasi seluler Android atau iOS, atau aplikasi yang terhubung ke API lain. Aplikasi modern menyiratkan jumlah klien yang tidak terbatas yang menyediakan data atau layanan.
Aplikasi modern menyediakan API untuk mengakses data dan layanan yang diminta. API harus tetap dan konstan, dan tidak ditulis secara khusus untuk permintaan khusus dari klien tertentu. API tersedia melalui HTTP(S) dan menyediakan akses ke semua fungsionalitas yang tersedia di GUI atau CLI.
Data harus tersedia dalam format interoperabilitas yang diterima secara umum seperti JSON. API memaparkan objek dan layanan dengan cara yang bersih dan terorganisir, seperti RESTful API atau GraphQL menyediakan antarmuka yang layak.
Aplikasi modern dibangun di atas tumpukan modern, dan tumpukan modern adalah tumpukan yang masing-masing mendukung aplikasi semacam itu. Tumpukan ini memungkinkan pengembang untuk dengan mudah membuat aplikasi dengan antarmuka HTTP dan titik akhir API yang jelas. Pendekatan yang dipilih akan memungkinkan aplikasi Anda dengan mudah menerima dan mengirim data dalam format JSON. Dengan kata lain, tumpukan modern sesuai dengan elemen Aplikasi Dua Belas Faktor untuk .
Versi populer dari jenis tumpukan ini didasarkan pada , , , , ΠΈ . Arsitektur Layanan Mikro mewakili contoh tumpukan modern yang diterapkan di setiap bahasa yang disebutkan.
Harap perhatikan bahwa kami tidak menganjurkan pendekatan layanan mikro secara eksklusif. Banyak dari Anda bekerja dengan monolit yang perlu berevolusi, sementara yang lain berurusan dengan aplikasi SOA yang berkembang dan berkembang menjadi aplikasi layanan mikro. Yang lain lagi beralih ke aplikasi tanpa server, dan beberapa menerapkan kombinasi di atas. Prinsip-prinsip yang diuraikan dalam artikel berlaku untuk masing-masing sistem ini dengan hanya sedikit modifikasi.
Prinsip
Sekarang setelah kita memiliki pemahaman yang sama tentang apa itu aplikasi modern dan stack modern, saatnya untuk mendalami arsitektur dan prinsip pengembangan yang akan membantu Anda dengan baik dalam mengembangkan, mengimplementasikan, dan memelihara aplikasi modern.
Salah satu prinsipnya terdengar seperti "buat aplikasi kecil", sebut saja begitu prinsip kekecilan. Ada aplikasi yang sangat kompleks yang terdiri dari banyak bagian yang bergerak. Pada gilirannya, membuat aplikasi dari komponen kecil dan terpisah membuatnya lebih mudah untuk merancang, memelihara, dan bekerja dengannya secara keseluruhan. (Perhatikan bahwa kami mengatakan "menyederhanakan" bukan "membuat sederhana").
Prinsip kedua adalah kami dapat meningkatkan produktivitas pengembang dengan membantu mereka fokus pada fitur yang mereka kembangkan, sekaligus membebaskan mereka dari masalah infrastruktur dan CI/CD selama implementasi. Jadi, singkatnya, pendekatan kami terfokus pada pengembang.
Akhirnya, segala sesuatu tentang aplikasi Anda harus terhubung ke jaringan. Selama 20 tahun terakhir, kami telah membuat langkah besar menuju masa depan jaringan karena jaringan menjadi lebih cepat dan aplikasi menjadi lebih kompleks. Seperti yang telah kita lihat, aplikasi modern harus digunakan melalui jaringan oleh banyak klien yang berbeda. Menerapkan pemikiran jaringan ke arsitektur memiliki manfaat signifikan yang sejalan prinsip kekecilan dan konsep pendekatan berorientasi pengembang.
Jika Anda mengingat prinsip-prinsip ini saat merancang dan mengimplementasikan aplikasi, Anda akan memiliki keuntungan yang tak terbantahkan dalam pengembangan dan pengiriman produk Anda.
Mari kita lihat ketiga prinsip ini lebih detail.
Prinsip kekecilan
Sulit bagi otak manusia untuk memahami sejumlah besar informasi pada saat yang bersamaan. Dalam psikologi, istilah beban kognitif mengacu pada jumlah total upaya mental yang diperlukan untuk mempertahankan informasi dalam memori. Mengurangi beban kognitif pada pengembang adalah prioritas karena memungkinkan mereka untuk fokus pada penyelesaian masalah alih-alih menyimpan model kompleks saat ini dari seluruh aplikasi dan fitur yang sedang dikembangkan di kepala mereka.
Aplikasi terurai karena alasan berikut:
- Mengurangi beban kognitif pada pengembang;
- Percepatan dan penyederhanaan pengujian;
- Pengiriman cepat perubahan dalam aplikasi.
Ada beberapa cara untuk mengurangi beban kognitif pada pengembang, dan di sinilah prinsip kekecilan berperan.
Jadi, inilah tiga cara untuk mengurangi beban kognitif:
- Kurangi kerangka waktu yang harus mereka pertimbangkan saat mengembangkan fitur baru β semakin pendek kerangka waktunya, semakin rendah beban kognitifnya.
- Kurangi jumlah kode yang melakukan pekerjaan satu kali - lebih sedikit kode - lebih sedikit beban.
- Menyederhanakan proses pembuatan perubahan inkremental pada aplikasi.
Mengurangi kerangka waktu pengembangan
Mari kita kembali ke hari-hari ketika metodologi waterfall adalah standar untuk proses pengembangan, dan kerangka waktu enam bulan hingga dua tahun untuk mengembangkan atau memperbarui aplikasi adalah praktik umum. Biasanya, para insinyur pertama-tama akan membaca dokumen yang relevan seperti persyaratan produk (PRD), dokumen referensi sistem (SRD), cetak biru arsitektur, dan mulai menggabungkan semua hal ini bersama-sama menjadi satu model kognitif, yang menurut kode mereka. Karena persyaratan dan, akibatnya, arsitektur berubah, upaya serius harus dilakukan untuk memberi tahu seluruh tim tentang pembaruan model kognitif. Pendekatan seperti itu, paling buruk, bisa melumpuhkan pekerjaan.
Perubahan terbesar dalam proses pengembangan aplikasi adalah pengenalan metodologi tangkas. Salah satu fitur utama dari metodologi agile merupakan pengembangan berulang. Pada gilirannya, ini mengarah pada pengurangan beban kognitif pada insinyur. Alih-alih meminta tim pengembangan untuk mengimplementasikan aplikasi dalam satu siklus panjang, agile pendekatan memungkinkan Anda untuk fokus pada sejumlah kecil kode yang dapat dengan cepat diuji dan diterapkan, sambil menerima umpan balik. Beban kognitif aplikasi telah bergeser dari kerangka waktu enam bulan menjadi dua tahun dengan sejumlah besar spesifikasi untuk penambahan dua minggu atau perubahan fitur yang menargetkan pemahaman yang lebih kabur tentang aplikasi besar.
Mengalihkan fokus dari aplikasi masif ke fitur kecil spesifik yang dapat diselesaikan dalam sprint dua minggu, dengan tidak lebih dari satu fitur di depan sprint berikutnya, merupakan perubahan yang signifikan. Ini memungkinkan kami untuk meningkatkan produktivitas pengembangan sambil mengurangi beban kognitif, yang terus berfluktuasi.
Dalam metodologi agile aplikasi terakhir diharapkan menjadi versi yang sedikit dimodifikasi dari konsep aslinya, sehingga titik akhir pengembangannya pasti ambigu. Hanya hasil dari setiap sprint tertentu yang bisa jelas dan tepat.
Basis kode kecil
Langkah selanjutnya dalam mengurangi beban kognitif adalah mengurangi basis kode. Sebagai aturan, aplikasi modern sangat besar - aplikasi perusahaan yang kuat dapat terdiri dari ribuan file dan ratusan ribu baris kode. Bergantung pada bagaimana file diatur, tautan dan ketergantungan antara kode dan file mungkin terlihat jelas, atau sebaliknya. Bahkan eksekusi kode debug itu sendiri dapat menimbulkan masalah, tergantung pada pustaka yang digunakan dan seberapa baik alat debug membedakan antara pustaka/paket/modul dan kode khusus.
Membangun model mental yang berfungsi dari kode aplikasi dapat menghabiskan banyak waktu, dan sekali lagi menempatkan beban kognitif yang besar pada pengembang. Hal ini terutama berlaku untuk basis kode monolitik, di mana terdapat sejumlah besar kode, interaksi antara komponen fungsional yang tidak didefinisikan dengan jelas, dan pemisahan objek perhatian sering kabur karena batas fungsional tidak dihormati.
Salah satu cara efektif untuk mengurangi beban kognitif para insinyur adalah beralih ke arsitektur layanan mikro. Dalam pendekatan layanan mikro, setiap layanan berfokus pada satu set fitur; sedangkan arti dari layanan biasanya didefinisikan dan dimengerti. Batasan layanan juga jelas - ingat bahwa komunikasi dengan layanan dilakukan melalui API, sehingga data yang dihasilkan oleh satu layanan dapat dengan mudah diteruskan ke layanan lainnya.
Interaksi dengan layanan lain biasanya terbatas pada beberapa layanan pengguna dan beberapa layanan penyedia yang menggunakan panggilan API yang sederhana dan bersih, seperti menggunakan REST. Ini berarti beban kognitif pada insinyur berkurang secara serius. Tantangan terbesar tetap memahami model interaksi layanan dan bagaimana hal-hal seperti transaksi terjadi di berbagai layanan. Hasilnya, penggunaan layanan mikro mengurangi beban kognitif dengan mengurangi jumlah kode, menentukan batasan layanan yang jelas, dan memberikan pemahaman tentang hubungan antara pengguna dan penyedia.
Perubahan bertahap kecil
Elemen terakhir dari prinsip kekecilan adalah manajemen perubahan. Merupakan godaan khusus bagi pengembang untuk melihat basis kode (bahkan mungkin kode mereka sendiri yang lebih lama) dan berkata, "Ini omong kosong, kita perlu menulis ulang semuanya." Terkadang ini adalah keputusan yang tepat, dan terkadang tidak. Ini menempatkan beban perubahan model global pada tim pengembangan, yang pada gilirannya menyebabkan beban kognitif yang sangat besar. Lebih baik bagi para insinyur untuk fokus pada perubahan yang dapat mereka lakukan selama sprint, sehingga mereka dapat meluncurkan fungsionalitas yang diperlukan secara tepat waktu, meskipun secara bertahap. Produk akhir harus menyerupai produk yang telah direncanakan sebelumnya, tetapi dengan beberapa modifikasi dan pengujian yang sesuai dengan kebutuhan klien.
Saat menulis ulang sebagian besar kode, kadang-kadang tidak mungkin untuk mengirimkan perubahan dengan cepat karena ketergantungan sistem lain ikut berperan. Untuk mengontrol aliran perubahan, Anda dapat menggunakan penyembunyian fitur. Pada prinsipnya, ini berarti fungsionalitas sedang dalam produksi, tetapi tidak tersedia menggunakan pengaturan variabel lingkungan (env-var) atau mekanisme konfigurasi lainnya. Jika kode telah melewati semua proses kontrol kualitas, maka kode tersebut mungkin berakhir dalam produksi dalam keadaan laten. Namun, strategi ini hanya berfungsi jika fitur tersebut akhirnya diaktifkan. Jika tidak, itu hanya akan mengacaukan kode dan menambah beban kognitif yang harus dihadapi pengembang agar menjadi produktif. Manajemen perubahan dan perubahan inkremental itu sendiri membantu menjaga beban kognitif pengembang pada tingkat yang terjangkau.
Insinyur harus mengatasi banyak kesulitan bahkan dengan pengenalan fungsi tambahan yang sederhana. Di pihak manajemen, akan lebih bijaksana untuk mengurangi beban yang tidak perlu pada tim sehingga dapat fokus pada elemen fungsional utama. Ada tiga hal yang dapat Anda lakukan untuk membantu tim pengembangan Anda:
- Gunakan metodologi
agileuntuk membatasi kerangka waktu di mana tim harus fokus pada fitur-fitur utama. - Terapkan aplikasi Anda sebagai beberapa layanan mikro. Ini akan membatasi jumlah fitur yang dapat diimplementasikan dan memperkuat batasan yang membuat beban kognitif tetap bekerja.
- Lebih suka perubahan inkremental daripada yang besar dan berat, ubah potongan kode kecil. Gunakan penyembunyian fitur untuk menerapkan perubahan meskipun tidak segera terlihat setelah menambahkannya.
Jika Anda menerapkan prinsip kekerdilan dalam pekerjaan Anda, tim Anda akan jauh lebih bahagia, lebih fokus dalam mengimplementasikan fitur yang diperlukan, dan lebih mungkin meluncurkan perubahan kualitatif lebih cepat. Tetapi ini tidak berarti bahwa pekerjaan tidak dapat menjadi lebih rumit, terkadang, sebaliknya, pengenalan fungsionalitas baru memerlukan modifikasi beberapa layanan, dan proses ini bisa lebih sulit daripada yang serupa dalam arsitektur monolitik. Bagaimanapun, manfaat mengambil pendekatan kecil itu sepadan.
Akhir dari bagian pertama.
Segera kami akan menerbitkan terjemahan bagian kedua, dan sekarang kami menunggu komentar Anda dan mengundang Anda untuk , yang akan berlangsung hari ini pukul 20.00.
Sumber: www.habr.com