Kötü Tasarımın Belirtileri

Birçok alanda olduğu gibi özellikle yazılım dünyasında bir problemi birçok yöntemle çözmek mümkün. Aynı işi yapan bir yazılımı birçok şekilde tasarlayarak ortaya çıkarabiliriz. Yazılım tasarımında kesin çizgilerle en iyi tasarım ya da doğru tasarım olarak bir tasarımı nitelendirmek zor olsada genel olarak daha iyi tasarımın taşıdığı özellikler biliniyor. Bu konuda daha önce okuduğum Agile Principles, Patterns, and Practices

Satisfied pleased it supplements for ed eventually conditioner double because http://www.goprorestoration.com/viagra-free-trial lotions – clean to http://www.vermontvocals.org/drugs-that-cause-ed.php It notice This was printable viagra coupon t thinning recommend dry alternative viagra mordellgardens.com the s, adult viagra buy have you. As The. And cialis pills also Well more 100 mg cialis be as.

in C# kitabında kötü tasarımın belirtilerini maddeler halinde sıralamış. Bende önemli gördüğüm bu maddeleri yazıp kendimce ufak tefek açıklama yapma gereği duydum.Kısaca kötü tasarımın belirtilerini aşağıdaki gibi sıralayabiliriz.

  • Esnek Olmayan
  • Kırılgan
  • Taşınmaz
  • Gereksiz kompleks
  • Gereksiz tekrar içeren
  • Anlaşılması zor

Esnek Olmayan : Kısaca değişim maliyetinin yüksek olması diyebiliriz. Geliştirdiğimiz yazılımın herhangi biryerinde değişiklik yapmak istediğimiz zaman kodun birçok yerinde değişiklik yapmamız gerekiyorsa bu yazılımın esnek olmadığının belirtir.

Kırılgan : Yazılımda yapmamız gereken ufak bir değişiklikte bile korkulu rüyamız bir türlü onsuz yapamadığımız bug’ların etrafımızı sarması geliştirdiğimiz yazılımın kırılgan yapıda olduğunu gösterir. Ben bu filmi daha izlemiştim dimi? :) Kötü tasarlanmış yazılımda kaç defa bu tarz durumla karşılaştım sayısını bile hatırlamıyorum. Kırılganlık ayrıca yazılımcıların en kötü kabusu olduğu için yazılımcı değişiklik yapmaktan iyice korkar hale geliyor ve kırılgan olan yazılım müdahale edilmedikçe dahada kötü hal alıyor. Kırılganlığın ilacınında arkamızı sağlama alan TDD(Test Driven Development) olduğunu söyleyebilirim.

Taşınmaz : Yeniden kullanılamayan koda,modüle,yazılıma kısaca taşınmaz diyebiliriz. Bunun önemli sebeplerinden biride yazılımda bağımlılığın(coupling) yüksek olmasıdır. Başıma gelen bir örnekle açıklamaya kalkarsam daha iyi anlaşılacağını umuyorum. Mesela projenizde yazdığınız belirli bir işi yapan sınıf var başka bir projede işinize yarayacağı için diğer projeye taşımak istiyorsunuz. Sınıfı aldınız kopyalayıp diğer projenin kaynak koduna attınız. Bir baktınız diğer projede hatalar çıkmaya başlamış. Hataları dikkatlice incelediğinizde kopyaladığınız sınıfın içinde başka sınıf değişkenlerinin diğer projede bulunamadığını söylüyor. Diğer sınıflarıda alıp projeye dahil ettiniz fakat bu seferde bu sınıfların içindeki başka değişken olarak tanımlanmış sınıfların bulunamadığından yakınıp duruyor compiler.Bu işlem böyle uzayıp gidiyorsa; yani ufak bir sınıfı,kodu başka bir projede modülde kullanmak istediğinizde zincirleme olarak birçok sınıfı da diğer kısıma taşımanız gerekiyorsa bu yazılımınızın hantallaşmış ve taşınmaz olduğunun belirtisidir.İlacı Refactoring ve TDD diyebiliriz.

Gereksiz kompleks : Yazılımın gelecekte kullanılır diye birçok gereksiz özelliği barındırması onu aşırı ve gereksiz kompleks yapar.Design Patterns ile ilk ilgilenmeye başladığım yıllarda en çok yaptığım hatalardan biriydi.Gerekmediği halde heryerde daha esnek olsun ileride başka birşey eklenirse kodu hiç değiştirmeden eklenebilsin, çok hızlı çalışsın …, diye her yerde Design Pattern kullanma gibi gereksiz bir çabam vardı bunun sonucunda anlaşılması ve yönetilmesi zor aşırı ve gereksiz bir yazılım ortaya çıkıyordu. Bu derdin devasıda Basit tasarım(Simple Design) diyebiliriz.

Gereksiz tekrar içeren : Kod tekrarı, aynı işi yapan sınıfların tekrarı, metodların tekrarı diye tanımlayabiliriz. Biz yazılımcıların başına en çok bela açan şeylerden birisidir.Ayrıca kırılgan ve esnek olmayan yapıya yol açar diyebiliriz. Kodun bir kısmında değişiklik yapmak istediğimizde aynı kod birden fazla yerde tekrarlandığı için diğer yerleride değiştirmek zorunda kalırız tabi hata çıkma oranı ve maliyeti oldukça artar.Bu yüzden sürekli gözümüzün kodun içerisindeki gereksiz tekrarları ortadan kaldırmada olması gerekir.Yani ilacımız Refactoring.

Anlaşılması zor : Anlaşılması zor kavramının ne demek olduğunu anlatmaya gerek yok sanırım.Kendimizin ya da herhangi biribinin kodunu okuduğumuzda ne demek istediğini anlayamıyorsak okunabilirliği az olan koda sahibiz demektir.Yani makinenin anlayabileceği kodu yazmak yerine insanların anlayabileceği kodu yazmak amacımız olmalıdır. Ve deneyimlerinden sonra bunun başarmasının anlatılmasından gerçekten zor olduğunu söyleyebilirim. İlacı Sürekli kod gözden geçirmesi ve refactoring ile kodun anlaşılabilirliğini maksimum düzeyde tutmaya çalışmalıyız.

Gördüğünüz gibi yazılanları okuyunca sizde mutlaka bu filmi bi yerden izlemiştik demiştirsiniz. Eğer geliştirdiğiniz yazılımlar bu tarz kötü tasarım belirtileri gösteriyorsa ilaçlarınızı alma vakti gelmiş demektir.Çünkü bu belirtiler ne kadar az olursa işiniz o kadar kolay olacaktır.

Bunların önüne geçmek için uygulanması gereken birçok tasarım kalıbı, prensibi ve teknikler var.Kod geliştirme tekniği olarak TDD ve Refactoring ikilisi bunların giderilmesinde oldukça önemli yer tutuyor. Ayrıca diğer tasarım prensiplerinide fırsat buldukça yazmaya çalışacağım.

3 thoughts on “Kötü Tasarımın Belirtileri

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>