Bagaimana cara saya menangani ketidaksepakatan dalam ulasan kode tentang kasus tepi yang tidak mungkin?


188

Saya bekerja di startup robotika di tim cakupan jalur dan setelah mengirimkan permintaan tarik, kode saya ditinjau.

Rekan satu tim saya, yang telah berada di tim selama lebih dari setahun, telah membuat beberapa komentar pada kode saya yang menyarankan saya melakukan lebih banyak pekerjaan daripada yang saya yakini perlu. Tidak, saya bukan pengembang yang malas. Saya suka kode elegan yang memiliki komentar baik, nama variabel, lekukan dan menangani kasus dengan benar. Namun, ia memiliki tipe organisasi yang berbeda dalam pikiran yang tidak saya setujui.

Saya akan memberikan contoh:

Saya telah menghabiskan satu hari menulis kasus uji untuk perubahan ke algoritma pencarian transisi yang saya buat. Dia telah menyarankan agar saya menangani kasus yang tidak jelas yang sangat tidak mungkin terjadi - bahkan saya tidak yakin itu mungkin terjadi. Kode yang saya buat sudah berfungsi di semua kasus uji asli kami dan beberapa yang baru yang saya temukan. Kode yang saya buat sudah melewati 300+ simulasi kami yang dijalankan setiap malam. Namun, untuk menangani kasus yang tidak jelas ini akan membutuhkan waktu 13 jam yang bisa lebih baik dihabiskan untuk mencoba meningkatkan kinerja robot. Agar jelas, algoritme sebelumnya yang telah kami gunakan sampai sekarang juga tidak menangani kasus tidak jelas ini dan tidak sekali pun, dalam laporan 40k yang telah dihasilkan, pernahkah hal itu terjadi. Kami adalah startup dan perlu mengembangkan produk.

Saya belum pernah melakukan review kode sebelumnya dan saya tidak yakin apakah saya terlalu argumentatif; haruskah aku diam saja dan melakukan apa yang dia katakan? Saya memutuskan untuk tetap menunduk dan melakukan perubahan meskipun saya sangat tidak setuju bahwa itu adalah penggunaan waktu yang baik.


Saya menghormati rekan kerja saya dan saya mengakuinya sebagai programmer yang cerdas. Saya hanya tidak setuju dengan dia tentang suatu hal dan tidak tahu bagaimana menangani perbedaan pendapat dalam ulasan kode.

Saya merasa bahwa jawaban yang saya pilih memenuhi kriteria untuk menjelaskan bagaimana pengembang junior dapat menangani ketidaksepakatan dalam ulasan kode.


152
Anda benar-benar menyadari bahwa tes unit, sebagian, dimaksudkan untuk menangkap cacat satu dalam sejuta ketika seseorang memeriksa perubahan kode Anda yang merusaknya dengan cara yang tidak jelas, bukan? Tes unit tidak hanya memastikan kode Anda benar sekarang , tetapi juga dalam tiga tahun ketika orang lain mempertahankan kode yang Anda tulis.

189
@Lik "Input nyata tidak akan pernah seperti ini" Di situlah Anda salah. Saya jumpai terlalu banyak kasus "masukan tidak akan seperti ini" dan menjadi terkejut ketika itu "seperti ini." Dalam lingkungan produksi, segala macam hal aneh bisa terjadi. Jangan hanya memikirkan bagaimana perangkat lunak Anda akan bekerja tetapi juga bagaimana itu akan gagal?

38
@Snowman Tinjauan kode titik lebih banyak lagi, sebagian, dimaksudkan untuk menangkap cacat satu-dalam-sejuta yang dites unit dan bahkan pengujian / fuzzing acak tidak ditemukan.
Derek Elkins

11
Perlu juga diingat bahwa ulasan kode tidak hanya ada untuk menangkap masalah, mereka juga ada di sana untuk Anda pelajari bagaimana Anda bisa melakukan yang lebih baik sehingga perlakukan mereka sebagai kesempatan belajar.
Steve Barnes

72
hey @Klik, sepertinya masalah mendasar di sini adalah Anda "takut berbicara dengan pikiran Anda". JANGAN PERNAH marah, SELALU ucapkan pikiran Anda - sambil tersenyum. Anda seharusnya langsung mengatakan kepada orang itu, "Hmm, itu akan memakan waktu setidaknya dua hari, apakah ini sepadan, mari kita bertanya kepada bos kami?" dan kedua Anda seharusnya mengatakan, "Jangan lupa manusia sedang mengerjakan robot, sebenarnya sensor kiri tidak mungkin berada di sebelah kanan sensor kanan - mari kita tanyakan kepada bos berapa banyak kasus sudut anti-fisik yang kita inginkan menutupi". Masalah Anda adalah milik Anda , masalah Anda adalah Anda perlu bertukar amarah untuk berbicara .
Fattie

Jawaban:


227

kasus tidak jelas yang sangat tidak mungkin terjadi - sebenarnya saya tidak yakin itu mungkin terjadi

Tidak memiliki perilaku yang belum teruji dalam kode bisa sangat penting. Jika sepotong kode dijalankan misalnya 50 kali per detik, kemungkinan satu dari sejuta akan terjadi kira-kira setiap 5,5 jam runtime. (Dalam kasus Anda, peluangnya tampak lebih rendah.)

Anda dapat berbicara tentang prioritas dengan manajer Anda (atau siapa pun yang lebih senior yang bertanggung jawab untuk unit tempat Anda bekerja). Anda akan lebih memahami apakah mis. Bekerja pada kinerja kode atau kode yang anti peluru adalah prioritas utama, dan seberapa tidak mungkin kasus sudut itu. Peninjau Anda mungkin juga memiliki gagasan prioritas yang miring. Setelah berbicara dengan penanggung jawab, Anda akan memiliki waktu yang lebih mudah untuk menyetujui saran peninjau Anda, dan akan memiliki sesuatu untuk dijadikan rujukan.

Itu selalu merupakan ide yang baik untuk memiliki lebih dari satu resensi. Jika kode Anda hanya ditinjau oleh satu kolega, minta orang lain yang tahu kode itu, atau basis kode secara umum, untuk melihatnya. Pendapat kedua, sekali lagi, akan membantu Anda untuk lebih mudah (tidak setuju) dengan saran peninjau.

Memiliki sejumlah komentar berulang selama beberapa ulasan kode biasanya menunjukkan hal yang lebih besar tidak dikomunikasikan dengan jelas, dan masalah yang sama muncul lagi dan lagi. Coba cari tahu hal yang lebih besar itu, dan diskusikan langsung dengan reviewer. Ajukan cukup pertanyaan mengapa . Ini banyak membantu saya ketika saya memulai praktik tinjauan kode.


9
@ 9000 Ini juga bisa membuat frustasi ketika jawabannya adalah "karena hidup seperti itu." Misalnya, ini adalah yang baru-baru ini harus saya lalui: "Gunakan spasi di atas tab." "Mengapa?" "Karena pemandu gaya kita bilang begitu." "Mengapa?" "Aku tidak tahu; aku tidak menulisnya." "Ha, jelas kamu salah dan aku benar, dan aku akan meninggalkan kodeku dengan tab!" Kemudian hook post-commit mengubahnya, tetapi tetap saja - jika Anda menggunakan teknik 5 whys, lanjutkan sampai Anda mendapatkan jawaban yang masuk akal, tidak sampai Anda membuat orang lain frustrasi.
Nic Hartley

111
@QPaysTaxes: Semua orang harus tahu alasan spasi di atas tab (atau tab di atas spasi): karena keduanya benar tetapi konsistensi lebih penting jadi pilih saja, konsisten dan jangan buang waktu bikeshedding
slebetman

30
Not having untested behaviors in code can be very important. If a piece of code is run e.g. 50 times a second, a one in a million chance will happen approximately every 5.5 hours of runtime. (In your case, the odds seem lower.)-- Apa? Tidak. Tidak kecuali Anda menjalankan simulasi Monte-Carlo, atau kode Anda menyertakan beberapa elemen acak. Komputer tidak menjalankan perangkat lunak sesuai dengan kurva lonceng atau standar deviasi kecuali Anda memberi tahu mereka secara khusus untuk melakukannya.
Robert Harvey

