Haruskah seorang programmer memperbaiki bangunan gagal orang lain? [Tutup]


45

Seorang programmer melakukan beberapa pekerjaan ke repositori SVN, lalu pulang. Setelah dia pergi, bangunan otomatis Hudson gagal. Programmer lain melihat ini, dan setelah melihat melalui perubahan kode, mendeteksi bahwa masalahnya adalah tidak adanya satu perpustakaan. Dia menambahkan perpustakaan ini ke SVN dan bangunan berikutnya selesai dengan sukses.

Apakah programmer kedua melakukan hal yang benar atau haruskah dia menunggu sampai programmer pertama menyelesaikan masalah?


31
Pertanyaan: Seorang anggota programer mengajukan pertanyaan. Anggota lain membaca pertanyaan dan melihat beberapa kesalahan sintaksis dan tata bahasa, jadi dia memutuskan untuk mengedit pertanyaan dan memperbaikinya, untuk membuat pertanyaan sedikit lebih mudah dibaca. Apakah yang dilakukan editor dengan benar atau haruskah ia hanya menunggu poster memperbaiki kesalahan?
yannis

2
Apa aturan tim Anda untuk situasi ini?

4
@ Ahab Oh, jangan khawatir, saya tidak mengatakan bahwa ini masalah :). Hanya saja dalam sebuah komunitas, seperti dalam sebuah tim, anggota yang saling membantu harus didorong. Juga saya tidak berpikir bahwa pengembang yang melanggar bangunan tidak profesional, bahkan jika untuk bug kecil, hal-hal ini terjadi pada kita semua.
yannis

11
Seluruh gagasan memiliki Hudson di tempat pertama adalah karena manusia adalah manusia dan akan merusak bangunan sesekali. Anda hanya ingin menangkapnya lebih awal. Dapat diperdebatkan bahwa programmer yang dimaksud harus memverifikasi bahwa build dibangun sebelum pulang.

14
Ini jauh lebih mudah dipahami jika Anda menganggap sebaliknya - Jika build rusak, memperlambat seluruh tim (bahkan di rumah, setelah jam) dan Anda dapat memperbaikinya tetapi membuat pilihan yang disengaja untuk tidak karena beberapa titik prosedur , haruskah Anda diizinkan untuk mempertahankan pekerjaan Anda?
Bill K

Jawaban:


87

Tergantung sampai batas tertentu pada bagaimana tim Anda biasanya bekerja, tetapi saya akan mengatakan itu baik-baik saja. Menjaga pembangunan tetap menghemat waktu orang lain.

Adalah sopan bagi programmer kedua untuk mengirim email pertama untuk menjelaskan apa yang telah ia lakukan, untuk berjaga-jaga jika versi perpustakaan tertentu diperlukan atau ada beberapa komplikasi lain. Ini juga cara yang sedikit lebih halus untuk menunjukkan bahwa mereka telah merusak bangunan.


101
itu juga sopan untuk pengembang pertama untuk membeli donat untuk menebus melanggar build
jk.

17
Saya lebih suka bir daripada donat.
Martin York

2
Donat bisa menyinggung gluten yang tidak toleran. Kartu hadiah seharga $ 5 untuk Best Buy, di sisi lain ...
Christopher Mahan 8'11

1
@ChristopherMahan akan menghasilkan pertengkaran antara semua anggota tim tentang siapa yang mendapatkannya; atau jika diberikan satu anggota tim seperti distribusi implisit dari kotak donat di ruang istirahat adalah proposisi yang jauh lebih mahal. Dan dalam hal apa pun, kartu hadiah Best Buy bisa menyinggung siapa pun yang dulu bekerja untuk Circuit City atau CompUSA. :)
Dan Neely

1
Apa yang bisa Anda dapatkan dari Best Buy dengan harga di bawah $ 5?
kevin cline

12

Tergantung.

  • Apakah bug itu begitu jelas sehingga menambahkan perpustakaan adalah cara untuk memperbaikinya? Terkadang perbaikannya adalah menemukan solusi untuk tidak membutuhkan perpustakaan itu.

  • Apakah proyek dalam fase di mana semua perubahan harus dikaitkan dengan tiket yang ada? Jika demikian, apakah Anda mengajukan tiket? Apakah tiket itu sudah ditugaskan untuk Anda?

Bagaimanapun, fokuslah untuk memperbaiki bug, bukan menyalahkan yang bertanggung jawab.


9
"... tidak menyalahkan yang bertanggung jawab." Kecuali itu kejadian biasa.
Shawn D.

11

