Haruskah saya memberi tahu seseorang bahwa komit mereka menyebabkan kemunduran?


115

Saat Anda melacak dan memperbaiki regresi — yaitu bug yang menyebabkan kode yang sebelumnya berhenti berfungsi — kontrol versi memungkinkan untuk mencari siapa yang melakukan perubahan yang merusaknya.

Apakah layak melakukan ini? Apakah konstruktif untuk menunjukkan ini kepada orang yang membuat komitmen? Apakah sifat kesalahan (pada skala kurangnya perhatian terhadap kesalahpahaman mendasar dari kode yang mereka ubah) mengubah apakah itu ide yang baik atau tidak?

Jika itu adalah ide yang baik untuk memberitahu mereka, apa cara yang baik untuk melakukannya tanpa menyebabkan pelanggaran atau membuat mereka menjadi defensif?

Asumsikan, demi argumen, bahwa bug cukup halus bahwa tes otomatis server CI tidak dapat mengambilnya.


119
Jangan CC seluruh tim ketika Anda mengirimnya email ini.
quant_dev

26
Tentu saja katakan padanya, secara diplomatis atau dengan lelucon. Di perusahaan tempat saya bekerja, kami memiliki dasbor dengan nama setiap pengembang. Setiap kali seseorang membuat kesalahan yang berhubungan dengan repositori (lupa untuk melakukan sesuatu, lupa untuk menandai, tidak mengkompilasi, dll) bahwa pengembang mendapatkan "+". Ketika dia memiliki "+++" dia harus membayar sarapan untuk hari berikutnya. Anehnya, karena sistem telah diberlakukan, ada lebih sedikit sarapan "wajib" :-)
Jalayn

26
@Jalayn - bukan dengan lelucon - yang hanya mengganggu orang
user151019

29
"Asumsikan, demi argumen, bahwa bug itu cukup halus sehingga tes otomatis server CI tidak dapat mengambilnya." Kenapa tidak? Apakah ini sesuatu yang belum Anda uji? Jika ya, hal pertama yang harus Anda lakukan adalah menulis tes (atau beberapa tes) yang gagal sekarang akan berlalu ketika bug diperbaiki. Jika tidak bisa diuji, mengapa tidak?
Thomas Owens

18
@ Thomas Owens Karena itu bukan pertanyaan yang saya ajukan. :-P Dalam dunia yang ideal, tidak ada bug yang masuk ke sistem, karena kami akan menulis kode yang sempurna pertama kali, dan akan ada rangkaian lengkap tes otomatis jika kami tidak melakukannya. Namun, ini bukan dunia yang ideal, jadi saya bertanya apa yang harus Anda lakukan ketika bug masuk ke kode Anda.
Scott

Jawaban:


38

Jika Anda hanya mendekati mereka untuk memberi tahu mereka tentang kesalahan yang mereka buat maka kecuali Anda adalah diplomat terbaik di dunia, akan sulit baginya untuk tidak hanya terdengar seperti "Ha! - lihat kesalahan yang Anda buat ini!". Kita semua manusia dan kritik sulit diterima.

Di sisi lain, kecuali perubahan itu benar-benar sepele dan jelas salah, saya biasanya merasa perlu untuk berbicara dengan orang yang melakukan perubahan asli sebagai bagian dari penyelidikan saya hanya untuk memastikan bahwa saya benar-benar memahami apa yang sedang terjadi, maka cara saya biasanya akhirnya menangani situasi ini adalah dengan pergi ke orang tersebut dan melakukan percakapan yang sedikit seperti ini:

Saya: Saya sedang mengerjakan bug ini di mana ... ringkasan bug ... dan saya pikir saya telah melacak masalah ke perubahan yang Anda buat. Bisakah Anda ingat untuk apa perubahan ini? Saya sudah punya waktu untuk menjelaskan perubahan ini?

Maka baik:

Mereka: Tentu, itu untuk menangani ... situasi yang saya tidak sadari ...

Atau sesuatu seperti:

Mereka: Tidak maaf saya tidak ingat, terlihat salah bagi saya.

Dengan pergi dan menyelidiki perubahan / bug bersama-sama, committer asli dapat belajar dari kesalahan mereka tanpa hanya merasa seperti mereka sedang dikritik *, dan ada juga peluang yang cukup bagus bahwa Anda akan belajar sesuatu juga.

