Code Review Ethics #

Ada dua tim engineering yang keduanya melakukan code review untuk setiap PR. Tim pertama: review berlangsung cepat, komentar mengalir, diskusi teknis terjadi, dan engineer merasa lebih pintar setelah setiap review — baik sebagai author maupun reviewer. Tim kedua: review terasa seperti sidang, author menjadi defensif membaca komentar, reviewer merasa review mereka diabaikan, dan lama-kelamaan orang mulai menghindari memberikan feedback yang bermakna karena takut konflik.

Perbedaan antara keduanya bukan pada tooling, bukan pada proses formal, dan bukan pada seberapa senior engineer di tim. Perbedaannya ada pada etika — seperangkat prinsip dan perilaku yang menentukan apakah proses code review menjadi alat kolaborasi yang kuat atau sumber gesekan yang mengikis kepercayaan.

Code review adalah proses teknis sekaligus proses sosial. Komentar yang secara teknis benar bisa tetap merusak jika disampaikan dengan cara yang merendahkan. Feedback yang berniat baik bisa tetap memicu defensifitas jika framing-nya salah. Dan budaya review yang tidak sehat bisa membuat engineer berbakat memilih diam daripada berkontribusi — yang pada akhirnya merugikan seluruh tim.

Artikel ini membahas etika code review: mengapa ia penting, bagaimana pola yang tidak etis muncul dan merusak, dan bagaimana membangun kondisi di mana code review bisa menjadi yang seharusnya — investasi bersama dalam kualitas sistem dan pertumbuhan tim.

Mengapa Etika Menentukan Keberhasilan Code Review #

Kualitas teknis sebuah review tidak hanya ditentukan oleh akurasi komentar yang diberikan, tapi juga oleh kemungkinan bahwa komentar tersebut akan diterima, dipertimbangkan, dan menghasilkan perubahan yang baik. Komentar yang benar tapi disampaikan dengan cara yang merendahkan memiliki kemungkinan lebih kecil untuk menghasilkan diskusi yang produktif dibanding komentar yang mungkin kurang presisi tapi disampaikan dengan rasa hormat.

graph LR
    subgraph Tidak Etis
        A1[Komentar merendahkan] --> B1[Author defensif]
        B1 --> C1[Diskusi tidak produktif]
        C1 --> D1[Engineer enggan beri feedback]
        D1 --> E1[Review jadi formalitas]
        E1 --> F1[Kualitas kode menurun]
        F1 --> A1
    end

    subgraph Etis
        A2[Komentar menghormati] --> B2[Author terbuka]
        B2 --> C2[Diskusi teknis berkualitas]
        C2 --> D2[Kedua pihak belajar]
        D2 --> E2[Review terasa bernilai]
        E2 --> F2[Budaya kolaborasi tumbuh]
        F2 --> A2
    end

Siklus di atas menunjukkan sesuatu yang penting: etika dalam code review adalah investasi jangka panjang. Satu komentar yang merendahkan mungkin tidak langsung merusak hubungan kerja, tapi pola ini yang terakumulasi — reviewer yang konsisten merendahkan, author yang konsisten defensif — mengubah code review dari mekanisme peningkatan kualitas menjadi sumber stres yang ingin dihindari semua orang.

Lima Pola yang Merusak Etika Code Review #

1. Review sebagai Ajang Superioritas #

Ini adalah pola yang paling merusak budaya tim. Reviewer menggunakan posisinya sebagai penjaga gerbang untuk mendemonstrasikan pengetahuan teknis mereka — bukan untuk membantu meningkatkan kualitas kode. Komentar bernada “seharusnya kamu tahu ini” atau “ini basic banget” menciptakan hierarki yang merusak psikologis engineer yang lebih junior.

Perbandingan komentar — superioritas vs kolaboratif:

  Situasi: author menggunakan for loop di mana functional approach lebih idiomatis

  ✗ Superioritas:
  "Masa gini aja nggak tahu? Ini harusnya pakai map/filter."
  → Merendahkan, tidak menjelaskan mengapa, tidak mengajarkan

  ✗ Superioritas halus:
  "Kenapa nggak pakai cara yang lebih modern?"
  → Implisit merendahkan tanpa penjelasan, author harus menebak

  ✓ Kolaboratif:
  "Pertimbangkan menggunakan map() di sini — lebih ekspresif dan
   lebih konsisten dengan cara kita menulis transformasi data di
   file lain. Ini contoh singkatnya: [contoh kode]
   Apakah ada alasan kamu memilih loop di sini?"
  → Menjelaskan mengapa, memberikan contoh, membuka dialog