Ya tidak apa-apa Namun, tidak profesional bagi programmer asli untuk pulang sebelum menguji apakah build akan dikompilasi.

Reputasi Anda 100% dalam kendali Anda. Hal-hal seperti ini merusak reputasi Anda dan berusaha memoles reputasi yang ternoda sangat sulit.


2
+1 untuk menempatkan tanggung jawab pada pengembang pertama untuk menguji build. Paragraf kedua benar-benar tidak benar atau tidak relevan. Orang lain dapat merusak reputasi Anda, baik secara sengaja atau tidak, bahkan ketika perilaku Anda benar-benar unggul.
Caleb

6
Sangat mungkin bahwa programmer asli memiliki perpustakaan di mesinnya, tetapi mesin yang melakukan pembangunan otomatis tidak. Ya, perpustakaan harus di SVN, tetapi ini bisa menjadi masalah yang sangat halus untuk tidak menyadarinya.
mpdonadio

7

Menyampaikan

Tidak ada aturan ketat (di samping aturan tim Anda sendiri) untuk skenario itu.

Dev2 harus bisa memberi tahu dev1 bahwa ia dapat memperbaiki kesalahannya, tak satu pun dari mereka harus takut akan sesuatu yang dihasilkan dari pertukaran ini, mereka adalah bagian dari tim.


5

Kenapa tidak? Jika produk Anda lebih penting daripada memperbaiki kesalahan, tentu saja tidak apa-apa. Meskipun build gagal karena perubahan pustaka cukup timpang dan Anda perlu menegur pengembang karena tidak mengujinya.


3

Kegagalan pembangunan terjadi. Jika penting bahwa build harian terjadi, maka saya akan memperbaikinya dan kemudian meminta pengembang yang memeriksa kode yang rusak untuk meninjau perbaikan pada hari berikutnya dan memastikan bahwa kode sekarang sebagaimana mestinya.

Seperti yang telah dikatakan, orang yang memperbaikinya mungkin harus mengirim email kepada orang yang memecahkannya dan merinci perbaikannya.


2

Moto saya, jangan berkomitmen untuk SVN setelah jam 3 sore dengan cara itu Anda selalu dapat memperbaiki kegagalan build Anda sendiri.

Jika Anda tidak memperbaiki kegagalan build-nya, maka build orang lain juga akan gagal. Saya akan memperbaikinya untuk menghemat waktu dalam jangka panjang, tetapi pastikan mereka sadar bahwa Anda harus memperbaikinya.

Memiliki semacam skrip 'tunjuk jari menyalahkan' adalah cara yang baik untuk melakukan ini, atau membuat orang yang melanggar donat beli membangun !!


2
Alat CI kami sebenarnya memiliki opsi untuk mengirim email ke pengembang yang melanggar pembangunan (selain tim lainnya).
TMN

2

Seseorang harus memperbaikinya dan programmer pertama seharusnya tidak pulang tanpa terlebih dahulu memastikan bahwa ia tidak merusak build. Namun, untuk masalah yang mudah diperbaiki, memanggilnya kembali untuk memperbaikinya sendiri akan menjadi ekstrem.

Saya setuju dengan saran Luke Graham untuk mengirim email penjelasan, meskipun saya akan mengatakan itu lebih sopan - itu komunikasi dasar.


Dengan pembangunan integrasi terkadang memakan waktu satu jam atau lebih tergantung pada kompleksitas sistem Anda, Anda harus menerapkan "cutoff komit" setiap hari untuk memastikan bahwa pembangunan terakhir hari itu akan terjadi ketika semua orang masih ada. Bahkan kemudian, orang-orang memiliki janji dengan dokter, latihan sepak bola anak-anak, dll. Dan perlu segera keluar, terlepas dari status pembangunannya. Agile mengatakan bahwa pekerjaan harus pada kecepatan yang berkelanjutan dan tidak boleh menguras tenaga para pekerja. Menjaga mereka di sana sampai jam 8:00 untuk menonton build berhasil adalah bertentangan dengan itu.
KeithS

@KeithS: Benar. Tetapi saya telah menemukan bahwa, terlepas dari kapan saya pergi, waktu yang paling mungkin bagi saya untuk menghancurkan bangunan adalah ketika saya sedang terburu-buru: tepat sebelum makan siang, tepat sebelum pertemuan, tepat sebelum akhir hari. Jadi saya pikir ini adalah "praktik terbaik pribadi" untuk tidak melakukan apa pun ketika tidak ada cukup waktu untuk menonton dan memperbaiki bangunan sesudahnya.
Daniel Pryden

2