Jika pengendara asli tidak ada atau sibuk maka Anda selalu dapat bekerja keras dan mencari tahu sendiri, saya biasanya menemukan bahwa berbicara dengan orang yang membuat perubahan lebih cepat.

* Tentu saja ini hanya akan berhasil jika Anda benar-benar tertarik pada bantuan orang lain. Jika Anda hanya menggunakan ini sebagai metode yang disamarkan untuk memberi tahu seseorang tentang kesalahan yang mereka buat, ini mungkin lebih buruk daripada sekadar bersikap terbuka tentang hal itu.


"Mereka: Tentu, itu untuk menangani ... situasi yang tidak kusadari ..." Aku punya masalah dengan tbh ini. Jika mereka telah mendokumentasikan perubahan secara efektif, maka situasi itu seharusnya bukan sesuatu yang Anda tidak sadari.
temptar

1
@ temptar Cukup adil - ganti "tidak sadar" dengan "belum memikirkan" atau apa pun yang Anda inginkan - maksud saya adalah bahwa meskipun Anda bisa mencari tahu sendiri (misalnya dengan melihat dokumentasi), ini biasanya lebih cepat hanya dengan bertanya. Juga banyak kode tidak terdokumentasi sebagaimana mestinya.
Justin

170

Bersikaplah asertif, tidak agresif. Selalu suka mengatakan sesuatu yang mirip dengan "kode ini tidak berfungsi" vs "kode Anda tidak berfungsi". Mengkritik kode, bukan orang yang menulis kode.

Lebih baik lagi, jika Anda dapat memikirkan solusinya, perbaiki dan dorong mereka - dengan asumsi Anda memiliki sistem kontrol versi terdistribusi. Kemudian tanyakan kepada mereka apakah perbaikan Anda valid untuk bug yang mereka perbaiki. Secara keseluruhan, cobalah untuk meningkatkan pengetahuan Anda dan pemrograman mereka. Tetapi lakukan itu tanpa ego Anda menghalangi.

Tentu saja, Anda harus bersedia mendengarkan pengembang lain yang datang kepada Anda dengan masalah yang sama dan bertindak sesuai keinginan Anda.


107
+1. Pendekatan favorit pribadi: "Sebelum saya bermain-main dengan ini, apakah ada alasan Anda melakukannya dengan cara ini?"
pdr

67
+1. "Mengkritik kode, bukan orang yang menulis kode."
c_maker

11
+1, Ini adalah saran yang sangat mirip dengan apa yang dikatakan oleh penasihat pernikahan saya kepada istri saya dan saya, ketika memiliki keluhan terhadap apa yang dilakukan pasangan Anda, hindari kata ANDA , itu terlalu konfrontatif.
maple_shaft

3
+1, tapi menurut saya kata "Anda" tidak konfrontatif. Perlu ada pemahaman yang jelas tentang kepemilikan. Saya pribadi memiliki orang-orang yang terus-menerus melakukan kode yang merusak build karena mereka tidak mengerti bahwa merekalah yang menyebabkannya. Saya suka pendekatan @ pdr ... pernyataan ini tidak konfrontatif namun memiliki kata "Anda" di dalamnya.
Tim Reddy

3
Sepertinya Anda mungkin memperkenalkan kembali bug baru. Perbaikan mereka mungkin telah memperbaiki masalah sebelumnya yang tidak Anda ketahui. Mengapa tidak mendatangi mereka dan bertanya mengapa mereka menulis kode seperti yang mereka lakukan. Mungkin mengungkapkan bahwa ada bahasa aneh / desain / vm quirk yang menutupi. Pergi dan tunjukkan pada mereka egomu ["heres bagaimana aku bisa berbuat lebih baik" tidak akan membantu mereka]
monksy

70

Ya selalu . Sebagai seorang programmer, tugas Anda adalah belajar dari kesalahan.

Memberi tahu mereka kesalahan yang mereka lakukan akan membantu mereka menjadi pembuat kode yang lebih baik dan mengurangi peluang mereka untuk membuat kesalahan di masa depan. TETAPI bersikap sopan dan tidak mempermasalahkannya, kita semua sering membuat bug. Saya menemukan email yang sopan adalah cara yang sangat tidak konfrontatif untuk memberi tahu orang.


3
Bagian "belajar dari kesalahan" tidak sepenuhnya benar secara universal. Banyaknya bug adalah hal-hal seperti validator yang hilang misalnya. Ini adalah hal-hal yang baru saja terjadi, bahkan untuk pengembang berpengalaman. Anda tidak akan belajar banyak dari itu. Itu sebabnya kita perlu memiliki QA yang layak.
Falcon

