TODO aslında 'yapılacak şey' değildir

 (sophiebits.com)
15 puan yazan GN⁺ 2025-07-23 | 1 yorum | WhatsApp'ta paylaş
  • Bazı ekipler tüm TODO yorumlarını bug tracker’a kaydetme ya da 1 yıldan eski TODO’ları otomatik silme politikaları kullanıyor, ancak bu tür uygulamalar önerilmiyor
  • TODO yorumları, mutlaka tamamlanması gerektiğinde değerli olan şeyler değil; kod yazıldığı andaki bağlamı ve fikirleri bırakan bir beyin anlık görüntüsü işlevi görür
  • Önemli TODO’lar issue olarak yönetilmelidir, ancak çoğu, düşük öncelikli veya edge case’leri kaydeden notlardır
  • İyi yerleştirilmiş bir TODO, gelecekte kodu okuyan kişinin "Bu kısmı refactor etsem olur mu?" diye düşündüğünde o dönemki yazarın niyetini anlaması için bir ipucu sağlar
  • TODO’nun değeri, tamamlanıp tamamlanmamasında değil; bağlamı, niyeti ve olasılıkları kaydederek gelecekteki bakım ve iş birliğine yardımcı olmasındadır

TODO yorumları, gerçekten mutlaka ele alınmalı mı?

  • Bazı organizasyonlar kod içindeki tüm TODO’ları bug tracker’a kaydetme ya da belli bir süre geçince (1 yıldan fazla) otomatik silme kuralı uygular
  • Ancak bu yaklaşım pratikte verimsizdir ve TODO’nun özünü kaçırır; değeri ancak gerçekten işleme alınmasıyla ortaya çıkan bir şey değildir

TODO’nun gerçek değeri

  • Örneğin,

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

    gibi bir yorumun gerçekten takip edilmesi gerekebilir

  • Ama iyi TODO’lar çoğunlukla

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

    örneğinde olduğu gibi edge case’leri kaydetmek ya da şu anda yapılamayan yapısal iyileştirme fikirlerini, gözden kaçan durumları bağlamıyla birlikte kaydetmek için kullanılır

TODO bir 'plan' değil, bir 'kanal'dır

  • TODO’ların çoğu aslında hemen ele alınması gerekmeyen düşük öncelikli şeylerdir
  • Yazıldığı andaki yazarın düşüncelerini, değerlendirmelerini ve bağlamını gelecekte kodu okuyacak kişiye aktarma işlevi görür
  • İleride kodu okuyan biri "Buradaki yapıyı değiştirsem olur mu?" diye düşündüğünde, TODO o zamanki yazarın niyetini anlamaya yardımcı olur

İyi yazılmış bir TODO’nun etkisi

  • Koddaki TODO’lar bazen olası sorunlar, yapısal iyileştirme fırsatları, ele alınmamış edge case’ler gibi önemli ipuçları sağlar
  • Mutlaka çözüm için yapılmış bir plan olmasa bile, iş birliği ve bakım süreçlerinde ince bağlam aktarımında büyük rol oynar
  • Sonuçta TODO yorumları, kodun anlaşılabilirliğini ve gelecekteki bakım yapılabilirliğini artıran değerli kayıtlar olarak işlev görür

