README Driven Development

İnsanoğlu, zorluklar karşısında kolaya kaçmaya meyilli bir canlı. Kısayollar ve kestirmeler bir çok konuda “işimize geliyor”. Kod yazarken geçtiğimiz kısayollar, daha sonra karşımıza büyük dertler olarak çıkabiliyor. Yalnızca bizim değil, geçtiğimiz yollarda bıraktığımız izlerin üzerinden geçenler de bu problemlere maruz kalıyor (Önceki Yazılımcı Sendromu).

Herhangi bir konuda, aşmamız gereken engeli ne kadar yüksek tutarsak, kendimize ne kadar yüksek bir çıta belirlersek, kolaya kaçmamızı o derece engellemiş olur ve programımızı da ona göre daha doğru belirleriz.

Yazılımda yazdığınız kodda çıta yükseltme ve engel koyma (dolayısıyla bir yol belirleme) tekniklerinden daha önce haberdar oldunuz aslında. Bunlardan en bilineni ise kendinize koyduğunuz kuralları belirleyip “yeşili görene kadar kod yaz” anlayışına dayalı bir teknik olan TDD. Kodunuzun nasıl çalışması gerektiğini söyleyip, ona göre yazmaya dayanıyor.


Yazılım geliştirmeyle ilgileniyorsanız bir çok yerde zaten TDD, BDD gibi terimlere denk gelmişsinizdir. Size kendim bulduğumu sandığım fakat araştırınca aslında gerçekten de zaten var olduğunu gördüğüm bir fikirden, yaklaşımdan bahsedeceğim bugün: README Driven Development, yani README Güdümlü Geliştirme. Bu tanım uzun olduğu için ben de geleneğe uygun olarak kısaltıp RDD şeklinde kullanacağım.

README Güdümlü Geliştirme’de tek ihtiyaç “README.md”
RDD, TDD veya BDD’ye alternatif değil. TDD ve BDD’yi geliştirmeye yönelik bir yaklaşım. RDD desteği ile projeleriniz kesinlikle daha kullanılabilir oluyor.

RDD Kuralları neler?

RDD’de 3 temel kural mevcut. (Evet, ben uydurdum.)

  1. README.md: Projede ilk oluşturulacak dosya “README.md” olmalıdır. (Markdown olması şart değil, herhangi başka bir şey de olabilir. Fakat basitlik önem arzediyor). Farklı dosyalara bölebilirsiniz, fakat en başta tek “monolitik” bir README en başta yönetim açısından kolay oluyor.
  2. Vizyonu tamamen aktar: Projenin tüm detaylarını incelikle yazmalı ve düşüncelerinizi, projenin olması gereken özelliklerini ayrıntılarıyla belgelendirmeli. Dikkat edelim, hala hiç kod yazmıyoruz. Ve bu süreçte henüz hiç kod yazmadan bir çok bug’ın ilginç bir şekilde çözüldüğünü de göreceksiniz.
  3. Mükemmellikten ödün verme: Kod örneklerimizi README’ye istediğiniz basitlikte yazmalı. Ortada hiç kod olmadığı için istediğiniz kadar “atıp tutabilirsiniz”. RDD’nin en büyük avantajı bu: Böylece kod size yazdıkça şekil vermiyor, en başta yazmak istediğiniz kodun API’ının nasıl olması gerektiğine siz karar veriyorsunuz. TDD aşamasına geçtiğinizde de buna göre yazıyorsunuz ve aslında TDD aşamasında işler normalden daha kolay bir hal alıyor.

Önce TDD ile başlamanın nesi yanlış?

Yanlış değil tabii ki, fakat TDD’de de kodun size hükmettiği durumlar mevcut. Ayrıca direkt API’ı kullanarak başladığınız için düşüncelerinizin koda aktarımında “vizyon kayması” yaşamanız ve API’ı istemeden bozguna uğratmanız mümkün.

TDD direkt kod ile başlamaktan çok daha kolay. Bildiğiniz gibi TDD’de ön kurallardan birisi önce testleri yazmak. Fakat testlerin kendileri de birer kod olduğundan burada da çıtayı bir anda aşağıya çekmeniz mümkün. README’de daha vizyoner bir çizgi çizebiliyorsunuz.

TDD’de bir sürü Test araçları ve konfigürasyonlarıyla boğuşurken vizyon çizmek sizi bir nebze olsun dağıtırken, RDD’de (Markdown ve reStructuredText arasında kararsız kalmazsanız) bu mümkün değil.

README.md’de istediğiniz kadar “atıp tutmanız” mümkün. Kullanmak istediğiniz kodu yazın.

RDD neleri çözüyor?

  1. Geliştirme yapmak istediğiniz kütüphane/uygulama ön analizden geçmiş oluyor. Çünkü analizini yapmadığınız bir şeyi belgelendirmeniz mümkün değil.
  2. Sizi daha iyi TDD/BDD testleri yazmaya itiyor.
  3. Daha kullanılabilir API’leriniz oluyor, çünkü kullanmak istediğiniz kodu yazıyorsunuz.
  4. Projenizin yol haritası kendiliğinden oluşuyor.
  5. Projenizi kullanacak olan diğer kişiler için “dökümantasyon” oluşuyor.
  6. Kodunuzun okunabilirliği artıyor, çünkü yazmak istediğiniz şey çok önceden belirlenmiş oluyor.
  7. Projenizin kullanıcılarından herhangi bir yerde takılanlara “RTFM” deme hakkınız sizde saklı kalıyor.
Önceliğimiz “manual”ı yazmak. RTFM deme hakkımız olması için WTFM!

RDD için hangi araçları kullanmalıyım?

RDD’nin en güzel yanlarından birisi de bu. Kullanacağınız dile dahi README’yi bitirdikten sonra karar verebilirsiniz. Neticede henüz hiç kod yazmadınız. (Yalnızca kod örneklerini de ona göre değiştirmeniz gerekecek, ama zaten onlar da tamamen hayali).

Herhangi bir editör, RDD için yeterli. Ben genellikle GitHub’ın built-in editörünü ya da Vim tercih ediyorum. Fakat her şey olabilir. Framework falan da gerekmiyor.

Henüz yazmadığınız kodun dökümantasyonu ve nasıl kullanılacağı bile mevcut.

Markdown, reStructuredText ya da benzeri bir dil bilmek faydalı olacaktır. HTML gibi biraz daha karmaşık işlere girmek istemeyebilirsiniz, zira amacınız afilli bir dökümantasyon yazmak değil, vizyonunuzu aktarmak.

Eğer RDD’yi deneyeniniz olursa ya da “ben de böyle geliştiriyorum” diyen varsa cevaplarınızı bekliyorum.

Ek Notlar

Yazıyı yazdıktan sonra etraftan gelen kaynaklar doğrultusunda iyice araştırma fırsatım oldu. “Aklın yolu bir” hissiyatını hiç bu kadar hissetmemiştim.

Tom Preston-Werner (mojombo)’nun Gollum’a ilk commit’i “README driven development”

RDD’nin dünya genelinde oldukça yaygın bir teknik olduğunu gördüm. Hatta GitHub’ın eski CEO’su ve founder’ı Tom Preston-Werner ve Zach Holman’ın bu konuda yazıları mevcut. GitHub’ın Gollum projesinin ilk commit’i README’den oluşuyor.


Like what you read? Give Fatih Kadir Akın a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.