2
@ Falcon Wawasan "kita perlu memiliki QA yang layak" adalah contoh belajar dari kesalahan. Anda dapat melanjutkan dengan berpikir tentang "mengapa kita tidak memiliki QA / mengapa QA kita melewatkan masalah ini"
MarkJ

2
@ Falcon "Ini adalah hal-hal yang terjadi begitu saja" <--- ini saja adalah pengetahuan yang Anda dapatkan dari kesalahan berulang tapi sepele. Pernahkah Anda memiliki pengalaman ketika Anda mengkompilasi dan hal-hal tidak berfungsi, hal pertama yang Anda periksa ejaan Anda dan bang, dalam 10 detik, bug hilang. Anda memiliki pengetahuan bahwa "ini adalah hal-hal yang baru saja terjadi", terkadang itu sebabnya Anda dapat melakukan debug dalam 10 detik, bukan 10 jam.
Gapton

@Apton dan MarkJ: Itu poin bagus! Saya tidak memikirkan hal itu.
Falcon

"Sebagai seorang programmer, tugasmu adalah belajar dari kesalahan." -> "Sebagai manusia ..." Belajar dari kesalahan Anda bukanlah sesuatu yang spesifik untuk bidang ini.
Burhan Ali

23

Cara konstruktif adalah menemukan bug, memperbaikinya dan mengambil tindakan untuk menghindari bug serupa muncul di masa depan.

Jika itu melibatkan menjelaskan kepada orang-orang bagaimana tidak memperkenalkan bug, lakukanlah.

Suatu kali, saya bekerja di sebuah tim di mana manajer proyek tidak pernah memberi tahu pengembang tertentu bahwa dia melakukan kesalahan: dia mengatur pertemuan dengan seluruh tim di mana dia menjelaskan bahwa ada kesalahan dan bahwa proses baru telah ditetapkan untuk menekan kesalahan semacam itu. Dengan begitu, tidak ada yang distigmatisasi.


4
+1 untuk "mengambil tindakan untuk menghindari bug serupa muncul di masa mendatang". Itu bagian terpenting, IMO.
CVn

1
The constructive way is to find the bug, fix it and take actions to avoid similar bugs to arise in the future.-> Pertanyaannya adalah Anda sudah memperbaiki bug.
Hugo

1
Ya, tapi berhati-hatilah dalam memperkenalkan proses baru. Jika Anda terlalu banyak memperkenalkan proses dan memanggil terlalu banyak pertemuan, itu memperlambat laju perkembangan dan meracuni moral perusahaan. Saya telah melihat terlalu banyak toko bereaksi berlebihan terhadap kesalahan satu orang. Hanya jika kesalahan menunjukkan proses yang rusak seharusnya proses baru sesuai.
Jacob

@ jacob - Saya setuju.
mouviciel

19

Secara umum, ya .

Tidak ada yang harus bersikap defensif jika Anda bijaksana tentang hal itu. Cara mudah untuk mengatasinya adalah meminta mereka memeriksa ulang perubahan Anda sebelum Anda mengembalikannya ke bagasi (atau apa pun yang relevan untuk sistem kontrol versi Anda). Orang akan menghargai jika Anda menyimpannya beberapa menit dengan memperbaiki kesalahan yang jelas, tetapi mereka tidak akan menghargai jika Anda memperbaiki sesuatu yang tidak rusak dan akhirnya melanggar kode mereka. Memberi mereka kesempatan untuk meninjau perubahan Anda memberi tahu mereka bahwa Anda tidak ingin menginjak kaki mereka dan memberi mereka kesempatan untuk menolak perubahan Anda.

Jika ini adalah perubahan besar dan bukan hanya kesalahan ketik, itu ide yang baik untuk memberikan pengarang sebelum Anda menggali untuk mencoba memperbaikinya. "Joe, aku menggabungkan barang-barangku sendiri kemarin dan menemukan sesuatu yang aku tidak yakin aku mengerti. Kelihatannya seperti bug, tapi aku ingin menjalankannya denganmu sebelum aku mengacaukan kodemu. Apakah kamu akan melihatnya dengan saya?"

