Okunabilir Kod Yazmak İçin 3 Basit Adım

Subscribe to my newsletter and never miss my upcoming articles

Hatırlatma: YouTube Kanalıma abone olarak, her hafta eklenen yazılımcılar için programlama ve kariyer video eğitimlerime ulaşabilirsiniz.

Çoğumuzun işe alınmasında ki en temel sebebin var olan bir uygulamanın bakımını yapmak olduğunu biliyoruz. Yıllardır Yazılım Mühendisi olarak çalışan birisi olarak ne kadar iğrenç kodlar gördüm bir ben bir de Allah bilir. İğrenç diyorum çünkü en basit ve temel okunabilir olma kriterlerini bile sağlamıyorlar. Ne kadar ezberci olursanız olun, bir dili ne kadar iyi bilirseniz bilin, eğer bir takım içinde ben tek tabanca takılırım ve herkes benim yazdığım kodu bir zahmet anlasın gibisinden bir davranış sergilerseniz, takım arkadaşlarınızdan saygı görmeyeceğiniz gerçeği ile er yada geç tanışacaksınız demektir. Başınıza böyle bir sorun gelince de önce başkalarını sorgulamak ve korumacı bir tavır almak yerine, kendinizi sorgulamak zorundasız. Yazdığınız kodları başka insanlar sizin yazdığınızdan çok daha fazla okuyacak. O insanların zamanlarının çoğunu sizin kodunuzu anlamaya çalışmakla geçirmek zorunda bırakma hakkınız olmadığı gibi aynı zamanda bu şekilde bir davranışın hiç bir iş ahlakına sığmayacağını da bilmek zorundasınız.

Peki ne yapmak lazım? Öncelikle, kodunuzu yazarken, “Ben gayet kolay bir şekilde okuyup anlıyorum aslında…” anlayışından uzaklaşıp, “Acaba bunu başkalarına okutsam ne kadar anlarlar? Acaba şu domain bilgisini bilmiyor olsaydım, bu sınıfın ve methodun ne anlatmak istediğini anlar mıydım?…” gibi soruları soracak düşünce dönüşümünü yaşamamız gerekiyor. Başkaları kodunuzu okurken, sizin sahip olduğunuz domain ve requirement bilgilerine sahip olamayabileceğini dikkate almanız gerekiyor. Eğer bu zihniyet değişimi size zor geliyor ve daha bencil yada tek başınıza çalışan bir insansız, en azından yazdığınız kodu 6 ay sonra tekrardan okuduğunuzda anlayabilir miydiniz sorusunu kendinize sormanız lazım. Yaptığınız işte profesyonel ve ciddi bir insansanız, genelde tek başınıza yaptığınız projeleri bile zamanla başkalarıyla paylaşmak ve onlar ile beraber çalışmak zorunda kalacağınız fikrine sahip olacağınızdan, kod okunabilirliğine dikkat edersiniz.

Peki çözüm?

Yukarıda genel hatları ile çizdiğim kod okunabilirliğinin önemi, yazının ciddiyetinin anlaşılması için. Yani bir inşaat mimari için çizimlerin anlaşılması ve doğruluğu ne kadar önemli ise, bizim içinde benzer çok önemli kriterler var. Hoş bazen bu ifadeleri illa da daha tecrübeli yazılım mühendislerinden duymak yerine, kendiniz bile rahatlıkla tecrübe edebilirsiniz. Bir sene önce yazdığınız kodları okurken anlamakta çok zorluk yaşıyorsanız, demek ki birşeylerin yanlış olduğu ve yazılım mühendisliğinde en çok yapılan kod okumak işinin bu kadar zaman almaması ve moral bozmaması gerektiğini sorguluyorsunuzdur. Bu hususta junior ile senior developer’lar arasında ki en temel fark, senior mühendislerin bu tip kodları daha çok okumuş olmasından dolayı daha az sabırlı olması ve daha çok sövm.si olabilir. Bir diğer önemli fark ise senior mühendislerin kodu daha okunabilir kılmak için değişiklikler yapmaktan korkmaması ve gerekirse bunu politik zeminde de tartışıp ispatlaması. Juniorlar baştan işlerin böyle olduğu düşünüp, hayatlarının bundan sonra böyle devam edeceği zannına kapılabiliyorlar. Hayır! Bu şekilde yaşamak zorunda değilsiniz. Kavgacı olmamak suretiyle kimsenin gururunu kırmadan kodun daha okunabilir olması için çalışabilirsiniz. Bu ise başka bir yazı olarak ele alınması gereken bir konu.

Başka başka?

Başka neler yapmak lazım? Başlıkta da dediğim gibi 3 tane yöntemden bahsettim. Birincisi zihniyet değişimi idi. Bunun kodunuzun kalitesi üzerinde yapacağı gelişmeyi azımsamayın. Çok güzel sonuçlara gebe olan bir anlayıştır bu. Neyse. Diğerleri ise doğru ve anlaşılır değişken, method, ve sınıf isimleri ve son olarakta artık anlaşılmayacak kadar içinde kod bulunduran method ve sınıflardan kaçınmak. Dedim ya gayet basit 3 tane yöntem. Bunlar anında kodunuzu daha okunabilir yapacak yöntemler. Tabi bazen başka şeylerin de devreye girmesi gerekebiliyor ama genel olarak bu 3 yöntem ile kodunuzun çoğunu gayet anlaşılır hale getirmiş oluyorsunuz.

