Karmaşıklık ne zaman kaldırılmalıdır?

Tasarım kalıplarını ihtiyaç duyulmadan uygulayarak karmaşıklığı zamanından önce uygulamak iyi bir uygulama değildir.

Ancak, SOLID ilkelerinin tümünü (hatta çoğunu) uygularsanız ve ortak tasarım desenleri kullanırsanız, tasarımınızı gerektiği kadar bakım ve esnek tutmak için özellikler ve gereksinimler eklendikçe veya değiştirildikçe bazı karmaşıklıklar ortaya koyacaksınız.

Ancak bu karmaşıklık bir kez tanıtıldığında ve şampiyon gibi çalıştığında ne zaman çıkardınız?

Misal. Bir müşteri için yazılmış bir başvurum var. Başlangıçta orada yaratıldığında çalışanlara yükseltmek için çeşitli yollar. Tüm süreci güzel ve temiz tutmak için strateji modelini ve fabrikayı kullandım. Zaman içinde, uygulama sahibi tarafından eklenen veya kaldırılan belirli yükseltme yöntemleri.

Zaman geçiyor ve yeni sahip devralıyor. Bu yeni sahibi sert burunlu, her şeyi basit tutar ve zam vermek için tek bir yolu vardır.

Strateji modelinin ihtiyaç duyduğu karmaşıklığa artık gerek yoktur. Ben şimdi olduğu gibi gereksinimleri bu kodlamak nerede ben bu ekstra karmaşıklığı tanıtmak olmaz (ama ben gerek ortaya çıkarsa az veya hiç çalışma ile bunu tanıtmak emin olun).

Şimdi strateji uygulamasını kaldırabilir miyim? Bu yeni sahibin yükseltmelerin nasıl verildiğini hiç değiştirmeyeceğini sanmıyorum. Ancak uygulamanın kendisi bunun olabileceğini gösterdi.

Elbette bu, yeni bir sahibin devraldığı ve birçok işlemi basitleştirdiği bir uygulamada sadece bir örnektir. Onlarca sınıfı, arabirimi ve fabrikayı kaldırabilir ve tüm uygulamayı çok daha basit hale getirebilirim. Mevcut uygulamanın gayet iyi çalıştığını ve sahibinin memnun olduğunu unutmayın (ve tartışılan karmaşıklık nedeniyle değişikliklerini çok hızlı bir şekilde uygulayabildiğim için şaşırdım ve daha mutlu oldum).

Bu şüphenin küçük bir kısmının, yeni sahibin beni artık kullanmayacağı büyük olasılıkla olduğunu itiraf ediyorum. Büyük bir gelir üreticisi olmadığı için başkasının bunu devralacağı umrumda değil.

Ama 2 (ilgili) şeyi önemsiyorum

1. Yeni bakıcı kodu anlamaya çalışırken biraz daha zor düşünmek zorunda kalacak biraz umurumda. Karmaşıklık karmaşıklıktır ve benden sonra gelen psikolojik manyayı kızdırmak istemiyorum.

2. Ama daha da fazlası, bir yarışmacının bu karmaşıklığı görmesinden ve saatlerimi işlere aktarmak için tasarım kalıpları uyguladığımı düşünmekten endişeleniyorum. Sonra diğer işime zarar vermek için bu söylenti yayıldı. (Bu sözü duydum.)

Yani...

Genel olarak daha önce ihtiyaç duyulan karmaşıklık işe yarıyor olsa da kaldırılmalı ve karmaşıklığa tarihsel olarak gösterilmiş bir ihtiyaç var, ancak gelecekte gerekli olacağına dair bir işaretiniz yok mu?

Yukarıdaki soru genel olarak "hayır" şeklinde yanıtlansa bile, projeyi bir rakibe (veya yabancıya) teslim ediyorsanız bu "ihtiyaç duyulmayan" karmaşıklığı ortadan kaldırmak akıllıca olur mu?

Bazı açılardan, bunun büyük ölçüde bir iş kararı olduğunu ve kodun kendisine dayanması gerekmediğini düşünüyorum. Dikkate alınması gereken bazı noktalar:

• Değişiklikleri yapmak için para alıyor musunuz?
• Kod şu anda beklendiği gibi çalışıyor mu?
• Kodda olduğu gibi güvenlik veya performans sorunları var mı?
• Teknik borç miktarı, sabitleme maliyetinden daha ağır mı?
• Kodu olduğu gibi bırakırsanız gerçekçi olarak ne olur?
• Yeniden düzenleme ile veya yeniden düzenleme olmadan ortaya çıkabilecek gelecekteki sorunlar nelerdir?
• Kod sizin ve işletmeniz için ne kadar sorumluluk içeriyor?

