Pairing programming ketika pengemudi dan pengamat memiliki tingkat keterampilan dan pengalaman yang berbeda


30

Saya tahu pemrograman pasangan adalah teknik pengembangan perangkat lunak tangkas di mana dua programmer bekerja bersama di satu workstation. Satu, pengemudi, menulis kode sementara yang lain, pengamat, meninjau setiap baris kode saat diketikkan.

Tapi saya hanya ingin tahu strateginya masih berfungsi dalam kasus ini. Sebagai contoh

  • jika mereka memiliki tingkat keahlian pemrograman yang sangat berbeda.
  • jika seseorang tidak pernah mengalami dalam masalah domain sementara yang lain miliki.
  • Apakah masih OK jika mereka memiliki tingkat keterampilan pemrograman yang rendah?

Bisakah Anda menyarankan strategi pemrograman pasangan dalam kasus di atas?


13
Pastikan keduanya sepakat tentang siapa yang memiliki tingkat keterampilan lebih tinggi dan yang seharusnya melatih yang lain. Jika level peran / keterampilan ini tidak jelas, pemrograman pasangan mungkin tidak akan berhasil dan menyebabkan konflik.
Giorgio

Tetapi, jika dilakukan seperti yang Anda sarankan, itu bisa menjadi kesempatan belajar yang luar biasa.
Mawg

Jawaban:


27

Dengan asumsi bahwa orang yang lebih berpengalaman dalam pasangan memiliki temperamen untuk membimbing orang lain, memasangkan seseorang dengan sedikit pengalaman dalam bahasa atau domain masalah dengan orang yang berpengalaman akan memfasilitasi transfer pengetahuan. Orang yang kurang berpengalaman akan memiliki mentor untuk mengajar mereka tentang bahasa, domain, aplikasi, dan praktik atau konvensi terbaik dari tim.

Ada ringkasan yang menarik tentang wiki C2 tentang transfer pengetahuan menggunakan pemrograman pasangan . Orang yang lebih senior, yang dibawa untuk melayani sebagai mentor tim, belajar banyak dari para programmer junior dan pengetahuannya bahkan meningkat sebagai hasil dipasangkan dengan lebih banyak junior, pengembang perangkat lunak yang kurang berpengalaman. Ada beberapa cerita lain tentang programmer ahli yang berpasangan dengan pakar domain.


Sepakat. Saya memiliki junior di tim dan pemrograman pasangan secara dramatis meningkatkan kualitas kode-nya. Namun, meninjau ulang kodenya juga sangat membantu.
Sulthan

2
Anda hanya perlu berhati-hati bahwa orang senior bukanlah pengemudi 100% dari waktu.
HLGEM

13
@HLGEM Saya bahkan berpendapat bahwa orang yang kurang berpengalaman harus menjadi pengemudi sebagian besar waktu, sementara orang yang lebih berpengalaman sedang meninjau kode untuk cacat dan gaya atau menulis kasus uji terhadapnya.
Thomas Owens

1
Saya setuju dengan @ThomasOwens; memiliki dorongan mitra yang kurang berpengalaman akan memunculkan 'pengalamannya lebih cepat daripada metode lain, sambil memungkinkan mereka untuk berbagi ide dan wawasan mereka sendiri dengan mitra yang lebih senior. Tidak akan lama sebelum tingkat kemahiran mereka lebih dekat.
Eric King

1
Saya bertanya-tanya apakah ini membuat dev senior lebih wajib untuk mempraktekkan apa yang mereka khotbahkan?
JeffO

16

Inilah tepatnya pemrograman use case pair yang dibuat untuk: berbagi pengalaman antara janggut tua dan belalang muda.

Ini adalah pembagian dua arah: serangga lincah memiliki banyak hal untuk diajarkan pada otak rematik.


1
Meskipun Anda mungkin akan menganggap saya satu, saya mencoba 'otak rematik' ...
Marjan Venema

1
Saya tidak berpikir istilah "kisah pengguna" dapat diterapkan di sini. Kisah pengguna menggambarkan persyaratan bisnis untuk suatu perangkat lunak.
Konrad Rudolph

Ya, saya pikir maksudnya "use case".
Jörg W Mittag

Downvoted: tidak ada kata tentang strategi bagaimana menangani kasus-kasus yang disebutkan.
coba-tangkap-akhirnya

10

Ketika saya dipromosikan ke tim saya saat ini, saya adalah pemula di J2EE tetapi saya adalah ahli dalam domain tersebut. Senior saya (pemimpin tim baru) terampil dalam J2EE tetapi tidak di platform.

Saya pikir saya belajar lebih banyak tentang Java2EE dalam 4 bulan ini dengan pemrograman pasangan daripada membaca buku dan pemimpin tim belajar tentang platform juga.

