Code Simplicity ( Kod Basitliği - 6)

S.a. Arkadaşlar,
Kod basitliği kitabının 6.bölümüyle devam ediyoruz. Geçen yazımızda kitabı yarısı geçtiğimizi söylemiştik. Şimdi artık yokuş aşağı iniş başladı diyebiliriz. İnşaallah hayırlısıyla bitirmek de nasip olur. 5.bölümde yazılımdaki değişiklikleri ve 3 kusuru işlemiştik. Bugün ise hatalar ve tasarım başlığını inceleyeceğiz. Hazırsak başlayabiliriz.
 
     Hatalar ve Tasarım

     Ne yazık ki hiç bir programcı mükemmel değildir .(Sanki mükemmel bir insan varmış gibi:) İyi programcılar yüzlerce satır kodda bir hata yapar, daha iyileri binlerce satırda bir hata yapar. Ve yazılımcı iyi oldukça da bu oran daha da iyileşir. Ama hata elbette olur. Başka bir deyişle iyi veya kötü bir yazılımcı olarak muhakkak kodunuzda hatalar olacaktır. Buna da kusurların olabilme kanunu diyoruz:

    Programınızda bir hata olma olasılığı onu değiştermenizle bağlantılıdır.

     Bu önemli bir kavramdır. Çünkü bizlerin amacı kullanıcılara yardım etmekti ve bu yüzden biz bu hatalardan kaçınmalıyız. Ayrıca hata düzeltimi sürdürülebilirliğin gerekliliğidir. Bu kanunla geleceği tahmin etmeden ufak değişiklikler yapabiliriz. Küçük değişiklikler = daha az kusur = daha az bakım.

     Bu kanun şunla da örtüşür : “eğer kodda ekleme veya değişiklikler yapmazsanız hatalar da olmayacaktır.” Burada araya girmek isterim. En iyi kod yazılmamış koddur derler. Çünkü bir yerde bir eylem/iş varsa orada hata da olmak zorundadır. Bu insanların fıtratında olan bir şeydir, ama önemli olan bu hataları en aza indirgeyebilmektir. Yoksa hiç hata yapmayan aslında hiç ilerlemiyordur diye de düşünebiliriz.

     Buradaki komik olan şey değişimin yasası ile çelişiyor gibi görünmesidir. Yazılım değişmek zorundadır, bu değişim beraberinde hataları da getirecektir. Bu tam bir çelişkidir ve zeki bir tasarımcı olarak bunu dengelemek zorundasınız. Bu çelişkiler neden tasarıma ihtiyaç duyduğumuzu açıklar. Bu da bize uygun bir tasarımın nasıl olması gerektiğini açıklar:

     En iyi tasarım en az yazılımsal değişiklikle en çok değişikliğe izin verendir.

     Bu basit bir şekilde bugünlerde iyi tasarımda olması gerekeni kısaca açıklıyor.

Kırılmazsa...

    Evet, siz değişiklik yapmazsanız programınızda hata oluşmaz, bu tasarımın yapı taşlarından biridir. Bununla beraber  çoğu yazılımcının bildiği ama bazılarının unuttuğu ve bu kuralla ilgili olan bir şey var: 

     Bir problem olmadıkça hatayı düzeltmeyin  ve hatanın var olduğunu kanıtlarıyla gösterin.

      Belki de hepimizin bildiği veya duyduğu “çalışıyorsa elleme” prensibine ne kadar da uyuyor. Onlara hitap etmeden önce hataları göstermek önemlidir. Yoksa kimsenin işini görmeyen çözümler üretebilirsiniz veyahut bir yerlerin patlamasına sebebiyet veren kodlar yazabilirsiniz. Bunun için tekrardan testlerin varlığı ne kadar önemli ortaya çıkıyor.

     Eğer problemleri kanıtınız olmadan çözerseniz belki başka şeylere sebebiyet verebilirsiniz. Sisteminizde yeni hatalara sebebiyet verebilirsiniz. Bununla da kalmayacak  zamanınıza ve yazılımınızın daha da karmaşıklaşmasına sebep olacak.

      Peki neler kanıt sayılabilir ?  Mesela 5 kullanıcı programınızdaki kırmızı düğmeye tıkladığında hata verdiğini söylüyor. Bu yeterli bir kanıttır. Bununla birlikte siz de kırmızı düğmeye basıp programın kırıldığını görürsünüz. Fakat sadece bir kullanıcı bir sorunu söylerse işte bu problemdir.  

     Bazı kullanıcılar yazılımınızın özelliklerinin farkında olmayacaklar ve ek özellikler isteyebileceklerdir. Örneğin, kelimeleri sıralamak için bir program yazdınız ve bir kullanıcı harfleri sıralamak istediğini söyler. Aslında bu özellik zaten mevcuttur.  Hatta bunun daha bile fazlasını yapıyor. Buna rağmen kullanıcı bunun farkında olmadan yeni özellikler istediğinde, onu programınızın yapabildikleri hakkında bilgilendirin.