2. Nitpicking yang Berlebihan #

Reviewer yang menghabiskan energi utama untuk mengomentari hal-hal trivial — spasi, naming yang sudah cukup jelas, atau preferensi style yang tidak ada di guideline — sementara melewatkan masalah arsitektur atau logika yang lebih penting. Ini bukan hanya buang waktu; ini juga mengirim sinyal bahwa hal-hal kecil lebih penting dari substansi.

Contoh nitpicking yang tidak proporsional:

  PR: Implementasi payment retry mechanism (200 baris)
  Komentar yang diterima author:
  1. "Nama variabel 'retryCount' sebaiknya 'retryAttempts'"
  2. "Ada spasi ekstra di baris 47"
  3. "Prefer single quote daripada double quote"
  4. Tidak ada komentar tentang: tidak ada jitter di backoff,
     tidak ada circuit breaker, tidak ada metric untuk retry rate

  Yang terjadi:
  → Author menghabiskan waktu untuk mengganti 3 hal trivial
  → Bug performa dan keandalan sistem lolos tanpa diperhatikan
  → Proses review terasa seperti spell-checker, bukan quality gate

Aturan sederhana: jika komentar kamu tidak mempengaruhi correctness, keamanan, atau maintainability secara signifikan, tanyakan pada diri sendiri apakah komentar itu layak disampaikan. Jika ya, tandai eksplisit sebagai [nitpick] agar author tahu ini bukan blocking issue.

3. Memaksakan Preferensi Personal #

“Saya lebih suka cara ini” bukan dasar yang valid untuk memblokir merge. Preferensi personal yang tidak didukung oleh guideline tim, alasan teknis yang jelas, atau data adalah bentuk kekuasaan yang disalahgunakan.

Preferensi personal vs alasan teknis yang valid:

  ✗ Preferensi personal yang tidak valid sebagai blocking:
  "Saya lebih suka async/await daripada promise chaining"
  "Biasanya saya tulis if-else bukan ternary untuk kasus seperti ini"
  "Menurut saya singleton pattern lebih clean di sini"
  → Semua ini adalah preferensi yang bisa valid tapi tidak seharusnya
    memblokir merge jika tidak ada guideline yang menyatakannya

  ✓ Alasan teknis yang valid:
  "Kita sudah sepakat di ADR-023 untuk menggunakan async/await
   demi konsistensi di seluruh codebase"
  "Ternary di sini menjadi sulit dibaca karena kondisinya kompleks —
   if-else lebih jelas untuk kasus ini karena..."
  "Singleton di sini membuat unit testing sulit karena state global.
   Dependency injection lebih testable karena..."
  → Didukung oleh keputusan tim atau alasan teknis yang bisa dikritik

4. Review tanpa Membaca Konteks #

Reviewer yang langsung membuka tab “Files changed” tanpa membaca deskripsi PR, tiket, atau RFC yang terkait — lalu memberikan komentar yang tidak relevan dengan masalah yang sedang diselesaikan. Ini bukan hanya tidak efektif; ini juga membuang waktu author yang harus menjelaskan konteks yang seharusnya sudah tersedia.

Dampak review tanpa konteks:

  PR: "feat: implement idempotent payment processing using Redis"
  Deskripsi: menjelaskan masalah double charge yang terjadi, pendekatan
  idempotency key dengan Redis, dan mengapa Redis dipilih daripada DB

  Komentar tanpa membaca konteks:
  "Kenapa pakai Redis? Kan bisa langsung di database saja"
  → Pertanyaan ini sudah dijawab di deskripsi PR
  → Author harus menjelaskan ulang sesuatu yang sudah ditulis
  → Frustrasi karena reviewernya tidak membaca

  Komentar setelah membaca konteks:
  "Sudah baca tentang pendekatan idempotency key-nya. Satu hal yang
   perlu dipertimbangkan: bagaimana jika Redis down? Apakah ada
   fallback atau apakah kita accept risiko ini?"
  → Pertanyaan yang relevan dan menambah nilai

5. Approve Tanpa Review yang Bermakna #

“LGTM” yang diberikan tanpa benar-benar membaca kode adalah bentuk ketidakjujuran dalam proses review. Ini menciptakan false sense of security — author merasa PR sudah divalidasi, padahal tidak. Ketika bug kemudian muncul di produksi, tidak ada yang bisa dipercaya sudah melihatnya.

