* Pemilik kode * sistem: apakah ini cara yang efisien? [Tutup]


50

Ada pengembang baru di tim kami. Sebuah metodologi tangkas di gunakan di perusahaan kami. Tetapi pengembang memiliki pengalaman lain: ia menganggap bahwa bagian-bagian tertentu dari kode harus ditugaskan kepada pengembang tertentu. Jadi, jika satu pengembang telah membuat prosedur program atau modul, akan dianggap normal bahwa semua perubahan prosedur / modul hanya akan dibuat olehnya.

Di sisi positifnya, seharusnya dengan pendekatan yang diusulkan kami menghemat waktu pengembangan umum, karena setiap pengembang tahu bagian kode dengan baik dan membuat perbaikan cepat. Kelemahannya adalah pengembang tidak mengetahui sistem sepenuhnya.

Apakah Anda pikir pendekatan ini akan bekerja dengan baik untuk sistem ukuran sedang (pengembangan situs jejaring sosial)?


23
Saya telah bekerja dengan cara ini dan saya akhirnya harus mengubah kode yang bukan milik saya. Karena kode itu bukan "milikku", kode itu selalu menyinggung seseorang dan kode itu tidak pernah didokumentasikan atau diuji dengan cukup baik agar perubahannya mudah. Dalam proyek yang saya miliki, saya selalu mendorong kepemilikan grup bersama dengan integrasi cepat (untuk mencegah penggabungan panjang).
Danny Varod

26
Saya tidak bisa cukup menekankan kepada Anda betapa buruknya ide ini. Jawaban di bawah merangkum semua yang salah dengan kepemilikan kode sehingga satu-satunya hal yang dapat saya tambahkan adalah pengalaman pribadi saya bagaimana sebuah toko pengembangan perangkat lunak tempat saya bekerja berubah dari tempat yang hebat untuk bekerja dengan orang-orang baik menjadi mimpi buruk pengembang egois, dua kali lebih banyak malas pengembang, dan kode koboi unmaintainable yang mengerikan.
maple_shaft

6
Saya benar-benar menanyakan pertanyaan ini sejak lama: programmers.stackexchange.com/questions/33460/…
Jim Puls

7
Kedengarannya seperti dia mencoba kode dirinya menjadi tak tergantikan.
Iain Holder

6
Klarifikasi: ketika Anda mengatakan "semua perubahan pada prosedur / modul hanya akan dibuat olehnya", maksud Anda tidak ada orang lain yang boleh menyentuh modul itu, atau apakah Anda maksudkan ketika kami membagikan tugas, kami mengalokasikan tugas terkait dengan modul itu ke programmer yang menulisnya (atau akrab dengannya) terlebih dahulu, jika mungkin? Itu perbedaan yang halus, tetapi itu benar-benar mengubah sifat pertanyaan.
Scott Whitlock

Jawaban:


37

Seperti banyak dari pertanyaan ini, saya pikir jawabannya adalah:

Tergantung

Ada alasan untuk percaya bahwa mengambil posisi bahwa setiap programmer harus tahu setiap baris kode salah arah.

Jika kita berasumsi sesaat bahwa seseorang dengan pemahaman mendalam tentang sepotong kode akan membuat perubahan 5 kali lebih cepat daripada seseorang yang tidak mengetahuinya sama sekali (bukan lompatan besar keyakinan dalam pengalaman saya) dan dibutuhkan sekitar satu bulan pengalaman coding untuk mendapatkan pemahaman yang benar-benar baik dari modul berukuran signifikan (juga tidak masuk akal) maka kita dapat menjalankan beberapa (benar-benar palsu dan fiktif) angka:

  • Programmer A: memiliki pemahaman yang mendalam
  • Programmer B: tidak ada

Katakanlah programmer A mengerjakan 1 unit pekerjaan per hari. Dalam 4 minggu dari 5 hari kerja dia bisa menyelesaikan 20 unit pekerjaan.

Jadi programmer B, mulai dari 0,2 unit kerja per hari, dan berakhir dengan 0,96 unit kerja pada hari ke-20 (pada hari ke 21 mereka sama baiknya dengan programmer A), akan mencapai 11,6 unit kerja dalam waktu yang sama Periode 20 hari. Selama bulan itu programmer B mencapai efisiensi 58% dibandingkan dengan programmer A. Namun, Anda sekarang memiliki programmer lain yang tahu modul itu serta yang pertama.

