Panduan Pengembangan Berbasis Komponen

Modularitas telah menjadi salah satu prinsip utama pengembangan perangkat lunak sejak 1960-an. Menerapkan prinsip ini membawa banyak manfaat bagi pemrograman. Modularitas berkontribusi pada penggunaan efektif prinsip pemisahan tanggung jawab, yang mengarah pada peningkatan kemampuan untuk membuat, menggunakan kembali, membangun kode.

Saat ini, penerapan prinsip modularitas dalam desain perangkat lunak telah mengambil bentuk baru, yang terkandung dalam komponen. Ini adalah Component Driven Development (CDD). Pustaka dan kerangka kerja modern untuk mengembangkan antarmuka pengguna, seperti React , Vue, dan Angular , serta alat yang berorientasi CDD seperti Bit , memungkinkan Anda membuat aplikasi berdasarkan komponen modular. Pemrogram memiliki kemampuan dan pola yang diperlukan untuk mengembangkan komponen dalam isolasi dan membangun komposisi komponen.


Komponen adalah fragmen independen yang jelas dari antarmuka aplikasi. Sebagai contoh komponen, Anda dapat mengutip entitas seperti tombol, slider, jendela untuk menampilkan pesan obrolan. Memahami fitur-fitur CDD dan mengetahui cara menerapkan pendekatan ini untuk pengembangan, kita dapat menggunakan komponen sebagai dasar aplikasi. Ini, ketika membuat proyek perangkat lunak, memberi kita segala sesuatu yang berguna, yang berarti menerapkan prinsip-prinsip pemrograman modular.

Jika Anda melihat dengan cermat apa yang terjadi sekarang di bidang komponen web , Anda akan melihat bahwa CDD menjadi pendekatan standar untuk pengembangan frontend.

Bahan, yang kami terbitkan terjemahan hari ini, adalah panduan pengembangan berbasis komponen.

CDD dalam pengembangan antarmuka pengguna

Bekerja pada Bit: membuat, mengisolasi, menggunakan kembali, dan berkolaborasi pada komponen

Sederhananya, pengembangan berbasis komponen mendesain aplikasi dengan membuat blok kode independen yang digabungkan secara longgar. Masing-masing dari mereka memiliki antarmuka yang dirancang untuk mengatur interaksi dengan bagian lain dari sistem. Banyak komponen, dikombinasikan satu sama lain melalui komposisi, membentuk aplikasi modular.

Misalnya, penggunaan CDD dalam membuat aplikasi Bereaksi berarti bahwa mereka pertama-tama membuat komponen yang membentuk dasar dari aplikasi, dan kemudian melanjutkan untuk mengumpulkan dari mereka bagian-bagian aplikasi yang lebih besar, seperti seluruh halaman dan blok besar fungsionalitas.

CDD terkait dengan desain atom (di sini adalah materi yang berguna tentang topik ini) dan dengan pendekatan untuk mengembangkan bagian sisi klien dari proyek web, yang dikenal sebagai " micro frontend ".

CDD membantu memecah proses pengembangan proyek besar menjadi proses pengembangan yang lebih kecil untuk komponen individu. Setiap komponen dirancang secara independen dari sisa aplikasi dan dibuat dengan mempertimbangkan kemungkinan interaksi dengan bagian lain dari sistem. Merancang setiap komponen sebagai entitas independen memberi pengembang banyak fitur yang bermanfaat.

Eddie Osmani menguraikan beberapa manfaat utama menggunakan CDD. Dia merancang mereka dalam seperangkat prinsip yang disebut PERTAMA .

Prinsip-prinsip ini adalah:

• Akselerasi pembangunan (Faster development). Fakta bahwa upaya pengembang ditujukan untuk membuat komponen terpisah memungkinkan pembuatan bagian modular aplikasi dengan API yang sangat terspesialisasi. Ini berarti bahwa komponen dapat, di satu sisi, dikembangkan dengan cepat, dan di sisi lain, bahwa lebih mudah untuk mengembangkannya ke tingkat kualitas yang dibutuhkan oleh proyek ketika mereka dikembangkan.
• Penyederhanaan dukungan (Perawatan lebih mudah). Ketika Anda perlu memodifikasi atau memperbarui bagian dari aplikasi, Anda dapat memperluas atau memperbarui komponen, daripada refactoring sebagian besar aplikasi. Ini dapat dibandingkan dengan prosedur medis, dengan operasi pada organ yang terpisah, menggantikan operasi yang melibatkan intervensi di hampir semua bagian tubuh.
• Kemampuan menggunakan kembali kode yang lebih baik. Karena penggunaan prinsip pemisahan tanggung jawab, komponen, selama pembuatan aplikasi selesai dari mereka, dapat digunakan kembali atau diperluas. Ini jauh lebih baik daripada kebutuhan untuk menulis ulang mereka lagi dan lagi ( inilah bahan pada topik ini).
• Meningkatkan kemampuan untuk menerapkan metodologi TDD (Better TDD). Selama pengembangan komponen modular, jauh lebih mudah daripada menggunakan pendekatan lain untuk mengimplementasikan tes unit yang bertujuan memverifikasi fungsionalitas komponen yang sempit. Hasilnya, ternyata lebih mudah untuk menguji sistem besar yang dirakit dari komponen. Faktanya adalah bahwa ketika menggunakan pendekatan modular, lebih mudah bagi pengembang untuk memahami apa tepatnya yang menjadi tanggung jawab satu atau beberapa bagian dari sistem.
• Kurva pembelajaran pemendek (Kurva belajar lebih pendek). Ketika seorang pengembang harus berurusan dengan proyek baru untuknya, ternyata lebih mudah untuk memahami esensi dan struktur komponen individu daripada mempelajari seluk-beluk seluruh proyek.
• Meningkatkan kemampuan sistem pemodelan (Pemodelan sistem yang lebih baik). Ketika sistem dibuat dari komponen modular, pengembang akan lebih mudah memahami struktur umum sistem, memahaminya, dan belajar bagaimana mempengaruhinya.

Alat CDD

Jika pengembangan didasarkan pada komponen, ini berarti bahwa programmer membutuhkan alat khusus. Alat-alat tersebut ditujukan untuk membuat komponen, mengujinya, mengatur akses umum ke sana, dan mendukung kolaborasi dengannya.

Secara khusus, penting untuk merancang dan menguji komponen secara terpisah. Ini memungkinkan mereka untuk bekerja dalam bentuk unit independen yang dapat digunakan dalam aplikasi. Selain itu, dukungan untuk penggunaan kembali komponen dan kemampuan untuk membagikannya juga penting. Ini memungkinkan seseorang yang bekerja sebagai bagian dari tim pada proyek besar untuk tidak menemukan kembali roda, yang, dalam bentuk komponen, telah ditemukan oleh salah satu anggota tim.

Berikut adalah beberapa alat yang berguna untuk membantu Anda mengatur pekerjaan Anda pada proyek gaya CDD. Dalam salah satu bagian berikut, kita akan berbicara tentang arsitektur proyek yang direkomendasikan untuk implementasi praktis prinsip-prinsip CDD.

▍Bit: pengembangan komponen dan individu

Bit adalah alat open source , yang pada dasarnya dibuat untuk mendukung aplikasi praktis dari metodologi CDD. Ini adalah video tentang Bit. Alat ini membantu Anda mengembangkan komponen, berkolaborasi dengannya, dan membuat proyek web menggunakannya.

Intinya adalah bahwa dengan Bit berarti Anda dapat mengisolasi komponen yang sedang dikembangkan sebagai bagian dari proyek. Katakan - dalam aplikasi atau perpustakaan. Bit mendukung alat baris perintah, ini membantu mengatur enkapsulasi komponen dengan semua file dan dependensinya. Bit memungkinkan Anda untuk mengembangkan dan menguji representasi virtual dari komponen yang dienkapsulasi secara terpisah.