Tanda-tanda approve yang tidak bermakna:

  ✗ LGTM dalam 2 menit untuk PR 400 baris
  ✗ Approve tanpa satu pun komentar pada PR yang kompleks
  ✗ "Looks good, minor nitpick" lalu approve tanpa memeriksa logika
  ✗ Approve karena tekanan deadline, bukan karena sudah direview

  Konsekuensi:
  → Bug masuk ke produksi yang seharusnya tertangkap
  → Reviewer tidak bisa dipercaya sebagai quality gate
  → Code review kehilangan nilainya sebagai mekanisme kontrol kualitas

Prinsip Etika yang Membangun Kultur Sehat #

Asumsikan Niat Baik (Charitable Interpretation) #

Setiap engineer yang membuat PR melakukannya dengan niat baik — mereka ingin menyelesaikan masalah, bukan sengaja menulis kode yang buruk. Ketika kamu melihat kode yang terlihat salah, pertanyaan pertama yang harus muncul bukan “kenapa dia melakukan ini?” tapi “apa yang mungkin dia pikirkan ketika menulis ini?”

Charitable interpretation dalam praktik:

  Situasi: author menggunakan approach yang tampak over-engineered

  Interpretasi negatif (tidak etis):
  "Dia pasti tidak memikirkan ini dengan benar"
  → Langsung menghakimi tanpa memahami konteks

  Charitable interpretation (etis):
  "Mungkin ada constraint atau requirement yang saya tidak tahu
   yang membuat approach ini masuk akal. Saya perlu bertanya."
  → Membuka dialog: "Saya perhatikan pendekatan ini cukup kompleks —
     ada constraint tertentu yang membuatnya diperlukan?
     Kalau tidak, mungkin ada yang lebih sederhana..."

Pisahkan “Kode Buruk” dari “Orang Buruk” #

Kode yang tidak optimal bukan cerminan dari kemampuan atau karakter seseorang secara permanen. Semua engineer pernah menulis kode yang tidak optimal — karena tekanan waktu, karena kurang konteks, atau karena belum tahu cara yang lebih baik. Feedback yang baik menunjukkan jalan menuju kode yang lebih baik, bukan menjadikan kualitas kode saat ini sebagai penilaian terhadap orangnya.

Bahasa yang memisahkan kode dari orang:

  ✗ Bahasa yang menyerang orangnya:
  "Kamu seharusnya tahu ini tidak aman"
  "Ini approach yang naif"
  "Kamu tidak memikirkan edge case ini"

  ✓ Bahasa yang fokus ke kodenya:
  "Bagian ini berpotensi rentan terhadap race condition jika..."
  "Pendekatan ini belum mempertimbangkan kasus ketika..."
  "Ada edge case yang perlu ditangani di sini: ketika X terjadi, Y..."

Berikan Konteks, Bukan Sekadar Instruksi #

Komentar “ganti ini dengan X” tidak mengajarkan apapun. Komentar yang menjelaskan mengapa perubahan diperlukan, apa konsekuensi dari pendekatan saat ini, dan bagaimana alternatifnya lebih baik — itu adalah komentar yang membangun kemampuan author untuk membuat keputusan yang lebih baik di masa depan.

Instruksi vs penjelasan kontekstual:

  Situasi: author tidak menggunakan parameterized query

  ✗ Instruksi tanpa konteks:
  "Gunakan prepared statement."

  ✓ Penjelasan kontekstual:
  "String concatenation langsung di query ini rentan SQL injection —
   jika email mengandung karakter seperti ' atau --, query bisa dimanipulasi.
   Gunakan parameterized query:

   // ANTI-PATTERN saat ini:
   db.query('SELECT * FROM users WHERE email = ' + email)

   // BENAR:
   db.query('SELECT * FROM users WHERE email = ?', [email])

   Ini juga lebih efisien karena query plan bisa di-cache oleh database."

Hormati Batasan Waktu Author #

Tidak semua feedback perlu ditindaklanjuti segera. Saran yang bagus tapi tidak perlu dilakukan sebelum merge seharusnya ditandai dengan jelas sebagai non-blocking — dan reviewer tidak boleh menahan approve hanya karena ada saran yang belum diimplementasi.