Hubungan Anda dengan penulis adalah faktor besar. Jika Anda tidak keberatan penulis memperbaiki kode Anda tanpa memberi tahu Anda, dan jika Anda cukup yakin perasaannya saling menguntungkan, maka itu mungkin tidak layak untuk disebutkan. Jika seseorang dengan lebih banyak pengalaman / senioritas / status, Anda ingin memberi tahu mereka bahwa Anda akan mengubah kode mereka. Jika seseorang dengan sedikit, pertimbangkan apakah itu jenis hal yang perlu mereka dengar untuk menghindari mengulangi kesalahan atau mungkin membuat mereka malu.

Selalu ingat bahwa jika Anda dapat mengetahui siapa yang memeriksa "bug", mereka dapat dengan mudah mengetahui siapa yang "memperbaiki" kode mereka. Jika Anda pikir mereka akan marah / kesal / malu mengetahui tentang perubahan Anda setelah fakta, tentu saja beri tahu mereka sebelumnya.

Selain itu, memperbaiki bug bukan satu-satunya pilihan Anda. Anda selalu dapat melaporkan bug di pelacak masalah Anda. Sekali lagi diperlukan kebijaksanaan di sini - melaporkan bug membuatnya lebih terlihat oleh seluruh tim, tetapi juga memberi penulis kesempatan untuk memperbaiki kesalahannya sendiri. Pelaporan adalah opsi terbaik jika Anda tidak yakin tentang cara terbaik untuk memperbaiki masalah atau jika Anda tidak punya waktu untuk memperbaikinya.


2
Saya suka "Saya tidak begitu mengerti ini, bisakah Anda menjelaskan kepada saya cara kerjanya?" pendekatan. Jika disengaja (dan baru-baru ini), maka programmer asli harus dapat menjelaskan dengan baik bagaimana kode bekerja. Jika itu bug, kemungkinan bagus bahwa dalam menjelaskan apa yang dilakukan kode, ia akan menemukan kesalahan dan di tengah penjelasan Anda akan mendengar "oops". Apa pun itu, siapa pun akan sulit sekali merasa seolah-olah ada jari yang menunjuk pada mereka untuk kemungkinan kesalahan.
CVn

3
+1 untuk "sepertinya bug, tapi saya ingin menjalankannya sebelum Anda mengacaukan kode Anda."
Russell Borogove

6

Jika saya membuat komit yang menyertakan bug, Anda sebaiknya memberi tahu saya. Jika saya menemukan komitmen Anda yang menyertakan bug, saya pasti akan memberi tahu Anda.

Kami hanya meningkatkan ketika kami memahami kesalahan kami. Itulah cara kami menghasilkan kode yang lebih baik di masa depan.


5

Anda mendapatkan jawaban yang bagus di sini.

Saya hanya bisa menambahkan teknik yang saya pelajari dari manajer ketika saya akan membuat kesalahan.

Saya adalah konsultan setengah baya dengan gelar Ph.D. dan dia adalah manajer muda tanpa, jadi bisa ada gradien prestise yang dirasakan. Bagaimanapun, dia jelas memiliki pengalaman dengan situasi ini dan tahu bagaimana mengatasinya.

Dia mengatakan kepada saya dengan nada yang hampir meminta maaf bahwa tampaknya ada masalah, dan apakah saya punya waktu untuk memeriksanya?

Cukup sering, kesalahan itu milik saya, dan dia tahu itu. Itu adalah keterampilan.


5

Saya pikir ada masalah yang lebih dalam yang mendasari pertanyaan ini. Ya, pengirim tentu harus dibuat sadar akan konsekuensi dari perubahan mereka, sehingga mereka dapat memahami apa yang terjadi dan tidak melakukan hal yang sama lagi. Namun, konteks pertanyaan Anda menunjukkan bahwa Anda menyiapkan dan mengirimkan perbaikan tanpa sepengetahuan pengirim asli bahwa mereka bahkan menyebabkan masalah. Disinilah letak masalah yang lebih dalam: mengapa pengirim belum tahu tentang regresi dan mengapa mereka tidak memperbaikinya sendiri? Situasi yang Anda gambarkan mungkin menunjukkan kurangnya akuntabilitas atau kewaspadaan dari pihak pengirim asli, yang merupakan kekhawatiran potensial sehubungan dengan kinerja dan motivasi mereka secara keseluruhan.

