Bagaimana Anda melakukan riset saat pemrograman berpasangan?

Saya baru-baru ini memulai pekerjaan baru dan berpasangan telah membantu saya menjadi efektif di sana dengan sangat cepat. Namun, saya mengalami kesulitan ketika kami harus melakukan penelitian bersama singkat selama alur kerja kami, yang mencakup fitur API, contoh kode, atau opsi perintah. Pimpinan tim saya mendesak kami untuk melakukan semua penelitian pada stasiun pemasangan kami, bukan laptop pribadi kami, dan untuk menyinkronkan penelitian kami dengan menegosiasikan secara lisan langkah-langkah antara sumber daya web yang berbeda.

Saya meneliti, membaca, dan menyerap informasi secara berbeda dari pasangan pasangan saya, dan saya merasa jauh lebih produktif ketika saya dapat mengikuti utas penelitian ke halaman web berikutnya tepat ketika saya ingin, daripada mencoba untuk menjaga kecepatan dan tempat yang tepat dengan apa yang membaca pasangan saya. Kami berdua cerdas dan cepat, tetapi kami tidak dapat membantu bergerak dengan cara yang berbeda dan kecepatan sesaat ketika kami memikirkan hal-hal. Tampaknya jauh lebih mudah untuk melihat-lihat satu per satu selama satu menit sampai salah satu dari kita berkata "Saya sudah mendapatkannya," kemudian kembali bersama dan kode.

Saat Anda memasangkan program, bagaimana Anda menangani tugas penelitian pendek? Apa yang paling cocok untuk Anda, dan bagaimana Anda tetap sinkron dengan pasangan Anda?

agile pair-programming

— traffichazard
sumber

Jawaban:

Pemrograman pasangan adalah alat. Seperti alat apa pun, ada kalanya berguna dan ada saat-saat tidak berguna. Menggunakan alat yang tepat untuk pekerjaan itu dapat melibatkan alat yang berbeda pada waktu yang berbeda, termasuk campuran dari alat tersebut.

Jadi, jika situasinya membutuhkannya, pisahkan jika perlu dan bertemu kembali saat diperlukan.

Misalnya, jika Anda berdua sedang meneliti sesuatu dan salah satu dari Anda menemukan sesuatu yang menarik, maka mungkin Anda berdua bisa melihatnya bersama. Tetapi jika Anda berdua berusaha menemukan jawaban, terkadang memisahkan untuk mencari secara paralel lebih produktif.

Ketika salah satu dari Anda menemukan jawabannya, lanjutkan pair programmingsesi.

Singkatnya, ini disebut Pair Programming,tidak Pair Researching.

— jmort253
sumber

Ketika saya memasangkan program siapa pun yang tidak mengetik di komputer utama memiliki akses ke laptop untuk melakukan penelitian. Ini membuat keseluruhan proses tidak membuat frustasi untuk anggota 'non-mengetik' dari pasangan.

— Westcoastdiff
sumber

Bukankah orang yang tidak lalim itu mengalihkan perhatian dari apa yang ingin dicapai oleh pasangan itu? Bagaimana dia mengejar apa yang dicapai programmer lain sementara mereka tidak melihat?

— Adam Lear

Jika dua orang bekerja pada dua komputer, itu bukan pemrograman berpasangan!

— Johnsyweb

Jika orang di stasiun pemrograman pasangan mencari dan tidak pemrograman, maka proses penangkapan hanya melibatkan "Hei Bung! Lihatlah apa yang baru saja saya temukan ...". Hanya karena kedua orang tersebut meneliti sesuatu secara mandiri, bukan berarti mereka berhenti berkomunikasi.

— jmort253

Saya tidak berpikir saya ingin melangkah sejauh ini - ketika kode sedang ditulis, saya ingin melihatnya. Saya berbicara lebih banyak tentang situasi di mana kita berdua tahu apa yang harus kita lakukan selanjutnya, tetapi kita tidak tahu bagaimana melakukannya - jadi kita luangkan waktu sebentar untuk mencarinya.

— traffichazard

Untuk memperjelas jawaban saya. Anggota yang tidak mengetik biasanya hanya akan melakukan penelitian jika kode tidak ditulis pada saat itu. Misalnya anggota pengetik sedang membangun atau meneliti juga. @ Jonnsyweb Saya pikir penting untuk mengenali bahwa pemrograman pasangan (atau anthing dalam hal ini) bukan proposisi semua atau tidak sama sekali.

— westcoastdiff

Penelitian paralel sangat kuat jika Anda mencari jawaban di lokasi yang berbeda. "Anda membaca artikel itu, saya akan menjelajahi buku dan kami akan menyinkronkan kembali dalam 10 menit". Siapa pun yang memberikan solusi (mungkin) harus berbagi pengetahuan tentunya.

Salah satu cara terbaik untuk menangani ini adalah dengan menggunakan " spike ". Ini terjadi selama rapat estimasi untuk membantu membuat estimasi lebih akurat. Singkatnya, Anda menunda estimasi tugas tertentu hingga lonjakan (timeboxed) selesai dan Anda cukup tahu tentang masalah untuk dengan yakin menempatkan angka di atasnya. Ini mungkin termasuk mencoba beberapa lib atau komponen baru atau menulis program kecil sebagai bukti konsep.

— Martin Wickman
sumber