SOLID Programlama Her Zaman Mantıklı mı?

SOLID prensiplerini örnek kodlar ile anlattığım videolarımı izlemek için YouTube kanalımda ki SOLID Prensipleri listemi ziyaret edebilirsiniz. Kanalıma abone olarak, devamlı eklediğim yeni eğitim videolarına ilk siz ulaşabilirsiniz.

Image for post
Image for post

Programlama dünyasında kaliteli kod yazma şartlarına bakıldığında iki tür görüşün olduğunu göreceksiniz. Birinci görüş hangi şartta olursanız olsun her zaman kaliteli kod yazmaktan ödün vermeyin. İkinci görüş ise şartlara göre nasıl bir yaklaşım sergilemeniz gerektiğine bakın çünkü her zaman SOLID kod yazmak mantıklı olmayabilir. Bu iki görüşü okurken kalbinizin ve aklınızın hangisini seçtiğini bilemem ama programlama kariyerimde Never (Asla) ve Always (Her zaman) gibi iki kelimeye karşı zihnimde bir iticilik gelişmeye başladı. Bu arada kalp ile akıl arasında ki muhtemel seçim farklarına dikkat çekmek istedim çünkü bir tanesi ideal olanı seçmek isterken diğeri daha çok içinde bulunduğu şartları da göz önünde bulundurarak seçim yapmak isteyebilir.

Hatta çoğu zaman insanlar kötü tecrübeler yaşadıkları olaylara karşı zamanla radikalleşme gösteren daha başka tavırlar sergilemeye başlarlar.

Fikirlerin tartışıldığı ortam ve zamanlar da öncelikle insan doğası ile alakalı bir kaç şeyin farkına varılması lazım. Aksi halde insanların karar vermelerinde ki mekanizmalar anlaşılmadığında verecekleri kararlar da tam olarak anlaşılmayacaktır. İnsan kendi fikirlerine benzer düşünceleri duymaya karşı eğilim gösterir ve sorularını benzer düşüncelere sahip insanlara sorarak kendi perspektifinden geliştirdiği realitelerine karşı koruma iç güdüsü oluşturmaya başlar. Dolayısıyla doğru ve yanlış her zaman objektif olmayabilir. Hatta çoğu zaman insanlar kötü tecrübeler yaşadıkları olaylara karşı zamanla radikalleşme gösteren daha başka tavırlar sergilemeye başlarlar. Örneğin, bir programlama dili ile bazı sorunları olmuş bir insan artık o dil ile alakalı hiç bir şeyi güzel görmez ve ona karşı tamamen duyarsız olmaya başlar. Bu tabiki de herkes ve her durum için geçerli olmasa da kesinlikle göz önünde bulundurulması gereken bir gerçek olarak çıkıyor karşımıza. Bunun sonucu olarakta zihni bir körlük yaşanıyor. Buna sebep olan faktörler ya hayatta yeterince tecrübe sahibi olacak kadar farklı ortamlarda ve insanlar ile çalışmamak ya da tecrübe sahibi insanların fikirlerine ve kitaplarına müracaat etmemek olabilir. Bu kısmı burada keselim. Umarım öncelikle insanı tanımanın alacağı kararları nasıl etkileceği gerçeğini anlatabilmişimdir. Bu konu hakkında daha detaylı araştırmalar yapmak isteyenler yabancı kaynaklarda Heuristic Fallacies ve Cognitive Biases anahtar kelimelerini araştırabilirler.

Ortaya sunulan kalitesiz bir ürün bile hiç ortaya çıkmamış en mükemmel üründen daha kıymetlidir.

