Apa kemungkinan kerugian dari pemrograman pasangan? [Tutup]


22

Pemrograman pasangan cukup terkenal sekarang-a-hari.

Ini memiliki beberapa keunggulan seperti:

  1. Program dengan bug lebih sedikit.
  2. Biaya perawatan pasca produksi jauh lebih sedikit.
  3. Praktik yang sudah mapan ditantang sehingga muncul ide-ide baru.
  4. Programmer saling belajar satu sama lain.
  5. Programmer mengembangkan soft skill.

Tapi apa kelemahan pemrograman pasangan?


1
Apakah "paralel" dalam judul pertanyaan salah ketik?
5gon12eder

14
Maksud Anda selain fakta bahwa dibutuhkan dua orang untuk menghasilkan output yang sama (mungkin kurang)?
Robert Harvey

4
@ ThorbjørnRavnAndersen Mungkin kurang.
Robert Harvey

4
@ ThorbjørnRavnAndersen Ada yang salah dengan matematika Anda. Pada dasarnya, apa yang Anda katakan adalah bahwa Anda terus - menerus dalam peer review / kode. Sulit membayangkan bagaimana itu lebih hemat waktu.
Robert Harvey

5
Itu dapat dicapai dengan cukup mudah tanpa gangguan pengaturan Pemrograman Pasangan yang penuh. Hanya bekerja dengan sesama pengembang perangkat lunak Anda dalam kapasitas ini sesuai kebutuhan.
Robert Harvey

Jawaban:


28

Meskipun pemrograman pasangan telah mendapatkan reputasi yang cukup besar, ia memiliki beberapa jebakan juga.

Beberapa di antaranya adalah sebagai berikut:

  1. Dalam pemrograman berpasangan Anda tidak dapat duduk dan mengevaluasi diri sendiri kode Anda.
  2. Salah satu pasangan mungkin berhenti terlibat aktif.
  3. Pengemudi perlu "memprogram dengan keras". Pemrograman yang diam-diam mengurangi manfaatnya.
  4. Dibutuhkan lebih banyak jam kerja untuk menghasilkan fitur yang sama. Keseimbangan harus dijaga antara kualitas kode dan peningkatan biaya pengkodean.
  5. Fenomena "watch the master" mungkin muncul ketika seorang programmer berpengalaman dan pemula berpasangan. Anggota pemula dapat menjadi pengamat dengan anggota yang berpengalaman menyelesaikan sebagian besar pengkodean.
  6. Ketika dua pengguna berpengalaman berpasangan, sebuah fenomena "ego pengembang" mungkin muncul, dengan masing-masing anggota berusaha untuk mendorong ide-idenya sendiri.

4
2 dan 5 dapat dilawan dengan Ping-Pong Pairing (beralih peran antara pengemudi dan navigator dengan sangat cepat dalam siklus-kunci dengan siklus TDD: Alice menulis tes gagal, Bob menulis kode untuk melakukan tes lulus, Alice refactor, Bob menulis tes gagal, Alice menulis kode untuk lulus ujian, refactor Bob, Alice menulis tes gagal ...). Dengan cara itu, pengemudi dan navigator berganti peran setiap beberapa menit paling lambat (lebih seperti puluhan detik), dan setiap anggota mendapat tugas yang sama besar dan penting.
Jörg W Mittag

5
4 terdengar jelas, tapi saya tidak yakin. Menangkap bug dan mendapatkan umpan balik lebih awal, misalnya, mungkin (atau mungkin tidak) benar-benar menebus jam pengembang berlipat ganda.
Jörg W Mittag

4
@ JörgWMittag (re: Ping-Pong pairing) terdengar seperti resep untuk hari kerja yang sangat menegangkan: / Saya harap saya tidak pernah harus memprogram di tempat di mana mereka menerapkan metodologi pemrograman pasangan ketat ini atau apa pun.
Andres F.

