Önemsiz olmayan bir uygulama oluştururken, işlerin hızlı bir şekilde çalışmasını sağlamak ve model mantığını görüşlerinizle karıştırmak, enkapsülasyonu kırmak - tipik kod kokuları gibi kısayollara odaklanmak en iyisidir? Veya, daha fazla mimari oluşturmak, doğru inşa etmek için zaman ayırmaktan daha iyi bir zaman geçiriyorsanız, ancak tasarımınız oldukça akıcı olduğu için tüm bu ekstra kodun kullanılamaması ve geri bildirim size yol açması durumunda atmanız gerekebilir farklı bir yöne gitmek için?

Bağlam için bir masaüstü uygulaması yapıyorum. Tek geliştiriciyim ve bir günlük işim olduğundan beri bu part-time yapıyorum. Şimdi, iş için, işleri doğru şekilde yapmaya çalışıyorum, izin vermeyi planlıyorum. Ancak, insanlardan geri bildirim aldıkça beklediğim bu proje için, bunun doğru bir yaklaşım olduğundan emin değilim. Bu hafta birkaç saatimi, modeldeki değişiklikleri görüşe iletmek için bir Model Kitabı Kontrol Cihazı tasarımı ders kitabı hazırlayarak hazırladım. Bu genel olarak harika, ancak verileri görüntülemek için birden fazla görüntülemeye ihtiyacım olup olmadığından emin değilim ve ek mimari olmadan daha hızlı bir şekilde görüntülenen şeylerin olabileceğini biliyorum. Projeye harcanmak için haftada 10-15 saat kala, iyi yazılım uygulamalarını takip edersem, demo uygulayabileceğim bir şey hazırlamanın yıllar alacağını düşünüyorum. Kullanıcılarımın kazandığını biliyorum MVC'yi dahili olarak kullanmam umrumda, sadece sorunlarını çözecek bir şey istiyorlar. Ancak kısa yollardan çok fazla teknik borç aldığınız durumda da, kodun korunması ve yeni özellikler eklemek için inanılmaz derecede zor olduğu bir durumdayım. Başkalarının bu tür bir soruna nasıl yaklaştığını duymayı çok isterim.

İyi inşa et .

Büyük resme bakarsanız "hızlı" inşa mantıklı bir yanlıştır. İyi inşa edilmenizi önleyecektir ve nihayetinde yeniden yapılanmayı önleyen veya hatta imkansız özelliklerin yanı sıra yeni özellikler ekleyen hatalar ve temel mimari kusurları ile tıkanacaksınız.

İyi inşa etmek aslında tam tersi. İlk başta daha yavaş olabilir, ama nihayetinde doğru seçimleri yapmak için zaman harcayarak elde ettiğiniz verimlilik kazanımlarının farkına varacaksınız. Ek olarak, gelecekteki gereksinimlere daha kolay adapte olacaksınız (gerekirse yeniden düzenleme) ve en azından daha az hata nedeniyle daha iyi bir nihai ürün elde edeceksiniz.

Başka bir deyişle (bu tek ve bitmiş bir sözleşme olmadıkça), hızlı kurdu = yavaş kur, iyi kur = hızlı kur .

Ayrıca “iyi inşa etmek” ve bir mimarlık tasarlamak hakkında farketmek için önemli bir şey var. Sen sordun...

... ancak tasarımınız oldukça akıcı olduğu için tüm bu ekstra kodun kullanılmaması riskini taşıyor ve geri bildiriminiz farklı bir yöne gitmenize neden oluyorsa atmak zorunda kalabilirsiniz?

Bu, "mimarlık zamanını harcamak" için gerçek bir risk değil. Mimari tasarım organik olmalıdır . Haklı çıkıncaya kadar herhangi bir bölüm için bir mimari tasarlamak için zaman harcamayın. Mimari yalnızca projenizdeki gözlemlenmiş ve onaylanmış modellerden gelişmelidir.

John Gall'ın Systemantics'ten kanunu :

Sıfırdan tasarlanan karmaşık bir sistem asla işe yaramaz ve çalışması için düzeltilemez. Çalışan basit bir sistemle baştan başlamak zorundasınız.