Ini berarti bahwa komponen yang dibuat dalam aplikasi dapat dilengkapi dengan semua dependensinya, dienkapsulasi dan diubah menjadi entitas yang dapat digunakan dan diuji di luar aplikasi.

Lebih lanjut, Bit memungkinkan Anda untuk mengemas komponen yang terpisah dan dienkapsulasi dan mengatur pembagiannya menggunakan alat cloud . Ini memungkinkan tim yang mengerjakan proyek untuk menggunakan semua komponen yang dibagikan. Komunitas Bit memiliki sekitar 50.000 pengembang. Upaya mereka menciptakan ribuan komponen sumber terbuka yang tersedia untuk semua orang.


Pengembangan proyek menggunakan komponen yang dienkapsulasi

Berkat kemampuan platform cloud, tim pengembangan dapat menginstal komponen sumber terbuka di aplikasi mereka. Anggota tim juga dapat menawarkan gagasan pembuat komponen untuk meningkatkan komponen dengan melakukannya langsung dari lingkungan kerja mereka. Bit memperluas kemampuan Git untuk melacak dan menyinkronkan perubahan kode sumber komponen di seluruh proyek. Ini memberi pengembang kemampuan untuk mengelola perubahan dan pembaruan komponen.

Bit menyimpan pohon dependensi komponen yang lengkap. Ini memberi pengembang kesempatan untuk belajar tentang cara memperbarui komponen yang dapat memengaruhi komponen dependen, tentang apa yang mungkin “rusak” dalam suatu proyek ketika perubahan dilakukan pada suatu komponen. Ini berarti bahwa, terima kasih kepada Bit, pemrogram memiliki kemampuan penuh untuk mengatur pengembangan berdasarkan komponen, memungkinkan Anda untuk membuat komponen, menguji mereka dan mengatur kerja bersama pada mereka dan penggunaan bersama mereka.


Kemampuan cloud dalam CDD

Fitur lain yang berguna dari Bit adalah bahwa platform ini memungkinkan tim pengembangan tidak hanya untuk bekerja dengan komponen mereka menggunakan antarmuka tunggal, tetapi juga untuk menggunakan komponen lain yang diletakkan dalam domain publik dan untuk berinteraksi dengan pembuat komponen ini.

Desainer antarmuka, perwakilan dari proyek pelanggan, serta pemrogram dapat, dalam pekerjaan bersama pada proyek, menggunakan alat visual yang umum. Ini menjembatani kesenjangan antara desainer dan programmer. Selain itu, perlu dicatat bahwa dalam situasi ini tidak hanya manfaat desainer dan programer, tetapi juga pengguna akhir aplikasi yang mengalami lebih sedikit heterogenitas dan kesalahan. Di sini , di sini dan di sini adalah beberapa materi tentang berbagai aspek penggunaan Bit.

▍ Pengembangan dan penelitian komponen UI: Storybook dan Styleguidist

StoryBook dan Styleguidist adalah lingkungan untuk mengembangkan elemen antarmuka pengguna dengan cepat menggunakan React. Kedua proyek ini adalah alat yang hebat untuk mempercepat pengembangan komponen.

Buku cerita

StoryBook adalah lingkungan untuk mengembangkan komponen UI dengan cepat. Ini memungkinkan Anda untuk bekerja dengan perpustakaan komponen, melihat berbagai status komponen, terlibat dalam pengembangan interaktif dan pengujian komponen.


Bekerja di StoryBook

StoryBook membantu merancang komponen secara terpisah dari aplikasi. Ini membantu meningkatkan reusability komponen dan meningkatkan testability komponen.

Menggunakan StoryBook, Anda dapat melihat komponen yang disimpan di perpustakaan, dan bereksperimen dengan propertinya secara online. Perubahan yang dilakukan pada komponen segera, tanpa memuat ulang halaman, divisualisasikan. Berikut adalah beberapa contoh komponen yang dibuat di StoryBook.

