wmaraci reklam

Her Geliştiricinin Bilmesi Gereken 10 Programlama Prensibi

Tüm efsanevi yazılımcıların söylediği gibi, başarmak isteyen herkes kod yazabilir. Fakat iyi kod yazmak herkesin harcı değil. Hal böyle olunca geliştiriciler sonra demiş ki, “Bunları kafasına göre bırakırsak herkes başka bir şey yapacak. İyisi mi, hepimiz bir prensip icat etsin. Bu işi bir yola yordama sokalım.” Böylece kodlama dünyasının yazılı olmayan ama geniş kitleler tarafından kabul edilen adabı muaşeret kuralları ortaya çıkmış.

Programlama prensiplerini anlamak için programlama gurusu olmanıza, uzay mekiği kodlamanıza veya bir programlama dilini uzman seviyesinde bilmenize gerek yok. Altı üstü prensip ama kitleler tarafından kabul görmüş prensipler önemlidir. Prensipleri takmadan kendi kafanıza göre kodlarsanız Prensip Tapınakları Şövalyeleriyle bir gün burun buruna gelebilirsiniz. Daha iyi kodlamak, şövalyelerden uzak durmak, biraz da “Yahu yumduk gözü yazıyoruz ama bakalım bi’ yamuk çıkacak mı?” Stresini çekmekten uzaklaşmak istiyorsanız, geniş kitleler tarafından kabul gören 10 programlama prensibine bir göz atın derim.

10- KISS

”Mükemmelliğe, eklenecek bir şey kalmadığında değil, çıkarılacak bir şey bulunamadığında ulaşılır.” - Antoine de Saint-Exupéry”

KISS açılımıyla ”Keep it simple stupid”. Bizim dildeki karşılığıysa varsın aşrı aşrı memleketlere yine kız vermesinler ama sen işi kolay tut demek. KISS’i programlamanın dışında yazdığında, çizdiğinde, tasarladığında, okuduğunda ve bütün hayatında uygulayıp başarılı olan ölümlülerin olduğu rivayet ediliyor. Programlama için ise KISS her şeyi basitlik erkânı etrafında toplamamızı öğütlüyor.

Şöyle ki; bir şey geliştirmek istiyorsanız onu en kolay nasıl geliştirmek istediğinizi çözmeniz gerekiyor. Sadece geliştirmekle bitmez. Etrafınızdaki insanların bunu anlaması hatta kullanıcıların kafalarının karışmaması gerekiyor. Mobil uygulama geliştirmeye ilgi duyuyor olmanız, Grand Theft Auto’yu baştan yazmanız anlamına gelmiyor. Marketlere bir bakalım… Candy Crush Saga, Clash of Class ve daha nicesi KISS prensibiyle hareket ediyor ve başarıyı cebe atıyor. KISS yapacağınız işi basit düşünün, küçük başlayın, sonra işiniz tutarsa büyütürsünüz mantığıyla olaylara ve kodlara yaklaşmayı gerektiriyor.

KISS’in faydaları kodlarınız bittikten sonra bile devam ediyor. Basit kod satırlarından oluşan dosyalarda debugging yapmak sancısız süreçleri yanında getiriyor. Yeni bir şey eklemek istediğinizde ise kafaları yemenize gerek kalmıyor.

Efsaneler Ölmez Şekil Değiştirir: Mavi Ekran Hatası Yeşil Oldu!
İlginizi Çekebilir!

Efsaneler Ölmez Şekil Değiştirir: Mavi Ekran Hatası Yeşil Oldu!

Microsoft Windows işletim sistemlerinde ilk defa Windows NT ve Windows 98 sürümleriyle birlikte kullanılmaya başlanan, Windows XP ile birlikte dünya çapında tanınan en popüler bilgisayar hatası mavi ekran veya namı diğer Blue Screen of D...

9- DRY

DRY açılımıyla “Don’t repeat yourself”, “Kendini tekrar etme” prensibi olarak biliniyor. DRY, temiz ve düzenlemesi kolay kodlar geliştirmek için programlamanın göbek taşı görevini üstleniyor. Aynı kod satırlarını birebir yazmıyor olmanız, aynı kod mantığını tekrarlamadığınız anlamına gelmiyor. Bazen satırlar farklı, “Run” sonucu farklı, gönül bambaşka şeyler söylüyor. İşte o zaman DRY devreye giriyor.

