Kod basitliği kitabından öğrendiklerimizi yazmaya devam ediyoruz. En son kitabın en önemli konusu olan 7.bölümde kalmıştık. 7.bölüm uzun olduğundan 2 yazıya bölme ihtiyacı doğmuştu. 1.kısmına buradan erişebilirsiniz. Bugün ise 2.kısmını ele alacağız. Hazırsak başlayalım.
Tutarlı Olmak
Basitliği temel prensiplerinden biri de tutarlı olabilmektir. Eğer siz bir yerde bir şeyi yapıyorsanız diğer yerlerde de aynı şeyi yapmalısınız. Mesela değişken isimlerine küçük harfle başlamışsınız öylece devam etmelisiniz. Bir yerde büyük harf bir yerde küçük harfle başlamamalısınız. Farklı bir örnek olarak değişken tanımı yaparken _ kullanıyorsanız öyle yapmaya devam edin. Veyahut yapılandırıcı metod içinde _değişken ismi kullanıyorsan diğer yapılandıcı metodda this.değişken kullanmak yerine yine _değişken tanımını aynen kullanmalısınız ki projede tutarlılığınız olsun. Eğer kodunuz tutarlı olmazsa kodun okunurluğu zorlaşır. Gerçek hayattan 2 cümleyle bu olaya el atalım:
• This is a normal sentence with normal words that everybody can understand.
• tHisisanOrmalseNtencewitHnorMalwordsthAtevErybOdycAnunderStaNd.
Aslında bu iki cümlede de aynı şey yazıyor. İngilizce bilenler her iki cümleyi de anlayacaklardır. Anlamayanlar da translatten anlayacaklardır :) Fakat 2 cümlede arasındaki farkı görüyorsunuz değil mi ? 1.cümlede ne yazıldığı rahatlıkla okunabilirken 2.cümlede bunu okumak cidden zordur. 1.sinin bu kadar kolay olmasının sebebi ise yazım şeklinin tutarlı olmasındır. Yazar gerçekten çok güzel örneklemiş, şahsen ben etkilendim. Okurken haz aldım. Kendi adıma da ne kadar doğru bir iş yaptığıma tekrar ikna oldum.
Buradaki konunun bir benzeri kod dünyasında da geçerlidir. Kodunuzu yazdığınızda her iki durumda da yazabilirsiniz. İstediğiniz kadar çılgın olun yine de bu kodunuzun çalışmasına engel değildir, fakat daha sonra tekrardan bu kodu düzeltmeniz veya okumanız gerektiğinde problemler başlayacaktır. Bu yüzden kodun sadece çalışmasına değil de nasıl çalıştığına da dikkat etmek gerekir. Buna şahsım adına elimden geldiğince dikkat etmeye çalışıyorum. Ne kadar başarıyorum tartışılır ama en azından böyle bir amacım var. Bu bilinçte olmak bile beni mutlu ediyor.
Tutarlılık programın genelinde kolaylık sağlar. Örneğin bir isim değişkeni tanımlayacaksınız. Bunu her yerde aynı tanımlamak yerine A objesi için a_name , B objesi için b_name olarak tanımlarsanız her obje için bir isim değişkeni ortaya çıkar ve her değişken için ayrı bir kod yazmak zorunda kalabilirsiniz. Kodun belirli bir yerinde A işlemi için 3 işlemi yapılıyorsa benzer B işlemi için de 3 işlem yapılmalıdır. Programcı A işleminizi anladığı anda B işlemine de anlamış olmalı. Aksi halde bir de B'yi öğrenmek için zaman harcamamalıdır. Bunların hepsi tutarlılığın parçalarındandır. Belki gerçek hayatta her şey bu kadar tutarlı değildir, fakat siz kendi yazılım dünyanızdan sorumlusunuz.
Şimdi bir örnekle bu bölümü sonlandıralım. İnsanlar Asya'da çubukla (çatalla yenilen yerler de var aslında ), Avrupa ve Amerika'da çatalla yemek yeniliyor. Bu bir bakıma tutarlılıktır. (Daha tutarlısı herkesin aynı malzemeyle yemesi ama tabi bu mümkün olmuyor her zaman. Yazılımda da zaman zaman bu mümkün olmuyor.) Çünkü Bob'un evinde makasla , James'in evinde başka bir şeyle yemek yediğinizi düşünsenize. Her gittiğiniz yerde yemek yemek için o aracı kullanmak zorunda kalacaksınız. İşte tam olarak yazılımda da böyledir. Siz ne kadar tutarlı olursanız karmaşıklık o kadar azalacaktır. Yazılım o derece basitleşecektir. Basitlik ise rahatlığı getirecektir :)
Okunurluk
Yazılım dünyasında sık sık geçtiği gibi kod yazıldığından çok okunur. Bir kere yazarsınız ama kim bilir kaç kere yazdığınız kodu hem siz hem de sizden sonra gelenler okur. Kodu daha okunabilir hale getirmek için şu çok önemlidir:
Kodun okunurluğu öncelikle harflerin ve sembollerin yerlerine bağlıdır.
Eğer tüm kainat siyah olsaydı objeleri birbirinden ayırt edemezdik. Tıpkı bunun gibi kodun içerisinde yeterli boşluk ve düzenlemeler olmazsa bu kodun anlaşılması da tıpkı o siyah kainat gibi anlaşılması oldukça güç olacaktı.
Kod okunurluğu için boşlukların ne çok olması lazım ne de az. Çok boşluk olursa aradaki bağlantıyı kurmakta zorlanırsınız. Boşluk olmazsa bu sefer de anlamakta zorlanıyorsunuz. Bunu küçük bir örnekle açıklamaya çalışırsak bazen kodlar görüyorum hiç düzenlenmemiş, sadece yazılıp geçilmiş. Kodu dizayn etmek o kadar zor değil. En basitinden zaten ide'lerin yapmış olduğu kod formatlanabilir. İlgili satırlar art arda olabilir. Farklı bir işlem yapılacaksa bir boşluk bırakabilir mesela. Çünkü bazen bakıyorsunuz kodun altında 5 satır boşluk var bir satır kod 3 satır daha boşluk, altında 8 satır yorum görüyorsunuz. Şimdi bu kodu anlamaya çalışmadan önce bence şöyle standart bir şekle koymak lazım diye düşünüyorum. Zaten kod yazdıkça genel standartlar ve insanın kendi standartları oluşmaya başlıyor. Şahsımca bunlara dikkat etmeye çalışıyorum. İlk başta bazen öylece bıraktığım kodlar olmuyor dersem yalan olur ama o kodu çalıştırdıktan sonra en azından kabasını aldığıma inanıyorum. Belki daha sonra refactoring de yapıyorum. Bunların ufak ama etkili şeyler olduğuna inanıyorum.
Bu konuda tam ve kesin bir kural bulunmamakla birlikte insanın gözünü yormayacak ve onu rahatsız etmeyecek şekilde kod yazılabilir. Burada 2 örnek kod vererek konuyu pekiştirmeye çalışalım.
İlk örneğimizde hiç boşluk bırakılmadan yazılan bir kod parçası bulunmaktadır.
x=1+2;y=3+4;z=x+y;if(z>y+x){print"error";}
İkincisinde ise çok fazla boşluk olan kodumuzu paylaşalım.
x = 1+ 2;
y = 3 +4;
z = x + y;
if (z > y+x)
{ print "error" ;
}
Her iki kod parçasını okumak da zordur. Buradaki örnekler elbette abartılıdır, fakat bu kadar olmasa da buna benzer kodlar görüyoruz. Belki daha tecrübeli yazılımcı arkadaşlarımız ya da danışmanlarımızdan bunlardan daha kötü kod görenler de olmuştur. Burada sadece söyleneni daha iyi anlayabilmek için biraz uç örnekler verilmiş. Olması gerekeni verip kodu okunurluğunu da kapatıyoruz.
x = 1 + 2;
y = 3 + 4;
z = x + y;
if (z > y + x) {
print "error";
}
İsimlendirme
Okunurluğun önemli parametrelerinden biri değişkenlere, metodlara, sınıflara düzgün isimler vermektir. İdeal olarak şunu söyleyebiliriz:
İsimlendirme, programcıyı sıkmayacak şekilde en kısa ve en düzgün şekilde olmalıdır.
Bu isimlendirmeyi yaparken nerede nasıl kullanacağımız da önemlidir. Örneğin sık kullanılan bir metod ise ve bu metod karmaşık işlemlerde kullanılacaksa elimizden geldiğince kısa isim vermeye gayret etmeliyiz, fakat bu metod nadir kullanılacak veya tek başına bir satırda kullanılacaksa metodun isminin uzunluğu pek problem olmayacaktır. Örneğin linq içerisinde bir metod kullandığımızı düşünelim. Burada işlem büyük ihtimal karmaşık olacaktır. Bu yüzden ne kadar kısa isim versek o kadar iyi olur, fakat bir metod içerisinde bir işlem yapılıp bir değişkene atılacaksa o zaman bu metodun ismi uzun olabilir. Çünkü zaten bu işlemi bir satırda yapmış olacağız ve okunurluğu çok etkilemeyecektir.
Yorumlar
Kodlar içerisinde yorum satırları okunurluğu artıran etmenlerden biridir. Bununla birlikte yorum ekleme ihtiyacı duyuyorsanız kodu yeterince anlaşılır yazmadığınız anlamına gelebilir. Bu yüzden öncelikle kodunuzu daha basit yazmanız gerekebilir. Eğer elinizden geleni yaptıysanız buna rağmen kodun anlaşılması zor ise o zaman yorum satır eklemeniz güzel olacaktır. Bazen her yere o kadar çok yorum satırı ekleniyor ki kodun okunurluğu ciddi manada düşüyor. Avantajı dezavantaja çevirmemek lazım. Ayrıca hatırlamadığım bir yerde okuduğum bir usta "kodu, yorum satırlarına ihtiyaç kalmayacak şekilde yazın" demişti. Tabi bunlar her zaman çok mümkün olmasa da hedeflenen bu yönde olmalıdır.
Yorum satırı yazmanın temel amacı ne yaptığınızı değil, ne yapmadığınızı söylemektir. Çünkü bazen kodun önemini kavrayamayan yazılımcı onu silmek veya düzeltmek isterken büyük hatalar yapabilir.
Kod okunurluğu tek başına sistemi sade yapmaz. Kodunuz sade olabilir, fakat sisteminiz hala çok karışık olabilir. Bunun için tasarımı düzeltmeniz gerekebilir. Bununla birlikte kod okunurluğu basit bir tasarımın temel taşlarındandır.
Basitlik Tasarım Gerektirir
Maalesef insanlar tasarıma dikkat etmeksizin devasa, yönetilmesi zor sistemler geliştirirler. Projeniz iyi bir tasarıma sahip olmadığında ve zamanla da projenizin daha da büyümesi sistemi karmaşıklaşacaktır. Bu işi kontrol edemez duruma getirecektir. Yeni özellikler eklemeye çalıştığınızda sudan sebeplerle bunun olmayacağını açıklarsınız ve bunlar bir gün projenizi askıya almasına yani başarısız olmasına sebep olacaktır. O zaman söyledikleriniz sadece bahane olarak kalacak ve sonucu değiştirmeyecektir.
Gerçekten iyi bir tasarım yaptığınızda kafanız rahat olacaktır. Kullanıcılar ve yazılımcı arkadaşlarınız bunu anlayacaklar mıdır ? Belki de anlamayacaklardır, fakat siz buna aldırış etmeyin. Yaptığınız işten gerçekten memnunsanız onların tebrik etmesinden daha önemli şeyler vardır. Kısa vadede belki bir yararı olmasa da uzun vadede elbette sizi öne çıkaracaktır. Yeter ki işinizi doğru yapmaya özen gösterin. Birinin görüp görmemesi veya 3 gün sonra o şirketten ayrılıp ayrılmamanız o kadar da önemli şeyler değildir.
İçimize sinen kodlar yazmak dileğiyle. Hoşça kalın.
Hiç yorum yok:
Yorum Gönder