TODO sebenarnya bukan sesuatu yang harus "dikerjakan"

• Beberapa tim memakai kebijakan seperti mendaftarkan semua komentar TODO ke bug tracker atau menghapus otomatis TODO yang berusia lebih dari 1 tahun, tetapi praktik seperti ini tidak direkomendasikan
• Komentar TODO tidak selalu bernilai hanya jika harus diselesaikan, melainkan berfungsi sebagai snapshot otak yang menyimpan konteks dan ide pada saat kode ditulis
• TODO yang penting memang sebaiknya dikelola sebagai issue, tetapi kebanyakan hanyalah catatan untuk prioritas rendah atau edge case
• TODO yang ditempatkan dengan baik memberi petunjuk untuk memahami niat penulis saat itu ketika pembaca kode di masa depan bertanya, "Apakah bagian ini aman untuk direfaktor?"
• Nilai TODO terletak bukan pada apakah ia diselesaikan, tetapi pada kemampuannya merekam konteks, niat, dan kemungkinan, sehingga membantu pemeliharaan dan kolaborasi di masa depan

---

Apakah komentar TODO memang harus selalu ditangani?

• Di beberapa organisasi, ada aturan untuk mendaftarkan semua TODO di dalam kode ke bug tracker, atau menghapusnya otomatis setelah jangka waktu tertentu (lebih dari 1 tahun)
• Namun pendekatan seperti ini sebenarnya tidak efisien dan melewatkan hakikat TODO — nilainya tidak muncul hanya jika benar-benar ditangani

Nilai sebenarnya dari TODO

• Misalnya,

  // TODO: 다음 주 출시 전에 이 파일의 뒷부분을 완성해야 함  
  

  komentar seperti ini memang mungkin perlu dilacak

• Tetapi TODO yang baik biasanya seperti

  // TODO: 사용자가 이 버튼을 트리플 클릭할 경우, 핸들러에서 \[xyz] 오류 발생  
  

  yang dipakai untuk mencatat edge case, atau merekam ide perbaikan struktur yang belum bisa dikerjakan sekarang, situasi yang terlewat, dan hal-hal serupa beserta konteksnya

TODO bukan "rencana", melainkan "saluran"

• Sebagian besar TODO sebenarnya adalah hal berprioritas rendah yang tidak perlu segera ditangani
• TODO berperan menyampaikan pertimbangan, penilaian, dan konteks penulis pada saat penulisan kepada pembaca kode di masa depan
• Saat seseorang yang membaca kode di kemudian hari bertanya, "Apakah struktur di sini boleh diubah?", TODO membantu memahami niat penulis saat itu

Dampak TODO yang ditulis dengan baik

• TODO dalam kode terkadang memberi petunjuk penting tentang potensi masalah, kemungkinan perbaikan struktur, atau edge case yang belum tertangani
• Meski bukan selalu rencana untuk diselesaikan, TODO berperan besar dalam menyampaikan konteks yang halus untuk kolaborasi dan pemeliharaan
• Pada akhirnya, komentar TODO adalah catatan berharga yang meningkatkan pemahaman terhadap kode dan kemudahan pemeliharaan di masa depan

Kesimpulan

• TODO tidak bernilai hanya jika harus diselesaikan; ia menjadi saluran komunikasi yang menyimpan pemikiran, niat, dan konteks penulis untuk pembaca kode di masa depan

[GN⁺]

Opini Hacker News

