Yazılım geliştirme algoritmamız

• Yakın zamanda tanınmış bir teknoloji CEO’su ve mühendisle yaptığım bir sohbette ilginç bir yazılım geliştirme metodolojisi duydum. Bu metodoloji, diğer sezgisel yöntemler ve genellemeler üzerine düşünmeme yol açtı.

Onun yöntemi

• Güne bir özellik üzerinde çalışmaya başlayarak başla. Günün sonuna kadar bitiremezsen hepsini sil ve ertesi gün yeniden başla. Yazdığın birim testlerini koruyabilirsin.
• Birkaç gün sonra hâlâ özelliği hayata geçiremediysen, bunu mümkün kılacak temel yapı, altyapı veya refactoring ihtiyacını düşün ve bunları uyguladıktan sonra özelliğe geri dön.
• Bu yöntem, 90’ların sonu ve 2000’lerin başındaki extreme programming hareketine benziyor.

Yöntem üzerine düşünceler

"Her şeyi iki kez yaz"

• Junior mühendislere verilen bir tavsiye: problemi çöz, kodu branch’e kaydet, sonra tekrar yaz.
• Bu yöntemi, dizüstü bilgisayarım bozulduktan sonra tesadüfen keşfettim. Yeniden yazım, ilk uygulamanın yalnızca %25’i kadar zaman aldı ve sonuç çok daha iyiydi.
• Zamanın 1,25 katına karşılık 2 kat daha yüksek kaliteli kod elde edebilirsin. Uzun vadeli bakım gerektiren projelerde faydalıdır.
• "Her gün yeniden başla" yöntemi bunun daha da uç bir hâli. Her yeniden yazışta daha pürüzsüz bir çözüm buluyorsun.

"Nicelik kendi başına bir niteliktir"

• Stalin’in sözü yazılım mühendisleri için de geçerli. Junior mühendisler için ilk 100 bin satır kod yazmak zorunlu.
• "Her gün yeniden başla" yöntemi, bu 100 bin satırı daha hızlı yazmana yardımcı olur.
• Aynı problemi tekrar tekrar çözmek, kalıpları hafızaya yerleştirmek açısından faydalıdır.
• 5 bin satır mükemmel kodla tüm ana kalıpları görebilirsin. Kalan 95 bin satır ise tekrar yoluyla nöronları yeniden düzenler.

"Silah başına dayanmışken" sezgisel yöntemiyle karşılaştırma

• Bir problem için çözüm öneren kişiye, "Bunu 24 saat içinde bitirmen gerekse ne yapardın?" diye sor.
• Bu yöntem, çerçeveleme ve anchoring bias etkisini kırar. Çoğu zaman birkaç dakika içinde, bir günde bitebilecek bir plan ortaya çıkarabilir.
• Pratikte bu plan gerçekten bir günde tamamlanabilir olmayabilir, ama yeni çözüm çoğu zaman birkaç gün içinde bitirilebilir.
• Bu düşünce deneyinin amacı gerçek çözümü üretmek değil, çözüm için alt sınırı belirlemektir.

Yol bulma

• Asıl mesele, problem uzayında bir yol bulmaktır. Her yol bir çözümdür ve mühendisin görevi en iyi yolu bulmaktır.
• Bu sezgisel yöntemlerle çeşitli yol bulma algoritmaları arasındaki benzerlikler üzerine düşünmeye değer.
• Mühendislik sezgileri için de aynı şey geçerlidir: daha iyi bir mühendis olmak, problem uzayında daha iyi yollar bulmak demektir.

GN⁺ özeti

• Bu yazı, yazılım geliştirmede verimli metodolojileri ve sezgisel yöntemleri inceliyor.
• "Her gün yeniden başla" yöntemi ile "Her şeyi iki kez yaz" yaklaşımı, kod kalitesini artırmada faydalıdır.
• Tekrarlayan problem çözümü, örüntü tanıma ve nöronların yeniden düzenlenmesine yardımcı olur.
• "Silah başına dayanmışken" sezgisel yöntemi, çözümün alt sınırını belirlemede faydalıdır.
• Problem uzayında en iyi yolu bulmak, mühendisin temel rolüdür.

[ahwjdekf]

