S.a. Arkadaşlar,
Bildiğiniz gibi kod basitliği kitabını işliyorduk. İlk 6 konuyu her hafta işlemeye özen gösterdim. Yeni iş, yeni proje , yeni teknoloji sebebiyle basitlik yazılarına ara vermek zorunda kalmıştık. Neyse ki pes etmeden tekrar devam etmek nasip oldu. Bugün kitabın 7.konusu olan kitabın temelini oluşturan basitliği işliyoruz. Hem konunun önemi hem de uzunluğu sebebiyle yazıyı 2 parçaya böldük. En yakın zamanda 2.parçasını da yayımlamak dileğiyle. Hazırsanız başlayalım.
Evet programınızda hiç değişiklik yapmazsınız hiç hata yapmıyorsunuzdur demektir. Değişim kaçınılmazdır. Eğer yeni özellikler ekleyecekseniz elbette hata olma olasılığı var demektir. "Hiç bir şeyi değiştirmeyin" bunun için çözüm değildir
Bölüm 6'da açıkladığımız gibi, hatalardan kaçınmak isterseniz küçük değişiklikler yapmaya özen gösterin. Ama siz küçük hatalardan da kurtulmak istiyorsanız , başka bir kanun size yardım edebilir ve bu kodunuzdaki hataları azaltmakla kalmaz, özellikleri eklemeyi kolaylaştırır, kod okunurluğunu artırır. Bu basitlik yasasıdır:
Yazılımın bakım kolaylığı basitliğiyle orantılıdır.
En basit parçaları gelecekte daha kolay değiştirirsiniz. Mükemmel bakım yoktur , ama mükemmelliğe yakınlık vardır. Hedefiniz de bu olmalıdır: Az kod az değişim.
Fark etmişsinizdir, bu kural sadece sisteme değil , tek tek parçalara da bakar. Peki neden ? Orta büyüklükteki bir bilgisayar programını bir insanın bir anda anlayamaz. Sadece parçalarını anlar. Gerçekten de programlar karmaşık ve büyük yapılara sahip olabiliyorlar. Programı da anlamak için parçalarına bakmak zorunda kalıyoruz. Parçaların kolaylığı insanların anlamasını hızlandıracaktır. Diğer insanlar kodu eline aldığında veya bir kaç ay sonra kendi kodunuza tekrardan döndüğünüzde bunun önemini daha iyi anlayacaksınız.
Peki bu kanunu yazılım dünyasında nasıl kullanırız ? Bu kitabın kalanın büyük bir kısmı bu konuya odaklanmıştır. Genel olarak bireysel parçalar oldukça sade olmalıdır ve zaman içinde basit kalmaya devam etmelidir.
Bunu yapmanın en iyi yollardan biri 5.bölümün sonlarındaki artırımlı tasarım ve tasarım yöntemidir. Her yeni özellik eklediğinde yeniden tasarım yapmaktır. Bu şekilde sistemi basit tutmaya devam edebilirsiniz. Bu yöntemi kullanmadığınız vakit arkanızdan gelecek yazılımcıların işini zorlaştıracaksınız.
Bu veya başka bir şekilde önemli değil , ama kodu daha basit hale getirmek zorundasınız. İlk yaptığınız tasarıma her zaman güvenemezsiniz. Sistemin parçalarını gelen istekler doğrultusunda yeniden tasarlamak zorunda kalabilirsiniz. Sonuç olarak bu zor bir iştir. Bilgisayar , yazılım karmaşık ve zor süreçlerdir, fakat siz bunun için mücadele etmelisiniz.
Yazılım tasarımın basitlik ve denklem
Bunu fark etmiş olabilirsiniz, ama bu bize yazılım tasarımında bakım maliyetini indirmenin en önemli şey olduğunu söyler. Biz kodumuzu geleceği tahmin ederek yazmak zorunda değiliz. Bunu kodumuzu inceleyerek yapabiliriz. Eğer karmaşık olduğunu düşünüyorsak bunu basitleştirme yoluna gitmeliyiz. Bunu sürekli olarak yapmalıyız. Sistemdeki değişiklikleri yapmayı ne kadar kolaylaştırırsanız , istediğiniz değişiklikler o kadar rahat halledebilirsiniz. Bununla ilgili 4.bölüme tekrardan göz atabilirsiniz.
Basitlik görecelidir
Evet, sürekli basitlikten bahsediyoruz. Fakat kime ve neye göre basitlik tanımı yapacağız. Yaptığınız bir iş size basit gelebilir. Çünkü siz o an işin içindesiniz ve bunu farketmeyebilirsiniz fakat dışarıdan bakan birisine zor gelebilir.
Kodunuzun dışarıdan nasıl göründüğünü anlamak istiyorsanız, daha önce okumadığınız kodları bulun ve onları iyice anlamaya çalışın. Bu kodda ne kadar zorlanıyorsanız, sizin kodunuza bakan kişinin de bu durumda olduğunu anlamış olursunuz. Bu nedenle kodlarınıza açıklamalar ekleyerek onları sonradan okuyacaklara yardım edebilirsiniz. Bu dokümantasyonlar projeye sonradan katılacak birine oldukça yardımcı olacaktır. Daha önce projede yer alan biri için o projeye ekleme yapmak çok da zor gelmeyebilir ama sonradan katılan biri için bu işi kolaylaştırmak istiyorsanız dokümantasyon çok yararlı olacaktır. Bunu yaparken yapmış olmak için yaparsanız yazdığınız şeyleri sadece siz anlarsınız. Bu durum hiç dokümantasyon olmamasından bile kötü duruma gelebilir.
İçerik de önemlidir. Örneğin bir kodun içeriğinde ne kadar ileri teknoloji kullanılmışsa o kadar basittir diyebiliriz, fakat gidip de her şeyi bir sınıfa ya da bir arayüze eklersek ileri teknolojinin bile bize faydası dokunmaz. Belki her şeyi bir sınıfa yazmak size kolay gelecektir, ama şöyle düşünün, sizce biz bu kitabı tek başlık altında yazmak yerine neden bölümlere ayırdık ?
Tüm bu bakış açıları yazılımın basitliğini imkansız hale mi getirir? Tabi ki hayır. Her şeyi hedef kitlesine uygun çözmeliyiz. Problem her şekilde çözülür fakat bunu çözerken ne kadar kolay çözeceğiniz o sistemin tasarımıyla ilgilidir.
Ne kadar basit olmalısınız
Bir projeye başladığımızda basitlikle ilgili sorular ortaya çıkabilir. Ne kadar basit olmalıyız, yaptığımız şey yeterince basit mi ? Basitlik tabi ki görecelidir ama buna rağmen son kullanıcıya göre programınızın kullanımı zor mu , kolay mı yoksa bunların arasında bir yerde mi veyahut başka bir yazılımcıya göre yazdığınız kodlar rahatlıkla anlaşılacak basitlikte mi ? Burada sıradan insanları baz alırsanız sizin için daha iyi olacaktır. Çünkü sıradan insanların anlayacağı programı dahiler de anlayacaktır ama tersi doğru değildir. Bunu asla gözden kaçırmamalıyız.
Bazen insanlar sıradan insanlara göre nasıl kod yazacaklarını bilmiyorlar. Gelin bunu size bir örnekle anlatayım. Büyük alışveriş mağazalarında belirli yerlerde neyi nerede bulacağınızla ilgili haritalar vardır. Her şey düzenlidir , ama üçgen işareti şeklinde "BURADASINIZ" şekli vardır. Eğer oradaki üçgen işareti olmasa yaklaşık 3-5 dakika nerede olduğunuzla ilgili bakmak zorunda kalırsanız. Bu basitlikle ilgili güzel bir örnektir.
Bir çok yazılımcı bu konuda maalesef kötü durumdadır. Kodu yazmak için uzun süre harcadığı için herkesin kodu anlaması için de uzun zamanı olduğunu düşünür. Bu büyük bir yanılgıdır. Neyse ki şimdiki programcılar daha akıllıdır. Bununla birlikte hala "programcılar zeki insanlardır, yazdığımı açıklamadan veya yeterince basit yazmadan da anlayabilirler" diye düşünürler fakat bu zeka değil bilgi meseledir. Siz ne kadar basit yazarsanız yazılımcının anlaması da o derece basitleşir ve kolaylaşır.
Kodları basitleştirmek için farklı yollar vardır. İyi dokümantasyon, basit tasarım, adım adım eğitici içerik bunlardan bazılarıdır. Bunlar tabi ki artırılabilir.
Eğer siz kodunuzu düzgünce yazmadığınızda insanlar kodlarla uğraşmak zorunda kalacaklardır. Onlar kodu doğru anlamayıp kodunuzda buglar meydana getirebilirler. Eğer o iş yerinizde çalışıyorsanız sizi bulup tekrar size neyi nasıl yaptığınızı soracaklar ve siz bu yüzden zaman kaybedeceksiniz. Yok eğer siz artık o işte değilseniz zaten kulağınızın çınladığını fark edeceksiniz zaten :) Siz de çınlatmışsınızdır muhakkak birilerinin kulağını ...
Başka bir yanılgı konusu da kodları karmaşık yazdığımızda insanların bizi zeki düşünecek olması ve bu sayede ben çok güzel yazdım onlar beni anlamadı eleştirisi yapmamıza sebep olacaktır. Bu gururumuzu okşayabilir, fakat sorarım size bu davranış diğer insanlara yardımcı olur mu ? Yanlış hatırlamıyorsam Cem Yılmaz'ın bir gösterisiydi. Şey demişti ben de işte şakalar yapabilirim insanlar gülmeyince aptallar ben komiktim onlar beni anlamadı ama bu işin önemli yanı insanların sizi anlamasını sağlamaktır. Aynı bu şekilde uzun vadede bize kazandıracak olan şey bizim olabildiğince basit olmamızdır.
Diğer bir deyişle siz kodunuzu basit yazdığınızda, insanların bu kodları anlamasını kolaylaştırır. Kodlarınızı anlamaları insanları daha mutlu ve zeki hissettirecektir. Bu da size karmaşıklıktan daha fazla hayranlık kazandıracaktır.
Ne kadar basit olmalıyız konusunu kapatırken , kendinize şu soruyu sorun. Ben gerçekten basit ve anlaşılır mı olmak istiyorum, yoksa karmaşık kalarak dikkat mi çekmek istiyorum ?
Yeterince basit ve anlaşılır kodlar yazmak dileğiyle.
Hiç yorum yok:
Yorum Gönder