10
@RobertHarvey: pertimbangkan sesuatu seperti kondisi balapan, yang merupakan elemen acak. Juga pertimbangkan bug yang bergantung pada data saat memproses data yang dialirkan; sementara data mungkin tidak cukup acak, tetapi kecuali itu sangat berulang, kombinasi byte tertentu dapat terjadi berulang kali. Satu dalam sejuta = dipicu oleh kombinasi tertentu sebesar 20 bit, bug seperti ini akan segera terlihat jika memproses aliran video; sesuatu yang jarang terjadi tetapi secara teratur mungkin melibatkan misalnya 40 bit.
9000

7
@RobertHarvey: Sangat mungkin! Saya hanya ingin menunjukkan bahwa ada bagian-bagian kode yang mungkin memiliki peluang 1e-6 (bukan 0 dan bukan 1) untuk istirahat di bawah permintaan khusus, merujuk pada «kasus tersembunyi yang sangat tidak mungkin terjadi». Sementara bug seperti itu biasanya tidak terlihat di bawah tes, mereka yang terlihat di produksi.
9000

323

Saya bisa memberikan contoh kasus sudut yang tidak pernah terjadi yang menyebabkan bencana.

Ketika Ariane 4 sedang dikembangkan, nilai-nilai dari accelerometer lateral diskalakan agar sesuai dengan integer bertanda 16-bit dan karena kemungkinan output maksimum dari accelerometer, ketika diskalakan, tidak akan pernah melebihi 32767 dan minimum tidak akan pernah jatuh di bawah - 32768 ada "tidak perlu untuk overhead memeriksa kisaran". Secara umum semua input seharusnya rentang diperiksa sebelum konversi apa pun, tetapi dalam hal ini yang akan mencoba untuk menangkap kasus sudut yang mustahil.

Beberapa tahun kemudian Ariane 5 sedang dikembangkan dan kode untuk penskalaan akselerometer lateral digunakan kembali dengan pengujian minimal karena “terbukti digunakan”. Sayangnya roket yang lebih besar dapat mengharapkan akselerasi lateral yang lebih besar sehingga akselerometer ditingkatkan dan dapat menghasilkan nilai float 64-bit yang lebih besar .

Nilai-nilai yang lebih besar ini "dibungkus" dalam kode konversi, ingat tidak ada pemeriksaan rentang, dan hasilnya pada peluncuran pertama pada tahun 1996 tidak baik. Harganya jutaan perusahaan dan menyebabkan jeda besar dalam program ini.

Masukkan deskripsi gambar di sini

Poin yang saya coba buat adalah bahwa Anda tidak boleh mengabaikan kasus uji karena tidak pernah terjadi, sangat tidak mungkin, dll.: Standar yang mereka kode untuk dipanggil untuk memeriksa kisaran semua nilai input eksternal. Jika itu telah diuji dan ditangani maka bencana mungkin bisa dihindari.

Perhatikan bahwa dalam Ariane 4 ini bukan bug, (karena semuanya bekerja dengan baik untuk setiap nilai yang mungkin) - itu adalah kegagalan untuk mengikuti standar. Ketika kode tersebut digunakan kembali dalam skenario yang berbeda, ia gagal serempak, sementara jika rentang nilai telah terpotong kemungkinan akan gagal dengan anggun, dan keberadaan kasus uji untuk ini mungkin telah memicu tinjauan nilai-nilai tersebut. Perlu juga dicatat bahwa, sementara para pembuat kode dan penguji datang untuk beberapa kritik dari para penyelidik setelah ledakan, manajemen, QA & kepemimpinan dibiarkan dengan sebagian besar kesalahan.

Klarifikasi

Meskipun tidak semua perangkat lunak bersifat kritis terhadap keselamatan, juga tidak begitu spektakuler ketika gagal, maksud saya adalah untuk menyoroti bahwa tes "mustahil" masih dapat memiliki nilai. Ini adalah kasus paling dramatis yang saya tahu tetapi robot juga dapat menghasilkan beberapa hasil yang menghancurkan.

Secara pribadi, saya akan mengatakan bahwa begitu seseorang telah menyorot kasing sudut ke tim uji, tes harus dilakukan untuk memeriksanya. Pemimpin tim implementasi atau manajer proyek dapat memutuskan untuk tidak mencoba mengatasi setiap kegagalan yang ditemukan tetapi harus menyadari bahwa ada kekurangan. Atau, jika pengujian terlalu rumit, atau mahal, untuk diterapkan, masalah dapat diangkat pada pelacak apa pun yang digunakan & / atau daftar risiko untuk memperjelas bahwa ini adalah kasus yang belum diuji - yang mungkin perlu ditangani sebelum perubahan penggunaan atau mencegah penggunaan yang tidak tepat.


102
Ya ampun, jawaban ini dia. OP berhadapan dengan perangkat lunak yang memiliki dampak fisik. Bilah telah dinaikkan. Peninjau mungkin tidak menyadari "kasus tepi" ini sampai mereka melihat kode lagi. Dan diberikan cukup waktu tidak ada yang tepi kasus. Anda tidak ingin secara tidak sengaja mengayunkan lengan robot ke kepala seseorang (bukan karena saya tahu lengan robot terlibat dengan kode ini).
Greg Burghardt

11
Greg & Steve, ini adalah contoh yang bagus, tetapi ini adalah contoh bug . Ini adalah bug yang tidak jelas. Secara harfiah "bug", membaginya dengan nol. Ketika Anda bekerja pada algoritma robotika, itu adalah ide sentral yang Anda pikirkan tentang konsep yang mungkin secara fisik dan tidak mungkin secara fisik. (Jika Anda akan, "belum" konsep mungkin secara fisik, dengan perangkat saat ini.) Kebingungan antara kedua pengembang, yang sedang dibahas di sini, adalah karena mereka (sangat mengejutkan) tidak puas dengan paradigma ini. Seluruh tim mereka memiliki masalah berat jika, semakin senior dudes tidak tertanam paradigma itu.
Fattie

11
Saya pikir ada contoh dunia nyata yang membuktikan mengapa kasus tepi harus dicakup, tetapi ini bukan salah satunya. Contoh yang dikutip adalah kasus menggunakan perpustakaan yang salah untuk suatu tugas. Kode untuk pisang tidak boleh digunakan secara membuta pada jeruk. Ini adalah kesalahan orang yang menggunakan kode pisang pada jeruk, bukan orang yang menulis kode untuk jeruk yang tidak bisa menangani pisang. (Saya harus mengganti Apple untuk Banana dalam analogi ini karena perusahaan teknologi besar di luar sana ...)
Origin

51
@ JoBlow Bug, ya, tapi salah satu yang bisa dicegah , yang bisa saja tertangkap dengan kasus uji tambahan dan / atau ulasan kode. Hanya Tuhan yang tahu jika ada seorang lelaki di sana pada suatu titik mengatakan, "Kamu tahu, saya pikir kita harus memvalidasi kisaran ini ..." dan yang lain mengatakan, "Jangan khawatir tentang itu ... apa yang mungkin salah dengan sebuah kasus yang mustahil ? " Jika bug tidak cukup bukti bahwa logika kita memiliki lebih banyak celah daripada yang kita inginkan, maka saya tidak tahu harus berkata apa ...
code_dredd

30
Poin yang saya coba sampaikan adalah bahwa Anda tidak boleh mengabaikan kasus uji karena tidak pernah terjadi, sangat tidak mungkin, dll., Standar yang mereka kodekan untuk memeriksa kisaran semua nilai input eksternal. Jika itu telah diuji dan ditangani maka bencana mungkin bisa dihindari. Perhatikan bahwa dalam Ariane 3 ini bukan bug tetapi gagal mengikuti standar. Ketika kode itu digunakan kembali dalam skenario yang berbeda jika gagal serempak sementara jika rentang nilai telah terpotong itu kemungkinan akan gagal dengan anggun.
Steve Barnes

