Pertanyaan Bagaimana cara pengembang yang baik menjaga dari membuat kode dengan faktor hit bus rendah? [Tutup]


alt teks http://www.metrocouncil.org/Directions/transit/images_transit/GoToBus.jpg

Lihatlah gambar di atas. Ini bisa menjadi programmer yang akan ditabrak bus. Menurut Wikipedia, dalam pengembangan perangkat lunak "faktor bus" proyek perangkat lunak (atau "faktor bus hit") adalah

pengukuran yang tidak hormat   konsentrasi informasi dalam suatu   satu orang, atau sangat sedikit orang. Itu   Faktor bus adalah jumlah kunci   pengembang yang akan jika tidak mampu,   seperti tertabrak bus, kirim   proyek menjadi berantakan seperti itu   tidak akan bisa melanjutkan.

Tertabrak bis bisa memakan banyak   berbagai bentuk. Ini bisa jadi a   orang yang mengambil pekerjaan baru, memiliki   bayi, mengubah gaya hidup atau hidup mereka   status, dampaknya akan sama   efek.

Atau dengan kata lain: jika pengembang asli sepotong kode pernah terkena bus, Anda akan gagal.

Jadi, pertanyaan saya adalah: Bagaimana cara pengembang yang baik menjaga dari membuat kode dengan faktor hit bus rendah?

Dan, siapa yang bertanggung jawab untuk mengasuransikan bahwa para pengembang, yang dibawa untuk mempertahankan sedikit kode, dapat memahaminya?


75
2017-12-30 14:27


asal


Jawaban:


Kehilangan anggota tim kunci terjadi sering, apakah sementara atau permanen. Apakah seseorang mengambil makan siang yang panjang, atau flu sedang terjadi di sekitar kantor, atau seorang programmer menginginkan perubahan peran dalam perusahaan yang sama, atau melalui perceraian yang menyakitkan, atau berhenti untuk berlayar di seluruh dunia, atau secara tragis dirugikan, prospek perubahan mendadak dan tak terduga dalam tim tidak bisa dihindari.

Salah satu atribut pengembang yang baik adalah mereka berusaha mengurangi "faktor bus" tim mereka membuat mereka menjadi diri sendiri kurang penting. Itu sulit dilakukan ketika Anda merasa tidak aman tentang pekerjaan Anda. SEBUAH manajer yang baik menciptakan keamanan orang perlu bersantai tentang hal semacam ini.

Praktek, kira-kira dalam urutan prioritas:

  1. Kode yang teruji dengan baik berarti maksud Anda tertulis dalam kode, dan menghilangkan rahasia.

  2. Teliti Tes Unit berfungsi baik sebagai semacam dokumentasi dan sebagai jaring pengaman ketika pemegang rahasia tidak tersedia. (Yaitu mereka dapat diverifikasi dokumentasi.)

  3. Pasangkan pemrograman, khususnya Promiscuous Pairing, akan menyebarkan pengetahuan tentang tim pengembangan dan memaparkan rahasia.

  4. Pengiriman sering berarti bahwa bahkan jika sesuatu terjadi, pelanggan Anda sudah memiliki produk kerja baru-baru ini, dan Anda memiliki kuantitas yang diketahui untuk memutar kembali jika ada yang rusak.

  5. Dokumentasi, baik dalam komentar maupun di tempat lain, menyimpan gagasan dan maksud yang tidak dapat diungkapkan dalam kode. Namun, dokumentasi itu mahal untuk dibuat, mahal untuk dikonsumsi, mahal untuk dipelihara, dan sering diabaikan, sehingga barang-barang lainnya lebih disukai.


74
2017-12-30 15:42



Saya akan mengatakan kode yang memiliki tes unit yang bagus. Untuk pengembang pengganti yang bergabung dengan proyek mengetahui bahwa perubahan mereka tidak melanggar bagian lain dari sistem itu penting.


17
2017-12-30 14:37



Bagian paling sulit dari pemeliharaan IMO tidak mengetahui apa yang dilakukan perangkat lunak atau bagaimana melakukannya: mengetahui apa yang seharusnya dilakukan perangkat lunak.

Jika saya tahu ...

  • Apa yang seharusnya perangkat lunak (yaitu spesifikasi fungsional ... Saya tidak perlu spesifikasi desain)

  • Cara membangun, cara menjalankan, dan (mengikuti dari spesifikasi fungsional) cara menguji perangkat lunak yang ada

... maka itu yang paling penting. Dokumentasi lain (misalnya "desain": yang menggambarkan bagaimana spesifikasi fungsional diimplementasikan oleh perangkat lunak) mungkin bagus juga, tetapi itu relatif opsional dan kurang penting daripada di atas.

Sebagian besar pengembang akan menjawab pertanyaan Anda dengan mengatakan "komentar dalam kode, pengenal yang diberi nama baik, kontrol sumber, dll." ... tapi menurut saya yang lebih penting adalah "sebagai pengembang, jika Anda menulis perangkat lunak yang tidak memiliki spesifikasi fungsional tertulis, maka tuliskan sedikit spesifikasi fungsional untuk disertakan dengan perangkat lunak Anda." FS akan berguna bahkan sebelum seseorang mencoba untuk mempertahankan perangkat lunak: ini akan berguna untuk QA yang ingin tahu cara menguji perangkat lunak.