Tentu saja, pada proyek berukuran layak, Anda mungkin memiliki ... 50 modul? Jadi membiasakan diri dengan semuanya membutuhkan waktu sekitar 4 tahun, dan itu berarti programmer yang belajar, rata-rata, bekerja pada efisiensi 58% dibandingkan dengan programmer A ... hmmm.

Jadi pertimbangkan skenario ini: programmer yang sama, proyek yang sama (A tahu itu semua, dan B tidak tahu apa-apa tentang itu.) Katakanlah ada 250 hari kerja dalam setahun. Mari kita asumsikan bahwa beban kerja didistribusikan secara acak di atas 50 modul. Jika kami membagi kedua programmer secara merata, A dan B keduanya mendapatkan 5 hari kerja pada setiap modul. A dapat melakukan 5 unit kerja pada setiap modul, tetapi B hanya mendapatkan, menurut simulasi Excel kecil saya, 1,4 unit pekerjaan yang dilakukan pada setiap modul. Total (A + B) adalah 6,4 unit kerja per modul. Itu karena B menghabiskan sebagian besar waktu mereka tanpa keahlian dengan modul yang mereka kerjakan.

Dalam situasi ini, lebih optimal untuk fokus pada subset modul yang lebih kecil. Jika B hanya berfokus pada 25 modul, mereka mendapatkan 10 hari masing-masing, dengan total 3,8 unit bekerja pada masing-masing modul. Programmer A kemudian dapat menghabiskan 7 hari masing-masing pada 25 modul yang tidak bekerja B, dan 3 hari masing-masing bekerja pada yang sama dengan B. Produktivitas total berkisar dari 6,8 hingga 7 unit per modul, rata-rata 6,9, dan itu secara signifikan lebih tinggi dari 6,4 unit per modul yang kami lakukan ketika A dan B menyebarkan pekerjaan secara merata.

Saat kami mempersempit ruang lingkup modul tempat B bekerja, kami mendapatkan efisiensi yang lebih tinggi (hingga titik tertentu).

Latihan

Saya juga berpendapat bahwa seseorang yang tidak tahu banyak tentang modul akan mengganggu orang yang melakukan lebih banyak daripada seseorang yang lebih berpengalaman. Jadi angka-angka di atas tidak memperhitungkan bahwa semakin banyak waktu yang dihabiskan B pada kode yang mereka tidak mengerti, semakin banyak waktu A mereka ambil dengan mengajukan pertanyaan, dan kadang-kadang A harus membantu memperbaiki atau memecahkan masalah apa yang B lakukan. Melatih seseorang adalah kegiatan yang menghabiskan waktu.

Solusi Optimal

Itu sebabnya saya pikir solusi optimal harus didasarkan pada pertanyaan seperti:

  • Seberapa besar tim Anda? Apakah masuk akal untuk membuat semua orang dilatih secara silang pada setiap bagian, atau jika kita memiliki tim 10 orang, dapatkah kita memastikan setiap modul diketahui oleh setidaknya 3 orang? (Dengan 10 programmer dan 50 modul, setiap programmer harus tahu 15 modul untuk mendapatkan cakupan 3x.)
  • Bagaimana pergantian karyawan Anda? Jika Anda membalikkan karyawan rata-rata setiap 3 tahun, dan butuh lebih lama dari itu untuk benar-benar mengetahui setiap sudut sistem, maka mereka tidak akan cukup lama untuk pelatihan agar dapat membayar sendiri.
  • Apakah Anda benar-benar membutuhkan seorang ahli untuk mendiagnosis suatu masalah? Banyak orang menggunakan alasan, "bagaimana jika orang itu pergi berlibur", tetapi saya telah berkali-kali dipanggil untuk mendiagnosis masalah dalam suatu sistem yang belum pernah saya alami. Mungkin benar bahwa orang yang berpengalaman dapat menemukannya jauh lebih cepat, tetapi itu tidak berarti Anda tidak dapat hidup tanpanya selama satu atau dua minggu. Beberapa sistem perangkat lunak sangat kritis terhadap misi sehingga masalahnya harus didiagnosis dalam 1 jam, bukan 5 jam atau dunia akan berakhir. Anda harus mempertimbangkan risiko-risiko ini.

