Peninjau harus objektif.
Jelas bahwa Anda telah membentuk pendapat tentang kode yang dipermasalahkan bahkan sebelum Anda meninjaunya, dan sepertinya Anda dan pemecah masalah telah mempertaruhkan posisi. Jika demikian, maka Anda akan mengalami kesulitan untuk tampil objektif, dan bahkan lebih sulit lagi menjadi objektif. Tidak ada yang membantu prosesnya, dan mungkin hal terbaik dan paling obyektif yang dapat Anda lakukan adalah mengundurkan diri dengan alasan Anda terlalu dekat dengan masalah tersebut.
Pertimbangkan pendekatan tim.
Jika Anda tidak dapat menghapus diri sendiri, mungkin Anda dapat meminta beberapa insinyur lain meninjau kode secara bersamaan. Entah mereka akan setuju dengan Anda bahwa kode tersebut harus ditolak atau tidak. Jika mereka setuju dengan Anda, maka itu tidak lagi hanya Anda vs pemecah masalah, dan Anda akan dapat membuat kasus yang lebih kuat bahwa tim melihat perbaikan secara objektif dan memutuskan untuk tidak menerimanya. Di sisi lain, jika mereka memutuskan untuk menerima perbaikan maka itu juga akan menjadi keputusan tim. Itu harus berjalan tanpa mengatakan bahwa Anda harus berpartisipasi dengan pikiran yang terbuka seperti yang Anda bisa kelola, dan bahwa Anda tidak boleh mencoba untuk mempengaruhi pendapat anggota tim lain dengan apa pun selain diskusi rasional. Penting: jika ada hasil yang buruk nanti, jangan lempar tim ke bawah bus dengan mengatakan "Ya, saya selalu mengatakan itu kode yang buruk, tetapi saya kalah jumlah dengan anggota tim lainnya. "
Penolakan adalah bagian alami dari proses peninjauan kode.
Proses peninjauan kode tidak ada untuk memperbaiki stempel karet dari orang yang lebih senior; itu ada di sana untuk melindungi dan meningkatkan kualitas kode. Tidak ada yang salah dengan menolak perbaikan asalkan Anda melakukannya karena alasan yang benar, yaitu bahwa perbaikan tidak meningkatkan kode. Jika, setelah peninjauan terbuka terhadap kode, Anda masih merasa bahwa perbaikan tidak mengurangi risiko dan / atau besarnya masalah yang dapat dibuktikan, maka Anda harus menolaknya. Ini bukan pribadi, hanya pendapat jujur Anda. Jika fixer tidak setuju, tidak apa-apa juga, dan pada saat itu menjadi masalah bagi manajemen untuk mencari tahu. Pastikan untuk tetap jujur, terbuka, dan profesional.
Tanggung jawab memotong kedua cara.
Anda mengatakan bahwa Anda tidak ingin bertanggung jawab atas perubahan ini, tampaknya karena Anda tidak percaya bahwa ada masalah. Namun, Anda perlu menyadari bahwa jika Anda salah dan ada adalah masalah, maka Anda mungkin berakhir menjadi bertanggung jawab untuk menolak kode yang akan menghindari masalah.
Ambil catatan.
Menyimpan catatan tertulis dari proses peninjauan akan membantu Anda menjaga fakta tetap benar. Tuliskan pikiran dan kekhawatiran Anda saat meninjau, menguraikan, dan hasil dari setiap tes yang mungkin Anda jalankan untuk mengukur dugaan masalah dan perbaikannya, dll. Jika masalah ini meningkat, Anda akan memiliki catatan tentang apa yang telah Anda lakukan untuk mendukung Anda posisi. Jika masalah muncul lagi di masa mendatang (mungkin akan terjadi jika fixer melekat pada pandangannya sendiri), Anda akan memiliki sesuatu untuk mengacaukan memori Anda.