Bagaimana hendak pergi dari Good to Great

Ini adalah pengenalan kepada siri multi-bahagian, di mana kita meneroka membuat proses pembangunan terdepan lebih cekap dan berskala - untuk membuat produk yang lebih baik, lebih cepat.

Membina produk yang hebat sering bukan satu usaha solo. Penyediaan yang paling rumit akan melibatkan pelbagai pasukan kreatif, pemasaran, produk, dan teknologi. Walaupun anda adalah syarikat satu, anda perlu berinteraksi dengan pengguna anda, untuk mengumpulkan maklum balas mereka tentang apa yang berfungsi untuk mereka. Rangka kerja iteratif proses reka bentuk kitaran untuk membantu meningkatkan kualiti dan fungsi biasanya dirujuk sebagai Alur Kerja Pengalihan Agile.

Semakin cepat anda dapat berulang, semakin baik produk anda akan menjadi.

Di StashAway apabila pasukan front-end pertama mula membina produk berasaskan web, kami berada pada garis masa dipercepat untuk melancarkan, dan proses pembangunan dan pengurusan produk kami kurang ketat. Sekarang produk itu matang, dan apabila lebih banyak ciri dijelajahi dan ditambah, kami sedang berusaha untuk meningkatkan dan mengetatkan proses kami membina arsitektur hadapan yang lebih baik dan lebih berskala untuk produk. Persediaan semasa kami tidak akan membolehkan kami untuk skala secara efektif dari segi penawaran ciri dan ekspansi negara.

Untuk membuat produk yang hebat, kita mesti menyempurnakan aliran kerja lelaran. Terdapat banyak kesusasteraan pengurusan produk tentang itu, dan itu bukan skop artikel siri ini. Apa yang ingin kita pelajari adalah bagaimana untuk menjadi lebih cepat dengan lelaran dalam fasa prototaip dan bangunan, dan untuk melakukannya, kita perlu memformalkan proses pembangunan dan kelulusan dalaman pasukan kami supaya kami boleh bekerjasama dengan lebih efisien dengan pasukan kreatif dan produk kami . Kami fikir kami dapat mencapai itu dengan menggunakan aliran berterusan dan aliran penghantaran bersamaan dengan aliran kerja lelasan produk yang lebih luas seperti yang dinyatakan sebelum ini.

Pada akhirnya, kami berhasrat untuk mendekati paradigma pengaturcaraan deklaratif yang menyatakan apa yang ingin kami lakukan dalam aplikasi kami, dan bukannya pengekodan secara imperatif. Untuk melakukan itu, kita perlu meletakkan asas untuk mencipta blok bangunan kita.

Kami bermula dengan mengembangkan pemisahan kami dengan UI dan logik aplikasi, supaya pembangunan komponen UI menjadi satu aktiviti yang berasingan. Ia akan mempunyai repositori pusatnya sendiri, bersama dengan utiliti biasa, suite unit, penerimaan dan ujian regresi. Komponen UI kami kini boleh diguna semula, dapat dikompilasi dan dapat dimain tema, untuk variasi laman web dan apl web. Apabila digunakan dengan buku cerita, kita boleh membuat perpustakaan corak interaktif.

Kami akan mempunyai keyakinan bahawa komponen UI kami akan melihat dan berkelakuan dengan tepat seperti yang sepatutnya supaya kami boleh memberi tumpuan kepada perkara yang menyeronokkan dan penting - aplikasi dan bagaimana mereka harus berkelakuan. Kami boleh menggunakan proses yang sama dengan komponen UI kami untuk projek khusus aplikasi kami, dengan suite ujian yang lebih spesifik untuk memaksimumkan liputan. Ia hanya dengan suite ujian ini yang kami boleh meningkatkan keyakinan pemaju dalam menolak dan menggunakan kod, dan sebagai balasan meningkatkan kelajuan lelaran.

Dengan repositori pusat komponen kompaun ini, kita boleh menggunakan prototaip dan idea-idea ujian lorong-lorong, dan juga menyampaikan ciri-ciri baru pada kadar yang lebih tinggi.

Tahap pengujian perisian

Anda akan perhatikan bahawa kami telah memukul balik mesej yang ujian adalah penting. Pengujian perisian adalah topik yang sangat luas dalam pembangunan perisian, tetapi mari fokus pada empat tahap pengujian yang penting dalam proses lancar proses penghantaran berterusan - unit, integrasi, sistem dan penerimaan.

Kami menggunakan ujian unit untuk mengesahkan komponen individu, unit ujian yang paling kecil, dalam perisian. Dalam kes kami, mereka biasanya adalah komponen UI atau kaedah penolong utiliti. Ujian integrasi berlaku apabila komponen individu diuji sebagai satu kumpulan. Sebagai contoh, ini mungkin bermakna ciri seperti kalkulator, di mana anda akan mempunyai butang dan skrin paparan, dan memastikan nombor yang betul dipaparkan sebagai tindak balas kepada butang tekan. Untuk API, titik akhir boleh membuat sambungan pangkalan data untuk mendapatkan satu set data.

Ujian unit dan pengintegrasian biasanya menyemburkan bug yang paling mencolok sebelum kita masuk ke penyusunan pementasan. Ia menjimatkan masa untuk penguji dalaman dan luaran, yang akan menilai sistem yang lengkap dan lengkap untuk pematuhan terhadap ciri dan keperluan perniagaan - domain sistem dan ujian penerimaan. Sebaik sahaja perisian melepasi empat tahap ujian, kita boleh menggunakannya untuk pengeluaran.

Ini adalah pandangan mengintip bagaimana kami merancang untuk membuat proses pasukan kami lebih efisien. Kami akan menerangkan lebih lanjut mengenai pelaksanaan dalam jawatan berikutnya mengenai pembangunan front-end di StashAway. Tinggal!

Kami sentiasa meninjau bakat teknologi tinggi untuk menyertai pasukan kami - lawati laman web kami untuk mengetahui lebih lanjut dan berasa bebas untuk menghubungi kami!