Itu sebabnya saya pikir "itu tergantung". Anda tidak ingin membagi 20 modul antara dua programmer di tengah (masing-masing 10), karena Anda tidak memiliki fleksibilitas, tetapi Anda juga tidak ingin melatih 10 programmer di 50 modul karena Anda kehilangan banyak modul. efisiensi dan Anda tidak perlu banyak redundansi.


3
Wajar jika beberapa orang mengetahui beberapa bagian lebih baik daripada yang lain. Tetapi konsep "kepemilikan" menyiratkan bahwa orang lain tidak boleh menyentuh kode itu tanpa izin, atau bahwa hanya pemilik yang memiliki keputusan akhir, dan itu terlalu jauh. Jelas ya, "itu tergantung" jika itu yang mereka maksud sebenarnya.
poolie

1
@poolie - Saya setuju tapi saya tidak tahu apakah itu yang dipotong dan dikeringkan. Apakah kepemilikan benar-benar menyiratkan "tidak boleh menyentuh"? Saya tidak yakin akan hal itu. Saya pikir itu menyiratkan "ini adalah orang dengan otoritas terakhir" pada potongan kode tertentu. Ada lebih dari satu masalah di sini ... tapi saya pikir akar pertanyaannya adalah tentang mengalokasikan tugas kepada programmer, bukan tentang tidak mengizinkan programmer tertentu untuk bekerja pada kode tertentu. Mengatakan, "programmer B tidak boleh mengerjakan kode ini" adalah konyol.
Scott Whitlock

Saya pikir kepemilikan berarti prioritas tertinggi untuk bekerja dengan sebuah fragmen kode. Jika programmer A gratis dan dia memiliki kelemahan tertinggi, dia harus mulai bekerja dengan fragmen tetapi programmer B tidak boleh melakukan ini.
sergzach

76

Itu ide yang buruk . Ini mungkin lebih cepat dalam jangka pendek, tetapi mendorong kode yang sulit dipahami yang didokumentasikan dengan buruk karena hanya pembuat kode yang menulisnya yang bertanggung jawab untuk mempertahankannya. Ketika seseorang meninggalkan perusahaan atau pergi berlibur, seluruh rencana menjadi berantakan. Itu juga membuatnya sangat sulit untuk mengalokasikan beban kerja; apa yang terjadi ketika dua bug mendesak muncul dengan kode yang "dimiliki" oleh seorang pembuat kode?

Anda harus kode sebagai tim . Orang secara alami akan dialokasikan tugas dan fokus pada bidang-bidang tertentu tetapi berbagi beban kerja dan bekerja bersama harus didorong, bukan berkecil hati.


5
Saya setuju secara prinsip tentang bekerja sebagai sebuah tim, tetapi dalam praktiknya orang-orang tampaknya lebih baik ketika mereka memiliki rasa memiliki tentang pekerjaan mereka, selama itu tidak sejauh "Anda tidak dapat mengubah kode itu, itu Milikku!" Itu sebabnya, sementara kami memiliki proyek tim tempat saya bekerja, pengembang individu bertanggung jawab untuk menyelesaikan bagian kode yang ditugaskan.
Robert Harvey

1
Salah satu masalah terbesar kepemilikan kode adalah serialisasi. Apa yang terjadi ketika 90% dari semua pekerjaan berada dalam area satu orang? Apakah anggota tim lainnya harus duduk dengan ibu jari dan menunggu?
Neal Tibrewala

5
Di mana saya bekerja, kami memiliki bagian-bagian kode yang 'dimiliki' oleh seseorang (atau beberapa kelompok), tetapi tidak berarti mereka satu-satunya yang menyentuh file-file itu. Ada terlalu banyak kode bagi semua orang untuk mengetahui segalanya, jadi orang mengkhususkan diri dalam subsistem tertentu dan bertanggung jawab untuk mengetahui dan mampu membuat keputusan desain skala yang lebih besar pada beberapa sistem, tetapi itu tidak biasa untuk yang lain dan membuat perubahan cepat yang lebih kecil sesuai kebutuhan.
Alex