• Saya berpandangan bahwa "TODO harus selalu terhubung ke issue yang konkret".
  Menurut saya ada tiga cara untuk menangani TODO sebelum merge.
  1. Tinggalkan issue—kalau itu memang pekerjaan yang benar-benar harus dilakukan, ada baiknya luangkan sekitar 20 detik untuk mencatat dan melacaknya.
  2. Langsung kerjakan—kalau terlalu sepele untuk dijadikan issue, selesaikan saja sebelum commit.
  3. Ubah jadi komentar—kalau tidak cukup layak untuk diperbaiki atau dilacak, tetapi tetap ingin diingat, saya sarankan tinggalkan sebagai komentar kode biasa.
  Demi kesehatan proyek, membiasakan diri melacak TODO itu baik, seperti makan brokoli demi kesehatan tubuh.
  • Melacak di sistem eksternal bukan cuma soal membuat issue; ada kerja tambahan berkelanjutan seperti kategorisasi, pengelolaan backlog, reklasifikasi, dan menutupnya saat selesai.
    Issue yang didaftarkan di sistem eksternal juga belum tentu terlihat jelas oleh developer yang sedang mengerjakan bagian kode tersebut.
    Kalau biaya untuk melacak hal-hal kecil yang sebenarnya mudah diperbaiki terasa tidak sepadan, lebih efisien membiarkannya sebagai TODO.
    TODO di dalam kode langsung terlihat saat mengerjakan bagian itu, dan mudah dihapus saat refactor.
  • Penulis tampaknya pada dasarnya mendukung poin 3 (biarkan saja sebagai komentar biasa).
    Namun sayang dia tidak menjelaskan dengan jelas perbedaan antara komentar TODO dan komentar biasa.
    Istilah TODO sendiri punya kekuatan visual sehingga orang bisa langsung tahu jenis komentar seperti apa itu.
    Agak meragukan ketika dikatakan bahwa komentar TODO tidak perlu dipahami secara harfiah sebagai "hal yang harus dilakukan".
    Saya umumnya setuju dengan isi tulisannya, tetapi menurut saya akan lebih baik kalau memang ditinggalkan saja sebagai komentar biasa.
  • Katanya "cukup luangkan 20 detik untuk mencatat dan mengelolanya", padahal itu sendiri pada dasarnya sudah TODO.
    Kalau harus dimasukkan ke sistem tiket, itu akan makan waktu lebih dari 20 detik dan malah lebih mengganggu daripada membantu.
  • Akan bagus kalau tracking cuma 20 detik, tetapi (karena saya di perusahaan besar) membuat satu tiket JIRA saja butuh mengisi lebih dari 10 kolom wajib.
  • Saya cuma memakai satu aturan: semua TODO wajib menyertakan nomor tiket.
    // TODO: improve the routing https://jira.com/whatever/TIX-1234
    Alasannya, kalau komentar jadi yatim piatu, tidak akan ada yang tahu lagi kenapa itu ditinggalkan.
    Kalau cuma meninggalkan komentar biasa, nanti seseorang akan lupa tujuan dan konteksnya.
    Jadi menurut saya harus buat tiket atau langsung dibereskan.
• Saya melakukan grep dengan membedakan kategori berikut.
  FIXME: bagian yang jelas salah atau rusak, prioritas tertinggi
  XXX: bagian yang jelek dilihat atau berisi asumsi yang salah, prioritas tinggi
  TODO: bagian yang suatu saat perlu implementasi pendekatan/kategori/cabang yang benar-benar baru
  NOTE: untuk menyampaikan informasi yang lebih penting daripada komentar biasa
  Saya kebanyakan bekerja di engine kode legacy/tidak terawat, dan di sana "kode adalah kebenaran", jadi saya tidak membuat JIRA dan langsung memperbaiki hal-hal sambil membaca.
  • Saya memakainya seperti ini.
    TODO: hal yang mutlak diperlukan sebelum rilis, persyaratan wajib. Kalau tidak termasuk ini, harus dipindahkan ke kategori lain. Ini adalah blocker rilis.
    FUTURE: sesuatu yang suatu saat bisa menjadi TODO, biasanya hal opsional seperti desain struktural
    MAYDO: bagus kalau ada, tapi tidak wajib
    PERF: bagus dikerjakan kalau butuh performa lebih
    Dan saya juga memakai tag bermakna yang terkait domain.
    Menurut saya TODO bukan code smell, melainkan sesuatu yang secara alami menumpuk di bagian-bagian inti codebase.
  • Saya memakai XXX sebagai catatan pribadi berarti "harus diperbaiki sebelum PR berikutnya".
    Kalau dipakai serius, saya bahkan mengatur CI untuk me-reject kode yang mengandung string tersebut.
    Dalam arti itu, XXX adalah prioritas tertinggi bagi saya.
  • Saya suka gaya ini. Di satu proyek, kami pernah membuat CI yang otomatis me-reject kode dengan FIXME, dan me-reject TODO kalau tidak ada tiket issue.
    Kalau diurutkan prioritasnya dari atas ke bawah:
    FIXME: untuk menjaga fokus. Kode harus diperbaiki sebelum bisa di-merge atau dianggap selesai.
    XXX: harus segera diperbaiki. Saat ini masih berfungsi, tetapi harus cepat dibetulkan.
    TODO: perlu dikunjungi lagi nanti. Kodenya sepenuhnya masih bisa dipakai. Prioritasnya di bawah XXX.
    NOTE: menjelaskan keanehan atau hal yang perlu diketahui agar membantu orang berikutnya yang mengerjakannya.
  • Saya juga mirip. Untuk jalur kode yang belum selesai tetapi bisa di-bypass, saya memasang assert alih-alih FIXME.
    TODO dipakai untuk meninggalkan pekerjaan yang mungkin dilakukan, seperti refactor/performa/peningkatan kejelasan.
    NOTE saya pakai untuk meninggalkan informasi historis atau alur pemikiran yang tidak mudah terlihat dari pembacaan langsung.
  • Secara teori bagus, tetapi menurut saya kesepakatan seperti ini tidak ada artinya tanpa dukungan tool.
    Apalagi kalau diasumsikan bekerja dalam tim.
    Bukan berarti saya bilang ini tidak berguna—justru saya rasa tool seperti ini perlu ada atau dibuat.