Membedakan priority feedback:

  [blocking] — harus diselesaikan sebelum merge:
  Bug logika, security vulnerability, atau pelanggaran arsitektur serius.
  "Ini akan menyebabkan data loss jika transaction di-rollback."

  [suggestion] — sangat disarankan, bisa ditindaklanjuti di PR berikutnya:
  "Pertimbangkan mengekstrak logika ini ke fungsi terpisah untuk readability
   yang lebih baik. Tidak perlu di PR ini, tapi worth noting."

  [nitpick] — preferensi minor, tidak perlu ditindaklanjuti:
  "[nitpick] 'processData' bisa lebih deskriptif, tapi ini minor."

  Dengan label yang jelas, author bisa memprioritaskan waktunya
  dan tidak merasa semua komentar harus diselesaikan segera.

Psychological Safety dalam Code Review #

Psychological safety — kondisi di mana seseorang merasa aman untuk mengambil risiko interpersonal seperti berbicara, mengajukan pertanyaan, atau membuat kesalahan tanpa takut dipermalukan — adalah fondasi dari code review yang efektif.

Tim dengan psychological safety yang tinggi memiliki engineer yang:

  • Tidak takut mengajukan PR karena khawatir dikritik
  • Berani menunjukkan ketidaktahuan lewat pertanyaan di komentar
  • Bisa tidak setuju dengan reviewer senior tanpa takut konsekuensi
  • Mau memberikan feedback jujur tanpa khawatir merusak hubungan

Tim tanpa psychological safety memiliki pola yang berbeda:

  • PR dibuat besar-besar karena enggan sering kena review
  • Author setuju dengan semua komentar tanpa benar-benar memahaminya
  • Reviewer menahan feedback yang mungkin menimbulkan konflik
  • Code review menjadi ritual tanpa substansi
flowchart TD
    A{Psychological Safety\ndalam Review}

    A --> |Tinggi| B[Engineer berani submitting PR\nberukuran kecil dan sering]
    B --> C[Review lebih cepat dan fokus]
    C --> D[Feedback lebih sering, lebih spesifik]
    D --> E[Engineer tumbuh lebih cepat]
    E --> F[Tim lebih produktif]

    A --> |Rendah| G[Engineer menghindari review\natau buat PR besar jarang]
    G --> H[Review jarang dan berat]
    H --> I[Feedback langka dan permukaan]
    I --> J[Engineer tumbuh lambat]
    J --> K[Tim defensif dan kurang inovatif]

Membangun psychological safety bukan proyek besar — ia dibangun dari setiap interaksi kecil. Satu komentar yang merendahkan bisa merusak kepercayaan yang dibangun dalam banyak review yang baik. Satu apresiasi yang tulus bisa mendorong engineer junior untuk lebih berani berkontribusi.

Menghadapi Disagreement secara Konstruktif #

Disagreement dalam code review adalah hal yang sehat — itu artinya ada perspektif yang berbeda yang layak dipertimbangkan. Yang menentukan apakah disagreement itu produktif atau merusak adalah cara keduanya dihadapi.

Pola disagreement yang konstruktif:

  Langkah 1: Pastikan kamu memahami posisi lawan bicara
  "Kalau saya mengerti dengan benar, kamu memilih approach ini karena X.
   Apakah pemahamanku benar?"

  Langkah 2: Jelaskan concern kamu dengan spesifik
  "Concern saya adalah bahwa dengan approach ini, kita akan menghadapi Y
   jika terjadi Z. Ini sudah pernah terjadi di PR 1234."

  Langkah 3: Tawarkan alternatif atau data
  "Apakah kamu sudah mempertimbangkan approach B? Kelebihannya adalah...
   Kekurangannya adalah... Menurutmu bagaimana trade-off-nya?"

  Langkah 4: Jika masih tidak sepakat, eskalasi dengan benar
  "Kita punya pandangan yang berbeda tentang ini. Apakah ada orang lain
   yang bisa kita minta perspektifnya? Atau apakah ini perlu jadi RFC?"

  Yang tidak boleh dilakukan:
  ✗ Terus berdebat tanpa progress di thread yang sama
  ✗ Menaikkan nada menjadi personal
  ✗ Unilateral approve tanpa resolusi yang jelas
  ✗ Membiarkan disagreement menghalangi merge tanpa jalur yang jelas