3
@Robert Harvey: tim memiliki semua kode.
Steven A. Lowe

2
"ide buruk" terlalu kuat. Kernel Linux menggunakan model itu dan tampaknya sudah bekerja dengan baik.
Joh

28

Itu tergantung pada apa domain masalahnya.

Jika itu hal-hal umum (yaitu tindakan CRUD sederhana, dll), maka saya setuju dengan Tom Squires (siapa pun harus dapat bekerja dan mengeditnya).

Namun ...

Jika solusi yang dimaksud membutuhkan keahlian domain (banyak waktu telah diinvestasikan sebelumnya atau banyak penelitian perlu dilakukan sebelum implementasi, karena dalam hal ini adalah sesuatu yang akan Anda daftarkan dalam persyaratan pekerjaan sebagai pengetahuan khusus yang tidak semua orang pada proyek telah), maka pemilik harus pasti akan ditugaskan ke bagian dari kode. Karena itu, siapa pun harus dapat melakukan modifikasi sesuai kebutuhan, tetapi harus selalu ditinjau oleh orang yang memiliki area proyek tersebut.

Anda tidak ingin seluruh tim Anda (atau sejumlah orang di tim) meneliti dan mempelajari subjek yang sama (siklus yang terbuang). Tetapkan pemilik, tetapi mintalah mereka mendokumentasikan pembelajaran dan desain mereka dan mungkin minta mereka melakukan sesi pelatihan informal (atau formal, tidak masalah) tentang teknologi.


2
Poin bagus tentang kasus tepi. +1
Tom Squires

1
@Danny: Saya tidak berpikir bahwa Anda membaca posting dengan seksama. Saya memang mengatakan bahwa siapa pun harus dapat melakukan modifikasi pada kode selama ditinjau oleh pemiliknya. Saya juga menyarankan agar pakar domain harus membagikan pengetahuan mereka melalui sesi pelatihan formal atau informal.
Demian Brecht

Maaf, lelah dan melewatkan bagian itu.
Danny Varod

+1 Saya pikir ini adalah satu-satunya jawaban yang menunjukkan bahwa berbagai tingkat kepemilikan mungkin memiliki manfaat tergantung pada proyek.
Thomas Levine

1
Saya tidak benar-benar melihat ini sebagai kepemilikan. Ulasan kode bersifat alami (ya, alami), dan wajar jika pengembang yang paling ahli pada subsistem tertentu akan meninjau perubahan pada subsistem ini.
Matthieu M.

10

Ini ide yang mengerikan . Saya telah bekerja di sebuah perusahaan yang telah menggunakan pendekatan ini dan itu cukup banyak resep untuk banyak hutang teknis . Intinya adalah bahwa dua kepala hampir selalu lebih baik dari satu. Mengapa? Karena kecuali Anda idiot, Anda tahu Anda bukan programmer yang sempurna dan Anda tidak akan menangkap setiap kesalahan yang Anda buat. Inilah sebabnya mengapa Anda memerlukan tim - lebih banyak mata melihat kode yang sama dari perspektif yang berbeda.

Itu bermuara pada satu hal: disiplin . Berapa banyak programmer yang Anda kenal yang benar-benar disiplin dalam gaya pengkodean mereka? Ketika Anda tidak membuat kode dengan disiplin, Anda mengambil jalan pintas (karena Anda akan "memperbaikinya nanti") dan pemeliharaan kode menderita. Kita semua tahu "nanti" tidak pernah datang. Fakta : Lebih sulit untuk mengambil jalan pintas ketika Anda segera bertanggung jawab kepada rekan-rekan Anda dalam sebuah tim. Mengapa? Karena keputusan Anda akan dipertanyakan dan selalu lebih sulit untuk membenarkan cara pintas. Hasil akhir? Anda menghasilkan kode yang lebih baik, lebih dapat dipelihara yang juga lebih kuat.


9

Keuntungannya adalah tidak semua orang perlu meneliti dan memahami segalanya. Kerugiannya adalah hal itu membuat setiap orang perlu untuk area kode mereka sendiri, dan tidak ada orang lain yang tahu bagaimana cara mempertahankannya.

