Kullanmaniz Gereken 10 Programlama Prensibi

Kullanmaniz Gereken 10 Programlama Prensibi

Bir programlama dili bilen herhangi biri kod yazabilir ama yazılan kod iyi bir kod mu? İşte işler burada birazcık zorlaşmaya başlıyor.

            Hepimiz “Spagetti Kod” ‘un ne olduğunu duymuşuzdur ve örneklerini görmüşüzdür belki de, bütün kodu If-Else zincirine bağlayıp bir değişkenin değiştirilmesiyle bütün kodun bozulması buna örnek verilebilir.

            Sadece kodun çalışmasını yeterli bulmamalısınız, çalışmasının yanı sıra geliştirilebilir, okunabilir olmasını amaçlamalısınız. Kodunuzu bir başka programcı baktığı zaman okuyabilecek şekilde  yazarsanız, sadece sizden sonraki programcı için değil kendiniz için de bir iyilik yapmış olursunuz. Sizlere bu makalede, kullanılırsa sizin yeteneklerinizi bir üst seviyeye taşıyabilecek 10 programlama prensibinden bahsedeceğim ve denemenizi öneriyorum.,

1. KISS(Keep it simple, stupid / Basit tut aptal)

            KISS tekniği hayatımızın tamamına uyarlanabilir, ancak bu prensib orta ile büyük projeler için büyük önem taşımaktadır.

            Bu adım kod yazmaya başlamadan önce neler yaratacağınızı planlarken önünüze çıkacaktır.

Oyun Geliştiriciliğini seviyor olmanız bir sonraki “GTA, WOW, CS, vs.” eserini çıkaracak anlamına gelmiyor. Yapmak istediğiniz şeyi yeterince basitleştirdikten sonra çekinmeyin ve bir daha basitleştirin, kodu yazarken önünüze çıkacak engelleri bilemezsiniz o yüzden küçük başlayın.

            Kod yazmaya başladıktan sonra bile kodunuzu basit tutmaya çalışın, karışık ve her işe el verişli bir kod tasarlamak ve yasmak uzun sürecektir ve hatalara daha açık olacaktır ki ileride bu kodu geliştirmek ilerledikçe zorlaşacaktır.

2. DRY(Don’t repeat yourself / Kendini tekrar etme)

            DRY prensibi, temiz ve kolay geliştirilebilir bir kod için olmazsa olmazdır. Kod yazarken, kullandığınız kodları tekrarlamamaya çalışın, örnek verecek olursam buna bir fonksiyon yazdınız ve bu fonksiyonda çok küçük bir değişiklik yapacaksınız ve bunu uyarlanabilir yapmak yerine başka bir fonksiyon yarattınız ve bunu kullandınız, bunu bir kere yaptığınızda belki gözünüze zararlı gözükmeyebilir ancak ileride 2.yi de yaptığınız zaman bu kopyalar çoğalacaktır ve kodunuzu okunamaz ve geliştirilemez hale getirecektir.

            DRY prensibiyle yazılan kodun tam tersine ise “WET(Write everything twice / Herşeyi iki kere yaz)” ya da diğer adıyla “Herkesin zamanını harca.” diye bilinir. Kodunuzun DRY değil de WET adı altına düşüp düşmediğini anlamak için kendinize şu soruyu sorun; “Programa yeni bir özellik eklemek istediğimde, bu kodu kaç ayrı bölüme eklemem gerekecek ?” bu soruyu cevaplamakta zorluk çekiyor ve kendinizi rahatsız hissediyorsanız cevabı evet olarak kabul edin ve kodunuzu “Refactor” edin.

3. Open/Closed (Açık / Kapalı)

            Kodunuzu eklentilere açık ancak modifikasyona kapalı şekilde yazmaya çalışın. Bu bütün tarzda projelerde geçerlidir ama özellikle başkalarının kullanmasını amaçladığınız durumlarda önemi artmaktadır.

Örnek verecek olursak, bir framework ürettiniz. Bunu o anki haliyle yayınlayabilirsiniz ve kullanıcıların paylaştığınız kodu direk değiştirip modifiye etmesini sorun olarak görmezsiniz. Peki birkaç ay sonra frameworkunuze büyük bir güncelleme yaptığınız zaman kullanıcılar uyguladıkları modifikasyonlar ve eklentiler frameworkunuzle uyumlu olmayacaktır ve verdikleri emek boşa gitmiş olacaktır.

Bunun yerine, frameworkunuzu insanların ana kodunuza modifikasyon etmekten ziyade üzerine yeni eklenti eklemeye teşvik etmeye amaçlamalısınız. Bu şekilde frameworkun ana fonksiyonelliği ve ekstra fonksiyonlarını ayırmış olursunuz. Yararları ne diye soracak olursanız; kodunuzun bakımı daha iyi olur ve kodunuz daha güvenilir( Kullanıcılar yanlışlıkla ana kodunuzu bozamaz.) olur.

