Sabit kodlanmış değerleri ve savunma tasarımını YAGNI ile kaldırma

İlk olarak biraz arka plan. Yaş -> Ücret aramasını kodluyorum. 7 yaş aralığı vardır, bu nedenle arama tablosu 7 satırlı 3 sütundan (Kimden | Kime | Ücret). Değerler nadiren değişir - bunlar 3 yıl boyunca aynı kalan yasal oranlardır (birinci ve üçüncü sütunlar). Bu tabloyu sabit kodlamadan depolamanın en kolay yolunun, bir CSV içeren tek bir metin değeri olarak genel yapılandırma tablosundaki veritabanında olduğunu anladım (böylece "65,69,0.05,70,74,0.06" 65-69 ve 70-74 katmanları depolanır). Ayrıştırmak sonra kullanmak nispeten kolay.

Daha sonra bunu uygulamak için yeni bir tablo, etrafına sarmak için bir havuz, repo için veri katmanı testleri, CSV'yi masanın içine sürükleyen kodun etrafında birim testler ve aramanın etrafındaki testler oluşturmam gerektiğini fark ettim. Tüm bu çalışmaların tek yararı, arama tablosunu kodlamaktan kaçınmaktır.

Kullanıcılarla konuşurken (şu anda arama tablosunu doğrudan kullanan - basılı bir kopyaya bakarak) görüş hemen hemen "oranlar asla değişmez". Açıkçası bu aslında doğru değil - oranlar sadece üç yıl önce yaratıldı ve geçmişte "asla değişmeyen" şeylerin değişme alışkanlığı vardı - bu yüzden bunu savunmacı bir şekilde programlamak için kesinlikle arama tablosunu saklamamalıyım uygulama.

YAGNI diye düşündüğüm hariç . Uyguladığım özellik oranların değişeceğini belirtmiyor. Oranlar değişirse, bakım o kadar nadiren değişecek ve bakım bile dikkate alınmayacak ve özellik, oran değişikliği ile güncellenen uygulama arasında bir gecikme olursa herhangi bir şey etkilenecek kadar kritik değildir.

Ben arama zor kod eğer değer hiçbir şey kaybolmayacağına karar verdim ve ben bu özel özelliği benim yaklaşım hakkında çok endişe değilim. Sorum şu: Bir uzman olarak bu kararı doğru bir şekilde gerekçelendirdim mi? Sabit kodlama değerleri kötü bir tasarımdır, ancak değerlerin uygulamadan kaldırılması sorununa gitmek YAGNI ilkesini ihlal ediyor gibi görünmektedir.

DÜZENLEME Soruyu açıklığa kavuşturmak için gerçek uygulamadan endişe etmiyorum. Ya hızlı, kötü bir şey yapabileceğimden ve YAGNI diyerek bunu haklı çıkarabildiğimden ya da en iyi durumda bile sonuçta düşük faydaları olan daha savunmacı, yüksek çaba gerektiren bir yaklaşım benimseyebileceğimden endişeliyim. Profesyonel bir programcı olarak kusurlu olduğunu bildiğim bir tasarımı uygulama kararım basitçe bir maliyet / fayda analizine iniyor mu?

DÜZENLEME Bir bireyin tasarım tercihlerine geldiğini düşündüğüm için tüm cevaplar çok ilginç olsa da, en iyi cevapların soruda dikkate almadığım şeyleri ortaya çıkardıklarında @ Corbin ve @EZ Hart'ın olduğunu düşünüyorum:

• veritabanına taşıyarak 'sabit kodlanmış değerleri doğru şekilde kaldırmanın' yanlış ikilemesine karşı sabit kodlama kullanarak 'YAGNI'yi etkili bir şekilde uygulamak'. Arama tablosunu uygulama yapılandırmasına koymanın üçüncü bir seçeneği vardı, bu da doğru şekilde ek yüke neden olmaz ve YAGNI'nin verimliliği olmadan. Genel olarak, ya / veya kararlarla sınırlı değiliz ve daha sonra bir maliyet / fayda kararına düşer.
• kod üretimi, sabit kodlanmış değerleri veritabanına taşıma yükünü azaltabilir ve bir CSV'yi tabloya işleme konusundaki aşırı tasarlanmış kararımı da kaldıracak şekilde. Arama yöntemi için temel gereksinimler değişirse, bu potansiyel olarak oluşturulan kodla ilgili uzun vadeli bir bakım sorunu da ekler. Tüm bunlar sadece maliyet / fayda analizini etkiler ve muhtemelen otomasyona sahip olsaydım böyle bir şeyi kodlamayı bile düşünmezdim.

@ Corbin'in cevabını doğru olarak işaretliyorum çünkü geliştirme maliyeti varsayımlarımı değiştiriyor ve muhtemelen yakın gelecekte cephaneme bazı kod oluşturma araçları ekleyeceğim.