Bu soruları cevaplamak için en iyi pozisyondasın. Ancak, açıklamanıza dayanarak, zamanınıza değecek gibi gelmediği için işleri yeniden düzenlemeyi ve basitleştirmeyi rahatsız edip etmeyeceğimi bilmiyorum. Şu anda çalışıyorsa, müşteri mutludur ve her şeyi güncellemek için ödeme almak istemezsiniz, o zaman bırakın ve gelir getiren bir etkinlik üzerinde çalışın.

Kısacası, her iki yol için bir maliyet-fayda analizi ve risk değerlendirmesi yapın ve en güvenli, en verimli ve en karlı eylem yolunu izleyin.

Bu kodu kaldırmak ve müşterinin dikkate alması ve ödemesi gereken bir özelliği kodlamanın ilerideki kolaylığı için basit bir şeyle değiştirmek değil mi?

Başka bir geliştiricinin öğrenebileceği faydalı bir şeye sahip olabilirsiniz, ancak başka bir müşterinin uygulamasını takmak için bulma olasılığının olası olmaması muhtemeldir.

Rakip kodunu dedikodu yapmak, önleyebileceğiniz bir şey değildir. Müşterileri olumsuz işe almaya çalışırken aptalca görünecekler.

Yaygın bir deyiş: "Eğer kırılmazsa, tamir etmeyin".

Bu kuralın arkasında birkaç gerekçe vardır. Bunlardan bazıları, "sadeleştirmenin" yeni, farklı ve muhtemelen daha büyük hatalar getirme riski taşıyacağı, diğer daha değerli çabalardan uzayan bir geliştirme süresi alabileceği ve gelecekteki beklenmedik iş fırsatları için tamamen yanlış bir değişiklik olabileceği olabilir. doğar.

Bu kodun taşınabilir ve daha sürdürülebilir olması için yeterli işletme değeri varsa, o değerin geçerli kodu "kırık" olarak değerlendirmek için gerçekten yeterli olup olmadığına karar verin. Planlanmış büyük bir iş genişlemesi varsa veya işi düşürebilecek karmaşıklıkta gizlenmiş gizli bir hatadan şüpheleniyorsanız iyi olabilir.

Her şeyden önce, uygulama zaten bir kez yeni bir sahip tarafından devralındıysa, tekrar olabilir. Ve bir sonraki sahibi, şu anda yararlanmayan bu karmaşıklığı tekrar kullanmaya başlayabilir.

Bunun dışında, çalışma kodundaki önemsiz değişiklikler her zaman bir risk doğurur, bu nedenle (diğerlerinin belirttiği gibi) müşteri onlarla aynı fikirde olmalıdır (ve bunun için ödeme yapmalıdır). Mevcut "ekstra" karmaşıklık, gözle görülür, ölçülebilir bir dezavantaja (performans sorunları gibi) neden olmazsa, kaldırmak için güçlü bir neden yoktur.

Sadece rakiplerin söylentilerine dayanarak sizi işe almayan (potansiyel) müşteriler, umutsuz bir gelire ihtiyaç duymadığınız sürece IMHO'ya sahip olmaya değmez. Uygulamayı yaptığınız gibi uygulamanızın iyi ve mantıklı nedenleri var ve herhangi bir ciddi müşterinin bunu anlaması muhtemeldir. Sana sormakla bile uğraşmayan ya da sormak bile istemeyen biri, işte zaten değerinden daha fazla sorun yaratacaktır.

Genel olarak daha önce ihtiyaç duyulan karmaşıklık işe yarıyor olsa da kaldırılmalı ve karmaşıklığa tarihsel olarak gösterilmiş bir ihtiyaç var, ancak gelecekte gerekli olacağına dair bir işaretiniz yok mu?

Hayır.

Yukarıdaki soru genel olarak "hayır" şeklinde yanıtlansa bile, projeyi bir rakibe (veya yabancıya) teslim ediyorsanız, bu "gereksiz" karmaşıklığı ortadan kaldırmak akıllıca olur

Hayır. Düşük önceliği düzeltmek için neden zamanınızı boşa harcıyorsunuz? Orada kalan kod hiçbir zararı.

Sorunuza gelince: Karmaşıklık ne zaman kaldırılmalıdır?

Benim almam, eğer kırılmazsa, tamir etme .

Karmaşıklığı giderebilmek için aşağıdakiler doğru olmalıdır:

1. Çıkarılan parça programdan bağımsız olmalıdır. Çevredeki programdan söz konusu koda herhangi bir bağımlılık varsa, sadece karmaşıklığı kaldırmak işe yaramaz
2. Ne yazık ki, karmaşıklık gibi görünüyorsa, parçaların bağımsız olmaması ve bağımlılıkları parçayı kaldırdığınızda programınızı kıracak olması muhtemeldir.
3. Tüm bağımlılıkların kaldırılması zaman alacaktır, böylece işlemin çabaya değip değmeyeceğini tahmin ederken zaman dikkate alınmalıdır.
4. Çoğu zaman çabaya değmez, ancak eski kodu kullanmak için yeni bir kod oluşturmamaya karar vereceksiniz

Burada işyerinde daha büyük bir şey olduğunu düşünüyorum ... Ölçeklenebilirlik

Sözünü ettiğin şey Ölçeklenebilirlik . Kodlamanın karmaşık olup olmadığı önemli değildir, uygulamanın yeni iş kurallarına veya değişen iş kurallarına göre gelişip gelişmeyeceği önemlidir. Bir sonraki sahip tamamen farklı bir şey isterse ne olur.

Yani, kodu tut ve belgeyi diyorum. Uygulamanın nasıl kullanılabileceğinin bir özelliği.

Genel olarak daha önce ihtiyaç duyulan karmaşıklık işe yarıyor olsa da kaldırılmalı ve karmaşıklığa tarihsel olarak gösterilmiş bir ihtiyaç var, ancak gelecekte gerekli olacağına dair bir işaretiniz yok mu?

Karmaşıklığı ortadan kaldırmak için bir çaba ve risk var. Bu, ek çabadan ve aşırı karmaşık kodu koruma riskinden daha yüksekse, o zaman saklarsınız. Aksi takdirde, kaldırırsınız. Ancak bu riskleri tahmin etmek zor.

Tasarım deseni Stratejisini neden ilk etapta kodda kullandığınızı belgeleyerek daha zor bakım riskini azaltabileceğinizi de ekleyeceğim . Ben şahsen herhangi bir tasarım modelinin açık bir gereklilikle (işlevsel veya işlevsel olmayan) izlenebilir olması gerektiğine inanıyorum.

Yukarıdaki soru genel olarak "hayır" şeklinde yanıtlansa bile, projeyi bir rakibe (veya yabancıya) teslim ediyorsanız bu "ihtiyaç duyulmayan" karmaşıklığı ortadan kaldırmak akıllıca olur mu?

Doldurma saatlerinde rekabet nedeniyle dağılma senaryo tam olarak karmaşıklığı belgelemenizin sebebidir. Herhangi bir kalıbın kullanımını belgelendirir ve haklı çıkarırsanız (belirli bir müşteri gereksinimi ile), kapsam dahilinde olursunuz. Bir deseni müşterinin gereksinimiyle haklı çıkaramazsanız, aşırı tasarım veya patternit gibi görünür.

Gereksinimler değişirse, kodu (veya kalıbı cerrahi olarak çıkarmak için gereken iş miktarını) kırma riski nedeniyle bırakmayı haklı çıkarabilirsiniz.

Bence kazara karmaşıklık ve temel karmaşıklık arasında ayrım yapmak iyidir , çünkü kalıplar genellikle her ikisini de içerir.

Yani, yükseltmelere karar vermek için değişen algoritmaları destekleme gereksiniminiz temel bir karmaşıklıktır (sorunun çözülecek kısmı). Bakım Kodunuzun Strateji deseni ile daha kolay yapılabilir, ancak eğer / ise alternatif Stratejisi olacak hala iş için kodlanmış. Yüksek lisans derslerimde öğrencilerin açık kaynaklı projelerde Strateji uygulama fırsatları buldukları egzersizler yaptım. Strateji uygulanırken karmaşıklık mutlaka daha iyi / kötü değildir (çünkü temel karmaşıklıktır). Bazen Stratejiyi anlamak daha da zor olabilir, çünkü kod büyük bir if / then / else bloğundan ziyade polimorfizm ile birden fazla sınıfa ayrılır.

İdeal olarak, bir desen sağladığı faydalar dezavantajlarının maliyetinden daha ağır bastığında çalışır. Yine, bunları ölçmek zordur. Çoğunlukla bir desen geliştiriciyi mutlu eder (sadece yeni bir yükseltme stratejisi eklemeyi kolaylaştırmakla kalmaz, aynı zamanda bir desenin uygulandığını bilmek için geliştiriciye sıcak tüyler verir). Müşterilere onlara nasıl fayda sağladığını göstermek zor.

Müşteri ayrıntıları umursamıyor, hatta anlamıyor. Yeni sahibinin süreçlerinde KISS uygulaması durumunda , yazılım çözümü üzerinde de etkisi olması gereken temel karmaşıklığı azaltmasıdır .