Tasarım belgelerinden çok throwaway code tercih etme eğilimi

• Yazılım geliştirmenin temiz ve düzenli bir akış izlediğini hayal ederiz

  • Tasarım belgeleri yazar, küçük değişiklikleri PR’larla yayına alarak özellikleri hayata geçiririz
  • Git geçmişi temiz ve düzenli görünür
  • Ancak gerçeklik farklıdır

• Tasarım belgesi ile gerçek uygulama arasındaki fark

  • Tasarım belgesini olduğu gibi uygulamak bir yanılsamadır
  • Kodlamaya başlayınca tasarım belgesindeki içerik değişir
  • Planlar, düşmanla temas ettiğinde hayatta kalmaz

• Yeni tasarım metodolojisi: koda dalmak

  • Taslak PR kullanarak prototip uygulanır
  • Erken dönemde geri bildirim alınarak yaklaşım ayarlanır
  • Taslak PR, tarihsel tasarım fikirlerini belgelemek için kullanılır
  • Taslak PR’ı tamamen çöpe atmaya hazır olunur
  • Taslak PR’dan aşamalı olarak kademeli PR’lara geçilir
  • Her PR adım adım test edilir ve dayanıklılığı güçlendirilir

• Olgunluğun önemi

  • Kodlanan fikri çöpe atabilme yeteneği önemlidir
  • Önemli olan kod satırları değil, kurumsal bilginin aktarımıdır
  • Prototip çalışmasının boşa gitmemesi için önemli noktalarda erken hizalanma sağlanır

• PR’ı dokümantasyon olarak kullanma yöntemi

  • PR, geliştiriciler için en iyi dokümantasyon biçimlerinden biridir
  • PR, belirli bir andaki durumu yansıtan tarihsel bir artefaktır
  • Tasarım belgeleri çoğu zaman gerçeklikten farklı bilgiler sunar

• Prototipin önemi

  • Bir prototip, 1000 tasarım belgesinden daha değerlidir
  • Değişimi yönlendirmek gerekiyorsa bu belgeyle değil kodla yapılmalıdır
  • Kurum, prototipi bir cevap olarak değil bir soru olarak görmelidir

• Tasarım belgelerinin faydası

  • Farklı paydaşlardan gelen geri bildirimleri organize etmek ve arşivlemek için faydalıdır
  • Fikir çok kavramsal ya da uzun vadeli olduğunda faydalıdır
  • Fikri yazıyla ifade etmek, kodlamaktan daha verimli olduğunda faydalıdır
  • Kurumun ilk çözümü çöpe atabilecek disipline sahip olmadığı durumlarda faydalıdır
  • Genç çalışanların kıdemli geliştiricilerin fikirlerini güvenli biçimde sorgulayabileceği bir ortam sağlar

• Tasarım belgelerinin yanlış kullanımı

  • Daha az deneyimli geliştiricilerin sürecini yavaşlatmak için kullanılır
  • Dokümantasyon olarak kullanılır ama hızla güncelliğini yitirir
  • Tüm tasarım problemlerini çözmeye çalışır, ancak gerçek sorunlar kodlama sırasında ortaya çıkar

• Ekip disiplinli olabiliyorsa, hacklemek tasarım yapmaktan çok daha verimlidir

  • Kurum içinde bu tür bir disiplin oluşturulması tavsiye edilir
  • Sonuçta kod, sözlerden daha güçlüdür

[GN⁺]

Hacker News görüşü

• Prototipleme, tasarım sürecinin önemli bir parçasıdır; problemi tanımlamak ve çözümü netleştirmek gerekir

  • Bazen basit bir doküman yeterlidir, bazen ise çok fazla geri bildirim ve iterasyon gerekir
  • "Birkaç haftalık kodlama, birkaç saatlik planlamadan tasarruf sağlayabilir" diye bir söz vardır

• Yazmak, problemi keşfetmek için faydalıdır; sorunu anladığını düşündüğü halde yazarken yeni sorular ortaya çıktığını deneyimlemiş

  • Mentorunun Lucidchart kullanarak 6 aylık çalışmayı anlattığı bir örneği hatırlatıyor

• Bir projeyi son tarihe yetiştirmek için geçici çözümler kullandığı deneyimi var

  • Geçici çözüm, prod destek aracı olarak da kullanılıyor ve kalıcı sürüm durdurulursa alternatif yol olarak değerlendiriliyor

• Tasarım dokümanlarının en büyük sorunu, kimsenin onları okumamasıdır

  • Prototiplemenin sorunu ise insanların bunu nihai kod sanmasıdır
  • Hibrit bir yaklaşımı tercih ediyor; planlama ve dokümantasyonu titizlikle yapıp, nihai üründe kullanılabilecek kalitede prototip kod yazıyor

• Kod ve tasarıma verilen geri bildirimin farkı büyüktür

  • Tasarım dokümanları, problem alanına dair "neden" sorusunu teşvik eder
  • Prototip çalıştığında bu soruları gündeme getirmek zorlaşır

• Çok fazla kod yazıp neyin işe yaradığını görmek iş tanımının kendisiyse, GPT bunu daha hızlı ve daha ucuza ikame edebilir

  • Ne inşa edilmesi gerektiği konusunda uzlaşmaya varmak her zaman zordur

• Yazılım geliştirmenin temiz ve düzenli bir akış izlediğini hayal eden neredeyse kimse yoktur

  • Kod yazmak, yazı yazmaya benzer; ilk taslaklar her zaman kötüdür ve iyi yazı çokça revizyonla ortaya çıkar

• Kodun Jenga gibi üst üste yığılıp kimsenin dokunmak istemediği hale geldiğini gördüğü olmuş

• Tasarım kararlarını belgelemek için sürekli yorum dizileri kullanılan bir süreci tercih ediyor

  • Bu süreci GitHub issue'larıyla yürütüyor

• Bu yaklaşım üzerine düşünüyor; en kötü senaryoda çok zaman boşa gidebilir

  • Problemi yeterince düşünüp doğru implementasyon için gerekli özellikleri tarif edebildiğinde, tasarım dokümanı yazmanın en faydalı olduğu zamanlar bunlardı
  • Kısmi çözümleri uygulayıp bunları kademeli olarak iyileştirmek de başarılı oldu