84

Karena tidak ditangani sebelumnya, itu di luar jangkauan untuk usaha Anda. Anda atau kolega Anda dapat bertanya kepada manajer Anda apakah sepadan dengan upaya untuk menutupi kasus ini.


19
Saya pikir ini adalah poin kunci - meskipun mencakup kasus tambahan memang perbaikan yang berguna dan valid, tidak perlu untuk dimasukkan ke dalam PR yang ada karena alasan yang berbeda.
DeadMG

6
Apakah itu ditangani sebelumnya atau tidak juga merupakan IMO yang tidak relevan, itu sama sekali tidak ada dalam deskripsi tugas sebelumnya.
Jasper N. Brouwer

6
Untuk menggemakan sentimen ini, jawaban yang bagus untuk menarik komentar ulasan adalah "Saya akan menaikkan tiket untuk membahas itu, poin bagus." Itu mengakui bahwa 'hal' perlu dilakukan, sementara juga memungkinkan untuk diprioritaskan bersama semua pekerjaan lain yang perlu dilakukan.
Edd

17
Tidak bisa lebih tidak setuju. Fakta bahwa masalah ini mungkin tidak diangkat selama implementasi awal fitur mungkin sama mudahnya - karena kita tidak tahu secara spesifik - menjadi indikasi telah sangat beruntung sampai sekarang karena itu bisa menjadi hal yang tidak perlu. Review kode dari modifikasi yang mengubah bagaimana algoritma ini bekerja - berpotensi meningkatkan kemungkinan kasus tepi ini - adalah tepat waktu untuk memunculkan potensi masalah. Apakah itu di luar ruang lingkup harus diputuskan setelah evaluasi yang tepat tentang hal itu, tidak diputuskan dengan sedikit konteks.
Matius Baca

6
Ini saran yang mengerikan! Since it wasn't handled before, it's out of the scope for your effortakan cukup untuk menandai setiap laporan bug sebagai wontfix, dengan asumsi spec Anda cukup buruk untuk memulai dengan itu tidak mempertimbangkan kasus tepi, jika Anda bahkan memiliki spec yang tepat.
Filip Haglund

53

Dengan algoritma yang kompleks, sangat sulit untuk membuktikan bahwa Anda telah memikirkan setiap test case yang akan muncul di dunia nyata. Ketika Anda sengaja meninggalkan ujian rusak karena tidak akan muncul di dunia nyata, Anda berpotensi meninggalkan lain uji kasus rusak yang Anda bahkan belum memikirkan belum.

Efek lain yang sering terjadi adalah ketika Anda menangani kasus uji tambahan, algoritme Anda menjadi lebih umum, dan karena itu Anda menemukan cara untuk menyederhanakannya dan membuatnya lebih kuat untuk semua kasus uji Anda. Ini menghemat waktu Anda dalam perawatan dan pemecahan masalah di jalan.

Juga, ada beberapa kasus bug "ini seharusnya tidak pernah terjadi" yang terjadi di alam liar. Itu karena algoritme Anda mungkin tidak berubah, tetapi inputnya mungkin berubah bertahun-tahun ketika tidak ada yang ingat tentang kasus penggunaan yang tidak tertangani ini. Itu sebabnya pengembang yang berpengalaman menangani hal-hal semacam ini ketika mereka masih segar dalam ingatan mereka. Kembali menggigit Anda nanti jika tidak.


7
Anda membuat poin yang sangat bagus di paragraf kedua Anda. Saya pernah mengalaminya sebelumnya, tetapi mengartikulasikannya sangat membantu.
Klik

7
Kasus ketiga = bingo. Saya bekerja sebagian besar dalam kode warisan, dan ada proyek-proyek di mana 80% dari pekerjaan itu hanya memperbaiki tempat-tempat yang membuat asumsi. Saya suka jawaban ini, tetapi saya akan menambahkan bahwa kadang-kadang tidak apa-apa untuk menutup kasus tepi yang mustahil dengan menyiapkan kegagalan anggun dengan pesan kesalahan yang tepat dan terperinci, terutama ketika Anda berada dalam krisis waktu.
Jeutnarg

Saya suka mencatat pengecualian yang mengatakan "[Deskripsi kesalahan] Menurut spesifikasi [versi] yang ditandatangani oleh [orang yang menandatanganinya] ini tidak dapat terjadi."
Peter Wone

Tetapi karena tidak ada test case untuk itu sebelumnya, kode (dengan asumsi spesifikasi menggantikan yang sebelumnya) tidak harus cocok dengan test case baru dalam iterasi itu. Dan jika tidak ada tes untuk kasus sudut itu sudah harus tiket / tugas baru yang harus dilakukan, bukan imo ulasan tinjauan kode.
kb.

38

Ini bukan pertanyaan teknis tetapi keputusan strategi bisnis. Anda perhatikan perbaikan yang disarankan adalah untuk kasus yang sangat tidak jelas yang hampir tidak akan pernah terjadi. Di sini ada perbedaan besar jika Anda memprogram mainan atau jika Anda memprogram mengatakan peralatan medis atau drone bersenjata. Konsekuensi dari kerusakan yang jarang terjadi akan sangat berbeda.

Ketika melakukan tinjauan kode, Anda harus menerapkan pemahaman dasar tentang prioritas bisnis ketika memutuskan berapa banyak investasi untuk menangani kasus yang jarang terjadi. Jika Anda tidak setuju dengan kolega Anda dalam penafsiran Anda tentang prioritas bisnis, Anda mungkin ingin berdiskusi dengan seseorang di sisi bisnis.


5
Tepat, tanyakan orang lain apakah itu layak untuk ditanggung. Setidaknya saya akan menulis test case dan menandainya sebagai "dilewati" dengan komentar yang mengatakan bahwa orang lain membuat keputusan bahwa itu tidak layak untuk diterapkan. CYA
Sean McSomething

2
Ya, setiap kali sesuatu yang besar, di luar ruang lingkup tetapi tidak mendesak muncul dalam tinjauan kode, kita cenderung membuat masalah untuk itu di pelacak kita dan kemudian memprioritaskannya di samping hal-hal lain yang perlu kita selesaikan. Kadang-kadang ini berarti bahwa tugas dibuang ke ujung daftar prioritas, tetapi jika itu masalahnya maka itu benar-benar tidak penting.
Tacroy

1
"Ini bukan peluangnya, ini taruhannya!"
user1068

2
Ini jawaban terbaik. Pertanyaannya sebenarnya tentang menetapkan prioritas dan mengelola risiko.
wrschneider

Saya setuju dengan ini menjadi keputusan bisnis. Buat tiket dengan perkiraan waktu yang Anda butuhkan untuk memperbaikinya, tetapkan ke atasan Anda (siapa pun yang bertanggung jawab atas alokasi waktu Anda), dan minta tiket diberikan prioritas (atau ditolak, sesuai kasus) mungkin)
Matija Nalis

21

Ulasan kode tidak sepenuhnya tentang kebenaran kode. Pada kenyataannya, itu cukup jauh di bawah daftar manfaat, di belakang berbagi pengetahuan dan menjadi proses lambat tapi stabil menuju terciptanya konsensus gaya / desain tim.

Seperti yang Anda alami, apa yang dianggap sebagai "benar" sering dapat diperdebatkan, dan setiap orang memiliki sudut pandang sendiri tentang apa itu. Dalam pengalaman saya, waktu dan perhatian yang terbatas juga dapat membuat ulasan kode sangat tidak konsisten - masalah yang sama mungkin diambil atau tidak tergantung pada pengembang yang berbeda dan pada waktu yang berbeda oleh pengembang yang sama. Peninjau dalam pola pikir "apa yang akan meningkatkan kode ini?" akan sering menyarankan perubahan yang tidak akan mereka tambahkan pada upaya mereka sendiri secara alami.