·              Eğer kullanıcıdan bu tarz istekler geliyorsa, kullanıcı bu özelliklere kolay erişemiyor demektir. Bu tarz problemleri de aşmalısınız.

     Bazen bir kullanıcı programın bir hata verdiğini söyleyecektir, ama aslında olması gerektiği gibi çalışıyordur. Diğer kullanıcılar da bu özellikten memnundur. O zaman çoğunluğun dediği olur. Buna hata gözüyle bakılmaz.

     En büyük problemlerden biri de bu noktada ortaya çıkar: Erken optimizasyon.  Bazı yazılımcılar kodlarını hızla geliştirmekten hoşlanırlar, ama bu sefer de kod optimizasyonu için zaman harcarlar. Bu da zenginlere yemek göndermeye benzer. Sonra da denilir ki biz insanlara yardım etmek istiyoruz. Mantıklı bir şey midir sizce bu ? Bu var olmayan bir problemi çözer.

     Programınız hız konusundaki tek endişeniz, kullanıcının performansla ilgili kaygıları olmalıdır. Kodun geri kalanı hız değil, basitlik ve rahatlık barındırmalıdır. Bunu bir çok şekilde ihmal edebilirsiniz , ama bu yoldan sapmak istemiyorsanız problemi çözmeden önce kanıtları ortaya koyun.

Kendini Tekrarlama

     Bu tasarımda gayet iyi bilinen bir kuraldır. Bu kitapta ilk defa karşılaşmıyorsunuz. Bu doğru, biz yine de kuralı pekiştirecek olursak;

     Her hangi bir sistem , her hangi bir parça bir kez var olmalıdır.

     Mesela şifre alanın kullanıcı ekranlarında 100 yerde kullanılacaktır. Alan ismine şifre değil de başka bir isimlendirme yaptığınızı varsayalım. Daha sonradan bu ismin güzel olmadığını ve şifre olması gerektiğine karar verdiniz. 100 yerde ayrı ayrı değiştirecek misiniz ? Kodlarda da bu geçerlidir. Kopyala-Yapıştır yapmamalısınız. Bunun yerine kod parçalarını güzel bir şekilde parçalayıp belirli bir yerden çağrılmasına izin vermek gerekir. Ben bir kodu kopyala yapıştr dediğim anda, bir yerlerde hata yaptığımı düşünüyorum. Onla ilgili çözüm üretmeye çalışıyorum. Tabi bunu yapmak zaman ve mekanla da alakalı. Bazen çok istemeseniz de sisteme boyun eğmek zorunda kalabiliyorsunuz L

     Bu kuralı uygulamanızın sebeplerinden biri de , o kodla ilgili bir şey değiştirdiğimizde tüm alanları gezmeye gerek kalmadan değişikliği uygulayabilmektir. Az değişiklik de az hata demektir.  Ayrıca tasarımlarınıza esneklik de katar.  Tüm programı gözden geçirmek yerine sadece tek bir yerden değişikliklerimizi yapabiliriz.

      İyi bir tasarım bu kurala dayanır. Olan kodu yazıp bir yerden çağırmak sizce de daha mantıklı değil midir ? Bu sayede yapıyı merkezleştirerek tasarımınızı esnek bir hale getirebilirsiniz. Bu da zekanızı programlamada başka bir alana taşımış olursunuz. Artık siz bir şampiyonlar ligi oyuncususunuz diyebiliriz J

      Tekrarlanmayan kodlar yazmak dileğiyle. Hoşça kalın.