DRY prensibi bu prensibin zıttı olan WET prensibine tepki olarak ortaya atılmış. WET: “Write everything twice”, “Her şeyi iki defa yaz” prensibidir. DRY prensibine gönül vermek, hazırlanan yazılımlarda düzenleme After Party’lerinin günlük gülistanlık geçmesine yardımcı oluyor. Örneğin bir e-ticaret sitesi hazırladınız ve bir listeleme modülünüz var. Arama sayfasında farklı listeleme modülü, kategori sayfasında farklı listeleme modülü ve farklı sayfalarda farklı bir listeleme modülü kullandığınızı varsayalım.

Şimdi bu listeleme sistemi üzerinde değişiklik yapmanız gerektiğinde tüm bölümleri teker teker elden geçirmeniz gerekecek. Ne mi olacak? After Party’niz bir anda Work Hard’a dönüşecek. Bir de ters zamanda işlerin başınıza patladığını hesaba katarsak Allah kurtarsın ya da DRY’ın yolundan ayırmasın diyorum.

8- Open/Closed

Open/Closed veya Açık / Kapalı’lık hazırladığınız kodların değiştirilmeye kapalı ama geliştirilmeye açık olması anlamına geliyor. Her programlama projesinde kullanılabilecek bu prensip, diğer kullanıcıların da faydalanacağı kütüphaneler veya framework’ler yayınladığınızda ciddi önem kazanıyor.

Örneğin bir GUI framework’ü hazırladığınızı ve Allah ne verdiyse olduğu gibi yayınladığınızı varsayalım. Şimdi bir son kullanıcı bu kodların üstünde dilediği gibi at koşturabilir. Sonra tuttunuz 4 ay sonra bir majör güncelleme yayınladınız. Sistemi güncelleyenler bir baktılar ki, çatır çutur tasarım kayıyor ve geliştiricilerin üzerine titreyerek yaptığı değişikliklerin hepsi duman olmuş. Bu felaket senaryosundan sonra artık tezgahı kapatıp sahil kasabasına yerleşmek üzere yola çıkabilirsiniz.

Ya da tıpkı WordPress ve benzeri sistemlerin yaptığı gibi Açık Kapalılık prensibine göre hareket ederek güncelleme ve geliştirme işlemlerini sıkıntısız sancısız bir sürece dönüştürebiliriz. Üstelik bunun bir çok faydası var;

  • Kodun daha stabil olmasını sağlıyor.
  • Kolayca güncellemelerin sunulabilmesine yardımcı oluyor.
  • Kullanıcıların yanlışlıkla kodu dağıtıp dökmesini engelliyor.
  • Her yayın değişikiliğiyle birlikte geliştiricilerin başına yeni çorapların örülmesinin önüne geçiyor.

7- Composition Over Inheritance

“Composition > Inheritance” veya “Composition Over Inheritance” karmaşık görünmese rağmen güç durumlarla başa çıkmaya yardımcı olan bir kodlama prensibi. Olayı kısaca özetlemek gerekirse; ihtiyaç duyulan sınıfların her biri için ayrı birer sınıf oluşturmak yerine bu sınıfları dışardan alma yoluyla edinmeye Composition Over Inheritance Prensibi deniliyor.

Programlama bilmeyen arkadaşlar için bu prensibi tek başına yalın bir dille anlatmak zorlayıcı olabilir. O yüzen yukardaki tablo mevzuyu açıklığa kavuşturacaktır. Kuş bir hayvandır, uçabilir ve yürüyebilir. Yürüyen ve uçabilen hayvanlar için farklı bir sınıf oluşturmak yerine yukardaki prensibi kullanarak kod kalabalığı ortadan kaldırılmış oluyor. Basit ve tek atımlık bir örnek verdik ama bu verilerin bazen binlerce olduğu, Arap saçına dönüp saç baş yoldurduğu zamanlar olabiliyor. Composition Over Inheritance prensibini takip etmek işi kolayca çözümlemeye yardımcı oluyor. Her tarafın veri sınıfına dönüştürülmesine gerek kalmıyor.