Sebagai seorang programmer yang berpengalaman (lebih dari 15 tahun sebagai pengembang), saya sering ditinjau oleh coders dengan pengalaman yang lebih sedikit daripada saya. Kadang-kadang mereka meminta saya untuk perubahan yang saya sedikit tidak setuju, atau berpikir tidak penting. Namun, saya masih melakukan perubahan itu. Saya berjuang melawan perubahan hanya ketika saya merasakan hasil akhirnya akan menyebabkan kelemahan pada produk, di mana biaya waktu sangat tinggi, atau di mana sudut pandang "benar" dapat dibuat objektif (misalnya perubahan yang diminta untuk dimenangkan ' t bekerja dalam bahasa yang kami gunakan, atau benchmark menunjukkan peningkatan kinerja yang diklaim bukan salah satunya).

Jadi saya sarankan memilih pertempuran Anda dengan hati-hati. Dua hari mengkodekan kasus uji yang menurut Anda tidak perlu mungkin tidak sebanding dengan waktu / upaya untuk berjuang. Jika Anda menggunakan alat ulasan, seperti permintaan tarik GitHub, maka mungkin berkomentar di sana tentang biaya / manfaat yang Anda rasakan, untuk mencatat keberatan Anda, tetapi setuju untuk tetap melakukan pekerjaan. Ini dianggap sebagai dorongan balik yang lembut, sehingga peninjau tahu bahwa mereka mencapai batas, dan yang lebih penting termasuk alasan Anda sehingga kasus seperti ini dapat meningkat jika mereka menemui jalan buntu. Anda ingin menghindari meningkatnya ketidaksepakatan tertulis - Anda tidak ingin memiliki argumen gaya forum Internet tentang perbedaan pekerjaan - jadi mungkin membantu untuk membicarakan masalah ini terlebih dahulu dan mencatat ringkasan yang adil dari hasil diskusi,diskusi ramah akan memutuskan untuk Anda berdua).

Setelah acara, ini adalah topik yang bagus untuk ulasan sprint atau rapat perencanaan tim pengembangan, dll. Sajikan dengan netral seperti yang Anda bisa mis. "Dalam ulasan kode, Pengembang A mengidentifikasi kasus uji tambahan ini, butuh dua hari ekstra untuk menulis, apakah tim berpikir bahwa pertanggungan ekstra itu dibenarkan atas biaya ini? " - pendekatan ini bekerja jauh lebih baik jika Anda benar-benar melakukan pekerjaan, karena itu menunjukkan Anda dengan cara yang positif; Anda telah melakukan pekerjaan itu, dan hanya ingin memberikan polling kepada tim untuk penghindaran risiko vs. pengembangan fitur.


2
"Presentasikan selebar mungkin", cukup. Saya akan melangkah lebih jauh dari NeilS dan menyarankan, seperti yang mereka katakan, Anda perlu menukar "kemarahan untuk bicara". Langsung saja dan katakan secara terbuka (misalnya, dalam contoh spesifik yang ada di tangan), "Steve, kasing sudut Anda non-fisik dengan desain mekanis saat ini, bukankah menurut Anda Bung? Mari kita putuskan dulu apakah itu non-fisik, dan bahkan jika itu layak menghabiskan dua hari. "
Fattie

1
"Jika Anda menggunakan alat ulasan" adalah pengamatan utama. IME, alat-alat ini memadai untuk menyimpan catatan tinjauan, tetapi pekerjaan nyata dilakukan tatap muka dengan diskusi. Ini adalah cara paling efisien untuk aliran informasi dua arah. Jika Anda tidak setuju dengan ulasan, lakukan pertentangan secara konstruktif secara langsung, dan baru kemudian masukkan hasil yang disepakati ke dalam alat.
Toby Speight

@TobySpeight: Saya setuju dan mencoba memasukkannya ke dalam jawabannya.
Neil Slater

1
2 jam adalah hal yang tidak akan saya lawan. 2 hari dan saya tidak akan bisa menyelesaikan semua tugas lain yang telah saya lakukan selama seminggu.
Matius Baca

15

Saya akan menyarankan Anda untuk setidaknya menegaskan terhadap kasus yang tidak jelas. Dengan begitu, pengembang masa depan tidak hanya melihat Anda memutuskan secara aktif terhadap kasus ini, tetapi dengan penanganan kegagalan yang baik, yang seharusnya sudah ada, ini juga akan mengejutkan.

Dan kemudian, buat test case yang menyatakan kegagalan itu. Dengan cara ini, perilaku tersebut didokumentasikan dengan lebih baik dan akan muncul dalam unit test.

Jawaban ini jelas mengasumsikan bahwa penilaian Anda terhadap makhluk "sangat tidak mungkin bahkan mungkin" benar dan kami tidak dapat menilai itu. Tetapi jika ya, dan kolega Anda setuju, maka pernyataan tegas terhadap acara tersebut harus menjadi solusi yang memuaskan bagi Anda berdua.


Setuju. Jika ada setiap kasus bahwa kode Anda tidak bisa menangani, memeriksa input sedini mungkin dan gagal di sana. "Program macet jika kita melakukan X" selalu lebih baik daripada "Robot kita membunuh orang jika kita melakukan X"
Josef

1
Saran yang bagus Kode yang baik adalah kode yang terbukti tidak pernah gagal, tetapi jika gagal, entah bagaimana gagal, gagal dengan cara yang jelas yang dapat diperbaiki. Kode yang tidak mungkin salah tetapi, jika itu salah ternyata tidak mungkin untuk mendapatkan atau memperbaiki, tidak terlalu bagus ...
leftaroundabout

Ini, saya akan memposting hal yang sama persis. Peninjau menunjukkan kemungkinan kegagalan, bagaimana mengatasinya adalah pertanyaan yang berbeda.
SH-

2
Oh, tidak, jangan tegaskan kode Anda. Jika pernyataan tidak dikompilasi, tidak ada yang akan melihatnya. Jika pernyataan dikompilasi maka robot Anda akan crash. Saya telah melihat lebih dari satu kasus di mana pernyataan untuk 'sesuatu yang tidak pernah bisa terjadi' dalam kode produksi dipicu dan menjatuhkan tidak hanya sistem itu tetapi segala sesuatu yang bergantung padanya.
Tom Tanner

@ TomTanner "dengan penanganan kegagalan yang baik, yang seharusnya sudah ada". Saya berasumsi bahwa kode sudah dapat menangani pernyataan yang gagal di sini. Yang mungkin tidak terlalu sulit, karena strategi kegagalan yang aman harus menjadi bagian dari sistem fisik apa pun.
WorldSEnder

13

Karena Anda tampaknya baru di sana, hanya ada satu hal yang dapat Anda lakukan - tanyakan kepada pemimpin tim (atau pemimpin proyek). 13 jam adalah keputusan bisnis; untuk beberapa perusahaan / tim, banyak; untuk beberapa, tidak ada. Itu bukan keputusanmu, belum.

Jika pemimpin mengatakan "tutupi kasing itu", boleh saja; jika dia mengatakan "nah, persetan", baiklah - keputusannya, tanggung jawabnya.

Sedangkan untuk ulasan kode secara umum, santai saja. Mengembalikan tugas kepada Anda sekali atau dua kali adalah hal yang normal.


7

Satu hal yang saya pikir tidak pernah saya lihat ditangani dengan baik, meskipun agak dibesarkan dalam jawaban @SteveBarnes:

Apa akibat dari kegagalan?

Di beberapa bidang, kegagalan adalah kesalahan pada halaman web. Layar biru PC dan reboot.

Di bidang lain itu hidup atau mati - mobil menyetir sendiri terkunci. Pembuat langkah medis berhenti bekerja. Atau dalam jawaban Steve: barang-barang meledak yang mengakibatkan hilangnya jutaan dolar.

Ada dunia yang berbeda dalam hal ekstrem itu.