Kesenjangan pengalaman antara keduanya adalah kunci untuk memasangkan imho pemrograman.


2
Sepakat. Saya bisa membayangkan memasangkan pemrograman dengan diri saya sendiri, dan saya pikir itu tidak ada gunanya. Kesenjangan inilah yang menciptakan perspektif berbeda yang relevan untuk membuat 4 mata mencakup lebih banyak ruang lingkup dalam diagram kemungkinan. Dua orang dengan keterampilan dan pengalaman yang sama akan melihat hal yang sama seperti satu sama lain dan tidak mendapat manfaat.
Jimmy Hoffa

5

Saya akan menggambarkan pengalaman saya dan mencoba untuk mendapatkan "strategi" dari itu.

Saya pernah memasangkan satu program dengan non-programmer lengkap. Dia ahli dalam masalah produk perangkat lunak yang kami kembangkan. Sebaliknya, saya tidak punya pengalaman dalam domain masalah. Dan dia juga adalah penyelia saya saat ini (saya tahu ini mungkin terdengar aneh :)

Manfaat utama dari metodologi ini adalah saya harus menjelaskan implementasi banyak hal dari domain pengetahuannya, sehingga memastikan ketepatan implementasi dan pemahamannya tentang proses, yang berarti dia mengerti mengapa perlu waktu ini.

Manfaat lain adalah fokus yang mudah pada tugas, tidak ada gangguan (ha-ha, bayangkan membuka Twitter di depan hidung bos Anda).

Namun, kadang-kadang cukup menakutkan, karena bahkan istirahat minum teh pun menjadi "gangguan dari pekerjaan" (bukan dari sudut pandangnya; itu hanya merepotkan untuk meminta istirahat dan sebagainya).

Jadi, ini bukan benar-benar pemrograman pasangan karena dia tidak bisa meninjau kode seperti yang diketikkan. Namun, itu tampaknya menjadi strategi yang waras (setidaknya untuk beberapa waktu). Ini akhirnya bekerja sama sekali karena kesederhanaan relatif dari kedua metodologi pengembangan (maksud saya, tidak ada teknik desain perangkat lunak yang kompleks seperti Pola OOP yang terlibat) dan materi pelajaran. Ini tidak akan berfungsi kalau-kalau kita harus mengembangkan kompiler saya pikir. Saya percaya itu masih bisa bekerja jika pengamat non-programmer berpartisipasi dalam proses pengembangan potongan-potongan kecil yang jelas. Katakanlah, tidak apa-apa untuk membuatnya menonton pemrograman dari suatu fungsi "menghitung parameter X dari Y dan Z dengan algoritma yang diberikan", tetapi mungkin tidak begitu ok untuk meminta dia menonton keseluruhan proses desain sistem (artinya pengembangan arsitektur perangkat lunak, yaitu hierarki dari kelas,

Saya pikir itu akan bekerja lebih baik jika dia akan memiliki beberapa keterampilan programmer dasar, karena saya tidak perlu menjelaskan "apa itu array".

Semoga bisa membantu :)


Ini penjelasan berpengalaman yang bagus!
Sakares

2

Dalam pengalaman saya jika kedua programmer memiliki tingkat keterampilan yang rendah itu bisa menjadi masalah. Dalam hal ini sering ada kecenderungan untuk mencoba pemrograman copy-paste. Saya pikir itu bisa menjadi ide yang baik untuk tidak memasangkan dua programmer pemula bersama-sama sampai mereka mencapai level tertentu yang ditentukan oleh tim.

Kalau tidak, pemrograman pasangan bisa menjadi ide bagus dengan asumsi tentu saja dua orang siap untuk berbagi apa yang mereka ketahui. Tidak hanya itu cara yang bagus untuk membuat semua orang mendapat informasi tentang kode sumber tetapi juga bertindak sebagai tempat yang baik untuk ide dan diskusi baru.


Pengembang tingkat keterampilan rendah cenderung menyalin dan menempel saat memprogram sendiri? Inilah yang biasanya terjadi ketika tidak ada yang menonton.
JeffO

1

Selama anggota tim saling menghormati satu sama lain, pemrograman pasangan dapat bermanfaat terlepas dari tingkat pengalaman pemrogram. Bahkan jika seorang programmer junior hanya melihat beberapa kesalahan sintaks (yang kita semua buat!) Sebelum programmer yang lebih berpengalaman, itu masih menghemat waktu dalam mengkompilasi kode.

Saya juga berpikir itu bisa membuka sikap seorang programmer terhadap kemampuan anggota lain dari tim mereka, terutama jika mereka memiliki pikiran terbuka dan berharap semua orang bisa mengajari Anda sesuatu.

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.