Sonuç

  • TODO, ancak tamamlandığında değer kazanan bir şey değil; yazarın düşüncelerini, niyetini ve bağlamını bırakıp gelecekte kodu okuyacak kişiyle iletişim kuran bir kanaldır

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-23
Hacker News görüşü
  • Benim görüşüm, "TODO her zaman somut bir issue'ya bağlı olmalı" yönünde.
    Merge öncesinde TODO'yu ele almanın üç yolu olduğunu düşünüyorum.
    1. Bir issue bırakmak — gerçekten yapılması gereken bir işse 20 saniye ayırıp kaydetmek ve takip etmek iyi olur
    2. Hemen halletmek — issue açmaya değmeyecek kadar küçük bir işse commit'ten önce çözmek
    3. Yoruma çevirmek — düzeltmeye değmiyor ve takip etmeye gerek yok ama hatırlamak istiyorsanız normal bir kod yorumu olarak bırakmanızı öneririm
    Sağlığınız için brokoli yemek gibi, TODO'ları da takip etme alışkanlığı iyidir.
    • Harici bir sistemde takip etmek, sadece issue açmakla bitmiyor; sınıflandırma, backlog yönetimi, yeniden sınıflandırma, tamamlanınca kapatma gibi ek işler sürekli çıkıyor.
      Harici sisteme kaydedilen issue'lar, o kod parçasına dokunan geliştiriciler için yeterince görünür olmayabiliyor.
      Kolayca düzeltilebilecek şeyleri sırf takip etmenin maliyeti gereksizse, onları TODO olarak bırakmak daha verimli.
      Kod içindeki TODO'lar, ilgili kod üzerinde çalışırken hemen göze çarpıyor ve refactor sırasında da kolayca silinebiliyor.
    • Yazının yazarı temelde 3 numarayı destekliyor gibi görünüyor (yani sadece yorum olarak bırakmayı).
      Ama TODO yorumu ile normal yorum arasındaki farkı net biçimde açıklamaması biraz eksik kalmış.
      TODO teriminin kendisi görsel olarak güçlü; bunun ne tür bir yorum olduğunu hemen anlatıyor.
      TODO yorumunu illa "TO DO (yapılacak iş)" diye okumamak gerektiğini söylemek biraz şüpheli geliyor.
      Yazıdaki genel görüşe katılıyorum ama bunun yerine doğrudan normal yorum bırakmak daha iyi bir iyileştirme olur diye düşünüyorum.
    • "20 saniye ayırıp kaydetmek ve yönetmek yeterli" denmiş ama bu zaten TODO'nun kendisi.
      Bunu ticket sistemine koyarsanız 20 saniyeden uzun sürer ve faydadan çok dikkat dağınıklığı yaratır.
    • Takip gerçekten 20 saniye sürse güzel olurdu ama (büyük şirketteyim) tek bir JIRA ticket'ı açmak için zorunlu 10'dan fazla alan doldurmak gerekiyor.
    • Ben tek bir kural kullanıyorum: tüm TODO'larda mutlaka bir ticket numarası olmalı.
      // TODO: improve the routing https://jira.com/whatever/TIX-1234
      Sebebi şu: yorum yetim kalırsa kimse neden bırakıldığını anlamaz.
      Sadece yorum bırakırsanız daha sonra birileri amacını ve bağlamını unutur.
      Bu yüzden ya mutlaka bir ticket oluşturulmalı ya da iş hemen yapılmalı diye düşünüyorum.
  • Ben grep için şu ayrımı kullanıyorum.
    FIXME: açıkça yanlış ya da bozuk olan şeyler, en yüksek öncelik
    XXX: çirkin görünen veya yanlış varsayımlar içeren şeyler, yüksek öncelik
    TODO: bir gün tamamen yeni bir yaklaşım/kategori/dal uygulanması gereken yerler
    NOTE: sıradan yorumdan daha önemli bilgi aktarmak için
    Ben daha çok legacy / bakımı yapılmayan kod motorlarında çalışıyorum; burada "kod gerçeğin kendisidir", bu yüzden JIRA açmak yerine okurken anında düzeltme yapıyorum.
    • Ben bunu şöyle kullanıyorum.
      TODO: release'ten önce kesinlikle gerekli işler, zorunlu maddeler. Buna uymuyorsa başka bir kategoriye taşınmalı. Release'i bloklayan şeylerdir.
      FUTURE: bir gün TODO olabilir, genelde yapısal tasarım gibi isteğe bağlı şeylerdir
      MAYDO: olsa iyi olur, olmasa da olur
      PERF: daha fazla performans gerektiğinde yapılması iyi olur
      Bir de alanla ilgili anlam etiketleri kullanıyorum.
      Benim görüşüm, TODO'nun bir code smell olmadığı; kod tabanının temel kısımlarında doğal olarak biriken bir şey olduğu yönünde.
    • Ben XXX'i "bir sonraki PR'dan önce mutlaka düzelt" anlamında kişisel not olarak kullanıyorum.
      Ciddiye almak istersem CI'ı, bu string'i içeren kodu reject edecek şekilde ayarlıyorum.
      O açıdan XXX benim için en yüksek öncelik.
    • Bu tarz hoşuma gidiyor. Bir projede CI ile FIXME içeren kodu her durumda reject ediyor, TODO varsa issue ticket'ı yoksa yine reject ediyorduk.
      Önceliği yukarıdan aşağı sıralarsak:
      FIXME: odağı korumak için. Çözülmeden merge edilemeyen ya da tamamlanmış sayılmayan kod.
      XXX: yakında düzeltilmeli. Şu an çalışıyor ama kısa süre içinde düzeltilmeli.
      TODO: sonra tekrar dönülmeli. Kod tamamen kullanılabilir durumda. XXX'ten daha düşük öncelikte.
      NOTE: sıra dışı noktaları veya bilinmesi gereken şeyleri açıklayarak sonradan gelen kişiye yardımcı olur.
    • Ben de benzer yapıyorum. Hâlâ tamamlanmamış ama etrafından dolaşılabilen kod yollarına FIXME yerine assert koyuyorum.
      TODO, refactor / performans / açıklık iyileştirmesi gibi olası işleri bırakmak için kullanılıyor.
      NOTE'yi ise geçmiş bilgileri ya da ilk bakışta anlaşılması zor düşünce akışını bırakmak için kullanıyorum.
    • Teoride güzel ama araç desteği olmadan bu tür anlaşmaların anlamsız olduğunu düşünüyorum.
      Hele ekip içinde çalışıyorsanız daha da öyle.
      Bu, keyfi biçimde "anlamsız" demek değil — böyle araçların var olması ya da yapılması gerektiğini düşünüyorum.
  • "Mükemmel, iyinin düşmanıdır" sözü aklıma geliyor.
    Bu tür teknik borçları ya da code smell'leri aslında daha iyi izlemek / kaydetmek / açıklamak gerekir ama JIRA gibi üretkenliği düşüren işler önerildiğinde insanlar hiçbir şeyi kaydetmemeye başlıyor.
    En azından kodun içinde bir TODO varsa, bir yerde iz bırakmış oluyor.
    TODO gerçekten de bir "yapılacak iş" olduğu için anlamlı.
    • Büyük bir kod tabanında farklı insanların TODO'ları iç içe geçip karmaşık hale gelebilir ama kişisel projelerde iyi bir uzlaşma.
      "Bunu daha iyi yapabileceğimi biliyorum ama bunun için akışımı bilerek durdurmuyorum. Özellik bozulmuyor; sadece olsa biraz daha iyi olurdu."
      Editörde TODO vurgusu ara sıra yeniden gözüme çarptığında, kısa bir boşlukta bunu çözmek istememe yardımcı oluyor.
      Yine de TODO'ların çoğu ömür boyu kalıyor ya da pratikte neredeyse hiç çözülmüyor.
    • Bazen kodda işlenmesi gereken bir işaret bırakmak istediğim için TODO bırakıyorum.
      Bunu JIRA, GH Issues vb. yerlere de yazsanız, nihayetinde kaydın birbirine bağlanması gerekir.
      Sadece referans bırakılırsa zamanla anlamını yitirebilir; o yüzden yorumun içinde açıklama da olmalı.
    • JIRA ticket'larını yapay zekanın oluşturduğu bir MCP sunucusunun Cursor içinden doğrudan çalıştırılabildiği bir özellik de zaten çıktı.
    • Bence bunu git commit mesajında bırakmak çok daha iyi.
      Birçok commit aslında içeriği yeterince iyi aktarmıyor.
      Eski usul TODO bırakmak yerine daha iyi araçların kullanımını teşvik etmek isterdim.
      Birçok geliştirici çok seyrek commit atıyor ve birden fazla işi tek commit'te topluyor.
      Commit mesajları da sık sık "updating somefile.py" gibi anlamsız şeyler oluyor.
  • Bu bir stil meselesi. TODO konusunda herkesin farklı tanımı ya da kültürü olabilir.
    Benim kod tabanımda TODO burada açıklandığı gibi kullanılıyor.
    TODO, uygulamanın nasıl çalıştığını açıklamak için, özellikle eksik parçaları belgelendirmek amacıyla kullanılıyor — mutlaka yapılması gereken bir iş anlamına gelmiyor.
    Bana göre asıl yapılacaklar listesini doğrudan kodun içinde tutmanın pek anlamı yok. Öncelikler sürekli değişir; yazıldığında önemli olan bir şey sonradan olmayabilir ve hiç düşünülmeyen başka bir konu daha sonra çözülmesi gereken işe dönüşebilir.
    Sırf TODO yorumlarını güncellemek için sürekli PR açamazsınız.
    Yapılacak işleri yazmak istiyorsanız, issue tracker ya da kolayca güncellenebilen bir metin belgesi gibi harici bir yerde yönetmek daha iyi.
  • Başlık biraz clickbait olsa da, genel içeriğe tamamen katılıyorum.
    Az önce ben de son derece nadir ortaya çıkan istisnai bir durumu kaydetmek için #TODO kullandım. 2 yıldır hiç yaşanmadı ama ileride bu kısmı neden ele almadığımı merak edersem yardımcı olacak.
    Bunun bazen sadece yorum olarak bırakılması gerektiğini söyleyenleri de anlıyorum. Bu, kod tabanının doğasına bağlı ve benim gibi 2 kişilik bir ekipte TODO yaklaşımı gayet iyi çalışıyor.
    • Bizim ekip // TBD: [...] ifadesini bunun için kullanıyordu. TODO konusunda takıntılı olanlar fark etmesin diye kullanılan küçük bir hileydi.
  • Değerli ama takip edilmeye değmeyen bilinen sorunları kaydetmek için bir yere ihtiyaç olduğu kesin.
    Aslında düzeltme planı yoktur ama bir gün zaman olursa belki toparlanabilir mi diye ctrl-F ile aranabilecek bir iz bırakmak istersiniz.
    Çok fazla araç ve sürecin TODO'yu bir code smell olarak görmesini mantıksız buluyorum.
    • Ben açıkçası böyle bir durumla henüz karşılaşmadım.
      Bence bu sadece önceliklendirme meselesi; sonuçta kırık pencereye dönüşüyor (Pragmatic Programmer'daki meşhur benzetme).
      Gerçekten düzeltmemeye karar verdiyseniz, bunu yazılım dokümantasyonunda belirtmek daha iyi olur.
  • Yazıda örnek olarak verilen

    // TODO: If the user triple-clicks this button, the click handler errors because [xyz]
    bana gerçek bir TODO'dan çok normal bir yoruma yakın geliyor.
    Böyle açıklayıcı yorumlar kesinlikle faydalı ama buna TODO demek biraz zor.
    TODO, gerçekten yapılması gereken bir öğenin açık olduğu; yani "bu fonksiyon XYZ'e göre farklı bir değer döndürmeli" gibi değişmesi gerektiğini bildiren şey olmalı.
    Bu anlamda TODO'nun kod içine gömülü olması değil, issue tracker'da yer alması gerekir.
    Deneyimime göre TODO, PR onayı acil olduğu için kod kalitesinden ödün vermeyi meşrulaştıran bir araçtan ibaret. Gerçekte neredeyse hiç yerine getirilmez; sadece "vakti bol bir sonraki geliştiriciye kalır, belki bir gün çözer" düşüncesi bırakır.

    • Yorumlar, bu kodun neden böyle çalıştığını açıklamak içindir.
      Örneğin sadece
      // If the user triple-clicks this button, the click handler errors because [xyz]
      diye yazarsanız bunun bir bug mı yoksa kasten mi böyle olduğu net olmaz.
      TODO, "burada kusursuz olmayan bir kısım var, üzerinde çalışırken bunu dikkate al" diyen kısa bir işaret.
      Eğer gerçekten çözülmesi gereken bir işse, başka bir yerde takip edilmesi doğru olur.
      Ama TODO'ları azaltmaya çalışmak, bence sadece belgelenmemiş kod miktarını artırır.
    • Bence yukarıdaki örnek iyi bir TODO yorumu değil.
      O sürede doğrudan bug'ı düzeltmek ya da en azından "üçlü tıklama [xyz] yüzünden yok sayılır" gibi bir yorum bırakmak daha iyi olurdu.
      Tetikleyiciyi ve sebebi bulduysanız, işin zaten %80'ini bitirmişsiniz demektir.
    • Buna daha çok "skip" gibi bakılabilir. Çoğu zaman hiç ele alınmasa da olur.
      Sorun, kod tam çalışmıyorken çalışıyormuş gibi varsayılmasıdır.
      Gördüğüm en iyi TODO, güvenlik kodunda geçen "TODO: encrypt this" idi.
      Bu sayede kodun şifrelenmediği hemen anlaşılıyordu; ayrıca şifrelemenin başka bir modülde yapılıp yapılmadığı ya da iki kez şifrelenme riski konusunda tereddüt azalıyor.
    • Verilen örnek TODO'dan çok FIXME'e yakın.
      Açıkça bir hata ama ele alma gerekliliği nispeten düşük.
  • Buna kesinlikle katılmıyorum.
    Eğer bunu bug olarak kaydetmeyecek ya da gerçekten üzerinde çalışmayacaksanız TODO bırakmayın.
    // TODO: If the user triple-clicks this button, the click handler errors because [xyz]
    Bu sadece bir durum kaydı. TODO kelimesi çıkarılmalı.
  • Ben de bunu katmanlı kullanıyorum.
    FIXME, mutlaka düzeltilmesi gereken ya da sıradaki adımı net olan durumlarda kullanılıyor.
    TODO ise daha genel düşünceler için ya da sadece zihnimden çıkarıp bir sonraki işe odaklanmak amacıyla.
    Henüz tam olgunlaşmamış bir fikir olabilir, gerçekten yapılmalı mı emin olmayabilirim ya da ilgili başka bir şeyi bekliyor olabilirim.
    Yazmazsam aklımda dönüp duruyor; ama TODO ya da başka bir şey olarak not alınca psikolojik olarak çok rahatlatıyor.
  • Ben yorumları, kod yazma becerisinin yetersizliğinin bir işareti olarak görüyorum.
    Keşke kodu yoruma ihtiyaç duymadan hemen anlaşılacak şekilde yazabilsek.
    Yine de sonradan ben okuyunca bile anlamayacağım kadar kafa karıştırıcıysa mecburen yorum yazıyorum.
    Üzücü olan şu ki, biri sonradan kodu değiştirip yorumu güncellemezse, bu kez daha da fazla kafa karışıklığı yaratıyor.
    Bence TODO commit edilmiş kodda bulunmamalı; proje ya da issue yönetim sisteminde takip edilmeli.