Kompromi adalah memiliki setidaknya 2 pemilik untuk setiap area kode. Kemudian seseorang dapat pergi berlibur, mengambil pekerjaan baru, atau pensiun, dan masih ada seseorang yang mengetahui kode (dan dapat melatih orang kedua yang baru). Tidak semua orang perlu mempelajari segalanya, yang sedikit lebih efisien.

Jangan memiliki 2 (atau 3) orang yang sama bekerja bersama sepanjang waktu. Ganti pasangan untuk area yang berbeda, sehingga pengetahuan ini juga dibagikan secara tidak sengaja ketika bekerja dengan orang yang berbeda di area program terkait.


1
Atau, dengan kata lain, Anda merekomendasikan XP :-)
Danny Varod

6

Ya, itu sedikit lebih efisien, dalam jangka pendek. Dan akhirnya ada manfaatnya. Itu bahkan tidak mendekati melebihi biaya.

Apa yang terjadi ketika dia sedang liburan, atau tiba-tiba sakit, atau pergi, atau tertabrak bis pepatah? Apa yang terjadi ketika Anda ingin melenturkan sumber daya untuk mendapatkan satu pekerjaan lebih cepat daripada yang lain? Seberapa efektif ulasan kode? Bagaimana bisa seorang manajer, terutama yang tidak ada dalam basis kode, tahu jika pengembang bekerja keras atau menarik wol ke matanya? Siapa yang akan memperhatikan jika utang teknis mulai menanjak?

Dalam pengalaman saya, orang-orang yang suka bekerja dengan cara ini adalah pemburu-kejayaan paling-paling, malas paling buruk. Mereka suka menjadi satu-satunya orang yang bisa Anda kunjungi dengan masalah yang diberikan dan mereka suka kode mereka untuk tetap pribadi. Dan mereka sering suka kode cepat, tanpa memperhatikan keterbacaan.

Itu tidak berarti bahwa, pada tim yang terdiri dari 50 pengembang, setiap orang harus mengetahui semua kode, tetapi tim yang terdiri dari 5-7 orang harus memiliki modul yang cukup besar untuk membuat orang-orang tetap bekerja. Tidak ada individu yang boleh memiliki apa pun.


Saya akan mengatakan itu tergantung pada ukuran dan cakupan basis kode. Setelah Anda mencapai beberapa ratus juta baris, Anda pasti berada di luar domain "manusia tunggal dapat memiliki segalanya di kepalanya" dan Anda harus mulai membagi tanggung jawab utama.
Vatine

1
@Vatine: Benar. Jadi, Anda memecah kode Anda menjadi modul dan memiliki tim yang bekerja pada setiap modul. Anda masih belum memiliki kode yang dimiliki oleh satu orang.
pdr

Ya, memecahnya menjadi satu individu (mungkin) tidak masuk akal, tetapi tentu saja ada beberapa argumen untuk "kepemilikan yang berbeda untuk berbagai bagian basis kode".
Vatine

6

Setidaknya ada tiga masalah yang ditunjukkan oleh jawaban lainnya; tapi saya ingin mencoba dan memperlakukan mereka berdua bersama. Dua masalah tersebut adalah:

  • keahlian : Seseorang dalam tim memiliki pengetahuan terperinci tentang bidang tertentu; pengetahuan ini tidak tergantung pada implementasi spesifik dari domain tersebut dalam proyek
  • kepemimpinan : Meskipun pekerjaan membangun proyek dapat dibagikan di banyak pengembang; peta jalan, serta keputusan langsung tentang rincian implementasi penting ada di tangan anggota tim tertentu atau hanya beberapa anggota tim.
  • kode egoless : Cara khusus yang diterapkan proyek tidak tergantung pada gaya pengkodean, praktik, atau pengetahuan pengembang mana pun di tim; dan dengan ketaatan pada gaya pengkodean yang terkenal atau spesifikasi yang dijaga dengan baik, setiap anggota tim yang baru memiliki kesempatan yang sama dalam memahami bagaimana dan mengapa proyek sebagai pengembang yang berpengalaman.

