Alasan Pemrograman Pasangan


13

Saya telah bekerja di beberapa toko di mana manajemen telah memberikan gagasan tentang pemrograman pasangan baik kepada saya atau manajer / pengembang lain, dan saya tidak bisa mendapatkannya sama sekali. Dari sudut pandang pengembang, saya tidak dapat menemukan alasan mengapa beralih ke gaya pengkodean ini akan bermanfaat, juga sebagai manajer tim kecil saya tidak melihat manfaat.

Saya mengerti bahwa ini membantu kesalahan sintaks dasar dan dapat membantu jika Anda perlu melakukan sesuatu, tetapi manajer yang keluar dari lingkaran pemrograman tampaknya terus melihatnya sebagai cara untuk menjaga desainer mereka dari pergi ke Facebook atau Reddit daripada sebagai alat desain.

Sebagai seseorang yang dekat dengan lantai pengembangan yang tampaknya tidak begitu mengerti dari buku yang melemparkan cara saya atau halaman wiki pada subjek ... dari posisi manajemen tingkat tinggi, apa manfaat dari Pair Programming ketika berhadapan dengan Scrum atau Agile lingkungan?


2
Saya pikir ini berguna dalam situasi yang sangat spesifik. Tetapi sebagai model pengembangan umum, ini agak tidak berguna.
Ryan Kinal

4
Ini mungkin tergantung pada perangkat lunak, yang dapat mewarnai tampilan Anda. Jika Anda memiliki banyak widget kecil dan mengerjakan berbagai perangkat lunak kustom yang berbeda setiap hari, kemungkinan tidak berguna. Ini menjadi sangat bermanfaat ketika Anda berurusan dengan sistem perusahaan besar di mana pengembang perlu memperhitungkan kaskade di seluruh sistem yang dibuat oleh fungsi yang mereka terapkan. Menulis satu kelas yang memengaruhi data yang digunakan di lebih dari 30 tempat yang berbeda umumnya dapat dipertimbangkan oleh 2 orang yang akan memiliki berbagai proses mental untuknya. Ini seperti metode monte carlo untuk penemuan pra-cacat.
Jimmy Hoffa

@JimmyHoffa Jadi proses pemikiran utama adalah bahwa jika kita menemukan bug sebelum mereka bahkan melakukan pengujian penerimaan kita dapat sangat mengurangi waktu yang hilang pada ulasan kode / pengujian di telepon?
Jeff Langemeier

3
@JeffLangemeier Sebenarnya lebih dari itu; Jika Anda melihat kekurangan dalam desain bagian A1 dari subsistem A sebelum A1 bahkan ditulis karena wacana alami yang terjadi antara dua pengembang di tengah penerapan subsistem A, Anda tidak hanya menghemat waktu yang akan dihabiskan untuk memperbaiki bagian A1, dan bagian A5 dan A7 yang bergantung pada A1 (atau menemukan bug di bagian-bagian dependen karena kaskade dari memperbaiki A1), Anda menghemat waktu dengan tidak menulis bagian buruk itu sama sekali. Ini mengurangi waktu tes ya, tetapi lebih lanjut mengurangi waktu dev dengan cara ini.
Jimmy Hoffa

@ MartinWickman Ini bukan duplikat. Dalam tautan Anda, mereka benar-benar mencari Kontra, meskipun judulnya meminta Pro dan Kontra. Juga, jawaban yang lebih menyeluruh dari pro diberikan dalam yang satu ini; sampai pada titik itu, bermanfaat bagi masyarakat untuk memiliki yang satu ini walaupun itu dekat dengan yang lain.
Jeff Langemeier

Jawaban:


25

Sebagian, itu tergantung pada bagaimana Anda melakukan pemrograman pasangan. Dalam beberapa kasus, driver dari pasangan menulis kode, sedangkan anggota kedua dari pasangan mengamati dan mendiskusikan desain dan implementasi detail dari sistem. Contoh lain dari pemrograman berpasangan melibatkan kedua orang menulis kode secara bersamaan - satu orang sedang menulis fungsionalitas yang diimplementasikan dan yang lainnya secara aktif mengembangkan dan menulis kode uji pada unit dan tingkat integrasi, lagi-lagi mendiskusikan rincian desain dan implementasi sistem.

Terlepas dari jenis pemrograman pasangan, secara efektif berfungsi sebagai tinjauan kode terus menerus . Anda memiliki perhatian dua orang pada kode, mengawasi kesalahan sebelum melarikan diri ke lingkungan pengujian sistem / penerimaan selanjutnya atau bidang. Anda juga memiliki dua orang yang memahami bagian tertentu dari sistem dengan sangat baik, untuk berfungsi sebagai redundansi untuk meminimalkan faktor bus Anda . Cacat penangkapan awal dan penyebaran pengetahuan sistem di sekitar tim mengurangi biaya membangun sistem.

