Bagaimana cara mempelajari pendekatan yang tepat untuk menerapkan fitur setengah? [Tutup]


12

Saya memimpin tim pengembangan dan saya ingin merilis produk kami sesering mungkin (Pengiriman Berkelanjutan).

Dalam banyak kasus, kami harus mengimplementasikan fitur yang membutuhkan waktu lebih lama untuk diterapkan daripada waktu antara rilis. Saya masih ingin orang-orang melakukan kode mereka setiap hari (Integrasi Berkelanjutan).

Berkali-kali menerapkan fitur baru mengharuskan fitur yang ada diubah dan fitur yang ada, tentu saja, masih perlu bekerja, bahkan jika fitur baru belum selesai.

Jika pengembang menggunakan pendekatan yang tepat , mereka dapat menyesuaikan fitur yang ada dengan hati-hati dan semua hal di atas tidak menjadi masalah.

Namun, sebenarnya apa pendekatan yang benar? Pemikiran pemrograman saya yang selaras memberi tahu saya apa yang harus dilakukan untuk setiap kasus individu, tetapi saya perlu belajar lebih banyak dan saya memerlukan beberapa bahan bacaan yang dapat saya baca dan rujuk anggota tim untuk membaca. Atau metode lain untuk belajar cara yang benar untuk mempelajari pendekatan ini akan dilakukan.

Jadi itu pertanyaannya. Bagaimana cara memastikan anggota tim mempelajari pendekatan yang tepat untuk menerapkan setengah fitur?

Saya telah mencari orang yang mengklaim memiliki strategi mengenai hal ini, tetapi belum menemukannya, kecuali orang yang menulis beberapa pemikiran acak tentang topik ini. Mungkin saya tidak menggunakan kata-kata pencarian yang tepat atau mungkin tidak ada yang membuat panduan resmi tentang ini.


"fitur yang ada, tentu saja, masih perlu bekerja" - tergantung pada konteksnya, istilah untuk persyaratan seperti ini dapat berupa kompatibilitas mundur atau tidak adanya bug regresi
agas


1
Berbagai jenis pengujian otomatis dapat mengurangi risiko kesalahan dalam perubahan kode. Memeriksa. Saya mencari pendekatan untuk digunakan sebagai pengembang yang harus mengimplementasikan fitur besar yang mungkin melibatkan 75% perubahan dalam kode yang ada dan 26% kode baru (persen tambahan ada untuk misteri tambahan).
Niels Brinch

1
@Niels: Anda harus memiliki beberapa pengembang yang luar biasa agar mereka dapat memiliki kode yang bekerja pada akhir setiap hari yang dapat diperiksa ke cabang utama dan lulus semua tes. Entah itu atau mereka hanya mendapatkan tulang-tulang minimal dilakukan sehingga mereka berada dalam posisi untuk memeriksa kode mereka pada akhir hari.
Dunk

bukankah mereka menyebut itu "Cabang Fitur". Anda membuat perubahan di cabang dan kemudian menggabungkan cabang kembali ke master ketika fitur selesai. Anda seharusnya tidak menghadirkan fitur yang setengah diimplementasikan dalam demo, jadi saya tidak mengerti mengapa ini tidak berhasil.
deltree

Jawaban:


14

Saya mengambil pandangan yang berbeda dari jawaban lain di sini sudah. Saya setuju dengan Anda bahwa Anda ingin mengintegrasikan perubahan dari pengembang sesegera mungkin, dan untuk terus menguji gabungan kode.

Namun, saya tidak setuju bahwa haknya untuk mengirim kode dikembangkan pagi ini, hanya karena kami merilis sore ini. Itu adalah resep untuk pelanggan yang kecewa.

Solusinya adalah memiliki cabang di pohon kontrol versi Anda, dan bahwa Anda memiliki proses terpisah untuk mempromosikan delta yang diverifikasi dari cabang pengembangan ke cabang rilis.

Dengan begitu Anda mendapatkan yang terbaik dari kedua dunia. Anda memiliki pengembang yang melakukan integrasi terus-menerus, dan keuntungan yang didapat, Anda memiliki pengiriman kode yang stabil secara teratur ke pelanggan, dan Anda memiliki proses baru yang menguji fitur yang telah selesai di cabang pengembang, dan jika mereka lulus pengujian menjadikannya bagian dari produk yang dirilis. .