Ketika topik itu murni salah satu keahlian, keberhasilan proyek mungkin tergantung pada tingkat pengetahuan yang tinggi tentang domain tersebut; tapi itu tidak tergantung pada pengetahuan ahli khusus tentang domain itu. Para ahli, meskipun mungkin langka dan berharga, pada dasarnya masih bisa dipertukarkan; satu akuntan pajak yang berpengalaman sama bermanfaatnya dengan proyek perangkat lunak perencanaan pajak seperti yang lainnya, dari sudut pandang pengetahuan domain mereka. Masalahnya menjadi salah satu dari seberapa baik ahli dapat mentransfer pengetahuannya ke proyek.

Ketika topiknya murni salah satu dari kepemimpinan, keberhasilan proyek tergantung terutama pada konsistensi dan wawasan dari keputusan yang dibuat oleh pemimpin proyek; meskipun kami cenderung lebih menyukai prospek proyek yang memiliki pengalaman dalam domain, atau terbukti sebagai pemimpin proyek, ini kadang-kadang sekunder dari perannya. "Pemimpin" dapat berubah dari hari ke hari jika keputusan yang diambil konsisten dari satu kasus ke kasus berikutnya dan setiap keputusan dijalankan dengan cepat oleh tim. Jika ini berfungsi dengan baik; banyak keputusan tidak harus "dibuat" oleh pimpinan proyek karena tim sudah mengerti keputusan apa yang akan diambil.

Saya tidak berpikir pertanyaan itu benar-benar tentang kode tanpa ego, tetapi sulit untuk berbicara tentang kepemilikan kode tanpa juga membahas betapa pentingnya masalah ini. Mempertahankan proyek mungkin merupakan bagian terbesar dari siklus pengembangan. Cara untuk memahami masalah ini adalah dengan bertanya-tanya apa yang akan terjadi jika beberapa pengembang harus segera meninggalkannya. Apa yang akan terjadi jika seluruh tim harus diganti? Jika proyek dilemparkan dalam keraguan karena tergantung pada beberapa pemain kunci, maka Anda berisiko tinggi untuk gagal. Bahkan jika Anda tidak pernah kehilangan satu anggota tim, fakta sederhana bahwa satu atau beberapa pengembang diperlukan untuk memajukan proyek berarti Anda mungkin tidak akan bekerja seefisien yang Anda bisa jika lebih banyak pengembang diberi petunjuk.


6

Kepemilikan kode cenderung mencegah refactoring, menciptakan hambatan pengembangan dan menyebabkan masalah ego ketika kode memiliki masalah yang harus ditangani.

Saya merekomendasikan berkonsultasi dengan pembuat kode sebelum mengubah, meskipun kode standar yang tinggi harus cukup didokumentasikan, unit diuji, integrasi diuji dan sistem diuji untuk membuat ini mubazir, masih tidak ada salahnya untuk mendapatkan pendapat lain.


5

Ini buruk karena banyak alasan, saya bekerja di sebuah toko di mana mereka mencoba mengubah dari ini menjadi sesuatu yang lebih masuk akal dan itu jelek.