Apakah 13 jam atau tidak untuk menutupi "kegagalan" layak pada akhirnya seharusnya tidak terserah Anda. Itu harus terserah manajemen dan pemilik. Mereka harus memiliki perasaan untuk gambaran yang lebih besar.

Anda harus bisa menebak dengan baik apa yang layak dilakukan. Apakah robot Anda hanya memperlambat atau berhenti? Performa yang menurun? Atau apakah kegagalan robot menyebabkan kerusakan moneter? Hilangnya nyawa?

Jawaban untuk pertanyaan ITULAH harus mengarahkan jawaban untuk "apakah itu layak 13 jam waktu perusahaan". Perhatikan: Saya katakan waktu Perusahaan. Mereka membayar tagihan dan akhirnya memutuskan apa yang sepadan. Manajemen Anda harus memiliki keputusan akhir.


1
Selain itu, apa akibat tanggung jawab atas cacat yang tidak diperbaiki, meskipun tidak jelas?
chux

5

Mungkin berbicara dengan orang yang bertanggung jawab untuk memprioritaskan pekerjaan? Di startup bisa jadi CTO atau pemilik produk. Dia dapat membantu menemukan apakah pekerjaan tambahan ini diperlukan dan mengapa. Anda juga bisa membawa kekhawatiran Anda selama standup harian (jika Anda memilikinya).

Jika tidak ada tanggung jawab yang jelas (misalnya pemilik produk) untuk merencanakan pekerjaan, cobalah untuk berbicara dengan orang-orang di sekitar Anda. Nanti bisa menjadi masalah bahwa semua orang mendorong produk ke arah yang berlawanan.


5

Cara terbaik untuk menangani perbedaan pendapat adalah sama, terlepas dari apakah Anda seorang pengembang junior atau pengembang senior, atau bahkan seorang CEO.

Bertindak seperti Columbo .

Jika Anda belum pernah menonton Columbo, itu adalah pertunjukan yang sangat fantastis. Columbo adalah karakter yang sangat sederhana ini - kebanyakan orang berpikir bahwa dia sedikit gila dan tidak layak untuk dikhawatirkan. Tetapi dengan tampil rendah hati, dan hanya meminta orang untuk menjelaskan dia bisa mendapatkan anak buahnya.

Saya pikir itu juga terkait dengan metode Sokrates .


Secara umum Anda ingin mengajukan pertanyaan tentang diri Anda dan orang lain untuk memastikan bahwa Anda membuat pilihan yang tepat. Bukan dari posisi, "Aku benar, kau salah," tetapi dari posisi penemuan yang jujur. Atau setidaknya yang terbaik yang Anda bisa.

Dalam kasus Anda, Anda memiliki dua ide di sini, tetapi mereka pada dasarnya memiliki tujuan yang sama: untuk membuat kode lebih baik.

Anda berada di bawah kesan bahwa skimping pada cakupan kode untuk kasus yang kemungkinan tidak mungkin (mustahil?) Mendukung pengembangan fitur lain adalah cara terbaik untuk melakukan itu.

Rekan kerja Anda mendapat kesan bahwa lebih berhati-hati dengan kasus sudut lebih berharga.

Apa yang mereka lihat yang tidak Anda lihat? Apa yang Anda lihat yang tidak mereka lihat? Sebagai pengembang junior, Anda sebenarnya berada dalam posisi yang hebat karena Anda tentu harus mengajukan pertanyaan. Dalam jawaban lain seseorang menyebutkan betapa mengejutkannya kasus sudut. Jadi Anda bisa mulai dengan, "Bantu saya mengerti - saya mendapat kesan bahwa X, Y, dan Z - apa yang saya lewatkan? Mengapa widget itu berbingkai? Saya berada di bawah kesan bahwa itu akan fintuble dalam keadaan cromulent. Will tongkat swizzle sebenarnya embiggen kuas ANZA? "

Ketika Anda mempertanyakan asumsi dan temuan Anda, Anda akan menggali, mengungkap bias, dan akhirnya mencari tahu apa tindakan yang benar.

Mulailah dengan asumsi bahwa semua orang di tim Anda sangat rasional dan mereka memiliki kepentingan tim dan produk yang terbaik, sama seperti Anda. Jika mereka melakukan sesuatu yang tidak masuk akal, maka Anda perlu mencari tahu apa yang Anda tidak tahu bahwa mereka lakukan, atau apa yang Anda tahu bahwa mereka tidak tahu.


3

13 jam bukanlah masalah besar, saya hanya akan melakukannya. Ingat Anda dibayar untuk itu. Cukup tuliskan itu sebagai "keamanan pekerjaan". Juga yang terbaik adalah menjaga karma yang baik di antara tim. Sekarang jika itu adalah sesuatu yang akan membawa Anda seminggu atau lebih, maka Anda dapat melibatkan manajer Anda dan bertanya kepadanya apakah itu penggunaan waktu Anda yang terbaik, terutama jika Anda tidak setuju dengan itu.

Namun, Anda sepertinya butuh pengaruh dalam grup Anda. Inilah cara Anda mendapatkan pengaruh: minta maaf jangan minta izin. Tambahkan item ke program sesuai keinginan Anda (dalam lingkup ofcourse, yaitu pastikan itu benar-benar menyelesaikan masalah yang diinginkan bos ..), dan beri tahu manajer atau kolega Anda setelah fakta. Jangan tanya mereka: "Apakah boleh jika saya menambahkan fitur X". Sebaliknya, tambahkan saja fitur yang Anda inginkan secara pribadi dalam program. Jika mereka kesal dengan fitur baru atau tidak setuju, boleh menghapusnya. Jika mereka menyukainya, simpanlah.

Selain itu setiap kali mereka meminta Anda untuk melakukan sesuatu, lakukan "upaya ekstra" dan tambahkan banyak hal yang mereka lupa sebutkan atau hal-hal yang akan bekerja lebih baik daripada apa yang mereka katakan. Tapi jangan tanya mereka apakah "ok" untuk bekerja ekstra. Lakukan saja dan ceritakan dengan santai kepada mereka setelah selesai. Apa yang Anda lakukan adalah melatih mereka ..

Apa yang terjadi adalah manajer Anda akan menganggap Anda sebagai "go-getter" dan akan mulai menaruh kepercayaan pada Anda, dan kolega Anda akan mulai melihat Anda sebagai pemimpin karena Anda mulai memiliki program. Dan kemudian ketika hal-hal seperti apa yang Anda sebutkan terjadi di masa depan Anda akan memiliki lebih banyak bicara karena pada dasarnya Anda adalah bintang tim dan rekan tim akan mundur jika Anda tidak setuju dengan mereka.


8
Sementara saya semua untuk programer menjadi proaktif dan tidak hanya "menerima pesanan dari atas", cara Anda menyajikan ini secara profesional tidak bertanggung jawab dan tidak etis. Anda pada dasarnya mengatakan OP harus menghabiskan waktu dan uang majikan tidak bekerja pada fitur yang diminta tetapi sebaliknya bekerja pada fitur yang dia "inginkan secara pribadi", dan kemudian menghabiskan waktu dan uang majikan menghilangkan fitur-fitur tersebut. Ini bahkan tidak memperhitungkan kemungkinan cacat yang ditambahkan atau waktu pengembang lain untuk meninjau / memelihara kode ini. Saya akan memecat pengembang dengan sikap yang Anda gambarkan, terutama yang junior.
Derek Elkins

1
Ya, Anda benar. Terutama jika insinyur pergi sendiri tanpa ada kepekaan terhadap apa visi klien. Tapi jangan menyabot apa yang saya katakan sepenuhnya - saya hanya mengatakan untuk melakukan "ekstra". Jadi itu berarti Anda menerima apa yang dikatakan bos Anda dan Anda mengembangkannya. Dan dalam perangkat lunak, itulah perbedaan antara perangkat lunak yang terlihat seperti hal sepele dan perangkat lunak yang sepertinya dibuat oleh seorang profesional. Saya tahu banyak pengembang yang melakukan "persis apa yang diperintahkan" bahkan jika apa yang mereka katakan adalah sampah total. Pengembang itu tidak pernah berarti apa-apa.