6- Single Responsibility

“Single Responsibility” veya “Tek Sorumluluk” prensibi, bir program içindeki her sınıf veya modülün sadece kendisinin spesifik bir fonksiyonel özelliğe sahip olması anlamına geliyor. Sınıflar ve modüller bu şekilde biçimlendirildiğinde, sonradan sisteme dahil edilecek olan ekstra özelliklerle başa çıkmak daha kolay oluyor. Tek fonksiyonluk kodlar gelecekte ekleme yapılması istendiği zaman küçük parçalara bölünüyor ve genişletiliyor. Sonuç olarak prensibimiz programımızın kaynak kodunda mayın tarlası gibi binlerce ayrı sınıf ve yüzlerce farklı kod satırı oluşmasının önüne geçmiş oluyor.

5- Separation Of Concerns Prensibi

Separation Of Concerns Principle bir önceki prensibimiz olan Single Responsibility’e benziyor fakat bu işin biraz Niravana’ya ulaştırılması boyutunu temsil ediyor. Separation of Concerns prensibine göre programın içindeki bölümler kısımlara ayrılmalı ve bu kısımlar bir diğerinin ne yaptığından haberdar olmamalıdır. Her bölüm kendi içinde yetkilere sahip olmalı ve bazı özel işlevleri yerine getirmelidir.

Separation of Concerns Principle’ın en bilinen örneklerinden biri model-view-controller’dır (MVC). MVC modelemesine göre, yapı verisi (“model”), mantık (“controller”) ve kullanıcıların gördüğü (“view”) şeklinde ayrıştırılıyor.

MVC bugün modern web framework’lerinde en sık karşılaşacağınız yapı örneklerinden biridir. İnternet üzerinden veriyi alıp veritabanına işleyecek olan kod dilimi verinin internetten nasıl alındığıyla (render) ilgilenmez. Sadece kendi işine bakar ve tüm sistem kendi içinde bunu tekrarlar. Modüler kodlamanın en yaygın örneklerinden olan bu yapı yardımıyla sistemin bakımını yapmak kolaylaşır. Gelecekte hiç olmadık kodları sisteme eklemeniz gerekirse tüm bir sistemi baştan yazmak yerine sadece ilgili kısımları düzenlemeniz değişiklik için yeterli olur.

4- YAGNI

YAGNI; “You aren’t gonna need it”, “Salla gitsin, buna nasıl olsa ihtiyacın olmayacak” prensibidir. YAGNI prensibine göre gelecekte ihtiyaç duyabileceğinizi düşündüğünüz hiçbir fonksiyonel kodu sisteme eklemiyorsunuz. Çünkü günün birinde ihtiyaç duyacağınızı düşündüğünüz o özelliğe gerçekten ihtiyaç duymamanız halinde zamamınızı boşa harcamış olacaksınız. Şans işte, eklemeyi düşündüğünüz fonksiyona ihtiyaç duyarsanız da bilgisayarın başına geçip “Ya ben bunu yazmayı düşünmüştüm ama” deyip tekrar hazırlamanız gerekecek.

YAGNI prensibine göre gelecekte ihtiyaç duyulabileceği düşüncesiyle sisteme eklenen kodların tamamı gereksiz. Sistemin boş yere kod karmaşası hırkasını giymesine yol açıyor. Kod dosyalarınızın toplam boyutunu arttırıyor olması cabası.

YAGNI’yi listenin başında değindiğimiz KISS prensibine benzetebilirsiniz. YAGNI de bir yerde kodunuzu ve sisteminizi temiz tutmanızı öğütlüyor. İhtiyacınız olma olasılığı üzerine kaynak kodda yer alan kodlardan kurtulmanız, bir gün sistemi değiştirmek istediğinizde daha az kod satırıyla uğraşmanıza yardımcı oluyor.

3- Prematüre Optimizasyondan Kaçınmak

Ecnebilerin deyimiyle “Avoid Premature Optimization”, sisteminizin henüz yavaş olduğunu görmeden “Dur ben bunu hızlandırayım” ifadesi altında yaptığınız optimizasyonların tamamını içeriyor. Bir yazılımın betası çıkıp kullanıcılar testleri yapana kadar tam olarak neresini optimize etmeniz gerektiğinden emin olamazsınız.