Ada dua alat yang saya kenal yang mendukung proses semacam ini dengan baik. Jika struktur pengembangan Anda sederhana, maka git, dengan git-flow mengimplementasikan struktur percabangan yang baik yang bekerja dengan baik dalam tim kecil hingga menengah (mungkin 20 pengembang).

Untuk tim pengembangan yang lebih besar, atau di mana strategi percabangan yang lebih kompleks diperlukan untuk mendukung banyak 'putaran' produk Anda, akurasi adalah yang terbaik yang ada. Pengembang yang tidak terlibat dalam mengelola perubahan akan mengeluh bahwa ini lebih sulit daripada sub-versi dll ... tetapi hal itu mendukung lingkungan pengembangan yang kompleks.


Saya akan sangat tertarik untuk mengetahui lebih banyak tentang strategi percabangan yang Anda maksud. Apakah Anda memiliki tautan ke artikel atau sesuatu yang lebih menjelaskan konsep yang Anda maksud?
Niels Brinch


Karakteristik utama dari git flow adalah strategi percabangannya yang terdefinisi dengan jelas, yang menjadikannya pilihan yang baik untuk produk yang hanya memiliki satu rilis untuk diproduksi. Accurrev tidak menerapkan strategi percabangan, tetapi memiliki fleksibilitas dan menyediakan alat untuk secara efektif mengelola pohon cabang yang jauh lebih kompleks.
Michael Shaw

6

Ada dua masalah di sini: satu menerapkan setengah fitur; yang lain adalah menjaga produk pengiriman bekerja selama pengembangan berkelanjutan.

Menerapkan setengah fitur

Desain menyeluruh yang kuat akan membantu dalam hal ini. Ini memungkinkan Anda menerapkan fitur dengan batasannya yang ditentukan dengan jelas - misalnya, API ke bit kode yang berdekatan, harapan tentang struktur data, dan pemahaman tentang bagaimana dan kapan kode yang diimplementasikan akan dipanggil.

Pengujian dapat mencakup versi kode yang dibuat-buat untuk bagian fitur lainnya; ini membantu kelancaran transisi ketika Anda menerapkan setengahnya.

Menjaga agar produk pengiriman tetap berfungsi

Ada beberapa opsi di sini:

  1. Matikan fitur 'off' pada produk yang dikirim. Hanya karena kode tersebut ada dalam produk tidak berarti harus dijalankan atau disajikan kepada pengguna. Kekurangannya adalah Anda tidak akan memberikan nilai tambahan kepada pengguna Anda, dan Anda tidak akan mendapatkan umpan balik.
  2. Buka tepi fitur untuk pengguna Anda. Tunjukkan apa yang Anda miliki, dan berikan beberapa indikasi tentang apa yang akan datang.
  3. Biarkan pengguna beralih antara fungsionalitas baru dan lama. Ini kadang-kadang membutuhkan mempertahankan dua jalur kode yang siap digunakan pengguna akhir.

Terakhir, jika Anda mengalami masalah dengan salah satu solusi ini, pertimbangkan apakah Anda telah membagi fitur di sepanjang batas yang benar. Jika Anda mengiris berbagai cara dengan cara yang berbeda, apakah akan lebih mudah untuk dipisahkan?


Cukup mudah untuk mematikan fitur baru yang belum sepenuhnya siap. Itu saran yang bagus. Jadi masalah inti dalam produk yang dikirim adalah fitur-fitur yang ada dapat rusak jika orang tidak menggunakan pendekatan yang tepat ketika mereka mengubah kode yang ada.
Niels Brinch

2
Di situlah pengujian yang baik masuk. Jika Anda tidak memiliki cakupan yang layak untuk basis kode Anda, mungkin ini bisa menjadi pemicu untuk upaya itu?
Alex Feinman

Tetapi bisakah jawaban atas pertanyaan saya hanyalah "melakukan praktik kode yang baik dan melakukan pengujian unit" dll ...?
Niels Brinch

1

Bagaimana cara memastikan anggota tim mempelajari pendekatan yang tepat untuk menerapkan setengah fitur?

Dengan mengajar mereka. (duh)