Alasan mengapa ini buruk:

  • Jika pemilik kode mengambil liburan dan beberapa bug besar muncul dalam barang-barang mereka, akan sangat sulit dan memakan waktu untuk mencoba mempelajari kode dan memperbaiki bug
  • Jika pemilik kode meninggalkan perusahaan, proyek-proyek mereka akan sangat mundur karena semua warisan dan pengetahuan suku hanya berjalan keluar pintu
  • Dokumentasi buruk. Jika saya satu-satunya orang yang membuat kode di dalamnya, mengapa saya harus mendokumentasikannya? Terkait adalah masalah bahwa setiap dokumentasi yang dipaksa dibuat juga kemungkinan akan menjadi buruk karena tidak ada yang akan cukup tahu tentang kode untuk benar-benar mengatakan apakah dokumentasi lengkap atau bahkan akurat.
  • Perang suci kode dapat dengan mudah dinyalakan ketika setiap orang memiliki kotak pasir kecil mereka sendiri, seperti yang orang lain katakan ini bisa menjadi sangat bodoh dengan sangat cepat. Di mana ini merupakan masalah adalah ketika dua orang harus bekerja bersama, tidak ada yang terbiasa berkompromi pada apa pun.
  • Karena poin di atas, keterampilan kerja tim tidak pernah terbentuk - orang tidak perlu bekerja dengan orang lain.
  • Fiefdoms dapat dengan mudah terbentuk, kerajaan-kerajaan kecil yang terbuat dari kantong limbah yang tidak membeli apa pun dari perusahaan. Anda tidak tahu ini terjadi sampai terlambat karena modul atau alat X adalah tanggung jawab Bob, dan celakalah engkau siapa yang harus bahkan menanyakan untuk apa yang dilakukan Bob di nya kode.
  • Ulasan kode dan tinjauan rekan menderita karena tidak ada yang tahu apa pun tentang kode. Jika Anda tidak tahu kodenya, Anda tidak dapat menemukan tempat-tempat yang tidak benar dan terbatas pada mengomentari pemformatan teks dan konvensi penamaan saja.
  • Dan jika Anda bekerja untuk saya ... perusahaan memiliki kodenya, bukan Anda. Kami memiliki kebanggaan pada apa yang kami lakukan dan apa yang kami capai, dan dalam apa yang kami tulis, tetapi itu adalah masalah kelompok, seperti ketika tim Anda memenangkan pertandingan yang sulit. Setiap karyawan yang bekerja untuk perusahaan memiliki kode yang sama, dan selama melakukan pekerjaan mereka diizinkan untuk mengeditnya dengan cara apa pun yang mereka inginkan untuk melakukan pekerjaan mereka yaitu untuk meneruskan tujuan perusahaan.

Yang terbesar sebenarnya adalah masalah personel dan dokumentasi. Orang itu akan pergi suatu hari, dan bocah laki-laki akan mendorong jadwal ke kiri selama beberapa minggu.

Pendekatan yang lebih baik adalah membuat semua orang terbiasa dengan setiap bagian dari basis kode (atau setengah lusin bagian atau lebih jika itu benar-benar besar dan beragam) ke titik yang mereka dapat

  • Perbaiki cacat apa pun di area itu
  • Tambahkan fitur atau tambahan baru kecil atau sedang

Setiap orang cenderung mengetahui sedikit lebih banyak tentang beberapa hal daripada yang lain, jadi untuk masalah sulit dua atau tiga dapat bersatu, atau ahli defacto dapat menerimanya. Saya telah bekerja dalam kelompok di mana ini terjadi dan bekerja dengan sangat baik. Tidak hanya tidak ada kontra yang tercantum di atas, stafnya jauh lebih dapat diprediksi karena kami tidak mencari-cari ahli.

Kepemilikan pro to sole code adalah bahwa "pemilik kode" kemungkinan dapat melakukan hal-hal lebih cepat daripada yang lain, tetapi ini hanya berlaku jika semua orang adalah "pemilik kode" pada proyek yang tidak tumpang tindih. Dengan kata lain, jika orang memutar keuntungan "pemilik kode tunggal" hilang.


2
Anda sedang berbicara tentang jenis silo parah yang tidak saya anjurkan, dan saya kira jarang. Tidak ada masalah sama sekali untuk memberi seseorang tugas dan membiarkannya menjalankannya, selama dia mengerti bahwa dia masih menjadi bagian dari tim. Itu berarti dia harus mengikuti standar dan praktik pemrograman toko, dan secara umum bersikap baik kepada orang yang harus menjaga kode-kode yang ada di belakangnya. Ini berarti bahwa tim juga harus memahami bagaimana kodenya bekerja dan memiliki akses lengkap ke sana melalui sistem kontrol sumber, sehingga orang lain dapat mengambil alih "kepemilikan," jika diperlukan.
Robert Harvey

5

Lihat Nomor Truk alias Faktor Bus

faktor bus (juga dikenal sebagai faktor truk , atau nomor bus / truk ) adalah ukuran konsentrasi informasi dalam anggota tim individu. Faktor bus adalah jumlah total pengembang kunci yang perlu lumpuh (seperti ditabrak bus / truk) untuk mengirim proyek ke dalam kekacauan sehingga tidak dapat melanjutkan; proyek akan menyimpan informasi (seperti kode sumber ) yang tidak dikenal oleh anggota tim yang tersisa. Faktor bus tinggi berarti bahwa banyak pengembang perlu dihapus sebelum proyek gagal.