2
Ada cara bertanggung jawab untuk melakukan apa yang Anda gambarkan. Berkali-kali persyaratan meninggalkan banyak ruang dan menggunakan penilaian Anda di sana untuk menghasilkan hasil yang lebih halus (seimbang terhadap upaya, termasuk upaya pemeliharaan, untuk mencapainya) adalah hal yang baik. Mengarahkan dan memperbaiki bug secara proaktif biasanya baik-baik saja. Menghabiskan waktu Anda sendiri untuk membuat prototipe fitur yang menurut Anda adalah kepentingan perusahaan dan menyajikannya kepada tim untuk kemungkinan inklusi juga baik-baik saja. "Keinginan pribadi" Anda tidak relevan, fokus sementara Anda dibayar harus pada kepentingan bisnis.
Derek Elkins

Lihat komentar kedua saya, untuk bagaimana saya mempresentasikan apa yang saya yakini sebagai ide yang Anda coba selesaikan. Seperti yang saya katakan, masalah saya lebih pada cara Anda menyajikannya. Pengembang membutuhkan kebanggaan untuk mengetahui bahwa mereka dapat membuat keputusan yang berarti, tetapi kerendahan hati untuk mengetahui bahwa mereka (biasanya) tidak memiliki gambaran luas tentang tujuan atau prioritas bisnis. Semakin banyak pengembang senior cenderung membuat keputusan yang buruk dan lebih mungkin untuk mengetahui apa tujuan bisnis dan bagaimana bergerak ke arah mereka.
Derek Elkins

juga perhatikan bahwa komentar saya adalah untuk mereka yang ingin beralih ke tingkat pimpinan atau konsultan. Perusahaan secara khusus mempekerjakan saya untuk pendapat saya.

3

Tinjauan kode memiliki beberapa tujuan. Yang jelas Anda sadari adalah, " Apakah kode ini cocok untuk tujuan? " Dengan kata lain, apakah secara fungsional benar; apakah diuji secara memadai; apakah bagian yang tidak jelas dikomentari dengan tepat; apakah itu sesuai dengan konvensi proyek?

Bagian lain dari tinjauan kode adalah berbagi pengetahuan tentang sistem. Ini merupakan kesempatan bagi penulis dan peninjau untuk mempelajari tentang kode yang diubah dan bagaimana ia berinteraksi dengan bagian lain dari sistem.

Aspek ketiga adalah bahwa ia dapat memberikan ulasan masalah yang ada sebelum perubahan dibuat. Cukup sering, ketika meninjau perubahan orang lain, saya akan menemukan sesuatu yang saya lewatkan pada iterasi sebelumnya (cukup sering sesuatu dari saya sendiri). Pernyataan seperti, "Inilah peluang untuk membuat ini lebih kuat daripada sebelumnya," bukan kritik, dan jangan menganggapnya sebagai satu!

Tim saya saat ini menganggap peninjauan kode tidak hanya sebagai gateway atau rintangan bahwa kode harus lulus tanpa cedera sebelum melakukan, tetapi terutama sebagai kesempatan untuk diskusi yang agak terstruktur dari area fungsionalitas tertentu. Ini adalah salah satu kesempatan paling produktif untuk berbagi informasi. (Dan itu alasan yang bagus untuk membagikan ulasan di sekitar tim, daripada selalu pengulas yang sama).

Jika Anda menganggap ulasan kode sebagai kegiatan konfrontatif, itu ramalan yang terpenuhi dengan sendirinya. Jika Anda menganggapnya sebagai bagian paling kolaboratif dari pekerjaan Anda, mereka akan merangsang peningkatan berkelanjutan untuk produk Anda dan bagaimana Anda bekerja bersama. Ini membantu jika ulasan bisa jelas tentang prioritas relatif dari sarannya - ada satu mil perbedaan antara "Saya ingin komentar yang membantu di sini" dan "Ini pecah jika xpernah negatif", misalnya.

Setelah membuat banyak pernyataan umum di atas, bagaimana itu berlaku untuk situasi spesifik Anda? Saya harap sekarang jelas bahwa saran saya adalah menanggapi ulasan dengan pertanyaan terbuka, dan untuk menegosiasikan pendekatan apa yang paling bernilai. Untuk contoh kasus Anda di mana tes tambahan disarankan, maka sesuatu seperti, "Ya, kita dapat menguji untuk itu; saya perkirakan akan memakan waktu <waktu> untuk mengimplementasikan. Apakah Anda pikir manfaatnya sepadan? Dan apakah ada hal lain yang kami lakukan? dapat lakukan untuk menjamin tes tidak perlu? "


Satu hal yang mengejutkan bagi saya ketika saya membaca pertanyaan Anda: jika dibutuhkan upaya dua hari untuk menulis kasus uji baru, maka tes baru Anda adalah skenario yang sangat berbeda dengan tes yang ada (dalam hal ini mungkin memiliki banyak nilai) atau Anda telah mengidentifikasi kebutuhan untuk menggunakan kembali kode yang diperbaiki di dalam test suite.


Akhirnya, sebagai komentar umum tentang nilai ulasan kode (dan sebagai ringkasan singkat dari apa yang saya katakan di atas), saya menyukai pernyataan ini, dalam Maintainers Don't Scale oleh Daniel Vetter :

Setidaknya bagi saya, ulasan tidak hanya tentang memastikan kualitas kode yang baik, tetapi juga tentang penyebaran pengetahuan dan peningkatan pemahaman. Pada awalnya mungkin ada satu orang, penulis (dan itu tidak diberikan), memahami kode. Setelah ulasan yang baik harus ada setidaknya dua orang yang sepenuhnya memahaminya, termasuk kasus sudut.


3

Kode bisa SELALU menjadi lebih baik.

Jika Anda berada dalam tinjauan kode dan Anda tidak melihat apa pun yang mungkin lebih baik atau unit test yang mungkin menangkap bug, itu bukan kode yang sempurna, tetapi pengulas yang tidak melakukan pekerjaan mereka. Apakah Anda memilih untuk menyebutkan peningkatan itu adalah pilihan pribadi. Tetapi hampir setiap saat tim Anda melakukan peninjauan kode harus ada hal-hal yang seseorang perhatikan yang bisa lebih baik atau semua orang mungkin hanya membuang-buang waktu.

Yang mengatakan, apakah Anda bertindak berdasarkan komentar atau tidak, tergantung pada tim Anda. Jika perubahan Anda memperbaiki masalah atau menambahkan nilai yang cukup tanpa perubahan yang diterima oleh tim Anda, maka gabungkan dan masukkan komentar mereka ke dalam jaminan yang harus diatasi oleh seseorang nanti. Jika tim menemukan perubahan Anda menambah lebih banyak risiko atau kompleksitas daripada nilai maka Anda harus menyelesaikan masalah sesuai.

Ingatlah bahwa kode apa pun memiliki setidaknya satu tepi case lagi yang dapat diuji dan dapat menggunakan setidaknya satu lagi refactoring. Inilah mengapa ulasan kode paling baik dilakukan sebagai grup dengan semua orang melihat kode yang sama pada waktu yang bersamaan. Sehingga pada akhirnya semua orang dapat mencapai konsensus tentang apakah kode yang ditinjau dapat diterima (sebagaimana adanya) dan menambahkan nilai yang cukup untuk bergabung ke dalam basis komunitas atau jika hal-hal tertentu harus dilakukan sebelum ada nilai yang cukup untuk digabungkan. .

Karena Anda mengajukan pertanyaan ini, saya asumsikan Anda tidak benar-benar melakukan "tinjauan kode", tetapi malah membuat permintaan tarik atau mekanisme pengiriman lainnya agar orang lain berkomentar dengan cara yang tidak deterministik. Jadi sekarang Anda menjadi masalah manajemen dan definisi selesai. Saya kira manajemen Anda ragu-ragu dan tidak benar-benar memahami proses dan tujuan ulasan kode dan kemungkinan tidak memiliki "definisi selesai" (DOD). Karena jika mereka melakukan DOD Anda akan secara eksplisit menjawab pertanyaan ini dan Anda tidak perlu datang ke sini dan bertanya.