Ada berbagai plugin yang dapat mempercepat pengembangan komponen menggunakan StoryBook. Ini memungkinkan Anda untuk mengurangi waktu yang berlalu antara mengubah kode komponen dan pembentukan representasi visualnya. Perlu dicatat bahwa StoryBook, selain Bereaksi, juga mendukung Bereaksi Asli dan Vue.js.

Bereaksi styleguidist

Bereaksi Styleguidist adalah lingkungan pengembangan komponen. Lingkungan ini berisi server pengembangan yang mendukung boot panas. Ini juga memiliki sistem manajemen gaya interaktif yang menampilkan propTypes komponen dan menyediakan pengembang dengan contoh yang dapat diedit dari penggunaan komponen berdasarkan file .md.


Bereaksi styleguidist

Platform ini mendukung JavaScript ES6, Flow, dan TypeScript. Dia dapat, tanpa pengaturan tambahan, untuk bekerja dengan Aplikasi Buat Bereaksi. Styleguidist memiliki kemampuan untuk secara otomatis membuat dokumentasi komponen. Ini memungkinkan sistem ini untuk memainkan peran portal dokumentasi visual untuk komponen yang sedang dikerjakan oleh beberapa tim.

Jika Anda tertarik pada proyek seperti StoryBook dan Styleguidist, maka Anda mungkin ingin melihat proyek React Live , yang sedang dikembangkan oleh Formidable.

Perbedaan antara Storybook dan Styleguidist

Saat bekerja dengan StoryBook, seorang programmer menulis "cerita" dalam file JavaScript. Ketika bekerja dengan Stuleguidist, ia menulis "contoh" dalam file Markdown. Sementara Storybook hanya menampilkan satu variasi komponen pada satu waktu, Styleguidist dapat menampilkan beberapa variasi komponen yang berbeda. StoryBook bagus untuk menganalisis berbagai status komponen, dan Styleguidist hebat untuk menghasilkan dokumentasi komponen dan menunjukkan kemampuan komponen.

Keputusan Arsitektur Digunakan Menggunakan Metodologi CDD

Bekerja dengan gaya CDD berarti bahwa ketika mengembangkan aplikasi, komponen dibuat terlebih dahulu. Selain itu, komponen tersebut harus independen satu sama lain. Ini berarti bahwa pengembang tidak hanya membuat "set komponen". Dia juga mengimplementasikan sistem desain yang disebut komponen antarmuka pengguna.

Komponen dapat dibuat baik dalam kerangka aplikasi itu sendiri (yaitu, dalam proyek yang sama, repositori), dan dalam format proyek yang terpisah (repositori) - dalam bentuk perpustakaan komponen.

Alat seperti Bit memungkinkan Anda untuk mengisolasi dan merangkum komponen. Ini memberi pengembang banyak peluang untuk membuat, menguji, menggunakan kembali komponen, dan memungkinkan mereka untuk diselesaikan di mana saja - di mana pun komponen itu dibuat.

Jika kita mengatakan bahwa penggunaan CDD menyediakan untuk pengembangan komponen dalam bentuk langkah pertama bekerja pada suatu proyek, maka ini juga menyiratkan bahwa komponen cenderung membuatnya cocok untuk penggunaan berulang. Ini memungkinkan Anda untuk menerapkannya saat membuat berbagai aplikasi. Oleh karena itu, pengembang perlu mencari tahu persis apa yang harus ia lakukan untuk membuat komponen tersebut. Tidak ada yang lebih buruk daripada menghabiskan enam bulan untuk membuat perpustakaan , yang pada akhirnya tidak akan digunakan oleh siapa pun. Sayangnya, ini terjadi dengan banyak tim.

Mengapa membuat perpustakaan komponen?