Geliştirme sürecinizde bir kusur buldunuz. Doğru olanı yapmak bir acı olduğunda (tablo oluşturmak, repo, repo testleri, testleri düzleştirmek ...), geliştiriciler bunun etrafında bir yol bulacaklar. Bu genellikle yanlış bir şey yapmayı içerir. Bu durumda, uygulama verilerine uygulama mantığı olarak davranmanız caziptir. Yapma. Bunun yerine, geliştirme sürecinize yararlı otomasyonlar ekleyin. Biz hiç kimsenin yazmak istemediği sıkıcı, kaynak kodunu üretmek için CodeSmith'i kullanıyoruz . Bir tablo oluşturduktan sonra, CodeSmith'i çalıştırırız ve her biri için DAO'ları, DTO'ları ve birim testlerini oluşturur.

Kullandığınız teknolojilere bağlı olarak, benzer seçeneklere sahip olmalısınız. Birçok ORM aracı mevcut bir şemadan modeller oluşturur. Raylar geçişleri ters yönde çalışır - modellerden tablolar. Dinamik dillerde meta-programlama özellikle kazan plakası kodunu ortadan kaldırmada güçlüdür. Karmaşık bir çok katmanlı uygulamanız varsa, ihtiyacınız olan her şeyi oluşturmak için biraz daha fazla çalışmanız gerekecek, ancak buna değer. "Vay canına, bu boyunda bir acı" hissine izin vermeyin, doğru şeyi yapmanıza engel olun.

Oh, ve verilerinizi ek işleme (CSV) gerektiren bir formatta saklamayın. Bu sadece dikkatinizi ve testinizi gerektiren ekstra adımlar ekler.

@ Thorbjørn Ravn Andersen'in cevabını kapatmak ve genişletmek için: Hesaplamayı / aramayı tek bir yerde tutmak iyi bir başlangıçtır.

Savunma ve YAGNI arasındaki düşünce süreciniz yaygın bir sorundur. Bu durumda, iki şey daha bilgilendirilmesini öneririm.

İlk olarak - kullanıcı gereksinimi nasıl sunuldu? Oranların düzenlenebilirliğini belirlediler mi? Değilse, eklenen karmaşıklık faturalayabileceğiniz bir şeyin parçası mıdır? (ya da personel iseniz, bunun yerine başka bir iş yapmak için zaman harcayabilirsiniz?) Öyleyse, o zaman kesinlikle devam edin ve makul ne istediğini teslim.

İkincisi ve belki de daha önemlisi, sadece düzenlenebilirliğin yasal bir değişiklik karşısında gerçek bir gereksinimi yerine getirmesi olası değildir. Oranlar değişirse ve ne zaman değişirse, bir kesinti tarihi ve gerçekleşmesi gereken işlem öncesi ve sonrası olabilir. Ayrıca, aynı arabirim daha sonra herhangi bir geri tarihli talep işleme yapmak zorundaysa, o zaman gerçek tarih yerine girişin yürürlük tarihine göre doğru oranın aranması gerekebilir.

Kısacası, gerçek bir düzenlenebilir gereksinimin oldukça karmaşık olabileceğine dikkat çekiyorum , bu yüzden ete gelmedikçe veya etmedikçe, basit muhtemelen daha iyidir.

İyi şanslar

Gerçek aramayı bir kütüphane işlevi haline getirin. Daha sonra kaynak havuzunuzda bu aramayı kullanarak tüm kodu görebilirsiniz , böylece oranlar değiştiğinde hangi programların yükseltilmesi gerektiğini bilirsiniz.

Sorunuzu doğru anladım mı bakayım. Bir özelliği uygulamak için 2 seçeneğiniz vardır: ya bir değeri sabit kodluyorsunuz ve özelliğinizin uygulanması kolaydır (btu sabit kod bölümünü beğenmezsiniz) ya da yapılan birçok şeyi "yeniden yapmak" için çok büyük bir çabanız vardır böylece size özel bir özellik geliştirebileceksiniz. Bu doğru mu?

Aklıma ilk gelen şey, "İyi uygulamaları bilmekle ilgili en önemli şey, onlarsız ne zaman daha iyi olduğunuzu bilmektir."

Bu durumda, çaba çok yüksektir, bu yüzden temiz bir şekilde yapabilirsiniz, bu değişikliğin teminat etkisi olasılığı yüksektir ve alacağınız getiri küçüktür (açıkladığınız gibi, muhtemelen değişiklik).

Sabit kod yaklaşımını kullanırdım (ancak gelecekte esnek olmaya hazır olun) ve gelecekte bu oranın değişmesi durumunda, kodun tüm bu kötü tasarım bölümünü yeniden düzenleme fırsatını kullanın. Böylece zaman ve maliyet doğru bir şekilde tahmin edilebilir ve sabit kodlu değerinizi değiştirmenin maliyeti minimum olacaktır.

Bu benim yaklaşımım :)

Bu, değişene kadar "değişmeyecek" bir öğedir. Değişmesi kaçınılmazdır, ancak bu süre biraz uzakta olabilir.