Bagaimana Anda memperbaikinya? Nah, minta manajer Anda untuk memberi Anda DOD dan memberi tahu Anda jika Anda harus selalu menerapkan semua komentar. Jika orang yang dimaksud adalah manajer Anda, maka jawabannya sudah jelas.


3

Pertanyaan ini bukan tentang kebajikan pemrograman defensif, bahaya kasus sudut, atau risiko bencana besar pada produk fisik. Sebenarnya ini bahkan bukan tentang rekayasa perangkat lunak sama sekali .

Yang benar-benar tentang adalah bagaimana seorang praktisi junior menangani instruksi dari seorang praktisi senior ketika junior tidak dapat setuju atau menghargainya.

Ada dua hal yang perlu Anda hargai tentang menjadi pengembang junior. Pertama, itu berarti bahwa sementara itu mungkin bahwa Anda berada di sebelah kanan, dan dia di yang salah, itu - pada keseimbangan probabilitas - tidak mungkin. Jika rekan kerja Anda membuat saran yang tidak dapat Anda lihat nilainya, Anda perlu secara serius menghibur kemungkinan bahwa Anda tidak cukup berpengalaman untuk memahaminya. Saya tidak mengerti dari pos ini.

Hal kedua yang perlu dihargai adalah bahwa mitra senior Anda disebut demikian karena ia memiliki lebih banyak tanggung jawab. Jika junior memecahkan sesuatu yang penting, mereka tidak akan mendapat masalah jika mereka mengikuti instruksi. Jika seorang senior memperbolehkan mereka untuk melanggarnya, namun - dengan tidak mengangkat masalah dalam tinjauan kode, misalnya - mereka akan benar-benar berada dalam banyak masalah.

Pada akhirnya, ini merupakan persyaratan tersirat dari pekerjaan Anda bahwa Anda mematuhi instruksi dari mereka yang dipercaya oleh bisnis untuk memimpin proyek mereka. Apakah Anda pada umumnya tidak dapat tunduk pada manula ketika ada alasan bagus untuk menghargai pengalaman mereka? Apakah Anda bermaksud untuk tidak mengikuti instruksi yang tidak dapat Anda mengerti? Apakah Anda pikir dunia harus berhenti sampai Anda yakin? Nilai-nilai ini tidak kompatibel dengan bekerja dalam tim.

Poin terakhir. Pikirkan kembali proyek yang Anda tulis enam bulan lalu. Pikirkan proyek yang Anda tulis di universitas. Lihat betapa buruknya mereka sekarang - semua bug dan desain terbalik, titik-titik buta dan abstraksi yang salah arah? Bagaimana jika saya katakan kepada Anda bahwa dalam waktu enam bulan Anda akan menghitung kekurangan yang sama dalam pekerjaan yang Anda lakukan hari ini? Apakah itu membantu menunjukkan berapa banyak titik buta dalam pendekatan Anda saat ini? Karena itulah perbedaan yang dialami oleh pengalaman.


2

terus-menerus membuat komentar pada kode saya yang menyarankan saya untuk melakukan lebih banyak pekerjaan daripada yang diperlukan.

Anda dapat memberikan rekomendasi, tetapi pada akhirnya itu bukan peran Anda untuk memutuskan apa yang perlu. Adalah tugas Anda untuk menerapkan apa yang manajemen atau (dalam hal ini pengulas Anda) putuskan adalah perlu. Jika Anda tidak setuju dengan apa yang perlu terlalu banyak atau terlalu kuat, Anda mungkin akan kehilangan pekerjaan. Konsekuensinya adalah bagian dari profesionalisme Anda untuk menerima ini dan berdamai dengannya.

Dia menyarankan agar saya menangani kasus yang tidak mungkin terjadi

Ada jawaban hebat lainnya di sini yang menunjukkan bagaimana bahkan non-bug (mis. Sesuatu yang terbukti tidak pernah gagal ) masih harus dikerjakan ulang kadang-kadang. (misalnya dalam hal membangun demi keamanan produk di masa depan, mengikuti standar, dll.) Bagian dari peran pengembang hebat adalah memiliki kepercayaan sebanyak mungkin bahwa kode Anda akan kuat dalam setiap situasi yang mungkin terjadi setiap saat, dan di masa depan -terlindungi juga, tidak hanya bekerja dalam situasi yang diuji dalam kondisi saat ini sebagian besar waktu


2

Saran untuk peninjau kode untuk meningkatkan kegunaan bisnis dari tinjauan kode Anda (Anda sebagai OP harus mengajukan perubahan seperti itu):

  • Tandai komentar Anda berdasarkan jenis. "Critical" / "Must-Do" / "Opsional" / "Perbaikan yang disarankan" / "senang memiliki" / "Aku merenung".

    Jika ini tampaknya terlalu CDO / anal / rumit, paling tidak gunakan 2 level: "Harus diperbaiki untuk lulus ulasan dan diizinkan untuk menggabungkan perubahan Anda" / "Yang lainnya".

Saran untuk menangani saran tinjauan kode yang tampaknya kurang penting untuk dibuat:

  • Buat tiket terbuka di sistem pilihan tiket Anda (mudah-mudahan tim Anda menggunakannya?), Melacak saran tersebut

  • Masukkan tiket # sebagai komentar tanggapan ke item ulasan kode jika proses Anda memungkinkan tanggapan terhadap komentar seperti Fisheye atau ulasan email lakukan.

  • Jangkau pengulas dan secara eksplisit tanyakan apakah item tersebut merupakan tipe "harus diperbaiki atau tidak akan digabung / dirilis".

    • Jika jawabannya "Ya", tetapi Anda tidak setuju, biarkan orang yang bertanggung jawab atas manajemen proyek (PM, manajer Anda, dll ...) membuat keputusan - tunjukkan ketidaksepakatan sepenuhnya dan jujur. Ini bukan tentang siapa di antara Anda yang "benar" tetapi tentang apa yang lebih baik untuk proyek ini, jadi pekerjaan PM / manajer.

Sekarang, perlakukan tiket itu sebagai permintaan pengembangan lainnya.

  1. Jika diputuskan akan mendesak setelah eskalasi, perlakukan itu sebagai permintaan dev yang mendesak. Merampas pekerjaan lain dan kerjakan ini.

  2. Kalau tidak, kerjakan sesuai prioritas yang ditugaskan dan ROI-nya (yang bisa berbeda berdasarkan lini bisnis Anda seperti yang dijelaskan dalam jawaban lain).


2

Anda tidak harus meningkatkan ini ke manajemen.

Di sebagian besar perusahaan, manajemen akan selalu memilih untuk tidak menulis tes tambahan itu, untuk tidak menghabiskan waktu sedikit meningkatkan kualitas kode, untuk tidak kehilangan waktu refactoring.

Dalam banyak kasus, kualitas kode tergantung pada aturan tidak tertulis dalam tim pengembangan dan pada upaya ekstra yang dilakukan oleh para programmer.

Anda adalah pengembang junior dan ini adalah tinjauan kode pertama Anda . Anda harus menerima saran dan melakukan pekerjaan. Anda hanya dapat meningkatkan alur kerja dan aturan di tim Anda jika Anda pertama kali tahu dan menghargainya untuk sementara waktu sehingga Anda bisa mengerti mengapa mereka ada di sana. Kalau tidak, Anda akan menjadi pria baru yang tidak menghormati aturan dan menjadi satu-satunya serigala tim.

Anda baru di tim, ikuti saran yang Anda dapatkan untuk sementara waktu, cari tahu mengapa mereka ada di sana, jangan membawa saran pertama yang Anda pertanyakan dalam rapat scrum. Prioritas bisnis nyata akan jelas bagi Anda setelah beberapa saat tanpa bertanya (dan mungkin bukan apa yang akan dikatakan oleh manajemen kepada Anda secara langsung).


