Bagaimana cara beralih dari Good ke Great

Ini adalah pengantar seri multi-bagian, di mana kami mengeksplorasi membuat proses pengembangan front-end lebih efisien dan terukur - untuk membuat produk yang lebih baik, lebih cepat.

“Sekelompok orang melakukan brainstorming atas laptop dan lembaran kertas” oleh Štefan Štefančík di Unsplash

Membangun produk hebat sering kali bukan usaha solo. Pengaturan yang paling rumit akan melibatkan multi-tim kreatif, pemasaran, produk, dan teknologi. Bahkan jika Anda adalah perusahaan yang terdiri dari satu orang, Anda perlu berinteraksi dengan pengguna Anda, untuk mengumpulkan umpan balik mereka tentang apa yang cocok untuk mereka. Kerangka kerja berulang dari proses desain siklus untuk membantu meningkatkan kualitas dan fungsi ini biasa disebut sebagai Agile Iteration Workflow.

Semakin cepat Anda dapat beralih, semakin baik produk Anda.
“Agile Iteration Workflow” oleh Smartsheet

Di StashAway ketika tim front-end pertama kali mulai membangun produk berbasis web, kami berada pada garis waktu yang dipercepat untuk diluncurkan, dan proses pengembangan dan manajemen produk kami kurang ketat. Sekarang produk telah matang, dan karena lebih banyak fitur dieksplorasi dan ditambahkan, kami ingin meningkatkan dan memperketat proses kami membangun arsitektur front-end yang lebih baik dan lebih skalabel untuk produk tersebut. Pengaturan kami saat ini tidak akan memungkinkan kami untuk skala secara efektif dalam hal penawaran fitur dan ekspansi negara.

Untuk membuat produk yang hebat, kita harus menyempurnakan alur kerja iterasi. Ada banyak literatur manajemen produk tentang itu, dan itu bukan ruang lingkup seri artikel ini. Apa yang ingin kami jelajahi adalah bagaimana menjadi lebih cepat dengan iterasi dalam tahap pembuatan prototipe dan pembangunan, dan untuk itu, kami harus memformalkan proses pengembangan dan persetujuan internal tim kami sehingga kami dapat berkolaborasi lebih efisien dengan tim kreatif dan produk kami . Kami pikir kami dapat mencapainya dengan memanfaatkan integrasi yang berkesinambungan dan aliran pengiriman bersamaan dengan alur kerja iterasi produk yang lebih luas seperti yang dijelaskan sebelumnya.

Pada akhirnya, kami bertujuan untuk mendekati paradigma pemrograman deklaratif yang mengekspresikan apa yang ingin kami lakukan dalam aplikasi kami, alih-alih secara imperatif mengkode caranya. Untuk melakukan itu, kita perlu meletakkan dasar untuk menciptakan blok bangunan kita.

Kami mulai dengan memperluas pemisahan kami dengan UI dan logika aplikasi, sehingga pengembangan komponen UI menjadi aktivitas yang terpisah. Ini akan memiliki repositori pusatnya sendiri, bersama dengan utilitas umum, rangkaian unitnya sendiri, tes penerimaan dan regresi. Komponen UI kami sekarang akan dapat digunakan kembali, mampu menulis dan tema, untuk variasi situs web dan aplikasi web. Saat digunakan dengan Storybook, kita dapat membuat pustaka pola interaktif.

Kami akan memiliki keyakinan bahwa komponen UI kami akan terlihat dan berperilaku tepat sebagaimana mestinya sehingga kami dapat fokus pada kesenangan dan hal-hal penting - aplikasi dan bagaimana mereka harus berperilaku. Kami dapat menerapkan proses yang sama dengan komponen UI kami untuk proyek khusus aplikasi kami, dengan rangkaian pengujian yang lebih spesifik untuk memaksimalkan cakupan. Hanya dengan suite pengujian ini kami dapat meningkatkan kepercayaan pengembang dalam mendorong dan menggunakan kode, dan sebagai imbalannya meningkatkan kecepatan iterasi.

Dengan repositori terpusat dari komponen-komponen yang mampu membuat ini, kami dapat membuat prototipe dan ide-ide pengguna-lorong, dan bahkan menghadirkan fitur-fitur baru dengan kecepatan yang meningkat.

Level pengujian perangkat lunak

Anda akan memperhatikan bahwa kami telah memalu rumah pesan bahwa pengujian itu penting. Pengujian perangkat lunak adalah topik luas dalam pengembangan perangkat lunak, tetapi mari kita fokus pada empat tingkat pengujian yang tidak terpisahkan dalam kelancaran proses pengiriman berkelanjutan - unit, integrasi, sistem, dan penerimaan.

Kami menggunakan tes unit untuk memvalidasi komponen individual, unit terkecil yang dapat diuji, dalam perangkat lunak. Dalam kasus kami, itu biasanya komponen UI atau metode bantuan utilitas. Pengujian integrasi terjadi ketika masing-masing komponen diuji sebagai kelompok. Misalnya, ini bisa berarti fitur seperti kalkulator, di mana Anda akan memiliki tombol dan layar tampilan, dan memastikan nomor yang benar ditampilkan sebagai respons terhadap tombol tekan. Untuk API, titik akhir dapat membuat koneksi basis data untuk mengambil satu set data.

Pengujian unit dan integrasi biasanya menyingkirkan sebagian besar bug yang menyilaukan sebelum kita masuk ke tahap penyebaran. Ini menghemat waktu untuk penguji internal dan eksternal, yang akan mengevaluasi sistem yang lengkap dan terintegrasi untuk kepatuhan terhadap fitur dan persyaratan bisnis - domain sistem dan pengujian penerimaan. Setelah perangkat lunak melewati empat level pengujian, kami dapat menggunakan produksi.

Ini adalah sekilas tentang bagaimana kami berencana untuk membuat proses tim front-end kami lebih efisien. Kami akan masuk ke detail lebih lanjut tentang implementasi di posting selanjutnya tentang pengembangan front-end di StashAway. Tetap disini!

Kami terus mencari bakat teknologi hebat untuk bergabung dengan tim kami - kunjungi situs web kami untuk mempelajari lebih lanjut dan merasa bebas untuk menjangkau kami!