4
Pemrograman ping-pong mengharuskan keduanya yang terlibat pada dasarnya dapat dipertukarkan. Saya memiliki seorang kolega di mana satu-satunya kombinasi pemrograman pasangan yang masuk akal adalah membuat dia berpikir dan saya mengetik (dan merenungkan). Ini membantunya menjaga fokus dan saya memahami apa yang sedang terjadi.
Thorbjørn Ravn Andersen

3
Anda juga dapat menyebutkan bahwa cukup banyak waktu yang terbuang untuk membahas rincian sepele sementara dalam ulasan kode Anda dapat fokus pada aspek-aspek penting saja.
Giorgio

24

Saya telah mencoba pemrograman pasangan beberapa kali, termasuk dalam sebuah organisasi yang (secara singkat) menganggap meluncurkannya sebagai proses wajib untuk semua insinyur (Anda dapat menebak seberapa baik ide itu muncul). Secara pribadi, saya benci itu.

Alasan saya daftar di bawah ini hanya pengalaman subjektif saya, dan saya tidak bisa 'mengukur' dampaknya secara konkret. Tapi di sini semuanya sama:

1 - Memiliki 'navigator' dan 'driver' hanya membantu jika yang pertama vokal dan yang kedua akan mendengarkan.

Kita semua telah bertemu dengan pengembang yang keras kepala, bersemangat tentang beberapa masalah teoretis atau secara patologis tidak mampu - secara psikologis - untuk 'membuang' pekerjaan lama ketika seseorang menyarankan masalah dengannya. Dan kita semua tahu individu terlalu malu-malu atau malu-malu untuk mengajukan kekhawatiran atau menyarankan kasus sudut.

Saat pengembang semacam ini dipasangkan, navigator dengan cepat mengambil peran pasif, dan yang akhirnya Anda lakukan adalah pemrograman tunggal dengan peninjauan kode otomatis. Ini adalah pemborosan sumber daya yang monumental.

2 - Berpasangan mencegah kreativitas.

Bertentangan dengan apa yang sebelumnya dirasakan tentang nilai 'brainstorming kelompok', konsensus akhir-akhir ini adalah bahwa pekerjaan pengetahuan kreatif membutuhkan kemandirian dan otonomi . Ketika Anda bekerja sendirian, Anda dapat dengan cepat meretas beberapa ide gila untuk melihat apakah itu benar-benar layak. Tanpa kata-kata Anda dapat membuat prototipe aneh, dan jika Anda gagal, itu tidak masalah, karena tidak ada yang tahu .

Bandingkan dengan berpasangan: ketika saya ingin mencoba beberapa konsep baru, saya harus meyakinkan pasangan saya, membicarakannya melalui implementasi, langkah-demi-langkah, dan berharap mereka tidak akan menilai saya jika gagal. Lingkungan semacam itu beracun untuk menciptakan ide-ide baru.

3 - Desain penyebut umum terendah.

Ketika pasangan tidak dapat memunculkan ide-ide baru, seperti di atas, atau ketika individu tidak dapat menyetujui beberapa prinsip dasar tentang bagaimana fitur harus dirancang, apa yang keluar adalah desain yang kacau yang berusaha untuk berkompromi dan memuaskan tidak ada seorang pun.

Jika Anda memasangkan pengembang yang membangun abstraksi pemrograman fungsional yang indah, fasih, dan ke langit dengan kinerja yang cepat dan kotor, kode yang mereka hasilkan bersama biasanya tidak akan terlalu elegan atau terlalu cepat.

4 - Kurangnya otonomi dan transparansi yang keras.

Transparansi dengan kekerasan adalah ungkapan yang saya petik dari polemik yang cukup terkenal (dan cukup kontroversial) terhadap metodologi Scrum. Ini menggambarkan cara beberapa organisasi menghina pengembang dan memperlakukan mereka dengan kecurigaan yang biasanya diperuntukkan bagi pekerja non-profesional.