Penyebaran pengetahuan tidak hanya terbatas pada pengetahuan teknis tim. Bergantung pada siapa pasangan itu, dapat memungkinkan informasi mengalir antara anggota yang lebih senior dari perusahaan ke anggota baru tentang hal-hal lain yang melampaui proyek - gaya pengkodean, budaya perusahaan, harapan, dan sebagainya. Hal ini juga dapat memungkinkan seseorang yang lebih akrab dengan teknologi atau alat untuk berbagi pengetahuan mereka dalam teknologi atau alat itu dalam pengaturan dunia nyata yang diterapkan.

Seperti yang Anda sebutkan, ini juga membantu pengembang tetap fokus dan terus berjalan . Selain mengalir, banyak individu lebih kecil kemungkinannya untuk mengganggu beberapa orang yang mengerjakan sesuatu daripada satu individu yang mengerjakan sesuatu. Jika Anda berjalan di dekat meja seseorang dan mereka bekerja sendirian, tetapi Anda perlu berbicara dengan mereka, Anda mungkin mengetuk dan berbicara dengan mereka. Ini lebih kecil kemungkinannya jika Anda melihat dua orang atau lebih bekerja bersama atau berdiskusi - Anda tidak akan mengganggu mereka. Gangguan membutuhkan waktu, dan menghabiskan lebih banyak waktu berarti biaya lebih tinggi. Ini demi kepentingan bisnis terbaik untuk memaksimalkan produktivitas karyawan.

Namun, ada beberapa tantangan yang harus diatasi untuk membuat pemrograman pasangan layak. Pertimbangkan hal-hal seperti bentrokan kepribadian atau memilih pasangan untuk mendistribusikan pengetahuan dengan benar. Ada juga pertimbangan kapan tepatnya memutar pasangan. Pemrograman pasangan yang dilakukan secara sembarangan mungkin tidak akan efektif seperti yang direncanakan. Tergantung pada susunan tim Anda, mungkin tidak efektif untuk memasangkan orang sama sekali.


+1 untuk jawaban yang bagus. Saya masih sangat tidak menyukai ide itu, tetapi Anda memberikan manfaatnya dengan baik.

Saya suka potongan jib Anda, penjelasan ini sebenarnya membuat ini terasa layak.
Jeff Langemeier

9
Saya lebih suka model hybrid di mana pasangan lebih ad hoc berdasarkan kebutuhan saat ini. Juga, ada kalanya bekerja sendiri lebih efisien dan saat bekerja dengan pasangan lebih baik. Dipaksa menjadi pasangan permanen tampaknya sewenang-wenang dan tidak fleksibel bagi saya.
jfrankcarr

Jawaban yang sangat bagus Saya juga seorang programmer pada tim yang gesit dan kami melakukan banyak pairing. Pada awalnya kami juga skeptis, kami berpikir bahwa bekerja sendiri adalah cara terbaik untuk pergi. Daripada, pada suatu titik dalam evolusi tim, kami memberlakukan pemrograman pasangan. TIDAK ADA kode produksi yang dilakukan jika pasangan tidak diprogram. Ini adalah penegakan buatan dari konsep pasangan tetapi banyak membantu tim. Akhirnya, setelah kita semua terbiasa dengan teknik dan satu sama lain, kita mengubah stile kita dan kita bekerja sama secara ad-hoc dan sebagian besar ketika implementasinya lebih kompleks atau rawan kesalahan.
Patkos Csaba

@ jfrankcarr, tidak ada yang menyarankan pasangan permanen; Saya tidak yakin dari mana Anda mendapatkan ide itu. (Perhatikan bahwa jawaban ini secara khusus menyebutkan "kapan harus memutar pasangan".) Tim kami menemukan bahwa adalah ide yang sangat buruk untuk menjaga dua orang yang sama berpasangan satu sama lain selama lebih dari satu atau dua hari; Anda mulai terbiasa. Beberapa tim memutar setiap satu setengah jam (tautan PDF).
Joe White

3
  1. Kurang Kesalahan dalam kode akhir (efisiensi)
    Tidak sepenuhnya menggantikan ulasan kode tetapi sangat efektif untuk memperbaiki semuanya sejak awal. Ada penelitian di luar sana yang menunjuk ke arah itu.

  2. Penyelesaian lebih cepat (efektivitas)
    Ada beberapa penelitian yang menunjukkan hal ini. Ketika datang ke fitur kompleks 2 kepala hanya lebih efektif. Pengalaman dalam Berpasangan adalah suatu keharusan untuk ini.