Saya akan jujur ​​dengan Anda: Repositori Git tidak disusun dengan mempertimbangkan kemungkinan menyimpan kode komponen atom di dalamnya, yang direncanakan akan dibagikan dalam berbagai proyek. Untuk mengatasi masalah ini, manajer paket tidak cocok. Keduanya diciptakan, yang dapat dimengerti, untuk mendukung repositori kode. Komponen bukan repositori.


Berbagi komponen dalam berbagai proyek

Itu sebabnya, jika Anda perlu mengambil komponen dari satu aplikasi dan menggunakannya di aplikasi lain, Anda perlu membuat repositori baru. Untuk menyelamatkan diri dari pekerjaan yang tidak perlu dalam membuat repositori terpisah untuk setiap komponen tersebut, sebagian besar tim membuat satu repositori bersama yang dirancang untuk menyimpan 20-30 komponen.

Saat menggunakan alat seperti Bit, pustaka komponen seperti itu tidak perlu. Alat tersebut memungkinkan Anda untuk mengunduh komponen dari aplikasi ke cloud dan mengimplementasikan komponen ini di proyek lain. Jika kita membandingkan skema kerja ini dengan repositori tradisional, maka kita dapat mengatakan bahwa ini adalah sesuatu seperti membandingkan CD musik dan Spotify. Benar, jika Anda dekat dengan ide mengembangkan dan menggunakan pustaka komponen, kemampuan platform seperti Bit dan StoryBook akan memungkinkan Anda untuk bekerja dengan pustaka.

Saat mendesain perpustakaan, Anda perlu membuat beberapa keputusan penting. Di bawah ini akan dipertimbangkan beberapa prinsip penting yang akan membantu Anda dalam hal ini. Poin utama dari prinsip-prinsip ini adalah bahwa tugas Anda adalah membuat komponen independen. Tahap-tahap pekerjaan yang tersisa pada proyek menyerupai perakitan konstruktor Lego. Jika prinsip pengembangan komponen independen tidak dihormati, maka suatu hari Anda mungkin akan mengalami masalah. Masalah akan dimulai ketika seseorang membutuhkan sesuatu yang berbeda dari apa yang ada di perpustakaan. Faktanya, ketika ini terjadi, tim berhenti menggunakan pustaka komponen.

Misalkan Anda memutuskan untuk membuat perpustakaan komponen. Jika demikian - kami menawarkan beberapa kiat yang akan membantu Anda dalam hal ini.

7 prinsip untuk mengembangkan perpustakaan berorientasi CDD berkualitas

