README Driven Development (2010)

• README odaklı geliştirme: yazılım geliştirme sürecinde önce README yazmayı esas alan bir yaklaşım
• TDD, BDD, Extreme Programming, SCRUM gibi çeşitli geliştirme metodolojileri ve teknikleri hakkında sıkça şeyler duyarız
  • Ancak geliştirdiğimiz yazılım kullanıcı ihtiyaçlarını karşılamıyorsa bunların hepsi anlamsızdır
  • Uygulama kusursuz olsa bile yanlış bir spesifikasyonu takip ediyorsa değersizdir; belgelenmemiş güzel bir kütüphane de neredeyse değersizdir
  • Yazılım yanlış problemi çözüyor ya da nasıl kullanılacağı anlaşılamıyorsa ciddi sorunlar ortaya çıkar

Çözüm: README ile başlamak

• Neden önce README yazılmalı
  • Kod, test ya da hikâyeler yazmadan önce README'yi yazın
  • README yazmak, iyi bir yazılım üretmenin gerekli bir adımıdır
  • Yazılım hakkında önce yazıya dökmeden neyi kodlayacağınız netleşmez
  • README sayesinde proje üzerine sistemli biçimde düşünebilirsiniz
• Önce README yazmanın faydaları:
  • Projeyi sistemli biçimde düşünme fırsatı:
    • Kodu değiştirmeye gerek kalmadan proje üzerine sistemli biçimde düşünebilirsiniz
    • Kodlamadan önce projenin yapısını ve içereceği API'leri değerlendirebilirsiniz
  • Kaliteli dokümantasyon elde etme:
    • Projenin başında, motivasyon ve ilgi yüksekken dokümantasyonu yazabilirsiniz
    • README'yi sonradan yazmak sıkıcı olabilir ve önemli ayrıntıların atlanmasına yol açabilir
  • Ekip çalışmasında verimlilik artışı:
    • Ekipteki diğer geliştiriciler, proje tamamlanmadan önce arayüz hakkında bilgi sahibi olup başka işlere güvenle başlayabilir
    • Net bir arayüz olmadan çalışmak, büyük çaplı kod yeniden çalışmasını gerektirebilir
  • Somut tartışmalar için zemin sağlama:
    • Önerilen çözümü metin olarak yazma gibi basit bir eylem, herkesin net bir fikirle tartışmaya katılmasını sağlar
• README Driven Development (RDD)'nin özellikleri:
  • RDD, Documentation Driven Development (DDD)'nin bir alt kümesi veya daha sınırlı bir sürümü olarak görülebilir
  • RDD, tasarım belgesini tek bir dosyayla sınırlandırarak aşırı spesifikasyon yazımı sorununu önler
  • Küçük ve modüler kütüphanelerin korunmasını teşvik eder

Sonuç

• README yazma sürecini gerçek bir "yaratım eylemi" olarak düşünün
• Tüm parlak fikirleriniz bu belgede ifade edilmeli; belge kendi başına yaratıcılık ve ifade gücünün bir kanıtı olmalıdır
• README, kod tabanındaki en önemli belge olmalı ve ilk önce yazılması doğru yaklaşım olmalıdır

[princox]

Yazılım, roman ya da film fark etmeksizin, hangi türde bir yaratım olursa olsun
önüne kağıdı koyup tasarımını ve planlamasını yaparak ilerlersen, daha ince ayrıntıları daha kolay gözetebilirsin diye düşünüyorum.. :)

[markman]

En temel şeyi bunca zamandır unutarak yaşamışım; artık bunu uygulamaya koymam gerekiyor.

[halfenif]

Buna "temel tasarım" demeye karar verdik.

[gargoyle92]

İstemeden de olsa çalışma biçimim ve bağlamım buna benziyor.
Sanırım o kısım README biçiminde ortaya çıkıyor.

Ben çalışırken What, Why, How gibi şeyleri net biçimde yazıp ilerlerken yapılması gereken işin şeklini oluşturan taraftayım; bu açıdan benziyor.

[kandk]

README odaklı geliştirme

[dbs0829]

Biz bir araştırma organizasyonuyuz; bu yüzden araştırma sonuçlarını kod biçiminde yayımlama konusunda epey düşündüm, ama README odaklı geliştirmenin bize oldukça uygun olabileceğini düşünüyorum. Araştırmanın başlangıç aşamasından itibaren üzerine düşünmeye değer bir yaklaşım gibi görünüyor.

[jamsya]

Benzer şekilde backend işi yaparken de ekrana bakıp önce API dokümantasyonunu kabaca yazmayı deniyorum,
bu da deneme yanılmayı azaltmada epey yardımcı oldu.

[bbulbum]

Bir bakıma, önce çözülmesi gereken problemi tam olarak tanımlamanın önemini hissettiriyor.

[xguru]

2010 tarihli bir yazı; başka bir yazıya bakarken denk geldim, paylaşayım dedim.