Sayangnya saat Anda memulai dengan baik rekomendasi Anda akhirnya menjadi sangat buruk.
Joshua

1

Sangat penting bagi Anda untuk membuat kode yang memenuhi permintaan pimpinan / manajemen Anda. Detail lainnya hanya akan menjadi "menyenangkan untuk dimiliki". Jika Anda seorang ahli (baca bahwa: "jika Anda bukan pengembang junior") di bidang Anda, maka Anda "berhak" untuk mengatasi masalah kecil yang Anda temukan di sepanjang jalan tanpa berkonsultasi dengan pemimpin Anda setiap saat.

Jika Anda berpikir ada sesuatu yang salah dan Anda relatif ahli dalam bidang Anda, maka kemungkinan besar Anda benar .

Berikut adalah beberapa pernyataan yang dapat bermanfaat bagi Anda:

  • Saya diminta untuk melakukan X, peninjau kode menyarankan juga melakukan Y, haruskah saya melakukannya atau haruskah saya beralih ke hal-hal yang lebih penting?
  • Anda menyarankan Y kepada saya, jadi bisakah Anda mencari tahu setidaknya satu kasus uji yang akan menangkap perilaku itu sehingga saya bisa mengujinya? Saya percaya kode itu tidak akan dipanggil.
  • Mungkin sebaiknya kita mengembangkan fallback yang aman untuk kasus yang tidak ditemukan terlebih dahulu? Jadi kami menangkap mereka lebih awal dan memperbaiki saat bepergian sehingga kami dapat fokus pada hal-hal yang lebih penting.
  • OKE, ketika saya sedang mengimplementasikan Y, bisakah Anda berbaik hati menulis beberapa test case untuknya sehingga kami menyelesaikannya sekali dan untuk selamanya ?
  • Saya diminta untuk melakukan X, dan saya pikir saya bisa melakukan Y kecuali ada prioritas lain. Lain kali mengapa Anda tidak mengajukan permintaan fitur daripada meletakkannya sebagai ulasan komentar pada kode saya ? Setidaknya kita dapat mendengar pendapat lebih lanjut dari anggota tim lain tentang fitur itu sebelum mengimplementasikannya (umumnya hal-hal penting harus menjadi fitur dan harus ditangani oleh lebih dari satu orang; biasanya tinjauan kode harus tentang meninjau kode dan pendekatan solusi; sisanya adalah perbaikan bug dan fitur).

Apakah Anda benar-benar berpikir bahwa sikap pengkaji Anda merusak proyek atau apakah menurut Anda ia paling benar (kecuali mungkin kadang-kadang ia hanya membuat kesalahan kecil dalam evaluasi dan melebih-lebihkan itu)?

Bagi saya itu terdengar seperti dia menulis hal-hal yang tidak termasuk dalam tinjauan kode, yang merupakan praktik buruk karena membuat semua orang lebih sulit untuk melacak hal-hal. Namun saya tidak tahu komentar komentar apa yang dia buat, jadi saya tidak bisa mengatakan apa-apa tentang kasus lain.

Secara umum, cobalah untuk menghindari kedua hal berikut:

  • Anda tidak melakukan apa yang diminta
  • Anda membuat pengulas Anda merasa bodoh

Jika dia benar-benar meninjau kode Anda, itu karena manajemen lebih memercayainya daripada Anda.


-1

Ketika ada perbedaan pendapat selama tinjauan kode tentang ruang lingkup:

  1. Dokumentasikan ruang lingkup yang sebenarnya tercakup oleh kode. Tidak ada yang suka kejutan yang tidak menyenangkan.
  2. Sadarilah bahwa ruang lingkup adalah keputusan bisnis. Lingkup seharusnya sudah diketahui pada saat Anda mulai bekerja pada suatu fitur, tetapi jika tidak, Anda selalu dapat meminta klarifikasi nanti.

Jika peninjau kode adalah yang membuat keputusan bisnis, ia dapat mengubah ruang lingkup kapan saja, bahkan selama peninjauan kode, tetapi ia tidak melakukannya dalam perannya sebagai peninjau kode.


ini tampaknya tidak menawarkan sesuatu yang substansial atas poin yang dibuat dan dijelaskan dalam 20 jawaban sebelumnya
nyamuk

-1

Jika Anda tidak dapat membuktikan bahwa tepi case tidak mungkin, Anda harus menganggap itu mungkin. Jika mungkin, maka tidak terhindarkan bahwa itu pada akhirnya akan terjadi, dan lebih cepat daripada nanti. Jika kasus tepi tidak terjadi dalam pengujian, itu mungkin petunjuk bahwa cakupan pengujian tidak lengkap.

  1. Terima umpan baliknya.
  2. Sebelum membuat perubahan apa pun pada kode Anda, cobalah yang terbaik untuk membuat tes untuk case tepi dan lihat apakah Anda bisa mendapatkan kegagalan tes (bukti bahwa masalah itu ada). Jika tidak mungkin membuat case uji dan gagal tes, maka Anda mungkin dapat menyimpulkan bahwa case edge sebenarnya tidak mungkin (walaupun saya ragu untuk menarik kesimpulan seperti itu).
  3. Jika Anda bisa mendapatkan kegagalan tes, terapkan perubahan kode yang sesuai untuk lulus tes.

Demi kebaikan produk, Anda mungkin ingin dapat menghasilkan kasing tepi dan menyebabkan kegagalan, sehingga Anda dapat menerapkan perbaikan dan memiliki keyakinan bahwa masalah potensial telah dihindari.

Inti dari ulasan kode adalah untuk memberi perhatian tambahan pada kode. Tak satu pun dari kita yang kebal dari kesalahan atau kekeliruan. Terlalu umum untuk melihat sepotong kode berkali-kali dan tidak melihat kesalahan yang jelas, di mana sepasang mata yang baru dapat langsung mengambilnya.

Seperti yang Anda katakan, Anda telah menerapkan algoritma baru. Tidaklah bijak untuk menarik kesimpulan tentang perilaku algoritma baru Anda berdasarkan perilaku atau pengamatan tentang pendahulunya.


ini tampaknya tidak menawarkan sesuatu yang substansial atas poin yang dibuat dan dijelaskan dalam 21 jawaban sebelumnya
nyamuk

-2

Ada peninjau kode yang tahu apa yang mereka lakukan, dan jika mereka mengatakan sesuatu perlu diubah, maka perlu diubah, dan ketika mereka mengatakan sesuatu perlu diuji, maka perlu diuji.

Ada peninjau kode yang perlu membenarkan keberadaan mereka sendiri dengan menciptakan karya yang tidak berguna untuk orang lain.

Yang mana yang harus Anda putuskan, dan bagaimana menangani jenis kedua lebih merupakan pertanyaan untuk tempat kerja.

Jika Anda menggunakan scrum, maka pertanyaannya adalah apakah pekerjaan Anda melakukan apa yang seharusnya dilakukan (ternyata memang demikian), dan Anda dapat menempatkan penanganan kasus yang sangat jarang dan mungkin tidak mungkin pada jaminan, di mana itu akan diprioritaskan, dan jika masuk ke sprint, maka reviewer Anda dapat merasa bebas untuk mengambilnya dan melakukan pekerjaan 13 jam. Jika Anda melakukan pekerjaan X dan karena Anda melakukan pekerjaan X Anda menyadari pekerjaan Y juga perlu dilakukan, maka pekerjaan Y tidak menjadi bagian dari pekerjaan X, itu adalah pekerjaan independennya sendiri.


6
Ini terlalu samar dan emosional untuk menjadi nasihat yang bermanfaat.
Robert Harvey

Pernyataan tentang SCRUM sepenuhnya benar, juts membuat tugas baru di backlog. Hapus awal jawaban Anda yang kasar dan Anda akan menerima skor positif.
xmedeko
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.