Bagaimana cara menangani metode yang belum diterapkan yang akan dilakukan oleh co-programmer?

Ini adalah pertanyaan tentang cara bekerja dalam tim.

Baru-baru ini saya mengerjakan proyek pemrograman pertama saya yang lebih besar (~ 80 kelas, Jawa) dengan tim yang terdiri dari 6 orang, meskipun hanya 4 dari kami yang terus-menerus mengerjakan kode. Kami mendistribusikan pekerjaan yang harus dilakukan sejak awal dan pada suatu titik saya perlu memanggil metode yang belum diterapkan oleh salah satu rekan programer saya. Bagaimana cara yang disarankan untuk menangani ini?

Pilihan yang saya lihat, meskipun saya tidak terlalu suka:

Tuliskan sendiri //TODOdan tinjau kembali baris kode ini nanti untuk memeriksa apakah metode tersebut telah diterapkan sementara itu.
Meminta anggota tim terkait untuk mengimplementasikannya sekarang .
Melempar runtimeException khusus dengan deskripsi yang jelas tentang apa yang belum diimplementasikan. (Setidaknya kita tidak perlu mencari waktu yang lama untuk mencari tahu apa yang hilang)
Menambahkan metode yang diperlukan ke kelas mereka dan menuliskannya //TODOdi badan pesan, mungkin juga mengirimi mereka pesan cepat tentang perubahan itu. (Sekarang ini bukan masalah saya lagi, tetapi ini dapat menyebabkan konflik gabungan yang mengganggu jika mereka sedang mengerjakan metode ini sementara itu)
Menentukan kelas atau antarmuka abstrak untuk semuanya sebelum benar-benar menulis kode yang berfungsi. (Tidak berfungsi dengan baik karena antarmuka ini sering diubah)

teamwork

— lucidbrot
sumber

Saya pikir alur kerja di mana Anda memerlukan metode yang ditulis oleh orang lain tidak benar. Anda sedang mengerjakan fitur. Jika fitur itu memerlukan metode, ANDA mengimplementasikannya. Jika dua orang menerapkan fitur tunggal, mereka berpasangan, atau mengintegrasikan dan berkomunikasi begitu sering sehingga hampir terlihat seperti berpasangan.

— Euforia

@Euphoric Beberapa kali saya menemukan situasi di mana fitur baru yang cukup besar akan dikembangkan dalam jangka waktu yang relatif singkat dan oleh karena itu antarmuka pengguna, logika bisnis dan lapisan API harus dipecah menjadi tugas yang berbeda untuk dikerjakan secara bersamaan, kalau tidak tenggat waktu tidak akan pernah bisa dipenuhi. Di situlah seseorang yang bekerja di UI hanya harus mendeklarasikan metode akses data dan perintah ke BL sebagai antarmuka dan membiarkan orang lain bekerja pada implementasi, sementara hanya bekerja di UI.

— Andy

@ Davidvider Apa yang Anda gambarkan bukan satu-satunya cara untuk mengatasi masalah itu. Irisan vertikal, integrasi sering, fitur kecil semua solusi yang lebih baik daripada irisan horizontal dengan setiap orang mengerjakan bagian yang terpisah.

— Euforia

@ Euforia, saya tidak bisa lebih setuju dengan Anda. Jika memungkinkan, kita pergi dengan cara melucuti fitur baru yang kompleks dari bagian-bagian yang tidak kritis (yaitu yang hanya akan meningkatkan UX tetapi tidak perlu segera). Sayangnya, terkadang opsi yang Anda sebutkan, maupun fitur stripping, tidak memungkinkan. Bisnis mengatakan, pengembang lakukan. Jadi, sementara poin Anda solid, ada juga kemungkinan seseorang akan dan akan menghadapi situasi di mana beberapa jenis work-split harus dilakukan untuk memenuhi kebutuhan bisnis.

— Andy

bagaimana dengan berbicara dengannya bagaimana dia ingin menanganinya?

— Aganju

Jawaban:

Ini adalah pertanyaan yang menarik dan jawabannya mungkin lebih mudah dari yang Anda pikirkan.

Sederhananya, tulis tes yang memvalidasi asumsi Anda. Tidak masalah jika Anda melakukan implementasi atau sesama programmer

Jawaban panjangnya.

Salah satu opsi yang Anda daftarkan agak pasif dan mengharuskan Anda untuk kembali dan mengunjungi kembali kode (jika ada) cepat atau lambat.

Komentar perlu dibaca dan ditangani oleh rekanan Anda yang bertanggung jawab atas implementasi. Sementara itu kode Anda tidak dapat dikompilasi. Jika Anda memeriksa keadaan tersebut di repositori kode, pipa integrasi berkesinambungan Anda tidak akan berfungsi, dan itu adalah praktik yang buruk ... jangan pernah memeriksa dalam kode yang rusak
Pengecualian runtime tampaknya lebih baik, tetapi masih beracun, karena sesama programmer Anda dapat mengasumsikan bahwa implementasi sudah dilakukan tanpa memeriksa, meninggalkan sistem dalam keadaan tidak stabil juga. Jika metode ini dipicu tidak terlalu sering, itu dapat menyebabkan kode produksi yang rusak ... praktik yang buruk juga ... tidak pernah memeriksa pengecualian "tidak diterapkan"
Menunggu sesama programmer untuk implementasi metode atau rintisan juga menakutkan. Itu merusak alur kerja Anda dan alur kerja sesama programmer Anda. Apa yang terjadi jika mereka sakit, saat rapat, saat rehat kopi, apakah Anda ingin menghabiskan waktu menunggu? ... jangan menunggu seseorang jika Anda tidak perlu
menerapkan metode yang hilang pasti cara terbaik untuk maju. Tetapi apa yang terjadi jika implementasi Anda tidak memuaskan seluruh kasus penggunaan dan sesama programmer Anda perlu mengubah atau mengubahnya? Bagaimana Anda dan mereka memastikan bahwa itu masih kompatibel dengan yang Anda maksudkan? Jawabannya mudah lagi. Tulis tes yang memverifikasi, menjelaskan, dan mendokumentasikan niat Anda. Jika tes rusak, mudah diketahui. Jika perubahan dalam metode itu perlu dilakukan yang merusak fitur Anda ... Anda melihatnya segera. Anda berdua memiliki alasan untuk berkomunikasi dan memutuskan apa yang harus dilakukan. Membagi fungsionalitasnya? Ubah implementasi Anda, dll ... jangan pernah mencek kode yang tidak cukup didokumentasikan oleh tes