"Ditabrak bus" bisa dalam berbagai bentuk. Ini bisa menjadi seseorang yang mengambil pekerjaan baru, memiliki bayi, mengubah gaya hidup atau status kehidupan mereka, atau benar-benar tertabrak bus: pengaruhnya akan sama ...


Mengingat signifikansi historis dari sumbernya, saya merasa itu otoritatif. en.wikipedia.org/wiki/WikiWikiWeb tampaknya mendahului penggunaan umum Faktor Bus sekitar 4 tahun.
Joshua Drake

1

Seperti banyak hal, itu adalah "tergantung" besar. Jika ketat "tidak ada orang lain yang dapat bekerja pada kode", itu mungkin buruk. Jika "pemilik harus melakukan tinjauan kode sebelum menerima perubahan", itu lumayan, tergantung pada keinginan pemilik untuk menerima perubahan eksternal.


1

Kerugiannya parah; "jumlah truk" tim Anda cukup banyak menjadi 1.

Untuk meninjau, "nomor truk" didefinisikan hanya sebagai "berapa banyak anggota tim, kasus terburuk, dapat ditabrak truk sebelum pengetahuan yang diperlukan untuk melakukan beberapa tugas penting hilang ke tim."

Itu wajar, dan agak didorong, bagi pengembang untuk fokus pada sub-disiplin ilmu; jika semua orang harus mengetahui segala sesuatu yang berkaitan dengan proyek, tidak ada yang bisa dilakukan karena semua orang akan belajar apa yang telah dilakukan orang lain, mengapa itu bekerja dan bagaimana hal itu dapat diubah tanpa merusaknya. Selain itu, jika pengembang tidak melakukan hal-hal yang berbeda untuk area yang berbeda, kecil kemungkinan perubahan akan bertabrakan. Jadi umumnya baik untuk memiliki dua atau tiga pengembang atau pasangan pengembang yang bekerja terutama di subsistem tertentu dari proyek dan mengetahuinya dengan baik.

Namun, jika hanya satu orang yang seharusnya menyentuh baris kode tertentu, maka ketika orang itu berhenti, dipecat, pergi berlibur, atau berakhir di rumah sakit, dan garis kode itu ditunjukkan sebagai penyebab bug yang harus diperbaiki, orang lain harus masuk dan memahami kode. Jika tidak ada orang lain selain orang yang menulisnya yang pernah melihatnya, itu akan membutuhkan waktu untuk mencapai tingkat pemahaman yang memungkinkan pengembang untuk membuat perubahan yang memperbaiki bug tanpa membuat lebih banyak. TDD dapat membantu, tetapi hanya dengan memberi tahu pengembang mereka melakukan perubahan "salah"; lagi, pengembang harus memahami tes apa yang menjalankan kode mana untuk memastikan bahwa tes gagal tidak mencoba membuat pernyataan yang salah.


1

Saya tidak menganggapnya ekstrem, tetapi saya lebih suka tanggung jawab kode . Anda menulis kode yang rusak, Anda harus memperbaikinya. Ini dapat dilakukan di tingkat individu, pasangan, atau tim. Mencegah agar kotoran Anda tidak dialihkan ke orang lain. Ini berlaku untuk perubahan juga.

Masalah beban kerja dan penjadwalan akan menimpa ini. Adalah bodoh untuk menunda memperbaiki bug besar karena pelakunya sedang berlibur dua minggu.

Tujuannya bukan untuk membuat tim Anda bermain "permainan menyalahkan" atau mengambil jumlah bug terlalu jauh (Mereka semua tidak sama.). Basis pada siapa yang memeriksa kode terakhir atau memiliki supervisor membuat keputusan dan menugaskannya kepada seseorang alih-alih melalui setiap bagian dari setiap baris kode.

Pemrogram yang lebih baik mungkin akhirnya memperbaiki banyak kode orang lain tidak peduli bagaimana Anda menetapkannya.

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.