Pengalaman rekayasa perangkat lunak saya telah mengajarkan saya untuk memiliki semua perubahan kode saya, tidak hanya proyek yang saya bertanggung jawab, semua cara untuk produksi, yang mencakup menyadari dampaknya, termasuk pada sistem build Anda dan (jelas) perilaku produk.

Jika perubahan seseorang telah menyebabkan masalah, itu tidak berarti orang tersebut adalah insinyur yang buruk, tetapi biasanya mereka harus bertanggung jawab dan terlibat dalam memperbaiki apa pun yang salah. Bahkan jika mereka tidak "salah", misalnya kode mereka mengekspos bug mendasar yang telah ada dalam basis kode selama bertahun-tahun, mereka harus menjadi salah satu orang pertama yang menyadari masalah dengan perubahan mereka. Bahkan jika pengirim asli bukan orang yang tepat untuk memperbaiki bug, mereka harus terhubung erat dengan siklus hidup perubahan mereka.


4

Traksi bagus untuk pertanyaan Anda! Semua orang memberi tahu Anda apa yang harus dilakukan. Haruskah Anda memberi tahu? IYA! Kapan saja pertanyaannya bertanya "haruskah saya berkomunikasi lebih banyak?", Jawabannya hampir selalu YA!

Tetapi untuk menambahkan sesuatu yang berbeda: premis Anda cacat.

Seorang rekan kerja membuat komitmen yang tidak melanggar CI, tetapi mengarahkan Anda untuk menemukan masalah.

Selamat! Anda menemukan bug baru, bukan regresi. Serius, apakah Anda menguji setiap skenario dan garis kode secara manual yang tidak dicakup oleh pengujian otomatis (atau manual terstandarisasi) saat Anda berkomitmen?

Dengan segala cara, ajak kolega Anda terlibat dalam perbaikan, dengan tes untuk memastikan itu tidak terjadi lagi. Anda berdua adalah pahlawan! Tetapi jika Anda membiarkan kesalahan dalam kata atau tindakan, Anda bertanggung jawab untuk melanggengkan salah satu penyakit organisasi terburuk: akuntabilitas tanpa tanggung jawab.

Jika Anda benar-benar perlu menemukan penjahat, pikirkan tentang orang yang melakukan kode asli yang rusak, dan meninggalkan jebakan untuk teman Anda yang tidak curiga (jelas tanpa cakupan tes yang memadai). Semoga itu bukan kamu!


2

Selalu menganggap orang lain sebagai seseorang yang lebih baik daripada Anda, selalu melihat karakteristik orang lain baik dan selalu tahu bahwa saya juga bisa membuat kesalahan.

Beri tahu mereka saat Anda berdua saja.


+1 untuk kalimat terakhir. Puji di depan umum, kritiklah secara pribadi.
Scott C Wilson

2

Jika seseorang tersinggung ketika Anda mengatakan kepadanya bahwa ia melakukan kesalahan, itu berarti ia berpikir bahwa ia adalah yang paling bijaksana di bumi dan tidak membuat kesalahan, dan ketika dikritik, ia mendapatkan perasaan, seperti yang kami katakan di Polandia, bahwa 'mahkota sedang jatuh dari kepalanya'.

Jadi Anda tidak perlu ragu untuk mengatakan bahwa seseorang telah melakukan kesalahan. Itu normal. Setiap orang membuat kesalahan, bahkan yang terbaik! Hanya mereka yang tidak membuat kesalahan;)


1
Semuanya tergantung bagaimana Anda memberi tahu orang itu bahwa mereka melakukan kesalahan. Saya melakukan kesalahan sepanjang waktu dan akan senang jika seseorang menunjukkannya sehingga saya dapat meningkatkan tetapi jika Anda datang dan memberi tahu saya "Sobat, komit terakhir Anda benar-benar memecahkan kode. Mengapa Anda tidak bisa lebih baik dalam memeriksa kesalahan Anda ? " Saya tentu saja akan tersinggung.
The Jug

Ya, namun pertanyaan "Bung, apakah Anda menjalankan tes junit sebelum melakukan?" adalah, saya pikir, sepenuhnya dapat diterima :)
Danubian Sailor

+1 untuk Hanya mereka yang tidak membuat kesalahan . Jelas ketika diartikulasikan, tapi saya belum pernah melihatnya dengan rapi.
FumbleFingers

2

