Yazılımı Yıkmanın Estetiği - Belirsizliğe Karşı Nasıl Mücadele Edilir

• Yazılımda pek çok şey belirsizdir.
• Bunun nedeni nedir?
  • En büyük neden, işin doğasında bulunan karmaşıklığın var olmasıdır.
  • Karmaşıklık nedeniyle durum sürekli değişir ve bu yüzden geliştiricinin öngörüleri yüksek olasılıkla yanlış çıkar.
  • Emek verilerek kurulan kule yıkılır ve olduğu gibi teknik borca dönüşür.
  • Daha küçük ölçekteki neden ise bilgi ve deneyim eksikliğidir.
  • Bilgi ve deneyim yoksa, geliştirici kendi elleriyle teknik borç üretebilir.
  • İş karmaşıklığı, geliştiricinin kontrol edemediği dış etkenlerdir; buna karşılık bilgi ve deneyim, geliştiricinin kontrol edebildiği iç etkenlerdir.
• Geliştiricinin önünde üç yol vardır.
  • Karmaşıklığa karşı koymanın anlamsız olduğunu düşünen karamsar yol
    • “Nasıl olsa değişecek, öyleyse yap gitsin”, “Teknoloji anlamsız” gibi sözler söylenmeye başlanır.
    • Rahat ve konforlu bir yol olduğu için kişi fark etmeden bu yolu seçebilir.
  • Karmaşıklığı görmezden gelip yalnızca ideal bir hayali düşünen yol
    • Kişi, kendi ideal gördüğü tek bir teknolojiyle her şeyi çözebileceğine inanır.
    • Katı ve tekdüze bir düşünce yapısına sürüklenir.
    • Geliştiricinin kolayca düşebileceği ama çıkmasının zor olduğu bir yoldur.
  • Karmaşıklığı kabul edip onunla mücadele eden yol
    • Mükemmel olunamayacağını kabul etse de daha iyi yolu aramayı sürdürmektir.
    • Zor ve dayanılması gereken bir yoldur.
  • Yazılım geliştirme, sürekli olarak karmaşıklıkla mücadele etmiştir.
    • Mimari, metodolojiler, Agile vb…
    • Sırada ne ortaya çıkacak?
• Yıkım odaklı geliştirme
  • Gerçeğe bakıldığında, “nasıl olsa silinecek” şeklindeki karamsar düşünceye kapılmak kolaydır.
  • Çünkü büyük emekle yazdığımız kodun başarısız bir ürün olduğunu hissedip onu kendi elimizle silmek çok acı vericidir.
  • Peki ya tersinden düşünüp, en azından iyi silinebilecek şekilde yapmak nasıl olur?
• Yıkım iyi bir şey midir?
  • Yıkım olmazsa yeni olan doğamaz.
  • Yazılımda görülebilen yıkım genel olarak ikiye ayrılır: pivot ve refactoring.
  • Pivot, organizasyonun ve ürünün daha iyi bir yol seçmesini sağlar.
  • Refactoring ise yazılımın ömrünü uzatmak için mutlaka gerekli bir iştir.
• O halde yıkım odaklı geliştirme nedir?
  • Kodun bir gün yıkılacağı gerçeğini kabul edip, bunu gözeterek geliştirme yapma metodolojisidir.
  • Üç büyük ilkeye yönelir.
    • Belirsizlik varsa, mümkün olduğunca belirsizliği azaltır.
    • Birden fazla yöntem seçilebiliyorsa, yıkması daha kolay olanı seçer.
    • Yalnızca gerekli olanı korur. Bu nedenle gereksiz olan her şeyi siler.
  • Analiz -> sınırların ayrılması -> kodun uygulanması -> karmaşıklığın giderilmesi
  • Temel nokta, iç etkenlerden kaynaklanan belirsizliği azaltmak ve kaçınılmaz dış etkenlerin yol açacağı yıkıma hazırlıklı olmaktır.
• Sınırların ayrılması
  • Belirsizlik, değişim oranıdır ve buna dayanarak ayrıştırma yapmak mümkündür.
  • Geliştirici, dış etkenlere hazırlanırken iç etkenlerden kaynaklanan değişim oranını mümkün olduğunca düşürmelidir.
  • Her etkenin değişim oranı kuruma göre farklı olabileceğinden bunu sabit bir sayıyla ifade etmek mümkün değildir -> sezgisel yöntemlerle ölçülür.
    • Örn.) story point ölçümü
  • Neyin ölçüt alınarak ayrılacağını belirlemek için soyutlama seviyesine karar verilmelidir.
• Yıkılabilirlik
  • Uygulama aşamasında büyük ilkeler doğrultusunda yıkması kolay olan taraf seçilmelidir.
  • Bağımsızlık, kavranabilirlik ve kontrol edilebilirlik dikkate alınarak yıkılabilirlik değerlendirilebilir.
    • Bağımsızlık; coupling ve cohesion düzeyi ile tek sorumluluk ilkesine ne kadar uyulduğuna göre değerlendirilir.
    • Kavranabilirlik, geliştiricinin koda bakıp onu ne ölçüde anlayabildiğidir.
    • Kontrol edilebilirlik ise geliştiricinin kontrol edebildiği bir alan olup olmadığını ifade eder.
• Karmaşıklığın giderilmesi
  • Gereksiz bir şey olup olmadığı kontrol edilmeli ve kaldırılmalıdır. Yani sonuçta kod tabanında yalnızca gerekli olanlar kalmalıdır.
  • Deadline gibi nedenlerle bunu yapmak zorsa, sadece kayda geçirip daha sonra yapmak da sorun değildir.
    • Çünkü iç etkenler kontrol edilebilir.
  • Temel nokta, yıkıma hazırlıklı olmak için mümkün olduğunca sadeliği korumaktır.
• Kodu yıkmanın tekniği
  • Kodu iyi silebilmek için çeşitli ilkeler ve yöntemler vardır.
  • Adımları bölmek (refactoring pattern)
  • Referans şeffaflığını korumak
  • Tek sorumluluk ilkesine uymak
  • Arayüz ayrımı ilkesine uymak
  • Strangler Fig pattern
  • Metot uzmanlaştırma
  • Tekrarlı kod yazımı
  • Değişim oranını kaydetmek

[annonymous1]

Bilgi ve deneyim eksikliğinin kod borcu yarattığı sözü bana pek ikna edici gelmiyor.

-> Gereksinimleri hayata geçirmek için verilen süre yetersiz olabilir; ayrıca birlikte çalışılan ortamlarda başkalarıyla uyum sağlamak için bir miktar teknik borcu göze almak da gerekebilir. Durumların çeşitli olduğunu düşünüyorum.

Bilgi ve deneyimi geliştiricinin kontrol edebileceği iç faktörler olarak görmek de bana pek doğru gelmiyor.

-> İş dünyası karmaşık; hangi durumla karşılaşılacağını öngörmek mümkün değil, bu yüzden her olasılığı anında çalışmak da mümkün olmuyor. O durumla karşılaşıp sonradan öğrenseniz bile, bir dahaki sefer bambaşka bir sorun çıkıp o bilginin işe yaramaz hale gelmesi de mümkün.

[kciter1]

Merhaba. Görüşünüz için teşekkür ederim.
Ben, ancak uç noktalara baktığımızda özün görülebileceğini düşünüyorum. Bu açıdan bakınca, eğer ‘bilgi ve deneyim’e kusursuz biçimde sahip olsaydık, süre içinde borç değil kod üretebileceğimizi düşündüm.

Zamanın yetersiz olması iki duruma ayrılabilir. Birincisi, kelimenin tam anlamıyla uygulama için gereken sürenin yetersiz olduğu durumdur. Bu durumda, bilgi ve deneyimden bağımsız olarak kod yazmak için fiziksel zaman yetersiz kalır. Dolayısıyla en baştan hedefe ulaşmanın imkansız olduğu bir koşuldur. İkincisi ise neyin iyi olduğunu anlayacak zamanın yetersiz olduğu durumdur. Böyle bir durumda, uygulama yöntemlerini öğrenmeye ya da daha iyi seçenekleri bulmaya zaman olmadığı için, yalnızca o anda sahip olunan bilgiyle kod yazıp işi bitiririz. İşi bu şekilde tamamladığımızda, ‘bir yerlerde bir şeylerin yanlış olduğunu’ biliriz ama tam olarak nasıl düzeltilmesi gerektiğini bilemeyiz. Eğer kesin bilgiye sahip olsaydık ve buna ilişkin deneyimden güven kazanmış olsaydık, böyle bir sorun ortaya çıkmazdı.

Yukarıda yazdığım zaman yetersizliği meselesinin benim görüşümü desteklediğini düşünüyorum. Elbette gerçek hayatta bu son derece zor bir meseledir. Ben sadece ideal olanı söyledim. Bilgi ve deneyimin kusursuz olduğu bir durum nadirdir ve sizin de söylediğiniz gibi, organizasyon için bunu bilerek göze alma durumları da elbette vardır. Bu haksız hissettirebilir ama ben bu sorunun, ‘uç noktadan bakarsak’, bilgi ve deneyim eksikliğinden kaynaklandığını düşündüm.

İkinci olarak sözünü ettiğiniz iç etkenler basit. ‘İş dünyası karmaşık olduğu için hangi durumla karşılaşılacağını öngörmek mümkün değil …’ Bu kısım, benim yazdığım metindeki ‘işin karmaşıklığı’ ile ilgili bölümdür. Yani bu, dış etkenlerden kaynaklanan bir sorundur. Dış etken olduğu için geliştiricinin bunu kontrol etmesi mümkün değildir ve bu yüzden korku hisseder. Buna da uç bir bakışla, işin karmaşıklığının hiç olmadığını varsayarsak, geriye yalnızca geliştiricinin yazdığı kod kalır. O zaman da içeride kontrol edilebilen yalnızca ‘bilgi ve deneyim’ sorunu kalır.

Elbette benim yazdığım metin de sadece benim görüşüm. Buna karşı yeterince çok örnek bulunabilir. Görüş alışverişinin bizi daha iyi bir yola götürebilecek bir fırsat olduğunu düşünüyorum. Bundan sonra da görüşlerinizi paylaşmanızı rica ederim. Teşekkür ederim.

[annonymous1]

Nazik yanıtınız için teşekkür ederim.

[winterjung]

Yazıyı keyifle okudum. Görünüşe göre organizasyonun bulunduğu aşamaya göre neyin erken optimizasyon ve neyin aşırı mühendislik olduğu da değişiyor. Zaten yeniden yazılması gerekecek bir kod olması, ama o yeniden yazma anının gelip gelmeyeceği de belirsiz olan bir kod olması zorlayıcı nokta gibi görünüyor. Ben bazen xxx hizmeti ya da özelliği ortadan kalkarsa yyy kodu ve verisi için en uygun yer neresidir? sorusuyla da karar veriyorum; başkalarının yöntemlerini de merak ediyorum.

[savvykang]

Kodun yanı sıra veri veya şemanın da ortadan kalkıp kalkamayacağını ya da değişip değişemeyeceğini düşünmeye çalışan taraftayım

1. DB şeması, protokol (REST API gibi), işlev olmak üzere üç sınıflandırma içinde kodun nereye ait olduğunu düşünürüm. Şema ve protokol kaçınılmaz olarak şirket içindeki koda ya da dışarıya yayılır; bu yüzden sonradan değiştirmek isterseniz bunu tek başınıza birkaç günde çözemezsiniz, iş birliği gerekir. Bu nedenle tasarım aşamasında biraz daha fazla zaman harcarım
2. Kodun ele aldığı verinin yaşam döngüsünü ve geçiciliğini düşünürüm. winterjung'un düşündüğü, hizmetin ortadan kalktığı durum da buna dahil olabilir gibi görünüyor. OLTP'de konuşulan defter, işlem, geçmiş tablo sınıflandırması da bu tür düşünmeye başlamak için bir yöntem olabilir diye düşünüyorum

[kciter1]

Veriyle ilgili içerik de eklemek istiyordum ama kafamda netleştirmekte zorlandım. Kritik bir alan olduğu için kolayca dokunmak zor ve yanlışlıkla migration cehennemine düşme ihtimali de olduğundan temkinli davrandım.

Dediğiniz gibi ilk tasarım aşaması çok önemli görünüyor; asıl kilit nokta RAW verinin olabildiğince iyi bir şekilde birikmesini sağlamak olacaktır. Ya da event sourcing mimarisi, silme açısından avantajlı olabilir. Elbette bu mimariyi doğru düzgün kullanmışlığım olmadığı için bunun gerçekten geçerli olup olmayacağından emin değilim.