Apa pun yang Anda pikirkan tentang 'bahaya' membuat pekerjaan pengembang sepenuhnya transparan (dan Anda mungkin tidak setuju itu sebenarnya merugikan), banyak orang menghargai otonomi mereka dan kemampuan mereka untuk bekerja sendiri, dipercaya untuk melakukan hal yang benar. Ini merupakan kebutuhan psikologis yang penting, dan untuk memaksa pengembang berpasangan (seperti yang saya lihat terjadi di setidaknya satu toko) akan membuat karyawan kecewa, kesal, dan teralienasi.

5 - Beberapa pengembang tidak bermain baik berpasangan.

Beberapa orang tidak akan atau tidak dapat berperilaku dengan tepat di lingkungan berpasangan. Mereka mungkin memiliki kebersihan yang buruk, kebiasaan kerja yang buruk, kepribadian yang kasar, cara yang 'keras' dan 'intens', atau sejumlah atribut lain yang membuat mereka menjadi pekerja individu yang baik, tetapi pemrogram pasangan yang miskin.

Bisakah kamu menyelesaikan ini? Tidak juga. Mengubah perilaku pribadi itu sulit. Toko pemrograman pasangan harus sangat berhati-hati dalam merekrut dan menginvestasikan banyak waktu untuk melihat bagaimana seseorang bekerja dan apakah mereka akan dapat bekerja dengan baik dengan rekan-rekan mereka. Namun, mendiskriminasi kepribadian dengan lebih keras berarti perekrutan akan memakan waktu lebih lama kecuali Anda melonggarkan standar keterampilan dan keahlian Anda.


3
Meskipun saya menyukai ungkapan "transparansi yang kejam", pengalaman saya bahwa metodologi yang disukai (scrum / gesit atau sesuatu yang lebih tradisional) tidak memiliki hubungan dengan apakah pengembang diperlakukan seperti profesional atau tidak. Organisasi disfungsional akan memperlakukan para profesional seperti anak-anak apakah mereka (berpura-pura) mengikuti Scrum atau CMMI.
David

1
"Bandingkan dengan pasangan: ketika saya ingin mencoba beberapa konsep baru, saya harus meyakinkan pasangan saya, membicarakannya melalui implementasi, langkah demi langkah, dan berharap bahwa mereka tidak akan menilai saya jika gagal. Jenis seperti itu lingkungan beracun untuk menciptakan ide-ide baru. ": Ini bukan hanya tentang penilaian, ini tentang kecepatan. Anda tidak ingin terganggu ketika Anda memiliki ide, Anda ingin menuliskan sebanyak yang Anda bisa selama Anda dalam aliran. Pairing programming secara aktif mencegah Anda melakukan hal itu.
Giorgio

1
Setelah Anda menuliskan semua ide Anda, Anda dapat merapikannya, mungkin pada hari berikutnya dan, setelah itu, biarkan seorang kolega melakukan peninjauan menyeluruh, misalnya pada alat seperti papan peninjau, sehingga mereka memiliki semua waktu untuk melihat Anda menyelesaikan ide dan memikirkannya tanpa tekanan waktu. Pemrograman pasangan juga mencegah hal ini karena mencoba menggabungkan pengkodean dan tinjauan kode menjadi satu aktivitas.
Giorgio

2
@ Jimmy: Jika Anda menulis lima jawaban alih-alih satu jawaban dengan lima poin, Anda akan mendapatkan lima upvotes dari saya.
Giorgio

Sepenuhnya setuju bahwa bereksperimen membutuhkan kerja yang sunyi dan cepat - kebalikan dari tuntutan pasangan. Mungkin pemasangan bekerja dengan baik untuk pengembang yang melakukan pemeliharaan atau menambahkan fitur diskrit ke sistem perusahaan besar yang ada. Tapi saya yakin itu tidak berguna sama sekali untuk pekerjaan yang membutuhkan penemuan, teknologi baru, kecerdikan atau cara kreatif untuk bekerja dengan kendala yang sulit.
Jimmy Breck-McKye

12

Tergantung pada situasi atau perspektif Anda.

Pemrograman Pasangan baik untuk organisasi. Tetapi apakah itu baik untuk individu?

