Hangi tasarımlar uygun tasarımla kolaylaştırılamayacak kadar büyük?

Bu oldukça belirsiz bir sorudur, ancak uygun tasarım hakkında okurken hiç tatmin edici bir şekilde cevaplanmadığını hissettiğim bir şeydir.

Genellikle, Nesne Odaklı programlama, soyutlama, çarpanlara ayırma, vb., Tasarımın kutsal kâsesi - ve her zaman söz konusu geliştirme tekniklerini kullandığınızı iddia etmelerinin nedeni - programınızı "değiştirmeyi kolaylaştıracaktır" , "sürdürülebilir", "esnek" veya bu tür üretken bir sondaj kavramını ifade etmek için kullanılan eş anlamlılardan herhangi biri. Ivars'ı özel olarak işaretleyerek, kodu birçok küçük, kendi kendine yeten yönteme bölerek, arayüzleri genel tutarak, programınızı toplam kolaylık ve zarafetle değiştirme yeteneğine sahip olursunuz.

Nispeten küçük değişiklikler için, bu benim için iyi çalıştı. Bir sınıf tarafından performansı artırmak için kullanılan dahili veri yapılarında yapılan değişiklikler hiçbir zaman büyük bir zorluk olmamıştır ve bir metin giriş sisteminin yeniden tasarlanması veya bir oyun öğesi için grafiklerin elden geçirilmesi gibi API'dan bağımsız olarak kullanıcı arayüzü ucunda da değişiklikler yapılmamıştır. .

Tüm bu değişiklikler doğal olarak bağımsızdır. Bunların hiçbiri, programınızın değiştirildiği bileşenin davranışında veya tasarımında, ilgili kod dışında herhangi bir değişiklik içermez. İster yordamsal olarak, ister OO tarzında, ister büyük işlevlerle ister küçük olsun yazsın, yazmayın, sadece orta derecede iyi bir tasarıma sahip olsanız bile bunlar kolayca yapılabilir.

Bununla birlikte, değişiklikler ne zaman büyük ve kıllı hale gelirse - yani API'daki değişiklikler - değerli "kalıplarım" hiçbiri kurtarmaya gelmez. Büyük değişiklik büyük olmaya devam ediyor, etkilenen kod etkilenmeye devam ediyor ve saatler süren böcek yumurtlama çalışmaları önümde duruyor.

İşte benim sorum bu. Uygun tasarım ne kadar büyük bir değişikliğin kolaylaşabileceğini iddia ediyor? Benim için bilinmeyen veya uygulayamadığım, yapışkan sondaj modifikasyonunu gerçekten basitleştiren başka bir tasarım tekniği var mı veya bu söz (bu kadar çok farklı paradigma tarafından yapıldığını duydum) sadece güzel bir fikir mi, yazılım geliştirmenin değişmez gerçekleriyle tamamen bağlantısız mı? Alet kemerine ekleyebileceğim bir "değiştirme aracı" var mı?

