Kötü tasarım kriterleri
Hayat oldukça basit çalışır: akıllı olmak için genellikle aptalca şeyler yapmamanız gerekir. Bu aynı zamanda yazılım geliştirme için de geçerlidir: çoğu durumda, bir şeyi iyi yapmak için, onu kötü yapmamanız yeterlidir.
Çoğu programcı, sistemin kötü tasarlanmış parçalarıyla ilgili deneyime sahiptir. Ama daha da üzücü olanı, çoğunuz böyle bir sistemin yazarları olduğunuzu fark etmenin üzücü deneyimini yaşayacaksınız. En iyisini istedik ama her zamanki gibi oldu.
Geliştiricilerin çoğu kötü mimariyi arzulamaz ve birçok sistem için öyle bir nokta gelir ki mimarisinin berbat olduğunu söylemeye başlarlar. Bu neden oluyor? Mimari tasarım baştan beri kötü müydü, yoksa zamanla mı kötüleşti?
Bu sorunun kökü, “kötü” tasarımın tanımının olmamasıdır.
Bana öyle geliyor ki, herhangi bir programcı için en önemli nitelikler, tasarım kalitesinin anlaşılması ve "çürüme" nedenleridir. Diğer birçok durumda olduğu gibi, asıl mesele sorunu belirlemek ve onu çözmek bir teknoloji meselesi olacaktır.
“Kötü tasarım” tanımı
Bir programcı arkadaşınızın önünde kodunuzla övünmeye karar verirseniz, büyük olasılıkla "Bunu kim yapıyor?", "Neden böyle?" ve "Her şeyi farklı yapardım." Bu çok sık olur.
Tüm insanlar farklıdır, ancak yine de kodu programcı arkadaşlarınız için yazıyorsunuz, bu nedenle her bir özelliği geliştirme sürecinde, diğer insanlar kodunuza baktığında her zaman bir gözden geçirme aşamasına ihtiyacınız var.
Ancak pek çok şey farklı şekillerde yapılabilse bile, tüm geliştiricilerin üzerinde hemfikir olacağı bir dizi kriter vardır. Gereksinimlerini karşılayan ancak yine de bir (veya daha fazla) özellik sergileyen herhangi bir kod parçası kötü tasarımdır.
Kötü Tasarım:
- Değiştirmek zordur çünkü herhangi bir değişiklik sistemin diğer birçok parçasını etkiler. ( Sertlik , Sertlik).
- Değişiklik yapıldığında sistemin diğer parçaları beklenmedik bir şekilde bozuluyor. ( Kırılganlık , Kırılganlık).
- Geçerli uygulamadan çıkarmak çok zor olduğu için kodu başka bir uygulamada yeniden kullanmak zordur. ( Hareketsizlik , Hareketsizlik).
Ve komik olan şu ki, bu özelliklerin hiçbirini içermeyen (yani esnek, güvenilir ve tekrar kullanılabilir), gereksinimi karşılayan ve aynı zamanda tasarımı kötü olan bir sistem parçası bulmak neredeyse imkansız. .
Böylece, bir tasarımın “kötü” mü yoksa “iyi” mi olduğunu kesin olarak belirlemek için bu üç özelliği kullanabiliriz.
"Kötü Tasarım"ın Nedenleri
Bir tasarımı sert, kırılgan ve taşınmaz yapan nedir? Modüllerin katı karşılıklı bağımlılığı.
Kolayca değiştirilemeyen bir tasarım katıdır . Bu katılık, dokuma bir sistemdeki bir kod parçasındaki tek bir değişikliğin bağımlı modüllerde basamaklı değişikliklere yol açmasından kaynaklanmaktadır. Bu her zaman bir kişi kod üzerinde çalışırken olur.
Bu, tüm ticari geliştirme sürecini anında karmaşıklaştırır: Art arda gelen değişikliklerin sayısı tasarımcı veya geliştirici tarafından tahmin edilemediğinde, böyle bir değişikliğin etkisini tahmin etmek imkansızdır. Bu nedenle, bu tür değişiklikleri süresiz olarak ertelemeye çalışırlar.
Bu da değişimin maliyetini öngörülemez hale getiriyor. Bu tür bir belirsizlikle karşı karşıya kalan yöneticiler değişiklik yapma konusunda isteksizdir, bu nedenle tasarım resmen katılaşır.
Bir noktada projeniz “olay ufkunu” geçer ve katı mimarinin “kara deliğine” düşmeye mahkumdur.
Kırılganlık , bir sistemin tek bir değişiklikten sonra birden çok yerde bozulma eğilimidir. Genellikle kavramsal olarak değişim yeri ile ilgisi olmayan yerlerde yeni sorunlar ortaya çıkar. Bu tür bir kırılganlık, sistemin tasarımına ve bakımına olan güveni ciddi şekilde baltalamaktadır.
Bu genellikle özel yöntemlerin olmadığı durumlarda geçerliydi. Tüm yöntemleri herkese açık hale getirmek yeterlidir ve kırılgan bir mimari görünümüne mahkum olacaksınız. Kapsülleme, bununla mikro düzeyde başa çıkmaya yardımcı olur. Ancak makro düzeyde modüler bir mimariye ihtiyacınız var.
Bir proje kırılgan bir mimariye sahip olduğunda, geliştiriciler ürünün kalitesini garanti edemez.
Uygulamanın bir bölümündeki basit değişiklikler, ilgisiz diğer bölümlerde hatalara yol açar. Bu hataların düzeltilmesi daha da büyük sorunlara yol açar ve eskort süreci kendi kuyruğunu kovalayan ünlü bir köpeğe dönüşür.
Sistemin gerekli parçaları diğer istenmeyen detaylara güçlü bir şekilde bağlı olduğunda tasarım hareketsizdir . Çok fazla kendi kodları, kendi benzersiz yaklaşımları ve çözümleri.
Geliştiricileri sebepsiz yere kendi günlük kaydı seviyelerini bulan JUL günlükçüsünü hatırlıyor musunuz? Durum bu.
Bir tasarımcıya mevcut bir tasarımı yeniden kullanmanın ne kadar kolay olduğu konusunda fikir vermesi için, yeni bir uygulamada kullanımının ne kadar kolay olacağını düşünmesi yeterlidir.
Tasarım birbirine sıkı sıkıya bağlıysa, sistemin gerekli parçalarını gereksiz ayrıntılardan ayırmak için gereken iş miktarı bu tasarımcıyı dehşete düşürür. Çoğu durumda, böyle bir tasarım yeniden kullanılamaz, çünkü onu ayırmanın maliyeti onu sıfırdan geliştirmenin maliyetinden daha ağır basar.
alaka
Her şey değişir ama her şey aynı kalır. (Çin atasözü)
Yukarıda çok güzel sorular sorulmuş. Kırılgan ve katı sistemlerin tehlikeleri nelerdir? Evet, çünkü böyle bir projeyi yönetme süreci öngörülemez ve kontrol edilemez hale gelir. Ve fiyat fahiş.
Bir yönetici, gerçekte ne kadar zaman alacağını bilmiyorsa, bazı özellikleri eklemek için nasıl onay verebilir veya veremez? Uygulamalarının zamanını ve karmaşıklığını yeterince tahmin edemiyorsanız, görevlere nasıl öncelik verilir?
Ve geliştiriciler aynı teknik borcu ödeyeceğimiz zaman nasıl ödeyebilirler ve komisyon alana kadar ne kadar komisyon yapacağımızı anlayamayız?
Kodun yeniden kullanımı veya test edilmesiyle ilgili sorunlar da çok önemlidir. Birim testleri, yalnızca test edilen birim hakkındaki bazı varsayımları test etmeye değil, aynı zamanda uyum derecesini belirlemeye de hizmet eder ve yeniden kullanımın bir göstergesi olarak hizmet edebilir.
İşte bu durum için Bob Martin'den bir alıntı: "Kodunuzu yeniden kullanmak için, sıfırdan geliştirme maliyetinden daha az yeniden kullanma çabası göstermeniz gerekir . " Yoksa kimse bu konuyla uğraşmaz bile.
Tasarım ilkelerinin ve modellerinin kullanımı tek bir amaca hizmet eder - tasarımı iyi hale getirmek. Kullanımları size herhangi bir fayda sağlamıyorsa (veya tam tersi, “iyi tasarım” ilkelerini ihlal ediyorsa), o zaman konservatuarınızda bir şeyler yanlıştır ve belki de alet başka amaçlar için kullanılmaya başlanmıştır.