İsim vermeden önce bir düşün!

Değişken, method, ve sınıf isimlerine gelince kaçınılması gereken bazı isimler vardır. Bunlar: Temp, Manager, Service, gibi. Tamam belki bazılarınız neden Manager ve Service gibi isimlerinin bu listede olduğunu merak edebilir. Bunların abartı kullanımından kaçılması gerektiği şeklinde bir düzeltme yapayım. Zaten bunları tek başına kullanacağınızı düşünmüyorum bile. Yani bir sınıfı sadece Service diye isimlendirip bırakmanızı hayal edemiyorum. Onun için bu hatanın üzerine düşmüyorum bile. Ama bu isimleri kullanırken, tutarlı olmaya özen gösterin. Mesela, AccountManager demek sureti ile account create, update, veya get edilen bir yer olduğunu vurgusunu yapıyorsanız, o zaman bu tutarlılığı Manager olarak isimlendirdiğiniz başka sınıflarda da kullanmaya özen gösterin. Ama Manager ismini kullanmadan önce, daha doğru ve anlaşılır başka bir isim bulabilir misiniz diye sormanız lazım. Mesela AccountRepository sizin yapmak istediğiniz işleri daha iyi anlatabiliyordur belkide.

Ne servismişsin arkadaş?!

Yazılımda Service kelimesi kadar hem fazla hemde bu kadar çeşit manada kullanılan başka kelime var mıdır emin değilim. Onun için insanların kafasını karıştırmamak için başka kelime seçimlerine bakmanızda fayda var. Eğer bir sınıf farklı yerlerde accountlar oluşturmak için kullanılıyorsa, ona AccountService demek yerine lütfen AccountCreator deyin. Hem daha anlaşılır olacak hemde Service kelimesini tüm sistem üzerinde tutarlı yapmak ile uğraşmış olmayacaksınız. Bilmem buraya kadar anlatmak istediklerimi anlatabildim mi?

Less is more

Son olarak sınıfları ve methodları küçük tutalım demiştim. İnsan zekası aynı anda birden fazla şeyi kafasında tutmak hususunda çok iyi değil maalesef. Belki alışveriş listesini hatırlayabilirsiniz ama Yazılım Mühendisliği gibi insanın zihnini yoran bir meslek yaptığınızda, okunabilirlik üzerine ufak tefek dokunuşların bile çok önemli olduğunu görüyorsunuz. Çok basit bir örnek vereyim: Eğer AccountService sınıfınız, AWS, Azure, Local Database, vs. birden fazla yerde account oluşturmak için kullanılıyorsa, bu kadar çeşit işlevi hatırlamak zor olacaktır. Rica ediyorum “Ne var bunda, bir sınıf sadece.” demeyin! Bu kafayla kod yazan adamın projelerine baktığınızda buna benzer sınıflardan yüzlercesi hatta belki de binlercesini göreceksiniz. Eğer kendinizi aşırı zeki zannediyorsanız, belki yazılım mühendisliği yapmak yerine, hayatın sırrını araştırmak yüksek zekanızı daha doğru yerde istihdam etmek olacaktır. Ama kendisini çok zeki zannedipte foseptik kod yazanlar ile ne çalışmak nede işe almak isterim. Neyse, AccountService yerine o sınıfı parçalamak ile daha anlaşılır AccountCreatorForAWS, AccountCreatorForAzure, vs. gibi isimler kullanmak hem kodun daha kolay okunabilir olmasını sağlayacak hemde daha modüler yapacaktır. Bu şekilde küçük ve yaptığı işle daha tutarlı parçalara bölmek ile her bir sınıfın sadece bir iş yaptığını bildiğinizden hatırlamak zorunda kalacağınız çok bir şey kalmıyor. Öğrenmek istediğiniz şeyi sınıfın ismi zaten söylüyor. Aksi halde bir sınıfın nerelerde hangi değişiklikleri yaptığını hatırlamak zorunda kalıyorsunuz. Ama “Ben hatırlamakla uğraşmam; sınıfın içine bakarım!” diyorsanız, bu da ayrı bir foseptik anlayış. Genelde bu kafa güzel kod yazmıyor. Her bir methodun ve sınıfın ne yaptığını ve benim işime yarayıp yaramayacağını isimlerine bakmak ile anlamak imkansızsa, 10 dklık bir iş için 1 hafta boyunca oradasınız demektir. Bu sadece çalıştığınız şirketin kaynaklarını kaybetmesi değil aynı zamanda sizin moral ve motivasyonun içinde kaybettirici bir sorun.

Dur iki dk!

Tamam bitiriyorum ama son olarak ufak bir eklenti yapmak istiyorum. Lütfen aynı değişkeni 100 farklı değer ataması için kullanmayın. Özellikle de methodlara gönderdiğiniz parametreleri. Allah için, fazladan ekmek mi alıyorsunuz ki sonra yemezsem israf olur korkusu yaşıyorsunuz? Tanımlasanıza arkadaşım başka bir variable! Bu nasıl bir tembellik!

Neyse… Bir başka yazımda görüşmek üzere.

No Comments Yet