Bagaimanapun, ini adalah metode penghematan biaya (umpan balik awal) dan produktivitas; Ini bukan tentang Anda tetapi proyek, produk, perusahaan ($$).

Meskipun Anda dapat memiliki manfaat pribadi, itu bukan alasan atau akhir dari metodologi pengembangan apa pun. Pemrograman pasangan (penuh waktu), misalnya, juga menghentikan Anda dari mengendur, berselancar, dll. Anda harus membenarkan jeda Anda kepada pasangan Anda.

Pasangan (berputar) Anda akan menjadi kamera pengintai terbaik: intensitas kerja meningkat.

Atau, dengan mendistribusikan pengetahuan, individu menjadi kurang berisiko bagi perusahaan (mis. Tidak dapat meninggalkan perusahaan dengan pengetahuan penting) dan memiliki lebih sedikit "chip tawar-menawar".

Saya yakin Anda menemukan lebih banyak poin dengan membaca artikel afirmatif lebih kritis dari situasi / sudut pandang ANDA yang sebenarnya di perusahaan daripada dari sudut pandang manajer Anda.

Hampir semua metodologi ditulis dari sudut pandang manajer.


Kecuali Anda memiliki perusahaan Anda diberi uang untuk menghasilkan kode. Kode yang lebih baik yang bisa Anda hasilkan lebih baik untuk atasan Anda - berpikir dengan cara untuk memiliki tawar menawar melawan majikan Anda menurut saya tidak memahami apa yang membuat Anda berharga di tempat pertama. Saya percaya PP sangat intensif sehingga Anda tidak bisa melakukan ini sepanjang hari, tetapi secara otomatis perlu istirahat.
Thorbjørn Ravn Andersen

7
Karena beberapa orang dipaksa mencari nafkah dari "menjadi berharga bagi majikan" mereka juga harus menghitung dengan kepentingan pribadi, dan tidak hanya dengan kepentingan atasan mereka seperti para pelayan.
Seorang tamu

1
@ ThorbjørnRavnAndersen kita tidak hidup di dunia yang ideal, di mana setiap orang membayar pajak dan semua orang mendapat kompensasi berdasarkan prestasi.
Den

1
@ ThorbjørnRavnAndersen Kode yang lebih baik semakin baik untuk majikan saya? Saya berharap saya hidup di dunia seperti itu, di dunia saya yang penting adalah memproduksi fungsionalitas secepat mungkin, di mana kualitas kode hanyalah nilai lunak menengah yang seharusnya tidak mendapatkan waktu lebih dari yang dibutuhkan. Bugnya ok, biasanya tidak parah dan mudah diperbaiki.
Alex

@Alex "biasanya tidak parah" - Saya merindukan dunia itu: D
Gusdor

5
  1. Tiba-tiba Anda sekarang harus memberi tahu seseorang ketika Anda ingin pergi ke toilet atau minum kopi. Setidaknya tidak perlu meminta izin.

  2. Anda harus mengatasi standar kebersihan orang lain.


4