Bu prensip iyi bir API yapmak için izlenmesi gereken ana faktördür.

 

4. Compositon > Inheritance ( Tekillik > Kalıtım)

            “Kalıtım yerine Tekillilik” prensibi, karışık işlevselliklere sahip olan bir sınıf başka bir sınıfın alt sınıfı olup da üzerine eklemekten ziyade tekil olarak yaratılmasını savunur.

            Kalıtım mimarisine uygun olacak diye bütün kodunuzu bu şekilde yazmanız önünüze iki büyük sorun çıkaracaktır. Birincisi, bu kalıtım mimariniz göz açıp kapayıncaya kadar karmaşık ve sağlıksız hale gelebilir. İkinci olarak ise kodunuz büyümeye başladıkça, yarattığınız objelerin esnekliği azalır ki buna örnek verecek olursak; varsayalım 10 tane sınıfınız var ve bu sınıflarınızın hepsi birbiriyle kalıtım ilişkisi içindeyse A sınıfında kullandığınız kodu B sınıfında aynısını kullanacağınız halde tekrardan eklemeniz gerekecektir. Bu aynı zamanda tekillilik içinde de geçerli neden böyle diye soracak olursanız cevaplayayım, Tekil sınıflar daha kolay değiştirilebilir, geliştirilebilir ve neredeyse sınırsız esnekliğe sahiptir. Bir tekil sınıfın içindeki fonksiyonlara ulaşmak istediğinizde tek yapmanı gereken o kodu kullanacağınız sınıfta tanıtmaktır ve bu şekilde bir değişiklik yapmak istediğinizde tanıttığınız sınıfa gidip oradan değişimleri yapabilirsiniz. Verdiğim örneğin neden kalıtımdan uzak durmanız gerektiğini açıkladığını sanıyorum ancak yine de belirteyim, aynı örneği biraz değiştirerek kalıtım üzerinden gidersek, bir fonksiyonu değiştireceksiniz ve bu fonksiyonun kopyasını bir çok sınıfta kullandınız ve bu yüzden her birinde tek tek değiştirmeniz gerekecektir ki bu proje büyüdükçe çözülmesi zor ve karışık sorunlara yol açacaktır.

5. Single Responsibility( Tek Sorumluluk )

            Tek sorumluluk prensibi, projenizde kullandığınz bütün model ve sınıflar sadece kendisinden sorumlu olmalı ve diğer sınıflara olabildiğince az bağımlı olmalı. Her bir sınıf veya model yarattığınızda başlangıçta çok göze çarpmasa da sınıfınızın kod satırları çoğaldıkça ve yeni özellikler ekledikçe bu sınıfın projenin büyük bir kısmından sorumlu olduğu konumuna gelmesi kaçınılmazdır. Bu noktaya geldiyseniz, yeni özellikler eklemeye devam etmeden önce kodunuzu küçük parçalara ayırıp daha sağlıklı ve okunabilir hale getirmeye çalışmalısınız.

6. Seperation of Concerns ( İlgilerin Ayırımı )

            İlgilerin Ayrımı prensibi “Tek Sorumluluk” prensibine benzemektedir ancak bu prensip daha kapsamlı seviyededir. Özünde şunu belirtmektedir, projenizin kod mimarisi tasarlanırken yarattığınız sınıflar ve modüller olabildiğince birbirini tanımamalılardır.

            Örnek verecek olursak; Veritabanına veri alışverişinden sorumlu bir sınıf bu bilgilerin nasıl kullanıldığına ihtiyaç duymamaktadır ve nasıl olduğunu bilmemelidir. Kullanılırken yeni bilgiye ihtiyaç duyulduğunda da aynı şekilde, kullanan sınıf bilginin nasıl veritabanıyla iletişim halinde olduğunu bilmesine gerek yok ki bunun için sorumlu bir sınıf var zaten. Bütün sınıflar kendisiyle ve sadece kendisiyle ilgilidir.

            Bu prensibi uygulamanız kolayca düzenlebilir bir kod mimarisine sahip olmanızı sağlar. İleride very iletişiminde kullandığınız kodu değiştirmek ve geliştirmek istediğinizde yazacağınız yeri nokta atışıyla bulabilirsiniz.