Dan, siapa yang bertanggung jawab untuk mengasuransikan bahwa para pengembang, yang dibawa untuk mempertahankan sedikit kode, dapat memahaminya?

Biasanya itu pemimpin tim pengembang baru (yaitu programmer senior yang sudah tahu kode yang ada); tetapi jika gagal (jika tidak ada pemimpin tim seperti itu), mungkin itu adalah manajer (manajer produk atau proyek, atau "insinyur rilis") jika manajer tersebut tahu di mana harus menemukan spesifikasi fungsional perangkat lunak dan membuat instruksi.


14
2017-12-30 14:47



Ulasan kode teman sebaya reguler membantu. Ini berarti bahwa setidaknya satu orang harus memeriksa setiap baris kode dan harus meminta agar diubah untuk kejelasan jika diperlukan.

Saya selalu berusaha untuk kode kejelasan atas keringkasan yang seharusnya membantu pengembang masa depan. Namun, ada kesempatan di mana Anda tidak bisa membantu tetapi menulis kode yang sedikit tumpul. Dalam hal ini saya mengumpulkan tim bersama selama 30 menit untuk menjalankan ide tingkat tinggi tentang bagaimana kode bekerja, jika bukan penjelasan lengkap.

Seperangkat tes unit juga membantu pengembang lain untuk memiliki keyakinan dalam mengubah kode karena mereka akan tahu ketika mereka membuat perubahan yang melanggar bagian dari sistem. Jika ditulis dengan baik mereka juga dapat menjelaskan bagaimana bagian-bagian dari sistem dimaksudkan untuk bekerja melalui penamaan daripada murni melalui kode.


12
2017-12-30 14:32



Ketika saya bekerja sebagai programmer mahasiswa di Universitas saya selama masa kuliah saya Faktor Bus Hit harus dikelola dengan baik. Saya mengerjakan proyek-proyek besar namun pekerjaan saya hanya sampai hari saya lulus. Pada titik ini programmer lain di departemen harus mengambil proyek saya dan mengelolanya dari sana. Saya mengelola ini dengan ember dokumentasi. 

Sejak saya memulai pekerjaan itu, saya berusaha sebaik mungkin untuk menjaga spesifikasi, kode, dan dokumentasi lainnya tetap up-to-date dan sebersih mungkin sehingga setiap rekan kerja yang kompeten dapat mengambil pemahaman yang kuat tentang pekerjaan saya dalam hitungan hari. (dengan atau tanpa bantuan saya). Setiap proyek saya akan memiliki Wiki Confluence terkait di mana saya akan menyimpan semua dokumentasi, diagram, spesifikasi dan sedikit 'tidbits' bagi pengembang lain untuk mengetahui.

Ini juga membantu jika Anda memiliki gaya pengkodean bersih yang baik. Jika kode Anda masuk akal dan mudah di mata, programmer lain harus dapat mengambilnya setelah kecelakaan bus malang Anda.


10
2017-12-30 14:38



Harus selalu ada duplikasi pengetahuan dalam suatu organisasi.

Sama seperti Anda akan selalu mem-back-up hard drive Anda (kanan ???), Anda tidak ingin satu orang menjadi satu-satunya pemilik informasi penting. Salah satu cara untuk mengurangi ini adalah membuat para programmer bekerja sama.

Apa yang Anda sebutkan sebagai masalah "bus" adalah, lebih praktis, "Bagaimana jika Joe pindah / memutuskan untuk berhenti" faktor. Umumnya, pekerjaan adalah keinginan, dan setiap orang dapat pergi kapan saja.

Organisasi yang tangguh tidak dapat bergantung pada satu pengembang yang memiliki semua pengetahuan penting.


7
2017-12-30 14:33



Sumber Kontrol dan dipikirkan dengan baik dan dikomentari kode adalah kunci.

Orang yang bertanggung jawab untuk memastikan ini tidak terjadi adalah semua orang yang terlibat dengan kode. Manajer Dev dan PM adalah orang-orang yang harus terus mengawasinya, tetapi manajemen eksekutif harus menerapkan kebijakan untuk mendukung mereka dan memiliki sumber daya yang tersedia untuk memastikan bahwa banyak orang yang memiliki area pengetahuan yang tumpang tindih adalah mungkin.


4
2017-12-30 14:34



Pemrograman pasangan mengurangi risiko ini ke tingkat yang cukup tinggi. Jika Anda tidak dapat melakukannya (banyak dari kita tidak memiliki kemewahan untuk berpasangan di setiap proyek), Anda selalu dapat menjadwalkan ulasan rekan secara rutin dan mendokumentasikan kode Anda saat kamu pergi, Berbeda dengan mendokumentasikan pada akhirnya.


3
2017-12-30 14:52