Delirdiniz mi? Buna ancak vakitten geçilmeyen insanlar kalkışabilir; bunun gerçek hayatta yapılabilir bir şey olduğunu mu sanıyorsunuz?

[dlehals2]

Kore'deki SI ortamında bu imkansızdır herhalde.. haha, olsa olsa kişisel projelerde

[kaistj]

Bu yaklaşım gerçekten hiç aklıma gelmemişti.
Bir kez denemem gerekecek haha

[eususu]

Yeniden yazma konusunda size fazlasıyla katılıyorum.
Bir keresinde üzerinde çalıştığım kodu yanlışlıkla silmiştim ve yeniden yazarken
ortada tasarımı değiştirmeye üşendiğim için görmezden geldiğim şeyleri de hesaba katarak geliştirdim,
sonuç ise aksine daha iyi oldu.

[GN⁺]

Hacker News görüşleri

• Yeni bir özelliği iki kez yazmak iyi bir strateji olabilir. Ancak iş geliştirme uzmanlarına veya proje yöneticilerine gereksiz bir gecikme gibi görünebilir

  • Özelliği baştan sona bir kez yazmak, mantığı düzenlemeye ve refactor etmeye yardımcı olur
  • Yeniden yazım, mantık akışını netleştirir ve planı daha doğrusal şekilde izlemeyi mümkün kılar
  • Daha sonra büyük çaplı refactor ihtiyacını azaltma eğilimindedir

• "24 saat içinde bitirmek zorunda olsaydın?" sorusu, proje yöneticisinin sorabileceği bir soru değildir

  • Bu, kişisel ve eğitsel bir alıştırmadır; işi daha hızlı bitirmenin bir yöntemi değildir

• İyi kod, doğru soyutlamaları seçerek yazılır

  • Doğru soyutlamayı seçmek için bütünün tamamını bilmek gerekir
  • Diğer mühendislik alanları, CAD yerleşimi gibi iyi blueprint paradigmaları kullanır
  • Yazılımda ise bu tür blueprint'ler eksiktir
  • Deneyimin önemli olmasının sebebi, bu dengeyi kurabilmektir

• Yetkin ekip arkadaşları varsa, kısa sürede neler yapılabileceğini gösterebilirler

  • Hızlı çalışmanın önemli olmasının birçok nedeni vardır
  • Araba tamirinde olduğu gibi, ne kadar uzun sürerse yeniden monte ederken bir şeyi unutma olasılığın o kadar artar
  • Bir özelliği bir günde hayata geçirmek riski azaltır
  • Araçlara dair sağlam bir kavrayış ve güvenilir bir CI/CD süreci gerekir

• Yazılımı iki kez yazmanın iyi olduğu fikrine katılıyorum

  • Bir kez yazdığım kodu kaybettikten sonra tekrar yazma motivasyonumu kaybediyorum
  • Yeniden yazmaya çalıştığımda odaklanamıyorum ve yaklaşımı hatırlayamıyorum

• Bir özelliği birkaç gün sonra bile uygulayamıyorsan, önce gerekli altyapıyı ya da refactor işlemlerini yapman gerekir

  • Araçların 'söz varlığını' kurmak ve sürdürmek önemlidir

• "24 saat içinde" ile "her şeyi iki kez yaz" birbiriyle bağlantılıdır

  • Kodu özensiz yazarsan, sonunda zaten yeniden yazmak zorunda kalırsın

• Bu gönderi, en iyi "programlama tavsiyeleri"nden biri

  • grug brained developer tavsiyesine benziyor

• Bazen bir sorunu çözmek için arka planda bir thread çalıştırmak gerekir

  • Daha deneyimli kişiler bu tür sorunları daha hızlı tespit edebilir
  • Bazen sorunu bir süre bırakıp başka bir işle uğraşmak daha iyidir

• Şu yaklaşım faydalıdır

  • Önce sorunu çözmek için birden fazla fikri yazarım
  • İşi, 'tek bir oturumda tamamlanabilecek' parçalara bölerim
  • Her oturumun sonunda kodun her zaman 'çalışır' durumda olmasını sağlayacak şekilde uygularım
  • Her oturumun sonunda yorumlara ya da README'ye bir beyin boşaltımı yazarım