Ada satu prinsip yang berguna untuk disagreement yang tidak terselesaikan: “disagree and commit”. Jika setelah diskusi yang cukup tidak ada resolusi yang jelas, tim bisa memutuskan untuk mengikuti pendapat author (karena mereka yang paling tahu konteksnya), mencatatkan dissenting opinion di PR comment, dan lanjutkan. Ini lebih baik dari PR yang macet berminggu-minggu karena tidak ada yang mau mengalah.

Tanggung Jawab Reviewer Senior terhadap Engineer Junior #

Reviewer yang lebih senior memiliki tanggung jawab ekstra — bukan hanya menjaga kualitas kode, tapi juga menjaga kondisi di mana engineer junior bisa tumbuh. Cara seorang senior me-review PR junior menentukan apakah junior itu akan merasa didukung atau merasa tidak mampu.

Review yang mendukung pertumbuhan junior:

  ✓ Jelaskan "mengapa" di balik setiap feedback
    → Junior belajar prinsip, bukan hanya mengikuti instruksi

  ✓ Tunjukkan apresiasi untuk hal yang sudah benar
    → "[praise] Error handling di sini sudah sangat baik —
       kamu sudah menangani semua edge case yang relevan."

  ✓ Bedakan antara "ini salah" dan "ada cara yang lebih baik"
    → "Ini berjalan dengan benar, tapi ada cara yang lebih idiomatis
       yang perlu kamu tahu untuk masa depan: [penjelasan]"

  ✓ Ajukan pertanyaan alih-alih langsung memberi jawaban
    → "Apa yang akan terjadi jika kita memanggil fungsi ini dengan
       input kosong?" — biarkan junior berpikir sendiri

  ✗ Yang harus dihindari:
    → "Harusnya kamu tahu ini di level kamu"
    → Komentar yang membuat junior merasa tidak layak ada di tim
    → Standar yang berbeda antara senior dan junior tanpa penjelasan

Membangun Budaya Review yang Sehat #

Budaya tidak dibangun oleh satu orang atau satu kebijakan. Ia dibangun oleh akumulasi perilaku sehari-hari dari semua anggota tim.

Langkah-langkah membangun budaya review yang sehat:

  1. Buat code review guideline yang eksplisit
     → Apa yang wajib dikomentari, apa yang tidak
     → Konvensi label (blocking, suggestion, nitpick)
     → Ekspektasi response time dari kedua pihak

  2. Pemimpin tim harus mencontohkan perilaku yang diharapkan
     → Senior developer yang memberikan feedback dengan respek
       menjadi model bagi yang lain
     → Satu senior yang toxic bisa merusak seluruh kultur tim

  3. Normalkan apresiasi
     → "[praise]" bukan basa-basi — ini komunikasi yang bermakna
     → Tim yang saling mengapresiasi lebih mudah menerima kritik

  4. Buat space untuk refleksi
     → Sesekali diskusikan: "bagaimana proses review kita berjalan?"
     → Retrospektif khusus tentang code review setelah sprint besar

  5. Atasi pola negatif segera
     → Jika ada reviewer yang konsisten merendahkan, ini perlu
       dibicarakan secara langsung — tidak diabaikan
     → "Komentar kamu di PR-nya Ali kemarin terasa sedikit harsh.
       Bisa coba cara yang lebih supportif?"

Anti-Pattern yang Harus Dihindari #

Dari sisi reviewer:

✗ "Tau gitu nggak pakai cara ini sejak awal"
  → Menghakimi keputusan masa lalu tanpa memahami konteksnya.
  Keputusan yang ada mungkin diambil dengan constraint yang sudah tidak relevan.

✗ Komentar yang bernada sarkasme atau ironi
  → Teks tidak memiliki nada suara — sarkasme di teks sering dibaca
  jauh lebih tajam dari yang dimaksud. Hindari sepenuhnya.

✗ Approve PR karena segan kepada senior yang jadi author
  → Ini adalah bentuk social pressure yang merusak nilai code review.
  Review harus berdasarkan kualitas kode, bukan hierarki sosial.

✗ Membandingkan author dengan orang lain
  → "Si A tidak pernah melakukan ini" atau "Bandingkan dengan PR-nya Budi"
  adalah perbandingan yang tidak fair dan merusak hubungan tim.

────────────────────────────────────────────────────────────────────────────

Dari sisi author:

✗ Langsung mengabaikan semua komentar reviewer
  → Setiap komentar layak mendapat respons — bahkan jika kamu tidak setuju.
  Mengabaikan tanpa respons adalah bentuk ketidakhormatan.