Hızlı, sonra iyi

Bu benim kişisel deneyimimden, birçok farklı yöntem denedim.

Yalnızca hızlı çalışma (ve serbest bırakma) ile ilgili sorun genellikle uygulamanızdaki özellikten sonra özelliği kullanacağınız ve piyasaya sürüldüğü için programınızda temel değişiklikler yapmanız çok zordur. Uzun vadede, sağlam bir mimariye sahip olan hiçbir şey olmadığı için yüksek bir bedel ödersiniz, sanki bir bataklıkta bir tokmak yapmak gibi.

Bunu iyi yapan program, çok fazla zaman ve kod boşa harcayacak olmanızdır. Planları olmayan bir konak inşa etmek gibi. Uygulama yazmak bir öğrenme sürecidir ve neredeyse (benim deneyimime göre) ön tasarım yapmak imkansızdır. Bu, çok fazla yeniden düzenleme yapacağınız anlamına gelir ve her şeyi her zaman "iyi" yazarsanız, çok fazla kod atmanız gerekir.

Önce, hızlı, sonra iyi!

Başlarken en önemli şey sadece kodun içindeki herşeyi kodlamaktır, böylece tüm özellikleri çivilemek ve ne tür bir mimariyi desteklemeniz gerektiğini görebilirsiniz. Bu metodolojiyle ilgili bir başka iyi şey, hızlı bir şekilde koşuya sahip olduğunuz için sizi motive edeceğim. Genel mimarinizi etkileyeceğinden, bazı "son derece" işlevler uygulamak da önemlidir. Bu aşamada ünite testleri yazmaya veya detaylarla uğraşmaya zahmet etmeyin. Gelecekte çok dilli dili desteklemeniz gerektiğini düşünüyorsanız, neyin olmadığını anlatan, uygulayan ancak hızlı ve kirli bir eklenti mimarisi. Uygulamanın yönetilebilir olmasını sağlamak için biraz refactoring yapın, ancak aşırı bir şey yapmayın.

Çalışan bir "prototip" iniz olduğunu düşündükten sonra, yeniden düzenlemeye başlamanın zamanı geldi. Temel olarak, şimdi bildiğiniz her şeyi bilerek sıfırdan başlarsanız, uygulamayı yaptığınız gibi tekrarlamak istersiniz. Önemli olan, mimariyi doğru yapmak, birinci aşamada yaptığınız tüm özellikleri yeniden uygulamak değil, ancak daha sonra destekleyecek mimariye sahip olmalısınız.

Bu sayede deneyimlerime rağmen, mümkün olduğunca verimli bir ses mimarisine sahip bir uygulama ile sonuçlanacak :)

İnşa et

Hızlı pazara zaman kalitesinden daha önemliyse

Eh kalite pazara zamandan daha önemliyse

Hızlı inşa etmek size kısa vadeli faydalar ve uzun vadeli zararlar sağlayacaktır.

İyice inşa etmek kısa vadeli zararlara, ancak uzun vadeli faydalara neden olacaktır.

İyi inşa etmek sabır ve bilgelik ister, ancak ödüllendirileceksiniz.

Hızlı inşa etmek sadece hızlı prototipleme ve çöpe atma işleri için iyidir. Uzun vadeli hedeflere ancak en başından itibaren doğru tutumla ulaşılabilir.

Başkalarının kullanması için dağıtmayı planladığınız projeler için her zaman ön çalışmanın yanında yer alırım. İyi düşünülmüş bir mimarinin gerektiğinde genişletilmesi daha kolaydır. Kısa kesimler yapmak, teknik borç biriktirmek için sadece bir modeldir.

Bazen sinir bozucu derecede yavaş olabilir. Yapmaya değer şeyler doğru yapmaya değer.

İyi inşa etmek = hızlı inşa etmek

Kısayollar geri dönüp sizi düşündüğünüzden daha hızlı ısırmaya meyillidir. Bazen öğle yemeğinden önce bile.