1. Standar Standar pengembangan apa yang Anda patuhi saat membuat perpustakaan Anda? Di mana komponen berada? Di mana tes itu berada? Bagaimana dengan gaya? Apa tumpukan teknologi yang Anda gunakan? Misalnya - apakah Anda berencana menggunakan TypeScript? Bagaimana komponen dibagi? Apakah komponen "Tabel", misalnya, terdiri dari "Baris" dan "Sel"? Apakah panel dengan tab terdiri dari tab terpisah (dapatkah pertanyaan yang sama diajukan terkait dengan entitas serupa lainnya)? Saya kira Anda sudah mengerti arti dari rekomendasi ini. Juga sangat penting untuk menyertakan desainer dalam proses pembentukan standar. Ini akan memastikan bahwa perpustakaan cukup fleksibel dan akan memenuhi persyaratan desain yang mungkin muncul di masa depan.
2. Stilisasi. Bagaimana Anda berencana menata komponen? Apakah Anda akan menautkan kode CSS yang sesuai ke setiap komponen? Jika demikian, apa yang terjadi ketika seorang desainer perlu mengubah sesuatu hanya untuk aplikasi terpisah yang menggunakan komponen? Mungkin untuk meningkatkan pemisahan komponen dari gaya perlu menggunakan perpustakaan yang mengimplementasikan CSS dalam teknologi JS ? Mungkin ada baiknya mencari beberapa pendekatan lain untuk styling? Misalnya, menggunakan Bit, Anda dapat menyorot topik sebagai komponen terpisah. Topik semacam itu dapat diterapkan pada komponen yang menerapkan semacam logika. Ini memungkinkan Anda untuk membuat aplikasi di mana desain dan logika digabungkan persis seperti yang dibutuhkan pengembang. Berikut adalah contoh fleksibilitas ekstrim dari sistem yang dibangun menggunakan prinsip modularitas.
3. Pengujian. Bagaimana Anda menguji komponen yang termasuk dalam perpustakaan? Menggunakan Jest dan Enzim? Pemilihan kombinasi yang baik dari alat pengujian komponen harus didekati dengan semua tanggung jawab. Ini akan memungkinkan alat tersebut untuk membantu Anda menerapkan metodologi CDD. Pilihan alat yang buruk akan mengganggu pekerjaan. Tes unit bagus. Tetapi mereka harus memeriksa API fungsional komponen, bukan rincian implementasinya. Tes integrasi dan end-to-end sama pentingnya dengan tes unit. Metodologi TDD bekerja dengan baik ketika diterapkan dalam proyek menggunakan CDD.
4. Proses perakitan kode. Kode perlu dikompilasi. Bagaimana Anda akan mengatur proses pembuatan kode untuk perpustakaan Anda? Bagaimana rilis akan diimplementasikan? Apakah Anda berencana untuk hanya menyalin kode dari aplikasi dan menempelkannya ke perpustakaan (mungkin sedikit memodifikasinya)? Apakah Anda akan menentukan konfigurasi perakitan untuk setiap komponen (Lerna) dan menerapkan mekanisme yang sesuai dengan kode sebelum menerbitkannya? Apakah Anda berencana untuk menggunakan, katakanlah, Bit yang telah disebutkan lebih dari satu kali untuk menyesuaikan proses pembuatan yang berlaku untuk semua komponen (atau individu)? Jika Anda terlalu menyulitkan proses perakitan, akan menjadi lebih sulit untuk terlibat dalam pengembangan, modularitas proyek akan memburuk. Kurva pembelajaran yang dibutuhkan untuk berpartisipasi dalam pengembangan akan menjadi terlalu curam.
5. Manajemen kode. Siapa yang memiliki perpustakaan? Dalam organisasi yang cukup besar, sering ada tim pengembang front-end dan, kadang-kadang, arsitek. Mereka menciptakan produk yang disebut "perpustakaan bersama." Tim pengembangan front-end lainnya membuat aplikasi menggunakan perpustakaan serupa. Dengan skema interaksi ini, sangat penting untuk menggunakan sistem yang memungkinkan Anda untuk dengan mudah menemukan komponen yang diperlukan (Bit, Storybook). Yang lebih penting, mungkin, adalah mekanisme di mana pengguna komponen dapat mengusulkan peningkatan komponen. Jika tidak ada mekanisme seperti itu dalam organisasi, maka tim pengguna komponen tidak akan ingin mengaitkan aplikasi mereka dengan perpustakaan dan menunggu PR mereka diterima, yang mungkin tidak mereka tunggu. Tidak perlu memaksa programmer untuk melakukan apa pun. Penting untuk menjalin kerjasama yang sehat. Jika Anda tidak berusaha untuk ini, tidak ada yang akan menggunakan perpustakaan. Pemrogram hanya akan menyalin dan menempelkan kode, dan tidak ada yang akan melakukan apa pun tentang itu. Selain itu, ini akan menjadi kesalahan Anda. Jika Anda bekerja dalam tim kecil, tentukan dengan jelas siapa yang mengelola kode. Bahkan jika tidak ada yang terlibat dalam basis kode sepanjang waktu, pilih beberapa spesialis yang akan mendukung kode ini. Sisanya akan melakukan PR - sama seperti di GitHub.
6. Mencari komponen. Perpustakaan tidak akan membawa banyak manfaat jika pemrogram tidak dapat menemukan komponen yang mereka butuhkan, tidak dapat mempelajari cara kerja komponen ini, dan tidak dapat menggunakannya dalam kode mereka. Bit memiliki kemampuan bawaan yang membantu pengembang menemukan komponen. Selain platform ini (atau bukan platform), Anda dapat menggunakan kemampuan StoryBook atau semacam solusi sendiri. Platform Codesandbox dapat memberikan beberapa manfaat dalam menyelesaikan masalah yang terkait dengan pemilihan komponen dan bekerja dengan dokumentasi untuknya .
7. Organisasi kolaborasi pada komponen. Apa yang terjadi ketika pengembang (mungkin dari tim lain, atau bahkan dari negara lain) perlu mengubah sesuatu yang terkait dengan komponen dari perpustakaan Anda? Apakah dia perlu lebih dalam membuat PR untuk perpustakaan Anda, dan, semoga saja, tunggu hasilnya. Bagi banyak pengembang, ini terlalu rumit, mereka tidak akan melakukan ini bahkan jika Anda mencoba mempengaruhi mereka. Akan jauh lebih baik jika Anda menggunakan platform tertentu yang menyederhanakan kolaborasi pada proyek.