✗ Bereaksi secara emosional terhadap feedback teknis
  → "Ini serangan personal" ketika feedback ditujukan pada kode.
  Pisahkan identitas diri dari kode yang ditulis.

✗ Merge PR tanpa resolusi dari semua blocking comment
  → Ini melanggar kepercayaan reviewer dan merusak nilai proses review.

✗ "Saya sudah engineer 10 tahun, saya tahu lebih baik"
  → Senioritas tidak mengecualikan seseorang dari code review.
  Bahkan engineer paling senior pun bisa memiliki blind spot.

Checklist Etika Code Review #

SEBAGAI REVIEWER:
  □ Sudah membaca deskripsi PR sebelum membuka diff
  □ Setiap komentar menjelaskan mengapa, bukan hanya apa
  □ Tidak ada komentar yang bisa dibaca sebagai serangan personal
  □ Komentar blocking dan non-blocking sudah dibedakan dengan label
  □ Ada apresiasi untuk hal yang sudah dilakukan dengan baik
  □ Preferensi personal yang tidak ada di guideline ditandai sebagai nitpick
    atau tidak dikomentari sama sekali
  □ Disagree disampaikan dengan pertanyaan atau data, bukan pernyataan
  □ Tidak pernah approve tanpa benar-benar membaca PR

SEBAGAI AUTHOR:
  □ Menerima feedback dengan terbuka — pertanyakan dengan argumen, bukan emosi
  □ Merespons setiap komentar, bahkan yang tidak menghasilkan perubahan
  □ Tidak merge sebelum semua blocking comment terselesaikan
  □ Jika tidak setuju, menyampaikan counter-argument dengan data atau reasoning

SEBAGAI TIM:
  □ Ada code review guideline yang terdokumentasi dan disepakati bersama
  □ Pola review yang tidak sehat dibicarakan secara langsung, tidak dibiarkan
  □ Apresiasi menjadi bagian normal dari proses review, bukan hal yang canggung
  □ Junior merasa aman untuk bertanya dan membuat kesalahan dalam proses review

Ringkasan #

  • Etika menentukan apakah code review menjadi investasi atau beban — komentar yang benar secara teknis tapi disampaikan dengan merendahkan menghasilkan hasil yang lebih buruk dari komentar yang kurang presisi tapi disampaikan dengan respek.
  • Asumsikan niat baik — engineer membuat PR dengan niat baik. Pertanyaan pertama saat melihat kode yang tampak salah bukan “kenapa dia melakukan ini” tapi “apa yang mungkin membuatnya masuk akal?”
  • Pisahkan kode dari orangnya — “kode ini berpotensi menimbulkan masalah” sangat berbeda dari “kamu tidak memikirkan ini”. Satu mengkritik kode, yang lain mengkritik orangnya.
  • Berikan konteks, bukan sekadar instruksi — “gunakan X” tidak mengajarkan apapun. Penjelasan mengapa X lebih baik dan apa konsekuensi dari pendekatan saat ini membangun kemampuan author untuk membuat keputusan lebih baik di masa depan.
  • Nitpicking yang tidak proporsional merusak proses — energi yang dihabiskan untuk spasi dan nama variabel adalah energi yang diambil dari memeriksa logika dan keamanan. Tandai nitpick sebagai nitpick, jangan jadikan blocking.
  • Preferensi personal bukan dasar blocking — jika tidak ada guideline tim atau alasan teknis yang jelas, preferensi pribadi tidak seharusnya memblokir merge.
  • Psychological safety adalah fondasi — tim yang engineer-nya takut kena review atau takut memberikan feedback akan menghasilkan code review yang bersifat formalitas tanpa nilai nyata.
  • Disagreement adalah sehat, tapi harus dikelola — gunakan pertanyaan, data, dan alternatif konkret. Jika tidak ada resolusi, “disagree and commit” lebih baik dari PR yang macet berminggu-minggu.
  • Senior memiliki tanggung jawab ekstra — cara senior me-review PR junior menentukan apakah junior merasa didukung atau merasa tidak mampu. Ini investasi dalam pertumbuhan tim jangka panjang.
  • Budaya dibangun dari setiap interaksi kecil — satu komentar merendahkan bisa merusak kepercayaan yang dibangun dari banyak review yang baik. Konsistensi perilaku yang etis adalah yang membangun budaya.

← Sebelumnya: Code Review Checklist   Berikutnya: Unit Test as Guard →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact