Tag: mimari

Eminim çok kez başınıza gelmiştir; geliştirme yaparken, çözmeye çalıştığınız ana problem yerine bir anda kendinizi teknik sorunlarla boğuşur halde bulmak. IDE sorunları, network sorunları, yanlış konfigürasyonlar… Siz de benim gibi iseniz içinizden geçmiştir; ben elimdeki probleme odaklanmak yerine neden bunlarla uğraşıyorum.

Fred Brooks 1975 tarihli “The Mythical Man-Month” kitabında yazılım geliştirmenin zorluklarını asli(essential) ve arızi(accidental) olarak ikiye ayırıyor. Asli zorluklar problemin özü ile ilgili ve çoğu zaman soyut şeyler: veri yapıları ve aralarındaki ilişkiler, algoritmalar. Problemi nasıl çözersek çözelim oradalar. Arızi zorluklar ise probleme ürettiğimiz çözümden – yani yazılımdan ve üretim süreçlerinden kaynaklı zorluklar. Aynı problemi farklı teknoloji çatıları ile çözebiliriz esas aynı kalacak; karşılaştığımız sorunlar farklılaşacaktır.

Peki bu bilgi gerçek hayatta ne işimize yarayacak?

• Brooks, yazısında arızi tarafta büyük gelişmelerin zaten yaşandığını ve artık buradaki iyileştirmelerin etkisinin kısıtlı olacağını söylüyor. Değer önerimizin hangi tarafa düştüğünü değerlendirerek kariyerimize yön verebiliriz. Bir .NET geliştiricisi olmak mı finans sitemlerinde uzman olmak mı daha değerli?
• Modüler ve bağımsız bir sistem hepimizin isteği peki modül sınırlarını nasıl belirleyeceğiz? Alın size bir başlangıç kriteri: asli olanı arızi olandan ayırabilirsiniz. Örneğin bir kelime işlemci uygulamasında kelimeleri dosyadan okuduğunuz ve yazdığınız bir modül(arızi), kelimeler üzerinde işlem yaptığınız başka bir modül(asli), kelimeleri ekranda görselleştiren başka bir modül(arızi) olabilir.
• Asli zorlukları aşmanın bir kısa yolu yok gibi görünüyor size sunulan sihirli değneklere mesafeli yaklaşın. Paydaşlarla o uzun konuşmalar yapılacak, isterler belirlenecek, sistemler tasarlanacak, demolar revizeler olacak …

Çocukken keyifle izlediğim Hulk Hogan çizgi film serisinin aklımda kalan bir bölümü var. Güreşçi olan ana karakterlerden Captain Lou’nun kilo vermesi gerekir ve bir güreşçi arkadaşı ona yardım teklifinde bulunur. Yapılacak şey basittir; bu arkadaş normalde yediği porsiyonların yarısını yiyerek kilo vermeyi başarmıştır ve Captain Lou’ya da bunu uygulamayı önerir. Captain Lou kilo vermek bir yana kilo alır çünkü atladıkları bir detay vardır; arkadaşın normalde yediğinin yarısı Captain Lou’nun normal porsiyonunun iki katıdır.

Sektörümüzün kötü bir alışkanlığı var; başkalarının reçetelerini bilinçsizce kullanmak. Bu reçeteler belirli hastalıklara çare olması için yazıldı hastalığınız aynı değilse; ilaçlar işe yaramadığı zaman şaşırmamalısınız (işe yarayıp yaramadığını ne kadar tartabiliyoruz tartışılır ama o başka bir yazının konusu). İlaçlardan fayda alamamak bir yana daha kötü bir durum ilaçların size yan etki yapması olur.

Bu alışkanlığın en yakın örneklerinden birini mikroservis mimarisinin kullanımında gördük. Yazılım ekipleri, ellerindeki problemin ölçek ihtiyaçlarına bakmadan, bu mimariyi başarılı bir şekilde uygulamanın gereklerini göz önüne almadan kullanmaya kalktılar ve sonu hüsran oldu. Şimdilerde mahallede yeni bir havalı çocuk var – modular monolith …

Captain Lou sonunda kilo vermeyi başarıyor nasıl olduğunu ben anlatmayayım siz buyrun izleyin. Çözülecek her problem, çözüm üretecek her şirket, her ekip farklı sıklette; dinamikleri, kısıtları farklı. Bize düşen çözüm aranan problemi iyi analiz etmek, içinde bulunulan bağlamı göz önünde bulundurmak, olası çözümlerin artılarını eksilerini iyi değerlendirmek ve ancak sonra tercihlerde bulunmak.