• Saya jadi teringat ungkapan bahwa kesempurnaan adalah musuh dari yang baik.
  Utang teknis atau code smell seperti ini sebenarnya memang lebih baik dilacak/dicatat/dijelaskan dengan lebih baik, tetapi kalau disuruh melakukan pekerjaan yang menurunkan produktivitas seperti JIRA, akhirnya orang malah tidak mencatat apa-apa.
  Setidaknya kalau ada TODO di dalam kode, sesuatu tetap tercatat di suatu tempat.
  TODO juga bermakna karena memang merupakan "hal yang perlu dilakukan".
  • Untuk codebase besar, TODO dari banyak orang bisa bercampur dan jadi rumit, tetapi untuk proyek pribadi ini kompromi yang bagus.
    "Saya tahu ini bisa dibuat lebih baik, tetapi saya tidak sengaja menghentikan flow saya demi itu. Fungsinya juga tidak rusak; hanya akan sedikit lebih baik kalau dikerjakan."
    Saat highlight TODO di editor muncul sesekali, itu membantu ketika sedang ingin membereskan hal kecil sebentar.
    Tapi kebanyakan TODO akan tinggal selamanya, atau nyaris tidak pernah benar-benar diselesaikan.
  • Kadang saya meninggalkan TODO karena ingin meninggalkan sinyal di kode bahwa ada sesuatu yang perlu ditangani.
    Bahkan kalau sudah didaftarkan ke JIRA, GH Issues, dan sebagainya, pada akhirnya catatan itu tetap harus saling terhubung.
    Dan kalau hanya meninggalkan referensi, maknanya bisa hilang nanti, jadi penjelasan juga harus ada di komentarnya.
  • Fitur MCP server yang memungkinkan AI membuat tiket JIRA langsung dari Cursor juga sudah ada.
  • Menurut saya jauh lebih baik meninggalkannya di pesan commit git.
    Banyak commit sebenarnya gagal menyampaikan isi dengan baik.
    Saya ingin orang didorong memakai tool yang lebih baik alih-alih meninggalkan TODO dengan cara lama.
    Banyak developer terlalu jarang commit, lalu memasukkan banyak pekerjaan sekaligus dalam satu kali commit.
    Pesan commit pun sering tidak bermakna, seperti "updating somefile.py".
• Ini soal gaya. Setiap orang bisa punya definisi atau budaya berbeda soal TODO.
  Di codebase saya, TODO dipakai seperti yang dijelaskan di sini.
  TODO dipakai untuk menjelaskan implementasi, terutama mendokumentasikan bagian yang hilang—bukan berarti wajib dikerjakan.
  Menurut saya meninggalkan daftar pekerjaan sungguhan di dalam kode sendiri tidak terlalu bermakna. Prioritas selalu berubah; sesuatu mungkin terasa penting saat ditulis, tetapi kemudian ternyata tidak, dan issue yang bahkan belum terpikir bisa jadi justru perlu diselesaikan lebih dulu.
  Tidak mungkin terus membuka PR hanya untuk memperbarui komentar TODO.
  Kalau ingin mencatat hal yang harus dilakukan, lebih baik kelola di luar, seperti issue tracker atau dokumen teks yang mudah diperbarui.
• Judulnya memang agak clickbait, tetapi saya sepenuhnya setuju dengan keseluruhan isinya.
  Barusan saya juga menulis #TODO untuk mencatat situasi pengecualian yang sangat jarang terjadi. Sudah 2 tahun belum pernah benar-benar terjadi, tetapi akan membantu nanti kalau saya bertanya-tanya kenapa bagian ini tidak saya tangani.
  Saya juga paham orang yang bilang hal seperti ini sebaiknya dibiarkan sebagai komentar biasa. Itu tergantung sifat codebase, dan di lingkungan seperti saya yang cuma tim 2 orang, pendekatan TODO seperti ini cocok.
  • Tim kami memakai // TBD: [...] untuk tujuan seperti ini. Itu semacam trik agar orang yang punya obsesi terhadap TODO tidak menyadarinya.
• Harus ada ruang untuk mencatat issue yang jelas bernilai untuk diketahui tetapi tidak perlu dilacak.
  Tidak ada rencana nyata untuk memperbaikinya, tetapi kalau suatu saat ada waktu luang, ini jenis hal yang layak dicari dengan ctrl-F untuk melihat apakah bisa dirapikan.
  Menurut saya tidak masuk akal jika terlalu banyak tool atau proses menganggap TODO sebagai code smell.
  • Saya sendiri belum pernah benar-benar mengalami issue seperti itu.
    Pada akhirnya ini cuma soal prioritas, dan saya menganggapnya seperti broken window (metafora terkenal dari Pragmatic Programmer).
    Kalau memang diputuskan tidak akan diperbaiki, lebih baik dicatat di dokumentasi software.