İlk olarak demeliyim ki kendimi daha pragmatik olarak ikinci görüş içerisinde görmekteyim. Çünkü ikincisi görüşün şartları ve realiteleri daha iyi okuduğu ve daha dengeli davrandığı kanısındayım. Bu kanıya sahip olmama sebep olan şartların başında da çok farklı şirketler ve şartlarda çalışmış olmamın olduğuna inanıyorum. Bizim mesleğimizin devam edebilmesi için yaptığımız ürünlerin birileri tarafından kullanılması gerekmektedir. Hayatımızı idame ettirmeyen ve ailemizi beslemeyen meslekler ile ancak bir zaman devam edebiliriz. Dolayısıyla yazılım mühendisliği çok güzel bir meslek olmasına ve bundan çoğumuzun zevk almasına rağmen bunun sonucunda para kazanmak zorundayız. Para kazanmanın amaç olduğu bir durumda ortaya başka faktörlerde girecek ve şartları ve alınacak kararları kısıtlayıcı rol oynayacaklardır. Bu arada para amaç mı araç mı gibi sosyal mesajları başka bir yazıya bırakıyor ve yaptığımız mesleğin amaçlarından bir tanesinin hayatımızın devamı için gerekli olan gelir olduğu gerçeği ile devam ediyorum. Bu kısıtlayıcı faktörlerden en çok göze batanları ise para ve zaman. Ortaya sunulan kalitesiz bir ürün bile hiç ortaya çıkmamış en mükemmel üründen daha kıymetlidir. Dolayısıyla şartların çok iyi anlaşılması ve alınacak yaklaşımın iyi değerlendirilmesi gerekmektedir ki sınırsız olmayan para ve zaman gibi kaynakları iyi bir şekilde değerlendirebilelim. Bu arada duruşumu tekrardan belirtmekte fayda var: Ben SOLID prensiplerinin çok önemli olduğunu ama her zaman her şartta kesinlikle kullanılması gerektiği gibi daha çok hayali duran bir yaklaşımdan daha ziyade daha realist olunması gerektiğini düşünüyorum.

Kaliteli kod yazma prensipleri para ve zamanın en verimli kullanılması için geliştirilmiş olup, uzun vadede daha etkili kod yazımına imkan tanıyor.

Birinci görüşü — yani her zaman ve her yer de SOLID — savunanlar da çoğu zaman aynı mantıkla yola çıkıyorlar. Bu görüş kaliteli kod yazma prensipleri para ve zamanın en verimli kullanılması için geliştirilmiş olup, uzun vadede daha etkili kod yazımına imkan tanıyor fikrini savunuyor. Katılıyorum. Ama şartların uygunluğunda buna katılıyorum. Peki yazılımın tamamlanması için verilmiş zaman daha uzun vadede verimliliği arttıracak bu şekilde bir çözümün gerçekleşmesi için yeteri kadar zaman içermiyorsa? Peki yazılan kaliteli kod için geçen zaman kendisini amorti etmeye başlayacağı anda verilen projenin teslim zamanı yaklaşılmışsa? Yada istekler ve gereksinimler devamlı değişiyor dolayısıyla farklı yerlerde alt yapının devamlı değiştirilmesi gerekiyorsa? Bu soruların cevapları bize hangi görüşün daha gerçekçi durduğunu anlamamızda yardımcı olacaktır.

Kaliteli kod kendi geliştirilmesini devam ettirebilen koddur. Gelişimini ise kendisine sunulan kaynakları en verimli şekilde kullanarak devam ettirebilir.

Image for post
Image for post

Müşteriler ile uzun vadeli iş yapmada öncelikli olarak asıl olan güvendir ve güvenlerini kazanmanın en hızlı yoluda söz verdiğiniz işi zamanında bitirmenizdir.

Ben fırsatı olan her yazılım mühendisinin müşteriler ile biraz zaman geçirmesi ve onları dinlemesi gerektiğini düşünenlerdenim. Tabi tonlarca para verilerek işe alınan bu insanların devamlı müşteriler ile uğraştırılması ile israf edilmesine karşıyım. Ama arada bir sadece izleyici konumun da bulunmaları mantıklı olacaktır. Bu sayede kendi pembe dünyalarında yaşayan bazı mühendisler müşteri gerçekliği ile tanışmış olup ve gerçek dünyanın olaylara daha farklı baktığını göreceklerdir. Piyasa da defalarca kendi işimi kurmuş ve farklı müşteriler ile bire bir çalışmış birisi olarak hiç bir müşteri kodun ne kadar güzel olduğunu ya da ne kadar anlaşılır olduğuna bakmaz. Müşteriler ile uzun vadeli iş yapmada öncelikli olarak asıl olan güvendir ve güvenlerini kazanmanın en hızlı yolu da söz verdiğiniz işi zamanında bitirmenizdir. Diğer kalite tanımlamaları bu güveni sağladıkları sürece faydalı olacaklardır. Kaliteli kod yazalım diye uzun zaman hiç ürün sunmamak kötü sonuçlar doğuracaktır. Çoğu zaman piyasa “Geç olsun ama güç olmasın.” anlayışına göre çalışmaz. Zaman en az para kadar belirleyici bir faktördür. Bu noktada akıllara şu gelebilir: Kalitesiz bir ürün zamanında teslim edilmiş olsa bile sonradan bakım gerektireceğinden söz verilen teslimat süresi yine uzayacaktır. Doğru ama bu müşteride uzun zaman hiç gelmeyen ürüne nispeten daha az endişe ve güven kırıklığı oluşturacaktır. Hatta bu piyasada o kadar yaygındır ki proje geliştiricileri tarafından teslimata çoğu zaman MVP ile başlanır. MVP (Minimum Viable Product) yani müşterinin en asgari ihtiyaçlarına cevap verebilecek ürün demektir. Bu sayede müşteri herşey istediği gibi olmasa da hem bir gelişme görecek ve parasının boşa gitmediğine olan inancı artacak, hem de gerekli olan geri beslemeleri zamanında verebilecektir.

