S.a. Arkadaşlar,
Kod basitliği kitabının artık iyice sonlarına yaklaştık. Şimdiye kadarki tüm yazılarımızda basitliğin üzerinde durduk. Hep olması gerekeni konuştuk, onu uygulamaya çalıştık. Özellikle bir önceki bölümde basitliğin üzerinde iyice durduk. Bu yazımızda basitliğin tersi olan karmaşıklığı ele alacağız. Uzun olmaması için yazıyı yine ikiye ayırıyor olacağız. Hazırsanız başlayalım...
Eğer bu işi profesyonel olarak yapıyorsanız belki de karşılaşmışsınızdır. Projeye başlarken en güncel teknolojiyi kullandınız, fakat üzerinden 5 yıl geçti ve artık teknoloji ihtiyaçlarınıza cevap veremiyor. Onu yeniden yazmaya kalkarsanız 5 yılınız daha gider. Siz bu geliştirmeyi yaparken belki de başka bir şirket sizden daha hızlı geliştirme yaptı ve ürününü piyasaya sürdü. Biz biliyoruz ki tüm bu söylemlerin ana dayanağı karmaşıklıktır. Basit bir projeye başlarsınız. Bir ayda bitireceğiz dersiniz , ek isteklerle 3 aya çıkar, proje karmaşıklaşmaya başlar, daha sonra oradan çıkan problemleri düzeltmek isterken bir bakarsanız size maliyeti 9 aya çıkmış. Sonra da yahu proje başarısız oldu. Talepleri önceden net bir şekilde belirtmezseniz maalesef böyle şeyler olacaktır. Zaten benden daha iyi bilirsiniz ki, hele bir başlayalım da sonra bakarız. Kervan yolda dizilir mantığı. Neyse ben buradan çıkayım yoksa yazıyı yazamayacağım :)
Karmaşıklık karmaşıklığı beraberinde getirir. 10 adet özelliğiniz olsun. Ona bir tane daha özellik katmaya çalıştığınız takdirde bunun size maliyeti doğrusal olarak artmaz. Çünkü bunu diğer 10 özellik ile birlikte çalışmasını da göz önünde bulundurmanız lazım. Bu zaman kaybını iyi bir tasarımla indirgeyebilirsiniz. Buna rağmen fazladan zaman kaybını göze almanız lazım. Bazen ilk versiyonda o kadar karmaşık özellikler gelir ki bu projeyi başarıyla canlıya almanız için onları iyice bir tıraşlayıp fazla yükten kurtulmak lazım.
Karmaşıklığı artıran sadece yeni özellikler eklemek değildir tabi. Bununla birlikte bir çok farklı yöntem de vardır. Bunları da kısaca açıklayalım.
Yazılımın amacını genişletmek : Projenizin her şeyi yapmasını isterseniz bu projeyi hiç bir zaman bitiremeyeceğinizi de göz önüne almalısınız. Saçmalıklarla dolu gelen isteklere yüksek sesle karşı çıkmalısınız. Bu bizde ne kadar mümkün bilemiyorum tabi.
Yeni programcılar işe almak : Evet doğru duydunuz. Oturmuş 10 kişilik yazılımcı grubuna 1 kişi eklediğinizde bu işinize balta vurabilir. Fred Brooks'un bu konuyla ilgili olan Mythical Man Month adlı ünlü kitabında ayrıntılı şekilde ele alınıyor. Ben bunu pişmiş aşa su katmak olarak düşünüyorum.
Değiştirilmesi gerekmeyen şeyleri değiştirmek : Yaptığınız her değişiklik bir hata olasılığıdır. Bu hiç değişiklik yapılmayacak anlamına gelmez, fakat bunun kararını iyi vermek gerekir. Hepimizin belki de bildiği, çalışıyorsa elleme kuralını doğrular bir niteliktedir.
Kötü teknolojilere bağlı kalmak : Kullanmaya başladığınız teknoloji sizi kendine bağlarsa bu kötü teknolojidir. Şöyle ki; bu teknolojiden başka bir teknolojiye kolaylıkla geçemiyorsanız bu teknoloji sizi kendine bağımlı hale getirir.
Yanlış Anlama : Yazılımcının istenileni yanlış anlaması sonucu sistemi karmaşık hale getirebilir. Bunun önüne geçmek için konuyu iyice anlayıp mümkün mertebe basit bir tasarım yapmaktır.
Kötü Tasarım : Projenin başlangıcında iyi bir tasarıma sahip olmazsanız ilerleyen zamanlar projenin çöpe hale gelmesi çok hızlı gerçekleşecektir.
Tekerliği yeniden icat etmek : Bir iş yapmaya karar verdiniz, onla ilgili yeterince araştırma yapmadan kendi çözümünü yapmaya çalışmanız buna delalet eder. Örneğin geçenlerde çalıştığımız projede canlı destek eklememiz lazımdı. Bunu oturup kendim de yazabilirdim belki (kim bilir ne kadar sürede) fakat küçük bir araştırmayla açık kaynaklı bir proje buldum ve projemize dahil ettik ve şuan başarıyla çalışıyor.
Karmaşıklık ve Amaç
Sistem olduğunca basit olmalıdır. Bu basit sisteme kendisine uygun olmayan özellikle eklediğinde sistem hızlı bir şekilde karmaşıklaşmaya başlar. Örneğin, elinizde bir kelime yazma programı var, fakat siz bunla bir de mail göndermek isterseniz sisteminiz hızlı bir şekilde karmaşıklaşmaya başlar.
Yazılımcının amacı ile kullanıcının amacı örtüşmelidir. Eğer farklı amaçlardan bahsediyorsanız bu işte bir yanlışlık vardır. Onun istediği mail göndermekse ve siz kelime yazma programı yazıyorsanız ona hayatı zorlaştırıyorsunuz demektir. Müşteri hızlı bir şekilde sinirlendirmek mi istiyorsunuz ? O zaman onların kullanacakları özellikleri zorlaştırın. Bazen yöneticileriniz veya müşterileriniz şirin olması açısından sizden uygun olmayan özellikler isteyeceklerdir, fakat siz buna direnmek zorunda kalacaksınız. Geçen codefiction'den podcast dinliyorum. Arkadaşlardan biri şey dedi, müşterinin dediğini yapmak 10dk'mı alacaktı, ama ben ona neden yapılmaması gerektiğini 1.5 saat boyunca anlattım. Evet maalesef bazen bunu yapmak zorunda kalıyoruz.
Bir süpermarkete gidiyorsunuz. Sabun elimizi temizlemeye yarar. Tuz yemeğin tadına güzellik katar(üç beyaza dikkat :). Bu örnekler çoğaltılabilir. Gördüğünüz gibi her ürünün bir işlevi var. Bir ürüne 500 görev yüklenmiyor. Siz de ürününüzü geliştirirken buna özen göstermelisiniz. Sahip olduğunuz özellik bir şeye odaklanmalı. Her şeyi bünyesinde çözmeye çalışmamalı. Müşteriyi mutlu edecek tasarım bu şekilde olmalıdır. Burada yine aramaya girmek istiyorum. Bilgem Çakır'ın güzel bir videosu vardı. Neden metro kullanmalısınız gibisinden. Kendisi Amerika'da laptopunu açıp işlerini halledebiliyormuş. Bir arkadaş da İstanbul'da metroya binmeye hasretiz, laptop mu açacağız demişti :) Burada da yazar haklı ama üzülerek söylemeliyim ki burada müşteriler onun hayal ettiği gibi değil.
Kötü Teknoloji
Yazılımın karmaşıklığını artıran bir diğer etken de kötü teknoloji seçimidir. İyi olan teknolojinin ilerde kötü olup olmayacağını bilmek bazen zor olabilir. Ama bunu test etmek için 3 parametre vardır: Hayatta kalma süresi, birlikte çalışırlık, kaliteye verdiği önem. Şimdi bunları sırasıyla inceleyelim.
Hayatta kalma süresi: Bir teknolojinin hayatta kalması bakımına bağlıdır. Bir araç bakımına devam ediliyorsa o teknoloji hayatta kalmaya devam ediyor demektir. Yazılımcılar kullanıcıdan gelen taleplere ne sıklıkta çözüme kavuşturuyor. Sunulan hata raporlarına göz atılıyor mu ? Destek ekipleri yeterince hızlı çalışıyor mu ? Bu gibi parametreler kullandığınız teknolojinin hala geliştirilip geliştirilmediğine dair fikirler verecektir. Ayrıca tek büyük bir müşteri tarafından mı desteklendiğini de dikkat etmenizde fayda vardır. Github üzerindeki bir projede bile son değişikliğe bakıyoruz. Eğer uzun süre önce değişiklik yapıldıysa, hımm demek geliştirilmiyor bu proje diyoruz. Bu da böyle bir durumdur.
Birlikte çalışırlık : Bir yazılımın başka yazılımlarla birlikte çalışabilmesidir. Örneğin; belirli bir veritabanı ile çalışıyorsunuz ve bu veri tabanı uluslararası standartları gayet iyi uygulamış. Bu sebepten ötürü küçük bir kaç dokunuşla başka bir veri tabanına geçebilirsiniz. Aksi için de o veri tabanına bağımlı kalır, onu değiştirmek için fazla maliyet harcamak zorunda kalabilirsiniz.
Kaliteye verdiği önem : Bu daha öznel bir ölçümdür. Eğer kodları açık kaynaklı ise kodları inceleyip kod gözden geçiriliyor mu , çıkan her sürümde ileriye doğru bir ilerleme var mı , her hangi bir güvenlik açığı mevcut mu gibisinden kodlara göz atabilirsiniz. Bunlar size kullandığınız yazılım ile ilgili fikirler verecektir.
Yazının çok uzamaması açısından burada bir ara verip geri kalan kısmı bir sonraki yazıya bırakalım. O zamana kadar karmaşıklığı az sistemler tasarlamak dileğiyle.
Hiç yorum yok:
Yorum Gönder