• Contoh yang diberikan di tulisan itu:

  // TODO: If the user triple-clicks this button, the click handler errors because [xyz]
  Menurut saya ini sebenarnya lebih dekat ke komentar biasa daripada TODO sungguhan.
  Komentar penjelas seperti ini jelas membantu, tetapi agak meragukan untuk disebut TODO.
  TODO seharusnya menunjukkan hal yang memang jelas perlu dilakukan, misalnya seperti "fungsi ini harus mengembalikan nilai berbeda sesuai XYZ".
  Dalam arti itu, TODO seharusnya tidak terkubur di dalam kode, melainkan ada di issue tracker.
  Dari pengalaman saya, TODO hanyalah cara untuk membenarkan pengorbanan kualitas kode demi cepat mendapat persetujuan PR. Pada praktiknya hampir tidak pernah dijalankan, dan yang tersisa cuma pemikiran "nanti developer junior yang punya banyak waktu mungkin akan membereskannya".

  • Komentar itu untuk menjelaskan kenapa kode ini bekerja dengan cara seperti itu.
    Misalnya kalau cuma ditulis
    // If the user triple-clicks this button, the click handler errors because [xyz]
    seperti ini saja, tidak jelas apakah itu bug atau memang perilaku yang diinginkan.
    TODO adalah sinyal sederhana bahwa "ada bagian yang belum sempurna di sini, jadi perhatikan saat mengerjakannya".
    Kalau itu memang sesuatu yang wajib diperbaiki, benar bahwa seharusnya dilacak di tempat lain.
    Tetapi kalau TODO sendiri dikurangi, menurut saya yang akan bertambah justru kode yang tidak terdokumentasi.
  • Saya tidak menganggap contoh di atas sebagai komentar TODO yang bagus.
    Daripada menulis itu, lebih baik langsung perbaiki bug tersebut, atau tinggalkan komentar seperti "triple click diabaikan karena [xyz]".
    Kalau trigger dan penyebabnya sudah diketahui, menurut saya 80% pekerjaan sebenarnya sudah selesai.
  • Itu bisa dianggap sekadar "lewati saja". Dalam banyak kasus, memang tidak apa-apa kalau tidak dikerjakan sama sekali.
    Yang jadi masalah adalah ketika kode tidak benar-benar bekerja dengan sempurna tetapi dianggap seolah-olah bekerja.
    TODO terbaik yang pernah saya lihat adalah sesuatu seperti "TODO: encrypt this" pada kode keamanan, yang dengan jelas menandai bahwa enkripsi belum dilakukan.
    Karena itu, siapa pun bisa cepat melihat bahwa kodenya belum dienkripsi, dan juga mengurangi kekhawatiran apakah enkripsi itu mungkin sudah ditangani terpisah lewat modularisasi atau malah akan dienkripsi dua kali.
  • Contoh itu lebih dekat ke FIXME daripada TODO.
    Itu jelas sebuah error, tetapi urgensi untuk menanganinya rendah.
• Saya sangat tidak setuju.
  Kalau tidak akan didaftarkan sebagai bug atau benar-benar dikerjakan, saya lebih suka TODO tidak ditinggalkan sama sekali.
  // TODO: If the user triple-clicks this button, the click handler errors because [xyz]
  Ini cuma catatan fenomena. Kata TODO seharusnya dihapus.
• Saya juga memakainya secara bertingkat.
  FIXME dipakai kalau memang harus diperbaiki, atau saat langkah berikutnya sudah sangat jelas.
  TODO dipakai untuk pikiran yang lebih samar, atau sekadar mengeluarkannya dari kepala supaya saya bisa fokus ke hal berikutnya.
  Bisa karena idenya belum matang, belum yakin harus dilakukan, atau sedang menunggu sesuatu yang terkait, dan sebagainya.
  Kalau tidak dicatat, pikiran itu terus muncul dan membuat kepala penuh; begitu ditulis, entah TODO atau apa pun, rasanya jauh lebih lega secara mental.
• Saya menganggap komentar sebagai bukti kemampuan menulis kode yang kurang baik.
  Saya berharap bisa menulis kode yang cukup jelas untuk dipahami tanpa komentar.
  Meski begitu, kalau nanti bahkan saya sendiri tidak akan paham saat membacanya lagi, mau tidak mau saya tetap menulis komentar.
  Yang menyedihkan, kalau setelah itu seseorang mengubah kodenya tetapi tidak memperbarui komentarnya, hasilnya justru makin membingungkan.
  Menurut saya TODO tidak seharusnya ada di kode yang sudah di-commit, dan seharusnya dikelola di sistem manajemen proyek atau issue.