Bazen beklemediğiniz yer patlak verir ve bazen beklediğiniz hatta emin olduğunuz bölümler daha iyi performans gösterebilir. Bu nedenle kitleler prematüre (erken) optimizasyon yapmanın zaman kaybı olabileceğine değinmiş ve ortaya bu prensibi atmışlar. Adamlar haksız sayılmazlar, gelin yazılımları tıpkı otomobillere benzetelim. Otomobiller yol üzerinde yapılan binlerce testten sonra iyileştirir ve son hallerini alırlar, yazılımlar da öyledir.

2- Code Refactoring

Code Refactoring, yeni yeni başlayan kişilerin düştüğü en büyük yanılgının prensibidir. Kodların her zaman ilk seferinde çalışacak olmasını beklemek hatadır. Ne yazık ki işin iç yüzüne girdiğinize olayın bu kadar basit olmadığını deneyimlersiniz. İlk başta yazdığınız kodu çalıştırısınız ama kod satırları aşağıya doğru indikçe sahneye büyük karmaşalar çıkar. Bu karmaşalardan çıkmak için önceki yazdığınız kod üzerinde değişiklik yapmanız gerekir. Böyle bir kısır döngü işte…

Kodlar internet ve teknolojinin kendisi gibidir. Onlar da zamanla gelişir ve teknoloji değiştirirler. Bir kere yazdığınız kod ilelebet çalışamaz. Yeni güncellemeyle kodlarının bir kısmı çöpe çıkabilir ve bazı bölümlerini düzenlemeniz gerekebilir. Kod düzenlemek ve sürekli kod satırlarının arasında yenilikler yaparak eski kodu düzenlemek (Code refactoring) kendinizi yetiştirme ve yeni şeyler öğrenmenize yardımcı olur.

Code Refactoring prensibi her zaman bir gereklilik olmayabilir. Büyük projelerde tekrar tekrar geri dönüp kod satırlarında oynama yapmak işleri kolaylaştırmaz. Lakin yeni başlayan aşamasında Code Refactoring prensibini benimsenizin kişisel gelişiminize faydası olacağı kesin.

1- Temiz Kod = Zeki Kod

Temiz kod (Clean Code), kodlama işinin felsefe taşına benziyor. Yazdığınız koda sonradan siz veya başka birileri ihtiyaç duyabilir. Kod sayfasını açtıklarında sadece sorunları çözüme kavuşturmak için rastgele yazılan satırlar mı görecekler? Yoksa belli bir hiyerarşi içinde düzenlenerek sisteme giydirilmiş kodlar mı? İşte temiz kodu budur!

Yazılımcılar arasında eski kabile üyelerinin devam ettirdiği bir gelenek vardır. “Clever Code” yani “Zeki Kod” adı verdikleri bu geleneklere göre, kodu nasıl yazdığınız hiç önemli değildir. Tam aksine kodunuz ne kadar karmaşıksa bu sizi o kadar zeki gösterir. İlkel zamanlarda bu teknik yer miydi, yerdi. Artık satmıyor.

Freelancer veya bir ekiple çalıştığınızda hiç kimse sizin kodlarınızı çözemediğinde ciddi sorunlar baş gösteriyor. Bir anda zeki adam değil, ekibin en zayıf halkasına dönüşüyorsunuz. Zeki olmak ve zeki görünmek seksi hissettirebilir fakat işten atıldıktan sonra nasıl hissettirdiğiyle pek ilgilenmek istemiyor olabilirsiniz.

Bu listede bahsettiğimiz kült haline gelen 10 programlama prensibi dışında sizi birçok prensibin beklediğin unutmayın :) Kolay gelsin.

Bu içeriğe tepkini gösterebilirsin! 👍

Bu içerik hakkında daha önce tepki gösterilmemiş. İlk tekpi göstererek yazarlarımıza geri bildirim verebilirsin.

Yorumunuz

    Son Yorumlar

    Site Ayarları
    • Tema Seçeneği
    • Site Sesleri
    • Bildirimler
    • Özel Mesaj Al