Gerekçeniz doğrudur. Şu anda, müşteri bu oranları kolayca değiştirme yeteneğini istemedi. Bu nedenle, YAGNI.

Bununla birlikte, istemediğiniz, oranlarınıza erişen ve kod tabanına dağılmış sonuçları yorumlayan koddur. İyi OO tasarımı, bir sınıftaki oranlarınızın dahili temsilini kapsüllemenizi ve yalnızca verileri kullanmak için gereken bir veya iki yöntemi ortaya çıkarmanızı sağlar.

Kopyalama ve yapıştırma hatalarını önlemek için bu kapsüllemeye ihtiyacınız olacak veya dahili gösterimde bir değişiklik yapmanız gerektiğinde oranları kullanan tüm kodlarda yeniden düzenleme yapmak zorunda kalacaksınız. Bu ilk önlemi aldığınızda, daha karmaşık yaklaşım basit bir takas olabilir ve daha özellikli sürümün yerini alabilir.

Ayrıca, mevcut tasarımın istemciye sınırlandırılmasını çağırın. Onlara, programı korumak amacıyla değerleri sabit olarak kodladığınızı söyleyin - bu, bunları güncellemek için bir kodlama değişikliği gerektirir. Bu şekilde, yeni mevzuat nedeniyle bekleyen oran değişikliklerinin farkına vardıklarında, arama tablosunu güncellemeyi veya o sırada daha karmaşık değişiklikleri gerçekleştirmeyi seçebilirler. Ama bu kararı kucağına koy.

Farkı bölün ve hız verilerini bir yapılandırma ayarına yerleştirin. Zaten sahip olduğunuz CSV biçimini kullanabilirsiniz, gereksiz veritabanı ek yükünü önlersiniz ve değişiklik gerekirse, müşterinin yeniden derlemek / yeniden yüklemek zorunda kalmadan ve karışıklık olmadan yapabilmesi gereken bir değişiklik olacaktır. veritabanında - sadece yapılandırma dosyasını düzenleyebilirler.

Genellikle iki uç arasında bir seçeneğe bakarken (YAGNI ile sabit kodlama dinamik verilerini ihlal edin), en iyi cevap ortada bir yerdedir. Yanlış ikiliklere dikkat edin.

Bu, tüm yapılandırmanızın dosyalarda olduğunu varsayar; kayıt defteri gibi zor bir yerde, muhtemelen bu tavsiyeyi dikkate almamalısınız :)

Bu tabloyu sabit kodlamadan saklamanın en kolay yolunun, bir CSV içeren tek bir metin değeri olarak genel yapılandırma tablosundaki veritabanında olduğunu anladım (böylece "65,69,0.05,70,74,0.06" 65-69 ve 70-74 katmanları depolanacaktı.

Sadece bir DB Tablosu oluşturduk. (Bir masanın tamamını bir dosyada saklamayı düşündüğünüzde, delirdiniz mi?)

Tablo 3 DEĞİL 3 alana ihtiyaç duyar. Yaş ve Oran. Bu sonraki satır üst değeri içerir! Bilmeden bile normalleştiriyorsun!

İşte Sql 67 yaşında birisinin oranını almak için.

Select * from RateTable where Age in (Select max(age) from RateTable where age <=67) 

Kapsam dışı olduğu için bir bakım ekranı yapmak için uğraşmayın. Daha sonra isterse bir değişiklik isteği yayınlayın ve yapın.

DÜZENLEME: Diğerlerinin söylediği gibi, tüm Rate yapısının değişmesi durumunda, kodu merkezileştirir .

Verilen cevapların çoğuna katılıyorum. Ayrıca, uygulamanın geri kalanıyla tutarlılığın önemli olduğunu da ekleyeceğim. Kodda sabit kodlanmış değerlere sahip tek yer bu ise, muhtemelen bakıcıları şaşırtacaktır. Bu, özellikle büyük, kararlı bir kod tabanı ise doğrudur. Sizin tarafınızdan tutulan küçük bir programsa, karar daha az önemlidir.

Kod çoğaltma için başparmak kuralının iki ve sadece iki kez olduğunu söyleyerek iyi bilinen bir çevik / OOP adamı (Dave Thomas veya Kent Beck veya birisi gibi) okurken uzak bir anı var: hayatınızda yalnızca iki kez yazabilirsiniz. Ama üçüncü kez ...

YAGNI'yi sorguladığınız için bu tam olarak soruyu ele almıyor, ancak bence çevik kuralların genel esnekliğini konuşuyor. Çevik olan nokta duruma uyum sağlamak ve ilerlemektir.

Bir fonksiyondaki sabit kod.

• Değerler değiştiğinde müşteriyi tekrar faturalandırabilirsiniz
• Değerler değiştiğinde, tablo biçiminin değişmesi ihtimali vardır, CSV yapmak zaman kaybeder
• Uygulanması daha kolay, mevcut sözleşmeyle bütçede olma şansı daha yüksek
• Güncellenmesi gerektiğinde kolayca bulabilir