Ya ya ya! Ini memupuk kepemilikan kode kolektif dan menetapkan semacam tekanan rekan sejawat dalam tim untuk menjaga standar tinggi dan tidak membiarkan skenario jendela pecah berkembang. Sedikit komunikasi untuk memberi tahu pengembang lain adalah ide yang bagus.


2

Saya pikir tidak apa-apa untuk memperbaiki hal-hal yang jelas - yaitu, jika Anda 100% yakin orang yang kodenya Anda perbaiki akan membuat yang sama - atau secara substansial sama - perbaiki. Jika perbaikannya lebih rumit, biasanya sopan untuk berbicara dengan orang yang kodenya Anda perbaiki - mungkin Anda salah paham tentang maksud atau alasan kerusakan bukan seperti yang Anda pikirkan, atau mungkin ia bermaksud memperbaiki lain tetapi untuk beberapa alasan belum bisa melakukan itu dulu (kehidupan terjadi, Anda tahu :).

Secara umum, aturan biasanya adalah: Anda melanggar build - Anda memperbaiki build, tetapi ada pengecualian, terutama jika perbaikannya jelas dan / atau orang yang bertanggung jawab tidak dapat dijangkau.

Tentu saja, jika Anda memiliki kasus serial build breaker - terutama dengan pola "check in, pulang, build rusak selama berhari-hari" - orang yang bertanggung jawab perlu berbicara tentang mengapa sistem CI dan tes ada dan bagaimana seseorang harus periksa sebelum check-in :)


1

Sesuatu terjadi. Kegagalan untuk menambahkan file kode baru (apakah sumber atau dikompilasi) ke Subversion mungkin merupakan penyebab paling umum dari bangunan yang rusak, dengan asumsi itu berfungsi pada komputer pengembang. Pada pekerjaan terakhir saya dengan lingkungan CI, bahkan orang paling senior pun terkadang lupa.

Saya pikir, jika orang lain bisa memperbaiki bangunan dan dengan demikian menjaga tim bersenandung, itu baik-baik saja. Saya pikir programmer yang pulang paling tidak memerlukan email yang menyatakan apa yang terjadi, dan untuk mengingatkannya untuk memastikan bahwa kode baru ditambahkan sebelum melakukan. Jika itu sering terjadi, mungkin membuat pelanggaran kecil itu dapat dihukum oleh "tarian rasa malu", untuk membantu mengurangi kejadian (dan meringankan suasana hati).


1

Itu tergantung pada dinamika Tim, tetapi dalam dunia yang ideal setiap orang di Tim akan "memiliki" seluruh proyek, semua kode, dan akibatnya, semua bug secara bersama-sama. Jadi, jika Anda menemukan masalah Anda memperbaikinya, dan berkomunikasi dengan pencetus bug hanya jika ada nilai tambah khusus untuk kode dalam melakukannya.


0

Tidak apa-apa untuk memperbaikinya kecuali ini adalah kejadian biasa di mana saya ingin bos memanggilnya dan membuatnya kembali dan memperbaikinya sendiri.


0

Itu tergantung, itu tergantung ...

Sebagai programmer, pekerjaan kami adalah membuat semuanya berfungsi, bukan menghakimi orang. Jadi saya akan mengatakan bahwa hal terbaik yang dapat Anda lakukan adalah memperbaikinya, atau jika tidak jelas, putar kembali perubahannya dan beri tahu programmer pertama agar ia dapat memperbaikinya nanti.

Ngomong-ngomong, memiliki cowok terbaru yang memecahkan bangunan untuk mengenakan topi aneh sudah cukup untuk lebih memperhatikan waktu berikutnya ^ _ ^


0

Di beberapa lingkungan, ini sangat kasar, dan untuk alasan yang baik. Di lingkungan lain, itu diharapkan, dan untuk alasan yang baik.

Masih di lingkungan lain, itu sangat kasar atau diharapkan untuk alasan yang sangat buruk.

Ini sangat tergantung pada seberapa kritis bangunan rusak versus seberapa kritis bangunan benar yang diverifikasi. Dan sampai batas tertentu, itu tergantung pada seberapa jelas perbaikannya adalah perbaikan yang tepat dan satu-satunya yang dibutuhkan.


0

Pertama, 'pulang ke rumah' adalah anakronisme. Programmer tidak pulang lagi - mereka hanya online atau offline. Anda bisa melakukan ping dan menunggu.

Lebih serius lagi, sebenarnya ada dua bagian dari pertanyaan itu. 'melihat melalui perubahan kode' baik-baik saja; istirahat mungkin bukan hal yang benar untuk dilakukan. Bagaimana jika penilaiannya terhadap perpustakaan yang hilang salah?

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.