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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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).

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).

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.

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.

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.

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.