Mühendis olarak kaliteli kodu sonradan yazdırmayacak bir sınırlama yoktur. Hatta ilk zamanlar da para ve zaman kısıtlamalarından dolayı hoşumuza gitmeyen ama çalışır halde olan kodları sonradan ziyaret edip bakımı daha kolay hale gelecek şekilde yeniden kodlayabiliriz. Buna refactoring deniyor. Yani ile anda yaptığınız factoring yeterli olmadığında yeniden daha doğru şekilde factoring etmek. Tabi bunun içinde nedenlerimiz ve bu nedenleri yeterli ve yapılabilir kılacak şartların ve kaynakların olması gerekiyor. Mesela bakımı belki hiç olmayacak ya da uzun zaman aralıkları ile olacak kısımlar için refactoring dediğimiz bu uğraşı yapmak zorunda değiliz. Çünkü müşteriler refactoring için para ödemezler. Dolayısıyla şirketler refactoring yaparken iki defa düşünürler. Burada ki denklem basittir: R + M < MWR ise refactoring kabul edilebilinir. R refactoring için geçen zaman, M sonradan bakım için gerekecek zaman olarak alındığında bu iki değişkenin toplamı refactoring yapılmadığında geçecek bakım zamanından (MWR) düşük olacaksa kabul edilir. Tabi burada ki denkleme uzun vadede bakmak gerekmektedir. Örneğin ilk bir kaç iterasyonda refactoring ile düzeltilen kısımlar istenilen randumanı hemen vermeyebilirler ama zamanla bakım süresini ciddi oranda düşürmeleri olasıdır. Dolayısıyla refactoring daha çok bakım ve onarım gereksinimleri yüksek olan kısımlar için mantıklıdır.

İçinde bulunulan şartların anlaşılması bir mühendis için elzemdir.

Yukarıda konu dağılmaya başladığından farklı bir paragraf ile meseleyi sonlandırmaya çalışalım. Kaliteli kod yazmak kesinlikle önemlidir ve bir kodun kaliteli olduğunu bakım — Hata düzeltimi, yeni eklentiler yapılması, var olan özelliklerin daha çok geliştirilmesi vs. — için geçen zamanı ölçerek görebiliriz. Bakımı çok fazla zaman alan ve beklenmedik hatalara sebep olan kod kaliteli değildir ve ileride projenin batmasına bile sebep olabilir. Ama bir seferlik yazılan ve ileride bakımı yapılmayacak projeler ise zaman, para, beklentiler, ve büyüklük gibi farklı açılardan değerlendirilerek nasıl bir yaklaşımla programlanabilir buna ayrı karar verilebilinir. Her zaman ve her şartta SOLID kullanmak şartlara bağlı olarak zaman israfı ve güven kaybına sebebiyet verebilir. Kod bir ürün için yazılır ve bu ürünün kullanılması ve bir yere katkısı olması istenir. Aksi halde eğer öğrenmek amacı yoksa yazılan kod zaman ve emek israfı olacaktır. Bundan dolayı içinde bulunulan şartların anlaşılması bir mühendis için elzemdir.

Written by

Senior Manager in Software Engineering. Former Technical Lead. Author of the book: Hands-on with Go http://amzn.to/2QYFoaV YT: http://youtube.com/c/tarikguney

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store