(catatan: Ini adalah alasan penjualan Anda untuk manajer: Secara finansial keputusan yang waras karena Anda mendapatkan lebih efisien melalui jumlah bug yang lebih rendah dan lebih efektif dengan penyelesaian yang lebih cepat)

  1. Mengajar Junior
    Anda dapat menambahkan junior langsung ke programmer yang lebih berpengalaman. Jika Anda memiliki sekelompok pemula absolut, mudah untuk bertahan dan membiarkan mereka, sebagai pasangan, mencari tahu dasar-dasarnya. Tetap di sana dan berikan saran. Konsep ini tampaknya sangat tua dan berasal dari keahlian.

3

Jawaban Cepat: sebagian besar manfaat dan biaya dipasang di Wikipedia , mari kita lihat dari sudut yang berbeda.

Saya ingin menyebutkan kasus-kasus tertentu dari manfaat pemrograman pasangan yang berlaku untuk lingkungan pengembangan agile / scrum, yang diambil dari posting blog :

Keberhasilan atau kegagalan perangkat lunak tergantung pada kualitasnya, dan Pair Programming secara langsung meningkatkan kualitas dalam berbagai cara. Ketika dua pengembang bekerja sama meningkatkan kualitas pola desain karena pasangan mengembangkan kode yang pendek, sederhana, dan mudah dirawat dengan bug yang lebih sedikit. Bug adalah masalah kualitas utama dalam pengembangan perangkat lunak; dengan dua pasang mata menulis kode, lebih banyak kesalahan ditangkap, sehingga mengurangi biaya pengembangan. Bug yang ditemukan terlambat dalam proses pengembangan seringkali mahal untuk diperbaiki. Menemukan cacat perangkat lunak lebih awal mencegah dan membantu mencegah masalah yang sulit di jalan. Kompleksitas sering muncul dalam pemrograman, dan dua pikiran yang bekerja untuk menyelesaikan masalah bersama dapat melihat lebih banyak opsi dan menarik kesimpulan lebih cepat dari satu.

Singkatnya:

  • Mempromosikan komunikasi tim
  • Mempromosikan transfer pengetahuan aplikasi yang efisien
  • Mendorong akuntabilitas pada pendekatan desain
  • Menghasilkan kode yang lebih baik, mudah dirawat
  • Membantu menghilangkan kode buggy di tahap awal
  • Meningkatkan produktivitas tim karena anggota tim akan memiliki perhatian penuh selama pengkodean
  • Meningkatkan keterampilan komunikasi dan kolaborasi anggota tim
  • Membangun persahabatan di tempat kerja
  • Membuat pekerjaan lebih menyenangkan

When two developers work together design pattern quality improves-> frasa itu tidak masuk akal sama sekali. Setidaknya tidak lebih masuk akal daripada When two bakers work together wheat quality improvesatau When two race drivers work together asphalt quality improves.
phresnel

Itu adalah kutipan dari blog yang mungkin Anda lihat. Namun, maksud saya adalah untuk menekankan fokus yang lebih baik pada desain teknis & kualitas kode, dengan beberapa jenis akuntabilitas, karena setiap pengembang berusaha untuk bangga pada kode yang dibuat.
Yusubov

2

Ada beberapa manfaat untuk pemrograman pasangan:

  • Kedua programmer dapat berkolaborasi dalam desain bersama, berpotensi menghasilkan arsitektur / kode yang lebih baik - dua pasang mata dapat menemukan kesalahan
  • Pengetahuan lembaga dipertahankan lebih baik - jika satu programmer pergi atau tidak tersedia, yang lain harus dapat melanjutkan pekerjaan tanpa banyak kehilangan produktivitas
  • Ini adalah salah satu cara untuk dengan cepat melatih pengembang baru - memasangkannya dengan anggota tim pengembangan yang berpengalaman dan mereka akan dapat mengalami basis kode dari perspektif veteran tim
  • Disiplin yang lebih baik - programer berpasangan cenderung menjadi produktif selama periode waktu yang lebih lama, karena salah satu dari yang lain dapat mengambil alih untuk semburan aktivitas. Tugas yang berpotensi membosankan, seperti pengujian unit, mungkin lebih jarang dilewati daripada untuk pengembang solo.

Wikipedia juga memiliki ringkasan yang bagus tentang biaya dan manfaat dalam entri wiki .

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.