Selamat tinggal, Clean Code (2020)

 (overreacted.io)
4 poin oleh GN⁺ 2023-12-09 | 1 komentar | Bagikan ke WhatsApp

Perpisahan dengan perapian kode

  • Memeriksa kode yang ditulis rekan kerja sepanjang minggu larut malam saat akan check-in.
  • Mengimplementasikan fitur untuk mengubah ukuran bentuk di kanvas editor grafis.
  • Kodenya berfungsi, tetapi berulang-ulang.

Keesokan paginya...

  • Atasan meminta percakapan pribadi dan meminta agar perubahan kode dibatalkan.
  • Awalnya terkejut, tetapi akhirnya menyadari bahwa keputusan atasan itu benar.

Tahap

  • Terobsesi pada "kode yang bersih" dan tenggelam dalam menghapus duplikasi adalah tahap yang dialami banyak pengembang.
  • Saat tidak percaya diri pada kode, sangat menggoda untuk mengaitkan harga diri dan kebanggaan profesional pada hal-hal yang bisa diukur.
  • Setelah mempelajari abstraksi, setiap kali melihat kode yang berulang, kita jadi ingin memakai abstraksi.

Opini GN⁺

  • Yang penting adalah bahwa mengejar "kebersihan" kode bukanlah tujuan itu sendiri, melainkan semacam mekanisme pertahanan saat menangani sistem yang kompleks.
  • "Clean Code" membantu pengembang menjadi penunjuk jalan di wilayah yang belum dikenal, tetapi kita juga harus tahu kapan berhenti terpaku padanya dan bisa melepaskannya.
  • Tulisan ini menawarkan sudut pandang menarik yang mengingatkan pengembang akan pentingnya kolaborasi dan pragmatisme dalam proses menulis dan memelihara kode.

Bacaan terkait

1 komentar

 
GN⁺ 2023-12-09
Opini Hacker News

  • "Clean Code" perlu perbaikan branding

    • Tujuan clean code adalah membuat kode lebih sederhana dan lebih mudah dirawat
    • Nilai perangkat lunak terletak pada kemampuannya untuk berubah seiring waktu
    • Jika refactoring membuat pemeliharaan lebih sulit, itu bukan clean code
    • Tidak berdiskusi dengan pengembang asli tentang refactoring adalah masalah yang terpisah dari clean code

  • Duplikasi kode kadang bisa baik, tetapi itu bukan bukti bahwa clean code itu buruk

    • Jika 10 baris perhitungan matematika yang berulang diganti dengan sebuah fungsi, itu bisa menjadi lebih clean
    • PR harus ditinjau dan ditolak jika tidak memenuhi standar
    • Sikap yang mengabaikan pentingnya clean code pada akhirnya mengarah ke codebase yang tidak ingin disentuh siapa pun
    • Pelajaran bahwa dibutuhkan komunikasi yang lebih baik dan pengendalian diri

  • Seorang rekan kerja menulis banyak kode dengan copy-paste

    • Refactoring harus diajukan untuk review
    • Atasan turun tangan langsung dan memerintahkan untuk mengembalikan perubahan adalah sinyal buruk
    • Ini bukan pelajaran bahwa copy-paste lebih baik daripada membuat fungsi

  • Kemungkinan besar versi clean code menggantikan kode yang kotor

    • Dibutuhkan pelajaran tentang cara bekerja dalam tim

  • Review rekan diperlukan saat mengubah kode

    • Harus menyadari kurangnya proses yang baik
    • Refactoring kode sebaiknya hanya dilakukan saat diperlukan

  • Di bidang keuangan, sering kali menangani produk yang mirip tetapi berbeda

    • Penting untuk menghindari abstraksi berlebihan sambil tetap menjaga clean code

  • Bahasa seperti Haskell memaksimalkan abstraksi di tingkat bahasa

    • Biaya belajarnya tinggi, meski abstraksi per proyek bisa diminimalkan

  • Memindahkan perhitungan matematika yang berulang ke fungsi terpisah termasuk clean code

    • Melakukan refactoring pada fungsi resize yang tampak seperti pembentukan antarmuka adalah tindakan yang keliru

  • Penjelasan tentang abstraksi yang buruk

    • Masalahnya adalah merancang tanpa cukup mempertimbangkan penggunaan di masa depan

  • Rob Pike mengatakan, "sedikit copy lebih baik daripada sedikit dependensi"

    • Prinsip DRY kadang menambahkan abstraksi, tetapi jika abstraksi itu tidak cukup ortogonal, justru memperburuk masalah