DRY, yazılım proje yönetiminin düşmanı mıdır?

Yazılım geliştirmenin en temel ve yaygın olarak kabul gören ilkelerinden biri DRY'dir (kendinizi tekrar etmeyin). Ayrıca çoğu yazılım projesinin bir çeşit yönetim gerektirdiği de açıktır.

Şimdi yönetmesi kolay görevler nelerdir (tahmin, zamanlama, kontrol)? Doğru, tekrarlayan işler, DRY'ye göre kaçınılması gereken görevler.

Bu nedenle proje yönetimi açısından, varolan bazı kodları 100 kez kopyalayarak bir görevi çözmek ve gerektiğinde her kopyaya küçük uyarlamalar yapmak harikadır. Her zaman tam olarak ne kadar iş yaptığınızı ve ne kadar iş kaldığını bilirsiniz. Tüm menajerler seni sevecek.

Bunun yerine, DRY ilkesini uygularsanız ve yinelenen kodu az çok ortadan kaldıran bir soyutlama bulmaya çalışırsanız, işler farklıdır. Genellikle birçok olasılık vardır, karar vermeniz, araştırma yapmanız, yaratıcı olmanız gerekir. Daha kısa sürede daha iyi bir çözüm bulabilir, ancak başarısız olabilirsiniz. Çoğu zaman, ne kadar iş kaldığını gerçekten söyleyemezsiniz. Sen proje yöneticisinin en kötü kabususun.

Tabii ki abartıyorum ama belli ki bir ikilem var. Sorumlarım şunlardır: Bir geliştiricinin DRY'yi abartıp geçirmediğine karar vermek için kriterler nelerdir? İyi bir uzlaşmayı nasıl bulabiliriz? Yoksa bu ikilemi tamamıyla aşmanın bir yolu var mı?

Bu soru benim önceki ile aynı fikre dayanmaktadır: Not yazılım geliştirme rutin çalışmalarının Miktarının ve tahmini üzerindeki etkisi , ama :) kendimi tekrar için benim açımdan daha net, çok üzgünüm yapar düşünüyorum.

Proje yönetiminin asıl amacının kesin tahminler üretmektir. Durum bu değil. Proje yönetiminin temel amacı, geliştiricilerle aynıdır: Ürün sahibine değer sunmak.

Otomasyon yerine çok yavaş manuel işlemler kullanan bir ürün teoride tahmin etmek daha kolay olabilir (bundan şüpheliyim olsa da), ancak müşteriye para için değer sağlamaz, bu yüzden sadece proje yönetimi kötüdür. İkilem yok.

Yazılım projelerinin tahmininin zor olduğu ve sayısız kitabın yazıldığı ve bunun yönetimi için çeşitli süreçlerin geliştirildiği iyi bilinmektedir.

Eğer sadece PM amacı tam tahminlerini üretmek oldu, o zaman kolay olurdu. Sadece tahminleri 10X'e getirin ve geliştiricilerin geri kalanı için erken bitirmeleri durumunda oyun oynamasına izin verin. Bu, zaman geçirmek için copy-paste busywork kullanmak için önerinizden daha iyi olurdu, çünkü oyun oynamak ürünün bakımını azaltamayacak.

Ancak gerçekte, ürün sahibi, yararlı tahminler ve mümkün olan en hızlı ve ucuz şekilde teslim edilen kaliteli bir ürün istiyor . Bunlar, bir PM'nin yönlendirmesi gereken gerçek kısıtlamalar.

Her durumda, tekrarlayan manuel çalışmanın otomatikleştirilenden daha öngörülebilir olduğu varsayımına itiraz ediyorum. Tüm deneyimler tekrarlayan el işlerinin hatalara daha yatkın olduğunu göstermektedir. Ya kopyalanan kodda bir hata bulunursa? Birdenbire bir hatayı tamir etmenin maliyeti, belirsizliğin patlamasını sağlayan tekrarlama miktarı ile çarpılır.

Haklısınız - kopyala-yapıştır harika çalışıyor ve DRY'nin görevinizin, kopyalanan şablonun veya kopyanın gelecekte muhafaza edilmesi veya geliştirilmesi gerekmeyeceği bir program üretmesi gerektiğinin bir anlamı yok. Bu iki yazılım bileşeni tamamen farklı bir yaşam döngüsüne sahip olduklarında, ortak kodu, ağır gelişme altında olan ortak bir kütüphaneye yeniden aktararak bir araya getirmek, gerçekten de çaba için öngörülemeyen etkilere neden olabilir. Öte yandan, bir program veya program sisteminin içindeki kod bölümlerini kopyalarken, tüm bu parçalar tipik olarak aynı yaşam döngüsüne sahip olacaktır. Bunun DRY ve proje yönetimi için ne anlama geldiğini aşağıda göstereceğim.

Cidden, orada birçok program var: örneğin, bilgisayar oyunu endüstrisi, birkaç ay veya bir yıl gibi kısa bir süre içerisinde maksimum bir süre boyunca sürdürülmesi gereken birçok program üretiyor ve bu süre sona erdiğinde, kopyala-yapıştır Bakım periyodunun aşıldığı eski bir oyundan eski bir kod, yeni bir oyunun kod tabanına mükemmel şekilde gayet iyi ve işleri hızlandırabilir.

Ne yazık ki, son yıllarda uğraşmam gereken çoğu programın yaşam döngüsü bundan çok farklı. Bana gelen gereksinimlerin veya hata düzeltme isteklerinin% 98'i değişiklik istekleriydimevcut programlar için. Var olan bir yazılımda bir şeyi ne zaman değiştirmeniz gerekiyorsa, "proje yönetimi" ya da planlama, test etme ve hata ayıklama çabalarınız oldukça düşük olduğunda en iyi şekilde çalışır; bu, bir yerde bir şeyi değiştirirseniz, ancak kopyalamaktan kaynaklanamaz. -pasted iş mantığı kolayca kod tabanında bir düzine başka yerlerde de değişiklik yapmanız gerektiğini unutur. Ve tüm bu yerleri bulmayı başarsanız bile, hepsini değiştirme zamanı (ve değişiklikleri test etme) muhtemelen değişecek tek bir yeriniz varmış gibi daha yüksektir. Böylece değişim için doğru bir tahmin bile yapabilirsiniz, maliyetlerin olması gerekenden düzin kat daha fazla olması proje bütçesine kolayca çarpışabilir.

TLDR - Orijinal belgenin veya kopyanın düzeltilmesi ve bakımı için bir zorunluluk veya sorumluluk bulunmayan bir program geliştirdiğinizde, kopyalamaktan çekinmeyin. Ancak siz, ekibiniz veya şirketiniz sorumluysa veya sorumlu olabilirseniz, ne zaman isterseniz DRY'yi uygulayın.

Örnek

Zeyilname olarak, "hata düzeltme ve bakım" ın ne anlama geldiğini ve bunun gerçek dünya örneği ile planlamada, özellikle tek bir ürünün içinde öngörülememenin nasıl olacağını açıklayayım. Gerçekten de bu tür şeylerin gerçekte gerçekleştiğini gördüm, muhtemelen 100 örnekle değil, ancak tek bir kopya örneğiniz olduğunda bile sorunlar başlayabilir.

Görev: bir uygulama için 100 farklı rapor oluşturmak, her rapor çok benzer görünüyor, raporlar arasında bazı gereklilik farkları, bazı farklı mantık, ama sonuçta pek fazla fark yok.

Bu görevi alan dev, birinciyi yaratır (3 gün sürdüğünü söyleyebilir), Kalite Güvencesi ve müşteri incelemesi nedeniyle yapılan bazı değişiklikler veya ufak tefek düzeltmeler bittikten sonra gayet iyi görünüyor. Sonra, her şeyi kopyalayıp yapıştırarak ve değiştirerek bir sonraki raporu oluşturmaya başladı, daha sonra bir sonraki ve her yeni rapor için ortalama olarak ~ 1 güne ihtiyacı var. Çok kestirilebilir, ilk bakışta ...

Şimdi, 100 rapor "hazır" olduktan sonra, program gerçek üretime gidiyor ve KG sırasında gözden kaçırılan bazı sorunlar ortaya çıkıyor. Belki performans sorunları var, belki raporlar düzenli olarak çöküyor, belki de başka şeyler amaçlandığı gibi çalışmıyor. Şimdi, DRY ilkesi uygulandığında, bu sorunların% 90'ı kod tabanını tek bir yerde değiştirerek çözülebilirdi. Ancak kopyala-yapıştır yaklaşımı nedeniyle, sorunun bir kez yerine 100 kez çözülmesi gerekiyor. Ve zaten bir rapordan diğerine uygulanmış olan değişiklikler nedeniyle, dev, ilk raporun düzeltmesini diğer 99'a hızlıca kopyalayamaz. 99 raporun tümüne bakmalı, bunları okumalı, değişikliği değiştirilmişe çevirmelidir. rapor et, test et ve her birini ayrı ayrı hata ayıkla. Başbakan için bu gerçekten zorlaşmaya başlar - elbette "normal" bir hata düzeltmesi için zaman alabilir (3 saat diyelim) ve bunu 100'le çarpabilir, ancak aslında, bu büyük olasılıkla yanlış bir tahmindir, düzeltmelerden bazıları olabilir. yapmak diğerlerinden daha kolay, diğerleri zor olabilir. Ve bu tahmin doğru olsa bile, hata ayıklamanın maliyeti olması gerektiği kadar 100 kat daha yüksek bir maliyete sahip olmak size çok pahalıya mal olacaktır.

Aynı şey, müşterinin, tüm raporlarda benzer şekilde şirket ambleminin rengini değiştirmesini, sayfa boyutunu yapılandırılabilir hale getirmesini veya tüm raporları benzer şekilde etkileyen başka bir yeni gereksinimle istemesi durumunda gerçekleşecektir. Dolayısıyla, bu gerçekleşirse, maliyetler hakkında bir tahmin yapabilir ve müşteriye kodun KURU olduğu zaman ödemek zorunda kalacağı fiyatın 100 katı fatura verebilir. Bununla birlikte, bunu birkaç kez deneyin, ardından müşteri projeyi iptal edecektir, çünkü fahiş gelişim maliyetlerinizi muhtemelen ödeyecektir. Ve belki de bu noktada birileri bunun neden olduğu sorusunu soracak ve bu kopyala-yapıştır programlaması için karar veren kişinin parmağını işaret edecektir.

Demek istediğim: başkaları için bir yazılım ürettiğinizde, her zaman en azından kısa bir süre için bir şeyin çalışmasını sağlamak, hataları düzeltmek, programı değişen gereksinimlere uyarlamak vb. Sorumluluğuna sahipsiniz. Yeşil alan projesinde bile, bunlar parçalar, başlangıçta planlanan geliştirme çabalarından çok daha fazlasını hızla toplayabilir. Özellikle de tüm kopyalanmış kodlarınız tek bir ürünün içinde olduğunda, sorumluluk süresi, tüm parçalar için aynıdır; bu, eski kodları artık olmayan ölü bir projeden kopyaladığınız durumdan oldukça farklıdır. aktif bakım altında.

Bu nedenle proje yönetimi açısından, varolan bazı kodları 100 kez kopyalayarak bir görevi çözmek ve gerektiğinde her kopyaya küçük uyarlamalar yapmak harikadır. Her zaman tam olarak ne kadar iş yaptığınızı ve ne kadar iş kaldığını bilirsiniz. Tüm menajerler seni sevecek.

Temel iddialarınız yanlış.

Yazılımı diğer mesleklerden farklı kılan şey, her gün yeni bir şey yaptığınızdır. Ne de olsa, başka hiçbirisinin yapmış olduğu bir şeyi inşa etmek için hiçbir müşteri size ödeme yapmayacak . Proje yöneticileri tahmin gibi ama belki onların gibi patronlar değeri . Sadece küçük değişkenlere sahip kopya yapıştırma kodunu kullanıyorsanız, şirket için çok fazla değer sağlamazsınız.

Sonunda şirket, aynı işi iyi bir programcı işe alarak zamanın bir kısmında yapabilirler. Ve eğer yapmazlarsa, rakipleri olacak.

Kes ve yapıştır programlama sonunda terk edilmiş yazılıma yol açar. Çok büyük bir telefon şirketinden kablolu servis siparişi vermek için sistem üzerinde müteahhitlik yaptım. Sistem yapıştırılmış ve yapıştırılmış bir reklam müzesiydi çünkü tüm testler manueldi ve çalışma kodlarını değiştirmek istemediler. En küçük geliştirme, yüzlerce kod satırının yeni bir kopyasına neden olabilir. Başlangıçta, uygulama on iki fiziksel satıra kadar olan hesapları ele almak için yazılmıştır. Elbette bu sınırlama koddaki yüzlerce yerde de yapıldı. Yaklaşık dört yıl sonra işletme ekibe daha büyük hesaplarla başa çıkmanın ne olacağını sordu. Yaklaşık 18 milyon dolar tahmin ettiler. Bu noktada proje, asgari bakım için offshore bir takıma devredildi. Mevcut takımın hepsi işten çıkarıldı.

Bu şekilde düşünen kuruluşlar daha iyi teknolojiye sahip şirketler tarafından eziliyor.

Burada geçerli olan ve unutulan bir maxim 3'ün kuralıdır . Bu, bir kez kod kopyalamanın uygun olduğunu ancak bunun ötesinde genel kodla değiştirilmesi gerektiğini belirtir.

3 isteğe bağlı bir sayı gibi görünebilir, ancak ortak bir senaryo bir uygulamada ve veritabanında veri ve mantığın çoğaltıldığı durumdur. Sıkça atıfta bulunulan bir örnek, veritabanında bir arama tablosu ve bir numaralandırma istemci tarafında olduğu yerdir. Paradigmalardaki fark, bunun tek bir yerde kolayca saklanmasına izin vermez ve bu nedenle bilgiler genellikle her iki yerde de görünür.

DRY koduna sahip olmak güzel olsa da, iş mantığının bir istisna belirttiği zamanlar olabilir ve bu nedenle daha önce jenerik olan kaynaktan iki veya daha fazla kod parçası oluşturmanız gerekir.

Yani - ne yapmalı? Statükonun kodu (sonuçta, YAGNI ). Değişiklik kolaylığı için kod yazılırken, ihtiyaç duyulmayacak bir şey için bir sürü çan ve ıslık yazmak sadece para kazanıyor.

Sorunuzda, proje yönetiminin sadece üç işlevini listeliyorsunuz - tahmin, çizelgeleme ve kontrol. Proje yönetimi, projenin kısıtları dahilinde hedeflere ulaşmak ile ilgilidir. Bir projenin sınırları dahilinde hedeflere ulaşmak için kullanılan yöntemler, yazılım projeleri için diğer birçok proje türünden farklıdır. Örneğin, üretim işlemlerinin yüksek oranda tekrarlanabilir ve iyi anlaşılmış olmasını istersiniz. Ancak, yazılım geliştirme çoğunlukla bilgi çalışmasıdır- rutin değildir ve katı talimat ve prosedürleri takip etmek yerine düşünmeyi gerektirir. Bir yazılım projesini başlatmak, planlamak, yürütmek, izlemek ve kontrol etmek ve kapatmak için kullanılan tekniklerin, bir yazılım projesinde yapılması gereken iş türünü, özellikle de yapılamayan rutin olmayan işleri hesaba katması gerekecektir. özel talimat ve prosedürlere.

Bence diğer problem, bilginin tekrarlanmasıyla ilgili bir kavram olan DRY'yi almanız ve bunları işleri yönetmek için uygulamaya çalışmaktır. DRY, yalnızca bilginin yalnızca bir yetkili temsiline sahip olmanız gerektiğini söyler. Proje yöneticileri bunu benimsemelidir, çünkü herkes bilgi için nereye gideceğini bilecektir, değişiklikleri iletmek kolay olacaktır ve değişiklikler iyi kontrol edilip yönetilebilir. DRY, yeniden kullanılabilir parçalar sayesinde, uzun vadeli maliyetleri düşük tutmaya, uzun vadeli programları sürdürmeye ve kaliteyi yükseltmeye yardımcı olur - Proje Yönetimi Üçgeni'ne üç parça . İşleri KURUŞTURMAK için etkili bir şekilde zaman ve para harcanması gerekiyor, ancak proje yöneticisinin görevi zaman, maliyet, program ve kalite dengesi yapmak.

Yeni kod yazmak, görevin yalnızca küçük bir kısmıdır

Öneriniz, başlangıçta yeni kod yazmanın bir parçasını tahmin etmenizi kolaylaştıracaktır. Bununla birlikte, gerçekte yeni bir şey getirmek için (yepyeni bir sistem, özellik veya işlev değişikliği de olsa) bunu yapmak yeterli değildir ve yalnızca azınlıkta bir çalışmadır - literatürde görülen tahminler pratikte şunu söylüyor: bölüm toplam çalışmanın% 20-40'ı kadar bir şeydir.

Bu nedenle, işin çoğunluğu (başlangıçtaki gelişmenizi gerçekten ihtiyaç duyulan şeye uyarlama, entegrasyon, test etme, yeniden yazma, yeniden test etme dahil) tahmin etmek kolaylaşmıyor; tam tersi bir şekilde, DRY'den kasten kaçınmak, o parçayı çok daha büyük, daha zor ve daha değişken tahminlerle yaptı - tüm klonlanan parçaların değiştirilmesini gerektiren bu hata ya da değişiklik ihtiyacı gerçekleşmeyebilir, ama öyleyse, tahminleriniz tamamen yanlış olacaklar .

İşin küçük bir kısmına ilişkin tahmin kalitenizi artırarak, işin büyük bir kısmını daha da kötüleştirerek daha iyi tahminler alamazsınız; bu yüzden bu gerçekten bir tradeoff değil, daha da kötüleştiğiniz ve aynı zamanda daha kötü tahminler alabileceğiniz bir kaybedilen durumdur.

NEM ALMA yararlı ama aynı zamanda aşırı derecelendirilmiş. Bazı insanlar bunu çok uzağa götürebilir. Pek çok geliştiricinin farkına varamadığı şey, DRY'yi aynı yöntemi iki (hafif) farklı amaç için kullanmak üzere uyguladığınızda, farklı kullanımlar arasında bir çeşit çok sıkı bağlantı ortaya koymanızdır. Şimdi, ilk kullanım durumunun kodunu her değiştirdiğinizde, ikinci kullanım durumunun gerisinde kaldığını da kontrol etmeniz gerekir. Bunlar genel olarak bağımsız kullanım durumları ise, sıkı bir şekilde birleştirilmeleri gerektiği çok şüphelidir - muhtemelen olmamalıdır.

DRY'nin aşırı kullanımı, bazı kodları çoğaltan daha küçük atomik yöntemlerin çok daha fazla korunabileceği durumlarda, konulmakta olan tüm farklı kullanım durumlarını ele almak için karmaşıklıkta patlayan Tanrı yöntemlerine de yol açabilir.

Ancak, sorunun proje yönetimi düzeyinde gerçekten alakalı olmadığını öne süreceğim. Bir proje yöneticisi, bu düzeydeki uygulama detaylarıyla gerçekten ilgilenmek istemeyecektir. Eğer öyleyse muhtemelen mikro yönetmedir. Gerçekten ... işlerin nasıl yapıldığı , geliştiricinin ve teknik liderin sorumluluğundadır. Proje yönetimi ile daha ilgili olduğunu neyi yapmış ve alır zaman .

EDIT: yorum başına, ancak geliştirme zamanını tahmin etmeyi kolaylaştırdığı sürece , DRY'den kaçınmanın bazen belirsizlik miktarını azaltabileceği konusunda hemfikirim . Ancak bunun, (1) iş gerekliliklerinin ne kadar sürdüğü, (2) bu süreçte hangi teknik borcun alındığı ve (3) toplam maliyetin riskleri konusunda daha acil sorularla ilgili olarak önemsiz bir mesele olduğuna inanıyorum. Yapılan mimari seçimlerin mülkiyeti - DRY'ye gidip gelmemek, çoğu durumda, proje yöneticilerine daha doğru bilgi vermeyi biraz daha kolay hale getirip getirmemek yerine, bu faktörlere daha fazla risk / ödül vermesi gereken bir tasarım tercihidir. .

Bence sen DRY'yi yanlış anlıyorsun.

Bir örnek kullanalım:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

public Class B
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }

    public int Add(int x, int y)
    {
        return x + y;
    }
}

vs.

public Class C : A
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}

B sınıfını C ile değiştirerek DRY prensibini uyguladık ve kod çoğaltmasını azalttık. Ancak, daha önce hiç miras almadıysanız, projeye ilişkin bilinmeyenleri veya riski artırmadık.

DRY hakkında konuşurken ne demek istediğinizi daha çok bir tasarım işi gibi düşünüyorum. yani:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

!!!Yeni gereksinim! Bazı müşterilerin çiftleri çoğaltabilmesi gerekir !!

// Use class B for new clients!!
public Class B
{
    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

vs.

public Class A // Version 2
{
    public int Multiply(int x, int y)
    {
        return Multiply(x as double, y as double);
    }

    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

Burada (işe yaradığı varsayılırsa) hem eski hem de yeni gereksinimle başa çıkabilen bir çözüm tasarladık, esasen gerçek hayat probleminin veya iş kurallarının matematiksel bir modelini oluşturmaya çalışıyoruz. Gerçek hayatta modellediğimiz sistem çok daha karmaşık olacak, modelimiz tam olarak uymayacak ve son vakalar ve beklenmedik sonuçların bulunması ve düzeltilmesi zaman alacaktır.

Öyleyse, bu durumda B veya A sürüm 2'yi almalı mıyız?

• B, daha az yan etki ile istenen gerçek değişikliğe daha spesifik olacak ve tahmin edilmesi daha kolay ve daha kolay olacaktır.

• Sürüm 2 daha az genel kodun ilerlemesine neden olacak ve daha şık bir çözüm olacak

Yine, şartname ve gereksinimlerin kalitesine bağlı olduğunu söyleyeceğim.

Kenar kasalarını ve geriye dönük uyumluluğu kapsayan çok net spesifikasyonlarımız varsa, sistemi hata üretmeden yeniden modellemek için sistemi yeterince iyi anladığımızdan emin olabiliriz.

Tek bir müşteri için acil bir talebimiz varsa, tek gereksinim bu davranışın tüm sistemi göz önünde bulundurmadan bu müşteri için değiştiği durumlarda; daha sonra, modeli yeniden canlandırarak modeli 'iyileştirmek' önemli bir risk taşır. Hem çözümü tasarlamak hem de test etmek için gereken fazladan zamanın bilinmemesi nedeniyle diğer müşterileri kırmak veya son teslim tarihini aşmak.

Paragrafa göre paragraf

Yazılım geliştirmenin en temel ve yaygın olarak kabul gören ilkelerinden biri DRY'dir (kendinizi tekrar etmeyin). Ayrıca çoğu yazılım projesinin bir çeşit yönetim gerektirdiği de açıktır.

Doğru.

Şimdi yönetmesi kolay görevler nelerdir (tahmin, zamanlama, kontrol)? Doğru, tekrarlayan işler, DRY'ye göre kaçınılması gereken görevler.

Tekrarlayan görevler otomatik, zorunlu olmalıdır . Elle yapıldığında sıkıcı, hata eğilimlidirler.

Bu nedenle proje yönetimi açısından, varolan bazı kodları 100 kez kopyalayarak bir görevi çözmek ve gerektiğinde her kopyaya küçük uyarlamalar yapmak harikadır. Her zaman tam olarak ne kadar iş yaptığınızı ve ne kadar iş kaldığını bilirsiniz. Tüm menajerler seni sevecek.

"Adaptasyon" kelimesini "konfigürasyon" ile değiştirebileceğinizi düşünüyorum. Kopyalanması gereken bu kod parçasında bir hata olduğunu düşünün. Belirli koşullar altında ortaya çıkan bir hata. Orijinal kaynakta sabit değilse ve kopyalanırsa, düzeltilmesi gereken çok yer olacaktır. Bu kötü olabilir, ama sonra birinin yapması gerekir:

• ilk önce kodu orijinal kaynakta düzeltin;
• diğer her yerde kodu düzeltin;
• bunların tüm yerler olduğundan emin olun. Bunun yöneticiye yapılması gerektiğini söylerken, muhtemelen en azından birinden nefret edecektir.

Bunun yerine, DRY ilkesini uygularsanız ve yinelenen kodu az çok ortadan kaldıran bir soyutlama bulmaya çalışırsanız, işler farklıdır. Genellikle birçok olasılık vardır, karar vermeniz, araştırma yapmanız, yaratıcı olmanız gerekir. Daha kısa sürede daha iyi bir çözüm bulabilir, ancak başarısız olabilirsiniz. Çoğu zaman, ne kadar iş kaldığını gerçekten söyleyemezsiniz. Sen proje yöneticisinin en kötü kabususun.

Kopyaları kaldırmak tek bir başarısızlık noktasına neden olur. Bir şey başarısız olursa, bunun nerede olduğundan emin olabilirsiniz. KATI ve Tasarım Desenleri tam olarak bu sorunu çözmenize yardımcı olmak için orada. Çok kısa tarihler prosedürel stil "kodlama" ya kışkırtma eğilimindedir. Yeniden kullanılabilir bir şey yaratmak için bir projeye daha fazla zaman harcanması, bir sonraki projede özelliğin tekrar kullanılması için harcanan zamanın minimum olması gerektiği , ancak ilk olarak yapılandırılabilir olması gerektiği anlamına gelir .

Tabii ki abartıyorum ama belli ki bir ikilem var. Sorumlarım şunlardır: Bir geliştiricinin DRY'yi abartıp geçirmediğine karar vermek için kriterler nelerdir? İyi bir uzlaşmayı nasıl bulabiliriz? Yoksa bu ikilemi tamamıyla aşmanın bir yolu var mı?

Birçok insan burada ikilem olmadığını belirtti. Evet ve hayır.

Daha önce hiç yapılmayan deneysel bir şeyiniz varsa - ikilem yoktur. Aksi takdirde, tekrar yapılması gereken bir şey varsa, yeni rezervasyon sistemi gibi, zaten soyutlamalar yapmış olmanız yeterlidir.

İkilemin, bence - istenmesi muhtemel değilse, bir özellik içinde bir şey uygulamalı mıyız? İstendiğinde bir şey uygulayın. Hiç kimsenin kullanılmayacak devasa bir altyapıya ihtiyacı yok.

bu, gelecekteki yeniden kullanım için tasarım ya da YAGNI ilkesi hakkında değildir. Mevcut çalışma paketindeki kodu tekrarlamakla ilgilidir.

Bu kesinlikle tasarımla ilgili. Belki kendi başına yeniden kullanmayın , ancak yine de tasarlayın.

Bir geliştiricinin DRY'yi abartıp geçirmediğine karar vermek için kriterler nelerdir?

Tecrübe ve mevcut ortamınız / durumunuz. Belirli bir problem için, daha fazla DRYness derecesi almaya çalışırken, Prado Prensibi'ni daha iyi anlayacaksınız. Sonra aniden yönetim değerlendirmeleri ortaya çıkmıştır. Zaman, hedefler, müşteri, uzun vadeli kod yönetimi (birisi teknik borç dedi ) vb. Saldırı planınızı bildirecektir.

İyi bir uzlaşmayı nasıl bulabiliriz?

Uh ... tasarım? Refactoring tasarımdır, olması gerektiği gibi. DRYing'in kapsamı, döngüden, metoda, sınıf (lar) a süper nova gibi kolayca genişleyebilir. Orada bulundum, yaptım. Ama problemi çalışana kadar gerçekten bilemezsiniz - bu tasarım.

Bir tasarım sorunu nasıl olamaz? Sorunu, eldeki kopya koddan hemen daha yaygın olarak düşünmelisiniz. Bu, var olan kod veya boş bir sayfa olup olmadığı bir tasarım etkinliğidir; "Extract" yöntemi mi yoksa yeni sınıflar ve modüller mi oluşturduğu.

son söz

... sorulan soru ve cevapları proje yönetimi yönünü kapsamamaktadır.

Tipik yönetim, tasarım zamanını dikkate almaz. İdeal olarak, kodlamadan önce gereksiz gereksiz yedekli tekrarlamayı tasarlardık. Bunun yerine, yönetim gelişimin (ve hata düzeltmelerinin) tek bir Olimpiyat olayı olduğunu düşünüyor - kodlama - aslında bir dekatlon olduğunda. Ve saniyenin 1 / 1000'ini ölçüyorlar çünkü hepsinin analog olduğunu düşünüyorlar.

Bunun yerine, DRY ilkesini uygularsanız ve yinelenen kodu az çok ortadan kaldıran bir soyutlama bulmaya çalışırsanız, işler farklıdır.

Bu deneyimi yaşadım: "İki günümü bu satırı (bir GUI formunda) ve iki saatini de formun geri kalanını yazarak geçirdim." Demek istediğim, yeniden kullanılabilir sınıfları tanımlamak için zaman harcadım - DRY doğal bir yan etki - GUI form satırında ve bazılarında w /. Bir kez hata ayıklandıktan sonra bunlar, şimdi ve çok hızlı kodlanan form boyunca ayrı ayrı ve kompozisyonda kullanılmış ve testin karmaşıklığına rağmen son derece hızlı olmuştur. Ve şaşırtıcı derecede düşük hata oranıyla resmi testlerden geçti.

Çoğu zaman, ne kadar iş kaldığını gerçekten söyleyemezsiniz. Sen proje yöneticisinin en kötü kabususun.

Ben de bilmiyordum ama ön tasarım çalışmalarının işe yarayacağına inanıyordum. Hepimiz bunu söylüyoruz ama özellikle yönetim buna güvenmiyor. Yönetim, uğraştığımı düşünürdü. “İki gün ve henüz% 2'sini bile kodlamadın!”

Bir durumda, yönetim “tasarım için çok fazla zaman harcıyorsun, git” dedi. Ve iş arkadaşları “çok fazla ders” diyor. Eh, çok daha az karmaşık bir alt projenin yaklaşık 1 ay sürmesi gerekiyordu (Tamam, basketbol sahası tahmin olduğunu düşündüm) ancak 5 ay sürdü. Bunun 3 ayını test ediyor / tamir ediyordu çünkü böyle bir POS. "Ama tasarlamak için zamanımız yoktu!" Bunu gerçekten söylediler.

Sorumlarım şunlardır: Bir geliştiricinin DRY'yi abartıp geçirmediğine karar vermek için kriterler nelerdir? İyi bir uzlaşmayı nasıl bulabiliriz? Yoksa bu ikilemi tamamıyla aşmanın bir yolu var mı?

Yönetime nasıl çalıştığını gösterin. Bazı verileri yakala. Diğer işlerle, özellikle de tokat atma işini yapan iş arkadaşlarınızla karşılaştırın. Bu başarısızlık yığını her zaman yarışı kaybediyor, teste sıkışıyor ve ardından serbest bırakıldıktan sonra daha fazla hata düzeltmek için tekrar tekrar geri döndü.