Selain apa yang dikatakan orang lain, pastikan itu benar-benar komit mereka yang menyebabkan bug. Tentu saja jangan menyalahkan orang lain atas kesalahan Anda sendiri. Tidak peduli seberapa bijaksana Anda mendekati mereka, Anda masih akan marah jika Anda menyalahkan mereka karena sesuatu yang tidak mereka lakukan. (Berbicara sebagai seseorang yang terus-menerus disalahkan atas bug orang lain; satu kali seseorang mendatangi saya dan berkata saya melakukan sesuatu yang benar-benar bodoh dan saya membuka log komit dan menemukan bahwa orang terakhir yang menyentuh baris kode itu adalah orang yang menyalahkan saya. Entah bagaimana, dia masih berpikir itu adalah kesalahan saya karena saya yang menulis kalimatnya semula.)


2

Mengapa saya tidak melihat satu jawaban pun di sini yang mencerminkan komentar pilihan teratas pada pertanyaan ??

Ya, benar-benar memberi tahu mereka tentang hal itu, tetapi jangan lakukan itu di depan seluruh tim

Dekati pengembang 1: 1 dan tunjukkan bug. Jangan terlalu mempermasalahkannya. Saya selalu berpikir bahwa menunjukkan kesalahan di depan seluruh tim adalah ide yang buruk. Mungkin bekerja untuk beberapa pengembang, tetapi tidak untuk semua orang dan dapat memiliki efek negatif. Ingat, kita semua berada di posisi mereka di beberapa titik atau yang lain, dan seperti jawaban 2 teratas mengatakan, Anda belajar dari kesalahan Anda

Saya biasanya menemukan itu bekerja paling baik ketika Anda mulai dengan pujian dan kemudian mendapatkan kesalahan ... sesuatu seperti "perbaikan yang Anda implementasikan bekerja dengan baik, TAPI tampaknya sudah rusak x, y, z", atau "terima kasih telah melakukan , b, c, TAPI tampaknya menyebabkan x, y, z "


2

Jawaban sederhana: Ya.

Jawaban yang lebih panjang: Pekerjaan terakhir saya adalah di sebuah perusahaan Agile yang menggunakan TDD dengan alat CI untuk memastikan bahwa apa yang ada dalam repo SVN kami baik, kode kerja setiap saat. Ketika sesuatu dilakukan, server TeamCity kami mendapatkan salinan, dikompilasi, dan menjalankan tes unit. Itu juga menjalankan tes integrasi setiap jam. Jika sesuatu dilakukan yang menyebabkan CI gagal, semua orang mendapat email yang menyatakan bangunan rusak berdasarkan komitmen oleh orang tertentu.

Itu tidak selalu menangkap segalanya; celakalah kami, kami tidak menerapkan cakupan kode, dan bahkan jika ada sesuatu yang dicakup oleh unit atau tes integrasi, mereka mungkin tidak menggunakan kode itu secara memadai. Ketika itu terjadi, siapa pun yang mendapat tugas memperbaiki masalah yang diketahui (jika QA menangkapnya) atau cacat (jika, dun-dun-dun, klien melakukannya), akan menjalankan "kesalahan" (menunjukkan siapa yang terakhir memodifikasi setiap baris dari suatu file kode) dan tentukan pelakunya.

Menelepon seseorang untuk memeriksa kode yang rusak tidak selalu merupakan hal yang buruk. Mereka telah gagal melakukan pekerjaan mereka dengan baik, dan mereka atau orang lain harus kembali dan memperbaiki kesalahan. Ini terjadi setiap saat; seberapa besar kesepakatan itu harus tergantung pada seberapa mudah perbaikannya, apakah kesalahan menunjukkan orang tersebut bahkan tidak menyusun atau menjalankan kode yang dimaksud, dan budaya perusahaan secara keseluruhan. Yang penting dalam semuanya adalah bahwa ada sesuatu yang dipelajari oleh orang yang melakukan kesalahan; jika bangunan rusak karena orang yang sama berulang-ulang, ada masalah yang lebih dalam dengan orang itu yang harus diatasi. Bangunan yang rusak sepanjang waktu menunjukkan masalah dengan komunikasi tim atau pengetahuan tentang proses tersebut.


Pada start-up kecil tempat saya bekerja, kami memiliki sistem yang serupa. Yang lucu adalah ketika Anda memeriksa beberapa kode dan tes gagal sistem build akan menyalahkan kegagalan tes pada orang yang terakhir memeriksa dalam edit pada baris bahwa tes / kompilasi gagal. Jadi jika saya menghapus fungsi yang Anda gunakan dan kode Anda sekarang gagal dibangun. Build-Bot akan dengan keras menyalahkan Anda. Panggilan nama mengutuk dan ramah berikutnya memastikan bahwa kesalahan build diperbaiki segera dan gangguan semua orang diarahkan pada Build-Bot.
Stuart Woodward