Bağlamınız hakkında; hemen soyut yapmayın. YAGNI'ye yapıştır ve çoğaltmayı kaldır. Gelecekte bir tane olabileceğini düşündüğünüzden değil, ikinci bir görüşünüz olduğunda bu Görünüm temelli deseni uygulayın. Bu ikinci Görünüm geldiğinde, yarattığınız soyutlama tipik olarak o ilk olayın etrafında yapacağınızdan çok daha iyidir.

Ne yaptığını zaten biliyorsan, hızlı yapmazsan

Ben bir araştırma bilimcisiyim ve büyük resmin ne olduğu veya projenin nasıl gelişeceği hakkında herhangi bir fikrim olmadan önce çok sayıda keşif kodu yazıyorum. Bu durumlarda, "iyi" nin nasıl tanımlanması gerektiğini bile görmek zor. Ayrıca, tüm küçük ayrıntıları ve işlerin önceden genişletilebileceği yolları görmek genellikle zordur. Bu nedenle, eski atasözü geçerlidir:

1. Çalışmasını sağla.
2. Doğru yap. Doğru saniye yapmak, işe yarama tecrübesine sahip olduğunuzda "doğru" kelimesini daha iyi tanımlayabilmeniz avantajına sahiptir.

İyi inşa et .. her zaman, ama hızlı olma yanılsamasını ver

ama hızlı yapmak için sadece daha küçük yapmak. Bütünün geri bildirim almak için yeterince önemli olan küçük bir alt kümesini oluşturun. Devamlı bir şekilde buna hızlı bir şekilde eklemek, ruhunuzu satılmadan uykusuz gecelerin zincirleme tepkisine vermeden hızlı bir şekilde inşa etmenin aynı faydasını sağlayacaktır.

Bence her zaman "iyi inşa edilmiş" olmalı. Piyasaya girme zamanı büyük bir endişe ise, artan bir geliştirme süreci kullanın. En kötü senaryoda, daha az özellik içeren bir ürüne sahipsiniz, ancak en azından gelecekteki özellik sürümlerinde genişletilebilecek yüksek kaliteli bir ürününüz var.

Denge

Kodunuzu mükemmele dönüştürmek veya bir kodu bir anda karıştırmak için pratik değildir, değil mi? Bu gerçekten de doğru dengeyi yakalamakla ilgili. Bence önemli olan ne zaman yaptığınızdır.

Bence buradaki en önemli şey kesinlikle uygulamanın özünü, temel yapıyı gerçekten iyi inşa etmeyi sağlamak. Hava geçirmez. Zamanında kısıtlamalara bağlı olarak, bu bir kez başarılırsa, zamanınız kısalırsa, birlikte bir kod alabilirsiniz ve daha sonra yeniden faktörlendirebilirsiniz ve bu lüksü karşılayabilirsiniz çünkü temel almak için özen gösterecektiniz. Tamam, ve yeniden faktörü kodlamaktan zarar gelmez.

İşe yarayabilecek en basit şeyi yap. Özel durumunuzda, programınız yarı zamanlı çalışan tek kişi siz olacağınız için çok büyük olmayacak. Kötüye kullanım, sıradan değişken isimleri vb. Gibi kötü davranışları savunmuyorum, ama olması gerekenden daha karmaşık hale getirmemelisiniz. Belki de MVC sizin özel projeniz için çok fazla bir sorumluluktur.

İnsanlardan geri bildirim aldıkça bekleyeceğim

Kendin için en iyisini söyledin:

Ancak kısa yollardan çok fazla teknik borç aldığınız durumda da, kodun korunması ve yeni özellikler eklemek için inanılmaz derecede zor olduğu bir durumdayım.

Eğer vaktiniz kısaysa, aynı sebeple projeyi işvereninizden tamamlamak için daha fazla zaman istemekten çekinmeyin. Eminim size vereceklerdir. Bunu söyledikten sonra, bazen bir şey için bu kadar çok çalışmanın ve sonuçların çoğunu gösterememenin ne kadar sinir bozucu olabileceğini anlıyorum. Ama endişelenme, oraya varacaksın ve iyi inşa etmek, kesinlikle yaptığın zaman buna değecek.