7. YAGNI( You Aren’t Gonna Need It /  İhtiyacın olmayacak )

            YAGNI prensibi ileride ekleyebileceğiniz bir koda uyumlu bir kod yazmaya çalışmaktan çekinmenizi savunur. Yüksek ihtimalle bunu yapmanıza gerek kalmayacak ve zamanınızı boşa harcamış olacaksınız ki sadece bunla kalmayıp kodunuzu daha da karmaşık bir duruma sokacaktır.

            Bu prensibi KISS prensibinin alternatifi olarak görebilirsiniz ve DRY prensibini aşırıya kaçımı olarak bakabilirsiniz. Genellikle farkında olunmasa da tecrübesiz programcılar, kodlarını yazarken olabildiğince kapsamlı ve modifikasyona açık bir kod yazmaya çalışıp, olabildiğince WET koddan uzak durmaya çalışırlar ancak farkedilmese de bu şekilde yazmaya çalışmak düzenli tutulması imkansız hale getirecektir.

            Bu duruma düşmemek için DRY prensibini sadece ihtiyacınız olduğunda uygulayın. Eğer bir kodun kendini sürekli tekrarladığını farkettiyseniz, bu kodu bir fonksiyon haline getirin. Ancak bir kodun tekrar ve tekrar kullanılabileceğini varsayarak bu kodu ayırmaktan kaçının.

8. Avoid Premature Optimization ( Erken Optimizasyondan Kaçının )

            Bu prensip YAGNI prensibine benzemektedir. Aradaki fark; YAGNI şuıanda ihtiyacınız olmayan işlevsellikleri eklememenizi belirtirken bu prensip de ihtiyacınıız olmadan performans için kodunuzu optimize etmeye çalışmamanızı belirtir.

            Bunun sebebi ise programın tam olarak nereden kaynaklı yavaş çalıştığını, çalıştırmadan anlayamazsınız. Tahmin yürütebilirsiniz elbette ve bazen doğru da tespit etmiş olabilirsiniz. Ama genellikle projenizi geliştirmeye ayıracağınız değerli zamanı, optimize edilmesi gerekmeyen bölümlere harcamış olmakla kalırsınız.

9. Refactor, Refactor, Refactor ( Kodu tekrar düzenlemek. )

            Tecrübesiz bir programcının kabul etmesi gereken zorlu bir gerçek vardır o da ilk sefer yazdığınız kodun, anlaşılır ve işlevsel olmayacağıdır. Projenize yeni bir özellik eklediğinizde kendinizi iyi hissedebilirsiniz ancak projeniz bu tarz özellikleri ekleye ekleye büyüdükce, karmaşayı da yanında getirecektir. Gelecekte kodunuzu yazarken daha rahat ve iyi hissetmeniz, kodunuzun o anki durumuna göre artacak veya azalacaktır.

            Yazılan kodun mimarisi, yeni şeyler eklendikce gelişmektedir. Önceden yazdığınız çalışan kodunuza göz atmanız, tekrardan yazmanız ve hatta tamamen mantığını değiştirmeniz gayet normaldir ve sadece normal olmakla kalmayıp aynı zamanda çok yararlıdır. Eski yazdığınız kodu sürekli olarak gözden geçirip daha iyi hale getirmeye çalışmak, hem projenizi daha iyi tanımanıza ve tekrar tekrar düzenledikçe ileride kodunuzu daha iyi şekilde yazabilmeniz için size yararlı bilgiler sağlayacaktır.

            Şunu da gözden çıkarmayın kodu tekrar düzenlerken, çok fazla abartmanıza gerek yoktur.

Proje zaten elinizin altında olduğu için, her zaman geri dönüp tekrar değiştirebilirsiniz. Uzun aralıklarla büyük düzenlemelere gitmekten ziyade kısa aralıklarla küçük düzenlemelerle giderseniz hem siz büyük yükün altına girmemiş olursunuz hem de daha verimli iş çıkarabilirsiniz.

10. Clean Code > Clever Code ( Temiz Kod > Dahi Kod )

            Egonuzu kapıda bırakıp sıradışı bir kod yazmaya çalışmaktan ziyade temiz bir kod yazmayı amaçlayın. Burda demek istediğimi anlıyorsunuzdur; yazdığınız kodun çözüm gibi değil de bir bilmeceyi andırmasından ve tek amacının ne kadar zeki olduğunuzu göstermeye çalışmasından bahsediyorum. Dürüst olacaksak kimsenin umrunda değil.

            Dahi Kod altına düşen bir koda örnek verecek olursak; bir satır koda olabildiğince fazla mantık yükleyip, bir satırda hallettim demek olabilir. Başka bir örnek ise kullandığınız dilin açıklarını kullanarak garip ama çalışan fonksiyonlar yaratmanız. Kısacası, başkası baktığı zaman “Bu ne?” sorusunu sorduğu koda Dahi Kod denir.

            İyi programcılar ve okunabilir kod birbirini tamamlayan bir ikilidir. Gerektiğinde kodunuza not düşün. Herkesin bildiği ve standart olarak kullanılabilecek kod mimarilerini kullanın. Büyük bir şirkete girdiğinizde sizden beklenen şey şirketin kod yazma standartlarına uymanız olacaktır.

Kaynak

Yorumlar
Anton Semchenko
Anton Semchenko Sunu okumanizi da tavsiye ediyorum: http://gameprogrammingpatterns.com/ Oyun gelistiriken en cok karsiniza cikacak duzenleri anlatan oldukca faydali bir kaynak