Untuk mencapai tingkat pengujian yang cukup, saya sarankan Anda melihat dua disiplin ilmu.

TDD - pengembangan yang digerakkan oleh tes - ini akan memastikan Anda menggambarkan maksud Anda dan mengujinya secara memadai. Ini juga memberi Anda kemungkinan untuk mengejek atau memalsukan metode dan kelas (juga dengan menggunakan antarmuka) yang belum diimplementasikan. Kode dan tes masih akan dikompilasi dan memungkinkan Anda untuk menguji kode Anda sendiri dalam isolasi kode sesama programer Anda. (lihat: https://en.wikipedia.org/wiki/Test-driven_development )
ATDD - pengembangan yang didorong oleh tes penerimaan - ini akan membuat loop luar (sekitar loop TDD) yang membantu Anda menguji fitur secara keseluruhan. Tes-tes ini hanya akan berubah hijau ketika seluruh fitur diimplementasikan, sehingga memberi Anda indikator otomatis ketika rekan Anda menyelesaikan pekerjaan mereka. Cukup rapi jika Anda bertanya kepada saya.

Peringatan: Dalam kasus Anda, saya hanya akan menulis tes penerimaan sederhana dan tidak mencoba untuk membawa terlalu banyak sisi bisnis, karena terlalu banyak untuk memulai. Tulis tes integrasi sederhana yang menggabungkan semua bagian sistem yang dibutuhkan fitur. Hanya itu yang dibutuhkan

Ini akan memungkinkan Anda untuk meletakkan kode Anda dalam pipa Integrasi Berkelanjutan dan menghasilkan implementasi yang sangat andal.

Jika Anda ingin mendapatkan lebih jauh dalam topik itu periksa tautan berikut:

— Jesko R.
sumber

103

Minta bertopik.

Atau tulis sendiri. Either way, Anda dan rekan kerja Anda harus menyetujui antarmuka dan bagaimana mereka dimaksudkan untuk digunakan. Perjanjian itu perlu relatif dipadatkan sehingga Anda dapat berkembang melawan bertopik - belum lagi, sehingga Anda dapat membuat tiruan sendiri untuk pengujian unit Anda ...

— svidgen
sumber

^^ Ini. Jika Anda menggunakan antarmuka dengan benar, Anda tidak perlu membutuhkan implementasi sampai orang lain selesai menulisnya.

— Robert Harvey

Dan untuk lebih jauh komentar Robert, jika Anda tidak menggunakan antarmuka dalam proyek yang dirancang khusus untuk dipisah di antara banyak orang, Anda akan memiliki waktu yang buruk ...

— corsiKa

Sayang sekali Java tidak memiliki file header. Di dunia C / C ++ Anda dapat mengerjakan API Anda dan menulis semua header Anda terlebih dahulu, kurangnya implementasi kemudian menjadi masalah bagi linker. (Penyederhanaan sedikit, ABI perlu tetap konstan juga untuk itu hanya menjadi masalah penghubung).

— Wes Toleman

@WesToleman Mengherankan, salah satu hal favorit saya tentang Java adalah tidak memiliki file header. "Antarmuka" yang disebutkan Robert dan corsiKa mengisi peran itu dengan sempurna. Anda mengerjakan API Anda terlebih dahulu, menulis antarmuka, dan kurangnya implementasi konkret bukan masalah bagi kompiler.

— GrandOpener

@ WillToleman Apakah itu berhasil untuk Anda? Di telinga saya yang terdengar sangat mirip gaya water-fall, dan tebakan saya adalah Anda harus memperbarui antarmuka lebih jauh ketika Anda menyadari bahwa Anda telah kehilangan "parameter penting" ini?

— netigger

Dalam situasi Anda, saya akan berbicara dengan anggota tim dengan tanggung jawab untuk fungsi itu. Mungkin mereka berada dalam posisi untuk memprioritaskan pengembangan fungsi itu sehingga Anda dapat mulai menggunakannya lebih cepat.

Saya akan menghindari opsi keempat Anda. Anda telah menulis semua kode Anda, dan seperti yang Anda katakan, Anda tidak lagi menganggapnya sebagai masalah Anda. Rekan Anda kemudian menulis implementasi fungsi tersebut, dan tidak lagi menganggapnya sebagai masalah mereka. Siapa yang benar-benar akan menguji bahwa kode yang Anda tulis bekerja dengan benar?

— Pete
sumber

Anda harus meminta API untuk fungsi itu yang akan menghasilkan satu atau lebih antarmuka. Ini mungkin ide yang baik untuk melakukan ini bersama-sama, karena Anda akan perlu menggunakan antarmuka ini sehingga Anda dapat merancang kasus uji awal berdasarkan input Anda. Implementasi aktual kemudian dapat datang kemudian (termasuk kemungkinan perubahan API)

— Thorbjørn Ravn Andersen