Genellikle yapıyı iyi inşa etmeyi severim ve belirli uygulama ayrıntıları hakkında endişelenmeyerek zaman kazanırım. Söylediğin gibi, yine de değişecekler. İyi yapılmış bir yapı inşa etmenin arkasındaki fikir, taban inşa edildikten sonra değişikliklerin çok hızlı gerçekleşebileceğidir. Sınıflarımda olabildiğince jenerik olmaya ve mümkün olduğunda onları yeniden kullanılabilir hale getirmeye odaklanmaya çalışıyorum. Genellikle, kullanıcıya yalnızca en temel kullanılabilirlik gereksinimlerini karşılayan iyi oluşturulmuş bir uygulama veririm. Kullanıcılar bir araç eline geçtikten sonra her türlü fikri elde ederler, bu yüzden ileriye dönük düşünmenin bir anlamı yoktur.

Bunu kurmak iyi . Vaktiniz yoksa, özellik setini azaltın.

Olabildiğince evrensel olarak tasarlayın . Örneğin bir eklenti mimarisi tasarlayın, bilseniz bile, ilk defa yalnızca bir eklenti kullanılacaktır. Başlangıçta sadece bir parametre olsa bile, evrensel yapılandırma şemaları kullanın (genişletilebilir yapılandırma, dil düzenleme). Bu çok iyi bir yatırım ve bu yatırımı sadece projenin başında yapabilirsiniz.

İşlerin hızlı bir şekilde çalışmasını sağlamak ve model mantığını görüşlerinizle karıştırmak, enkapsülasyonu kırmak gibi tipik kısayol kodları gibi kısayollara odaklanmak en iyisidir? Yoksa, daha fazla mimarlık oluşturmak için zaman ayırmayarak daha iyi olursunuz

Kulaklarımda, oraya koyduğunuz şekilde, iki ucu listeliyorsunuz. İlk tercih, kapsüllemeyi bozmak, görünümlere model mantık koymak, bu sadece tembelce programlamadır. IMHO, bu sorunları çözmenin daha fazla mimari koymakla aynı şey değil. Belki de bahsettiğin şey, UI kodunun SQL deyimlerini yürütmediği sürece. Ama sonra daha fazla mimari yapı demeyeceğim, o zaman tam bir tasarım ve mimari eksikliğiniz olduğunu ve bir tane almanız gerektiğini söyleyebilirim.

Mimarlığa gelince, şu anda probleminizi çözen en basitini seçip problemler ortaya çıktıkça genişleyeceğim.

Örn: İhtiyacınız olan şey şu anda tek bir veritabanı tablosundan veri döndürme işlevi, sorunun sonunda ortaya çıkacağını bilmeme rağmen, ilgili tablolardan nasıl veri yükleyeceğim gibi sorunlar hakkında endişelenmem. Bu işlevselliği uygulamaya başladığımda endişelenmeye başlayacağım.

Bu yüzden kendi ev geliştirme projelerim için şu yaklaşımı benimsem: Şu anda birlikte çalıştığım sorunu çözen mümkün olan en basit çözümü inşa et, ancak bunu iyi yap. Daha sonra, daha fazla karmaşıklığa ihtiyaç duyulduğundan çözümü yeniden yapılandırdım. TDD uygulamalarının uygulanması yeniden düzenlemeyi güvenli kılar ve aynı zamanda kod kokularından kaçınmaya da yardımcı olur (kapsüllemeyi çiğniyorsanız iyi birim testleri oluşturmak zordur).

Bu arada, aynı zamanda profesyonelce çalışırken aldığım yaklaşım. ;)

Öncelikle yazılımı ayağa kaldırmalı, her yönünü örtmeli ve yazılımı önce ve kademeli olarak durdurarak daha sonra performansını geliştirmeli ve geliştirmelisiniz.

Genelde bu iki kenarın ortasında olmak istersiniz:

İyi inşa et = insanların hayatlarının dayandığı hayati önem taşıyan gerçek zamanlı yazılım. yani, yazılım kontrolü: Nükleer reaktörler, Diyaliz makinesi, MRI makineleri vb.

Hızlı yap = kimsenin kullanmadığı işe yaramaz bir yazılım.