Tasarım, tasmam kime ne ?

Share Button

Aslında bugün “Bir fonksiyon yazdım-2” başlıklı yazıyla karşınıza çıkmayı hedeflemiştim ancak şu sıra üstüne çok konuştuğum, çokca da içinde bulunduğum projelere b.k atmama vesile olan başka bir konuyla karşınızdayım.

Hepimiz farklı şirketlerde geliştirici olarak değişik projelerde görev alıyoruz. PHP dünyası için konuşmak gerekirse şanslı bir azınlık popüler frameworklerle geliştirilmiş, kurallara/standartlara uygun yazılmış projelerde çalışırken malesef büyük bir çoğunluk kötü kodlanmış, çoğunlukla spagettiye dönmüş kodların içinde debelenip duruyoruz. Bu durum müşteriden gelen isteklere verilen zamansal hedeflerin tutturulamamasına, yeni geliştirmelerin bir şekilde eski geliştirmeleri bozarak yazılımın hatalı çalışmasına ve en kötüsü test edilemeyen kod üretimine neden olmaktadır. Peki doğru bir yazılımın tasarımı nasıl olmalı ?
İyi yazılım tasarımının nasıl olabileceğini açıklayabilmek için öncelikle kötü bir tasarımın ne gibi özelliklere sahip olduğunu bilmeliyiz. Robert Martin abimiz kötü bir yazılım tasarımının 3 temel özelliğe sahip olabileceğini söylemiş.
Rigidity
Rigidity (Esnemezlik):
Kötü tasarımlar geliştirmeye uygun değildir, Esneklikleri yoktur. Birgün, belki birkaç saat süreceğini düşündüğünüz bir iş haftalar sürebilir. İşin ne zaman biteceği kestirilemez. Dolayısıyla tasarım sorunu gün geçtikce yönetimsel bir problem halini alır.

Fragidity
Fragidity (Kırılganlık):
Hepimizin aşine olduğu bir konu. Yeni bir geliştirmenin eski bir geliştirmenin bozulmasına neden olmasıdır. Bu durum, yapılan her geliştirmede çalışan başka bir yerin bozulacağı korkusunu yaratır ki işinizi yapamaz hale gelirsiniz. “IT bir yeri yaparken bir yeri bozuyor be arkadaş” cümlesini sıklıkla duymanıza neden olur.

Immobility
Immobility (Taşınamamazlık) :
Bağımlılıklar nedeniyle bir kodun başka bir yerde kullanılamaması durumudur. Bu tarz durumlarda aynı modülün tekrar kullanılması gerektiği durumlarda modül/kod bloğu bir kere daha yazılır. Lojik değişikliği gerektiği durumlarda pek çok yerde değişiklikyapmanız gerekir, çoğunluklada atlanan/unutulan yerler nedeniyle sistemin stabilitesi bozulur, yazılım hatalı çalışmaya başlar.

Ortalama birgününüz, çözdüğünüz issue lar ve dahil olduğunuz projeler gözünüzün önünden geçti değil mi ? :)

Peki doğru bir tasarım nasıl olmalı ? Doğru tasarım aşağıda kısaca açıklamaya çalıştığım S.O.L.I.D. prensiplerine uygun olmalıdır.

Single Responsibility (Tekil sorumluluk):
Her kod bloğu (modül, sınıf, metod) kendi sorumluluğundaki işi yapmalı. Kod bloklarının kendi sorumluluğu dışında işleri yapması bağımlılığı arttırır. (Bkz. Bi fonksiyon yazdım… )

Open-Close (Açık – Kapalı) :
Modülleriniz gelişime açık, değişime kapalı olmalıdır. Herhangibir değişiklik gereksinimi olduğunda mevcutu değiştirmek yerine yeni bir özellik olarak eklenmelidir.

Liskov (Liskov prensibi) :
Türemiş bir sınıf atası olan sınıfla aynı davranışı sergilemelidir.

Interface Segregation (Arayüz ayırma):
Benzer özellikler taşıyan sınıflardaki metodların gruplanarak tek bir interface e tabi olmaları sağlanmalıdır. Böylece programınız tarafından kullanılmayan metodları projenize dahil etmemiş olursunuz.

Dependency Inversion (Bağımlılıkların azaltılması):
Bağımlılıklar, concreate sınıflardan yapılmak yerine mümkün olduğunca soyut sınıflar ve arayüzler üzerinden gerçekleştirilmelidir.

Share Button

About İbrahim Gündüz

1983 yılında İstanbul’da doğdu. İlkokul yıllarında cobol ve basic le olan tanışması, yazılıma olan ilgisini arttırdı 2005 yılında. Uludağ Üniversitesi Teknik Bilimler Meslek Yüksek Okulu Elektronik bölümünden mezun olan Gündüz, çeşitli alanlarda faaliyet gösteren kurumlarda yazılım geliştirici olarak görev almıştır. Mesleki ilgi alanları, ölçeklenebilir sistemler, uygulama entegrasyonları ve ödeme sistemleridir. Halen Markafoni back end geliştirici olarak çalışmaktadır.

Comments are closed.