Özellikle, beni forumlara yönlendiren karşılaştığım sorun şudur: Yorumlanmış bir programlama dili (D'de uygulandı, ancak bu ilgili değil) uygulamak için çalışıyorum ve kapanışlarımın argümanlarının olması gerektiğine karar verdim. anahtar kelime tabanlı, şu anda oldukları gibi değil. Bu, anonim işlevleri çağıran tüm kodların değiştirilmesini gerektirir, ki bu da, neyse ki, dilimin gelişiminde erken (<2000 satır) olduğum için, ancak bu kararı daha sonraki bir aşamada yapmış olsaydım çok büyük olurdu. Böyle bir durumda, tasarımdaki uygun öngörü ile bu modifikasyonu kolaylaştırabileceğim veya belirli (çoğu) değişikliklerin içsel olarak geniş kapsamlı olabileceği herhangi bir yolu var mı? Bunun kendi tasarım becerilerimin başarısızlığı olup olmadığını merak ediyorum - eğer öyleyse, '

Açık olmak gerekirse, hiçbir şekilde OOP veya yaygın olarak kullanılan diğer kalıplardan hiç şüpheci değilim. Ancak benim için onların erdemleri kod tabanlarının sürdürülmesinden ziyade orijinal yazısındadır. Kalıtım, tekrar eden kalıpları iyi bir şekilde soyutlamanıza izin verir, polimorfizm, kodu makine tarafından anlaşılan etki ( switchifadenin hangi dalı) yerine insan tarafından anlaşılan işlev (hangi sınıf) ile ayırmanıza olanak tanır ve küçük, bağımsız işlevler, çok hoş bir "aşağıdan yukarıya" tarzında yazın. Ancak esneklik iddialarından şüpheliyim.

Bazen bir değişiklik, bir geçiş yolu tasarlamanız gereken kadar büyüktür. Başlangıç ​​ve bitiş noktaları iyi tasarlanmış olsa bile, genellikle sadece soğuk hindiyi değiştiremezsiniz. Aksi halde pek çok iyi tasarımcı iyi göç yolları tasarlayamamaktadır.

Bu yüzden her programcının 7/24 üretim ortamları için bir yazma yazılımı yapması gerektiğini düşünüyorum. Kayıplarla ilgili olarak, dakika başına yıllık maaşınızın sırasına göre, sağlam geçiş kodu yazmayı öğrenmeye motive eden bir şeyler vardır.

İnsanların büyük bir değişiklik için doğal olarak yaptıkları eski yolu sökmek, yeni şekilde koymak, sonra kodunuzu tekrar derleyene kadar bazilyon derleme hatalarını düzeltmek için birkaç gün geçirin, böylece teste başlayabilirsiniz. Kod iki gün boyunca test edilemez olduğundan, aniden sıralamak için büyük bir dolaşmış hata karmaşası yaşarsınız.

Konumsal bağımsız değişkenlerden anahtar kelimeye geçiş gibi büyük bir tasarım değişikliği için, iyi bir geçiş yolu, konumsal desteği kaldırmadan önce anahtar kelime bağımsız değişkenleri için destek eklemek olacaktır . Ardından, arama kodunu anahtar sözcük bağımsız değişkenlerini kullanacak şekilde düzenli olarak değiştirirsiniz. Bu, daha önce yaptığınız şeye benzer, ancak bu süre ilerledikçe test edebilirsiniz, çünkü değişmeyen arama kodu hala çalışır. Testler arasındaki değişiklikleriniz daha küçük olduğundan, hataların daha önce düzeltilmesi daha kolaydır. Ardından, tüm arama kodu değiştirildiğinde, konumsal desteği kaldırmak önemsizdir.

Bu nedenle, herkese açık olarak yayınlanan API'ler, eski hindi yöntemlerini kaldırmak yerine eski yöntemleri kullanımdan kaldırmaktadır. Arama kodu için kesintisiz bir geçiş yolu sağlar. Her ikisini de bir süreliğine desteklemek daha fazla iş gibi gelebilir, ancak testte zaman ayırıyorsunuz.

Sorunuzu başlangıçta ifade edildiği gibi cevaplamak için, uygun tasarımla daha kolay hale getirilemeyecek kadar büyük değişiklikler neredeyse yok. Değişikliğiniz çok büyük görünüyorsa, kodunuzun taşınması için bazı geçici ara aşamalar tasarlamanız yeterlidir.

Big Ball of Mud makalesini okumanızı tavsiye ederim .

Temel olarak tasarımın, geliştirme ile ilerledikçe bozulma eğilimi gösterdiği ve işi karmaşıklığı içermeye adamanız gerekir. Karmaşıklığın kendisi ortadan kaldırılamaz, sadece içerilebilir, çünkü çözmeye çalıştığınız sorunun doğasında var.

Bu, çevik gelişimin ana ilkelerine yol açar. En alakalı olan iki "henüz ihtiyacınız olmayacak özellikler için tasarım hazırlamamanızı söyleyen" buna ihtiyacınız olmayacak "dır. kodun proje boyunca akıl sağlığının korunması.

Yanıt, hiçbir tasarımın, tasarımın gerçekte olduğundan daha güçlü olduğunu göstermek için özel olarak tasarlanmış, örneklerin ötesinde herhangi bir değişikliği kolaylaştıramayacağı gibi görünüyor.

Bir yan notta nesne yönelimli programlama konusunda şüpheci olmalısınız . Birçok bağlamda harika bir araçtır, ancak sınırlarının farkında olmanız gerekir. Özellikle mirasın yanlış kullanımı inanılmaz derecede kıvrımlı bir koda yol açabilir. Tabii ki diğer tasarım teknikleri konusunda da eşit derecede şüpheci olmalısınız. Her birinin kullandığı ve her birinin zayıf noktaları vardır. Gümüş mermi yok.

Genel olarak, "kod parçaları" (fonksiyonlar, yöntemler, nesneler, her neyse) ve "kod parçaları arasındaki arayüzler" (API'ler, fonksiyon bildirimleri, her neyse; davranış dahil) vardır.

Bir kod parçası, diğer kod parçalarının bağlı olduğu arayüzü değiştirmeden değiştirilebilirse, değişiklik daha kolay olacaktır (ve OOP kullanıp kullanmadığınız önemli değildir).

Bir kod parçası, diğer kod parçalarının bağlı olduğu arayüzü değiştirmeden değiştirilemezse, değişiklik daha zor olacaktır (ve OOP kullanıp kullanmadığınız önemli değildir).

OOP'un temel faydaları, genel "arayüzlerin" açıkça işaretlenmesidir (örn. Bir nesnenin genel yöntemleri) ve diğer kod dahili arayüzleri (örneğin nesnenin özel yöntemleri) kullanamaz. Kamusal arayüzler açıkça işaretlendiğinden, insanlar bu kamusal arayüzleri tasarlarken daha dikkatli olma eğilimindedirler (bu da daha zor değişikliklerden kaçınmaya yardımcı olur). Dahili arabirimler başka bir kod tarafından kullanılamadığından, başka bir kod hakkında endişelenmeden bunları değiştirebilirsiniz.

Sizi büyük bir gereksinim / kapsam değişikliğinin zorluklarından kurtarabilecek bir tasarım yöntemi yoktur. Daha sonraki bir tarihte düşünülebilecek tüm olası değişiklikleri hayal etmek ve açıklamak mümkün değildir.

İyi bir tasarım nerede yapar sen yardımcı olan yardım, önerilen değişikliğinden nasıl etkileneceği tüm parçaların birbirine uygun ve anlamak.
Ayrıca, iyi bir tasarım önerilen değişikliklerin çoğundan etkilenen parçaları sınırlandırabilir.

Kısacası, tüm değişiklikler iyi bir tasarımla daha kolay yapılır, ancak iyi tasarım büyük bir değişikliği küçük bir dönüşüme dönüştüremez. (Öte yandan, kötü bir tasarım / hiçbir tasarım küçük bir değişikliği büyük bir dönüşüme dönüştürebilir.)

Tasarım sıfır boş sayfa sıfırdan çalışan güvenilir bir nihai ürüne (en azından bir tane için tasarım) bir geliştirme projesi almayı amaçladığından ve bu bir projede olabilecek en büyük değişiklik olduğundan, böyle bir şey olduğundan şüphe ediyorum. ele alınamayacak kadar büyük bir değişiklik.

Eğer bir şey varsa bunun tersi olur. Bazı değişiklikler herhangi bir "tasarım" ya da süslü düşünmeyle uğraşmak için çok küçük. Örneğin basit hata düzeltmeleri.

Tasarım modellerinin, çok sayıda küçük özdeş tipte nesne oluşturmak gibi yaygın durumlara açık bir şekilde düşünmesine ve iyi tasarım çözümleri bulmasına yardımcı olduğunu unutmayın. Hiçbir desen listesi tam değildir. Siz ve geri kalanımız, ortak olmayan, herhangi bir güvercin deliğine uymayacak tasarım problemlerine sahip olacaksınız. Yazılım geliştirme sürecindeki her küçük hareketi bir resmi kalıba veya diğerine göre yapmaya çalışmak, işleri yapmak için aşırı dini bir yoldur ve sürdürülemez karışıklıklara yol açar.

Yazılımdaki tüm çalışmalar doğal olarak böcek yumurtlamadır. Futbolcular sakatlanır. Müzisyenler enstrümanlarına bağlı olarak nasır veya dudak spazmı alırlar. (Gitar çalarken dudak spazmı alırsanız, yanlış yapıyorsunuz.) Yazılım geliştiricileri hata alıyor. Yumurtlama oranlarını azaltmanın yollarını bulmayı seviyoruz, ancak asla sıfır olmayacak.

Süpürme değişikliklerinin maliyeti genellikle kod tabanının boyutuyla orantılıdır. Bu nedenle, kod tabanının boyutunun küçültülmesi her zaman uygun tasarımın amaçlarından biri olmalıdır.

Örneğin, uygun tasarım işinizi zaten kolaylaştırdı: 20000 veya 200000 satır kod tabanı yerine 2000 satır kod tabanı boyunca değişiklik yapmak zorunda.

Uygun tasarım, süpürme değişikliklerini azaltır, ancak bunları ortadan kaldırmaz.

Dil analizi araçlarından uygun destek alındığında, tarama değişiklikleri kolayca otomatikleştirilebilir. Tüm kod tabanına arama ve değiştirme stilinde bir battaniye yeniden düzenleme değişikliği uygulanabilir (dil kurallarına uygun şekilde uyulurken). Programcının her arama isabeti için sadece bir evet / hayır kararı vermesi gerekir.