Selain jawaban lain:

  1. Banyak perusahaan tempat saya bekerja untuk mengeluarkan programmer mereka dengan laptop (berbasis di situs klien - lebih mudah untuk menjaga peralatan tetap aman jika dibawa pulang setelah bekerja, dapat melakukan pekerjaan sambilan dari rumah menggunakan VPN dalam keadaan darurat, dll.) lalu saya sudah memiliki masalah untuk melihat pada layar laptop orang lain ("driver") dari perspektif selancar bahu - usia tidak akan memperbaiki ini (dan beberapa layar menjadi sulit dibaca di luar sudut pandang ideal dalam hal apapun).

    Jadi pasangan programmer akan membutuhkan layar yang cukup besar, yang akan meningkatkan biaya perangkat keras dan membatasi adaptasi ke lokasi. Mungkin tidak menjadi masalah bagi sebagian orang, dalam kasus lain itu akan menjadi masalah.

  2. Saya juga menemukan bahwa perbedaan dalam preferensi kebersihan pribadi (termasuk merokok, makan dan minum), serta bentrokan kepribadian, pasti akan menghambat produktivitas. Cukup mudah untuk memberitahu dua programmer untuk "menyedot dan bergaul", sering kali ini akan membuat orang lebih suka menutup mulut dan diam-diam saling menyabotase melalui tindakan agresif-pasif untuk melampiaskan kebencian mereka satu sama lain.
  3. Kebisingan. Saya, misalnya, menyukai lingkungan kerja yang tenang. Saya tidak dapat membayangkan obrolan terus-menerus dari beberapa kelompok programer berpasangan (karena Anda perlu berbicara untuk komunikasi). Bahkan musik vokal di headphone saya cenderung mengganggu konsentrasi saya (instrumental lembut untuk mendengarkan di kantor ...). Saya kira ini dapat dikurangi dengan pindah dari kantor rencana terbuka di mana-mana ke ruang kantor 2-orang khusus, tapi itu akan menaikkan biaya lagi.

Anekdot untuk hiburan Anda:

  • Majikan sebelumnya pernah mendapat kontraktor dari negara lain (semuanya tetap anonim untuk melindungi yang bersalah). Majikan menyediakan akomodasi tetapi tidak untuk transportasi. Karena kontraktor itu tinggal di sepanjang rute saya untuk bekerja, saya menjadi sukarelawan untuk menjemputnya dan menurunkannya lagi. Katakanlah kebersihan pribadinya tidak pada standar yang sama dengan yang saya gunakan, dan dia juga merokok berat ("yang terkuat!") Sedangkan saya tidak. Dalam perjalanan 15 menit kami ke kantor, saya menjaga jendela saya tetap terbuka - bahkan di musim dingin - yang tidak mencegah mobil saya berbau seperti ruang merokok yang basi setelah masa kerja 3 bulan rekan kerja (tidak, dia tidak merokok di dalam mobil , tapi dia melakukannya sambil menungguku).
  • Kami juga tidak melakukan pemrograman berpasangan, tetapi duduk bersebelahan di meja konferensi (untuk sementara waktu). Setelah sekitar satu bulan, ada cincin cokelat yang bagus di atas kayu imitasi meja di sekitar posisi tangan tikus rekannya. Pada saat itu saya mendapat meja terbuka tepat di sebelah area rencana-buka-pusat-panggilan, yang saya sukai (dengan bantuan headphone saya).
  • Lalu ada minuman kantor di mana-mana: kopi. Meskipun saya meminumnya, saya bisa bergaul tanpa dan tidak minum sesering rekan kerja lainnya. Napas dalam jarak dekat bisa sangat tidak menyenangkan - mirip dengan bau mug yang terlupakan. Sebut saja wewangian "lembab" ...

3

Saya pikir pemrograman pasangan gagal karena alasan sosial dan praktis. Pada dasarnya Anda meminta satu orang untuk bekerja di bawah pengawasan konstan dan yang lain untuk melakukan apa-apa selain menyodok lubang.

Apa yang tak terelakkan terjadi setelah beberapa saat adalah bahwa pasangan berpisah untuk 'memeriksa email' atau 'Anda melakukan pemeriksaan buruk pada masalah langsung itu' dll

Daripada meningkatkan output kode volume berkurang. Keduanya untuk alasan praktis, 'Saya perlu makan siang / rapat agar tidak selaras dengan Anda' dan sosial 'Saya hanya menunggu bob untuk menyelesaikan apa yang dia lakukan sebelum saya bertanya tentang berpasangan lagi, saya tidak ingin dilihat mengganggu'

Adapun keuntungan yang dibanggakan, ada banyak praktik umum yang mencapainya dengan cara yang lebih sederhana dan efektif


2

Memberitahu dua pengembang senior untuk melakukan "pemrograman rasa sakit" jika mereka yakin orang dapat melakukan pekerjaan itu adalah salah satu kelemahan terbesarnya.

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.