Ingatlah bahwa perpustakaan hanyalah repositori yang ada untuk memfasilitasi pembagian komponen dalam berbagai proyek. Perpustakaan tidak skala dengan sangat baik, kode di dalamnya menjadi usang, mereka menderita berbagai masalah. Mungkin lebih baik menyediakan akses langsung ke komponen yang dimaksudkan untuk berbagi, menggunakan semacam platform cloud.

Manfaat Tim CDD

Tim yang menggunakan prinsip CDD mendapat manfaat dari pengembangan yang dipercepat, peningkatan penggunaan kembali kode, peningkatan TDD dan antarmuka sistem desain yang konsisten.

Pemrogram dapat menulis kode dengan akses ke komponen yang sudah ditulis dan bekerja bersama untuk membuat perubahan pada komponen. Pengembangan fitur atau aplikasi baru bermuara pada penyesuaian dan perluasan komponen dasar. Ini, sebagai tambahan, membantu mencegah kesalahan yang hanya ditemukan dalam produksi.

Berbagi kode berarti, antara lain, mengurangi jumlah kode yang perlu didukung. Ini memungkinkan programmer untuk fokus pada menciptakan sesuatu yang baru. Ketika aplikasi dikembangkan berdasarkan komponen, ini menstandarkan pekerjaan karena fakta bahwa setiap orang menggunakan basis tunggal blok bangunan aplikasi. Pendekatan komponen juga berkontribusi pada fleksibilitas kerja.

Beberapa tim melaporkan bahwa alur kerja mereka menjadi lebih cepat hingga 60% berkat penggunaan komponen modular berdasarkan sistem desain yang diimplementasikan sebagai rangkaian komponen Bereaksi. Beberapa organisasi telah menemukan bahwa melalui pengenalan CDD, mereka dapat menghapus sekitar 30% dari kode dari basis kode mereka.

Perusahaan seperti Uber, Airbnb, Shopify, dan lainnya memperkenalkan pendekatan komponen.

Ringkasan

Secara pribadi, saya tidak terkejut bahwa penggunaan CDD meningkatkan efisiensi pengembangan perangkat lunak. Menurut Brad Frost, penulis buku tentang desain atom, modularitas dan komposisi adalah konsep paling penting dalam biologi, ekonomi, dan di banyak bidang lainnya. Modularitas dalam aplikasi untuk pengembangan perangkat lunak memberikan kecepatan, keandalan, kemudahan pengembangan. Ini mempromosikan penggunaan kembali entitas, meningkatkan testability dan ekstensibilitas kode. Modularitas memberi pengembang kemampuan untuk menggunakan komposisi saat membuat sistem yang kompleks. Semua ini sangat memengaruhi proses dan hasil pengembangan aplikasi.

Pembaca yang budiman! Apakah Anda menggunakan metodologi CDD saat mengerjakan proyek Anda?