Belajar akan melibatkan iterasi: mencoba sesuatu, melihat cara kerjanya, dan kemudian memodifikasi pendekatan mereka untuk mencapai hasil yang lebih baik. Untuk hal semacam ini, saya akan menganjurkan tinjauan desain / kode. Anda bisa melihat bagaimana fitur setengah dirancang / diimplementasikan dan memiliki kesempatan untuk memberikan umpan balik. "Ini dan itu tidak akan berhasil karena mereka akan merusak CI kita; bagaimana dengan XYZ?", "Kerja bagus di sini, itu benar-benar bersih."

Melakukan ulasan sebagai sebuah tim akan membantu semua orang mempelajari apa yang sudah Anda ketahui secara intuitif.


Saya benar-benar setuju dengan ini. Tapi sama seperti saya bisa mengajari seseorang cara membuat unit test ATAU merujuknya ke buku "The art of unit testing" - adakah sumber daya serupa yang bisa saya rujuk untuk topik ini?
Niels Brinch

1

Hal terbesar yang akan membantu Anda di sini adalah memiliki pemisahan kekhawatiran yang baik sehingga sejauh mungkin satu area kode tidak mengganggu yang lain.

Ini adalah tempat di mana menggunakan Ketergantungan Injeksi dan pemrograman ke antarmuka sangat membantu, sehingga Anda dapat memiliki implementasi ISupportingFeature saat ini di situs dan kemudian ketika Anda perlu membuat INewFeature yang tergantung pada implementasi yang berbeda, Anda bisa mengembangkannya dengan implementasi baru dan mempertahankan yang sudah ada dalam produksi sampai diuji dengan baik dan siap untuk ditayangkan. Dengan asumsi Anda memiliki DI Anda bekerja dari sistem konfigurasi semacam ini ini akan memungkinkan Anda untuk memiliki kode yang sama secara paralel di sistem Anda dan menggunakan kode stabil setiap saat.

Sebenarnya pendekatan konfigurasi ini dijelaskan oleh Martin Fowler sebagai Feature Toggle.

Tentu saja, masalahnya hanya muncul jika Anda menggunakan semua kode sepanjang waktu. Ini persis jenis skenario yang dirancang untuk fitur cabang dan meskipun saya mengakui bahwa Pak Fowler mengerutkan dahi mereka, saya tidak tahu bahwa mereka semua seburuk itu, terutama jika mereka dibuat dan digunakan dalam rencana dan pemikiran- melalui jalan.


Saya mendapat kesan bahwa melakukan semua kode ke cabang yang sama dan menggunakan semua kode saya sepanjang waktu merupakan bagian dari strategi integrasi berkelanjutan yang baik?
Niels Brinch

Membaca lebih dalam tentang Pengiriman Berkelanjutan, sudah pasti merupakan bagian dari itu. Saya agak meringis memikirkan hal itu, meskipun - apakah Anda ingin menggunakan kode setengah tertulis bahkan jika itu harus dinonaktifkan? Mungkin ini bekerja dengan baik dalam skenario di mana keamanan tidak penting, tetapi kedengarannya seperti pendekatan berisiko tinggi untuk banyak ruang aplikasi. Ini mungkin menandai saya sebagai fuddy fuddy pelukan keamanan kuno, meskipun.
glenatron

Tampaknya ada dua strategi yang bersaing, di mana satu memiliki sebagai cabang utama tunggal dan yang lain memiliki cabang untuk setiap tugas dan banyak penggabungan ... Saya tidak yakin apa yang terbaik atau benar - atau apakah itu menyentuh inti dari pertanyaan saya.
Niels Brinch

Saya pikir itu sangat tergantung pada jenis hal yang Anda buat - saya akan lebih cenderung ke cabang jika saya memiliki prioritas pada keamanan dan tidak ingin mengambil risiko benar-benar menyebarkan kode yang belum diuji di mana seseorang mungkin menemukannya atau mungkin secara tidak sengaja diaktifkan. Jadi jika saya menjalankan situs bank, saya tidak berpikir CD akan menjadi masalah, tetapi mungkin jika saya menjalankan situs web turnover tinggi untuk pengunjung biasa / sesekali, itu mungkin ideal.
glenatron
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.