2

Iya. Minta orang tersebut untuk meninjau perbaikan yang Anda buat pada kode. Kadang-kadang saya menemukan bahwa bug orang lain sebenarnya bagian rumit dari kode dengan beberapa konsekuensi lain yang tidak terlihat jika bug itu diperbaiki.


1

Ada banyak faktor yang berperan.

  • Seberapa parah bug ini?
  • Apa hubungan senioritas antara Anda dan pelanggar?
  • Seberapa sibuk / stres tim ini?
  • Apakah pemutus bekerja di bagian basis kode atau milik Anda?
  • Seberapa yakin Anda bahwa itu benar-benar bug, dan seberapa yakin Anda bahwa perbaikan Anda sudah benar?

Jika masalahnya kecil - salah ketik / thinko / cut & paste bug - dan pemecahnya adalah rekan sibuk, dan Anda yakin dengan penilaian masalah Anda, Anda mungkin tidak perlu membawanya ke perhatian mereka. (mis foo.x = bar.x; foo.y = bar.y, foo.z = bar.y.).

Dalam kebanyakan kasus lain, ada baiknya menyebutkan masalahnya. Dalam kasus yang tidak serius, Anda tidak perlu mengganggu apa yang mereka lakukan; tunggu dan lakukan saat makan siang atau ketika menabrak mereka di ruang istirahat.

Jika sifat kesalahan menunjukkan kesalahpahaman yang serius (dari platform implementasi, kebijakan lokal, atau spesifikasi proyek), bagaimanapun, bawa ASAP.

Jika Anda tidak yakin dengan penilaian Anda, minta mereka untuk meninjau perbaikan Anda, terutama jika itu tidak ada dalam kode yang Anda kenal. (Saya sangat menyarankan tim dev Anda mengadopsi kebijakan 'teman kode' di mana semua perubahan ditinjau oleh satu orang lain sebelum checkin, pokoknya.)


1

Apa yang terjadi jika Anda tidak memberi tahu mereka?

Kontra

Mereka mungkin membuat kesalahan yang sama di tempat lain karena mereka tidak mengerti bahwa itu menyebabkan masalah. Bukan hanya itu tetapi akan ada waktu ekstra yang tidak perlu untuk berulang kali memperbaiki kesalahan yang sama. Anda tidak dapat belajar dari kesalahan yang tidak Anda sadari.

Kedua, mereka pikir mereka melakukan pekerjaan yang lebih baik daripada mereka. Ketika orang tidak disadarkan akan masalah mereka, mereka hampir tidak dapat disalahkan karena berpikir bahwa mereka baik-baik saja ketika tidak. Bahkan ketika masalahnya adalah kesalahan yang ceroboh, orang membuat lebih sedikit dari mereka ketika mereka menyadari bahwa kesalahan itu diperhatikan.

Selanjutnya jika seseorang tidak melihat siapa yang melakukannya, bagaimana Anda akan tahu jika Anda memiliki karyawan bermasalah yang selalu ceroboh atau memiliki kesalahpahaman mendasar terhadap produk? Apakah orang yang bertanggung jawab ingin hal itu berlanjut di tim yang terkait dengannya?

Jika Anda memperbaiki dan melanjutkan tanpa mendiskusikannya, Anda yakin telah memperbaikinya? Terkadang tes yang perlu diubah ketika persyaratan berubah. Jika ini bukan kesalahan ketik kecil, bisakah Anda benar-benar yakin salah satu dari Anda memiliki solusi yang benar? Anda mungkin melanggar kodenya sebagai imbalan tanpa berkonsultasi.

Pro

Orang-orang tidak merasa malu atau jengkel dengan Anda karena menunjukkan kesalahan mereka.

Saya kira saya turun dengan kuat di sisi memberi tahu mereka tetapi melakukannya dengan baik dan pribadi. Tidak perlu dipermalukan di depan umum. Jika orang tersebut berulang kali membuat kesalahan yang sama atau membuat kesalahan kritis yang menunjukkan kurangnya pemahaman, maka penyelia perlu disadarkan juga.

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.