Günlük işimde bitebilecek birkaç kişisel projede çalışmayı / başlamayı planlıyorum. Beni düşündürdü, hangi yoldan başlamalıyım?

• Sadece prototip — kolay genişleme için optimize edip yeniden düzenlemeye zaman harcayan bana basit bir kod yaz.

• En başından itibaren temiz, optimize edilmiş ve belgelenmiş bir kod yazın; bir süre sonra maliyet etkin olmayacaksa düşürüleceğini unutmayın.

Güncelleme: YAGNI'yi sunpech ve M.Sameer cevaplarıyla birleştirmek bana mükemmel geliyor :) yardımlarınız için herkese teşekkür ederim.

Üçüncü bir seçenek var ... YAGNI bugün ihtiyaç duyulan gereklilikleri yerine getirmek için teste dayalı geliştirme yoluyla temiz kodlar yazıyor.

Şu anda gerekli olmayan, ancak gelecekte olabilecek kod yazma eğiliminde olmanız gereken bazı dezavantajlardan dolayı ... Sizden ihtiyacın olmayacak :

• Gerekli işlevselliğin eklenmesi, test edilmesi veya iyileştirilmesi için harcanan zaman alınır.
• Yeni özellikler hata ayıklanmalı, belgelendirilmeli ve desteklenmelidir.
• Herhangi bir yeni özellik gelecekte neler yapılabileceğine kısıtlamalar getirdiğinden, artık gereksiz bir özellik gerekli bir özelliğin daha sonra uygulanmasını engelleyebilir.
• Özelliğe ihtiyaç duyulana kadar ne yapması gerektiğini tam olarak tanımlamak ve test etmek zor. Yeni özellik doğru bir şekilde tanımlanmamış ve test edilmemişse, nihayetinde gerekli olsa bile doğru çalışmayabilir.
• Kod şişirilmesine yol açar; yazılım daha büyük ve daha karmaşık hale gelir. Spesifikasyonlar ve bir çeşit revizyon kontrolü olmadığı sürece, bu özelliği kullanabilecek programcılar tarafından bilinmeyebilir.
• Yeni özellik eklemek, başka yeni özellikler önerebilir. Bu yeni özellikler de uygulanırsa, bu sürtünme özelliğine karşı kartopu etkisine neden olabilir.

Sonuç olarak, sadece prototip yapmamalısınız ... ne de baştan itibaren temiz, optimize edilmiş ve belgelenmiş bir kod yazmamalısınız, akıl almazsa maliyet etkin olmayacak - düşmeyecektir.

Şimdi ihtiyacınız olan kodu, bugünün ve yarının ihtiyaçlarını en iyi şekilde karşılayabileceğinizi bilerek yazın.

her zaman oldugu gibi...

Değişir

Bir riski hafifletmek veya bilinmeyenleri ortaya çıkarmak için prototip oluşturuyorsanız, sadece kodlayın ve işiniz bittiğinde atmayı bekleyin

Yinelemeli iyileştirme için prototip oluşturuyorsanız, sadece kodlayın ve sık sık değiştirmeyi ve yeniden düzenlemeyi bekleyin

Asıl ürünü yazmaya başlıyorsanız ancak prototip olarak adlandırıyorsanız, böylece tembel olabilirsiniz , sonra tembel olmayın ve ilk defa iyi yazın.

Eğer prototip yapıyorsanız, neden temiz kod hakkında düşünüyorsunuz? Prototip oluşturma fikri, bir kavramı ya da fikri kanıtlamak ve daha sonra atılmak anlamına geliyor.

Buradaki herkesin çoğuna katılmayacağım diyerek, zaten temiz kod yazmak veya prototipleme için hızlıca bir şeyler yapmak arasında seçim yapmayı düşünüyorsanız, ikincisini seçin. Özellikle erken aşamadaki gelişimden söz ederken. Temiz bir kod yazmayın demiyorum, fikrim ortaya çıksın, gidilecek yolun olduğuna bakın, sonra tekrar temizleyin-- refactor.

Yazılım geliştiriciler olarak, işleri doğru yaptığımızdan ve ilk seferinde temizlediğimiz için çok yakalanıyoruz, sunduğumuz kod olmadığını, bir sorunun çözümünün olduğunu bilmiyoruz .

Bir makale yazarken kodlamayı düşünüyorum:

Bir makaleyi yazarken, bir yerden başlarız, fikirleri, ana hatları vb. Taslakları çizeriz. Tüm ayrıntıları içermez veya hiç bitmemiş bir bakışı olmaz - esasen ilk taslak, ardından ikinci, vb. Daha rafine ve bitmiş bir kağıda kadar birçok şey yeniden yazılacak, değiştirilecek ve hatta silinecek. (Açıkçası bu analoji, kodun gerçekten hiç bitmiş veya bir kağıt gibi son olduğunu söyleyecek kadar ileri gitmiyor).

İki tip prototip vardır:

• Nihai ürün olmak için geliştirmeler ve düzeltmelerle gelişmeye devam eden evrimsel prototip .
• Sadece ihtiyaçların toplanması ve müşterinin erken proje aşamalarında daha etkili bir şekilde geri beslenmesini sağlamak ve daha sonra tamamen düşürülmek için mevcut olan tek kullanımlık prototip , son ürünün gelişimi sıfırdan başlar.

Capers Jones'a göre, evrimsel prototipler kararlılığa ulaşmak için çok daha fazla çaba ve daha uzun zaman gerektiren düşük kaliteli ürünler üretiyor.

Dolayısıyla, prototip yapmayı düşünüyorsanız, müşteri daha iyi bir fikir ve gereksinimler hakkında daha fazla bilgi edinmenize yardımcı olmak için mümkün olan en kısa sürede bir şey görebilirse, tek kullanımlık bir prototip olmak ve geliştirme işleminin daha sonra temiz kodla yapılması daha iyi olur. Bunu karşılayamazsanız, baştan itibaren temiz kod yazın ve dikkatlice saklayın, ancak diğerlerinin önerdiği gibi, fazladan optimize etmeyin ve ihtiyaç duyuncaya kadar bir şey eklemeyin.

Herhangi bir nedenden dolayı kirli kodlamayı affetmek istemiyorum. Tecrübelerime göre, prototipleme için bahane olarak hızlı ve kirli olduğunu iddia eden insanlar, üretim de dahil olmak üzere herhangi bir koda karşı bu tutuma sahipler. Birisi dağınık bir prototip yaratırsa, herhangi bir kodda karışıklık yaratır. Prototipleme kirli kodlama anlamına gelmez, en önemli kullanım durumlarını test etmek için basitleştirilmiş varsayımlar anlamına gelir. Kod resmi olarak test edilemeyebilir veya tüm ayrıntılara dikkat etmeyebilir, ancak yine de iyi tasarlanmış ve iyi uygulanmış olmalıdır. Temizlik, bir yetkinlik işaretidir, yetkin programcılar, amacı ne olursa olsun, dağınık koda karşı doğal iğrenme hissederler.

En başından itibaren temiz, optimize edilmiş ve belgelenmiş bir kod yazın. Bunu kendim yapamıyorum ve bu gerçek bir problem. Ben bir kodlayıcı değilim, ancak müşteriyle yüz yüze çalışan yönetimlerdeki yazılım geliştirme şirketlerinde adil bir miktarda çalıştım ve bana birçok iyi fikir verdikleri için ara sıra bir şey için prototip yapıyorum. Neredeyse o prototip her seferinde “temizledi” ve bir nakliye ürününe dönüştüren bir geliştiriciye verildi. Kaynağı kontrol ettiğimde hala berbat kodum% 80-90 olacak.

Bir meslektaşım, her prototipi bir kenara atmak ve sıfırdan tekrar yazmak için yeterli disipline sahip olması gerektiğine dair ihtarı, tekrarlanan prototipleri coşkuyla onaylıyor - ve sadece bu değil Daha sonra birinin yaptığı şey, aynı prototipi birkaç kez farklı bir tarzda yazmasıdır. Gerçekten ciddiye almanızın muhtemel olduğu zekice bir kod parçasına bağlıysanız, yazdıracağınız, kaynak kontrol deposunu sileceğiniz ve çıktısını kendinize göndereceğinize dair ciddi bir öneride bulundu. Bir sonraki yinelemeye sızmayacak kadar uzun.

Her zaman çalışmasını sağlayarak her zaman başlayabilir, daha sonra temizlemesi için gözden geçirebilir ve bunu yapmak için ekonomik bir anlam ifade ediyorsa, hızlı / küçük yapabilirsiniz. Attığınız bazı deneylerle başlar, sonra neyin işe yaradığını saptadığınızda TDD'yi tekrar ortaya çıkarır.

İkiside iyi. İkisini de seviyorum. Birbirleriyle çelişmezler.

Prototip yapmayı severim. Prototip oluşturma yaratıcılık becerilerimi geliştiriyor. Pek çok olası çözümü test ediyorum. Hızlı yapmak bana sorunu çözmek için bir çok olası yolu test etme imkanı veriyor.

Temiz, iyi test edilmiş kod yazmayı seviyorum. Temel becerilerimi geliştiriyor. Genellikle prototiplerden birini seçerim, ya geliştiririm ya da sıfırdan yeniden yazarım.

Ancak prototipi üretim kodundan asla yanlışlamamalısınız. Prototip asla üretime girmemelidir. Her zaman prototip olarak işaretlenmelidir. En iyi ihtimalle, kendi şubenizdeki tüm prototipleri yapın.

Aşırılıkların neredeyse her zaman kötü olduğunu söylemeye meyilliyim.

Temiz, iyi belgelenmiş ve prototipleme arasındaki dengenin korunmasını tavsiye ederim. Bir kütüphane veya platform için geliştirdiğiniz zaman, prototip oluşturma yönüne daha fazla giremem. Bu özellikle başlangıçta ve platformlar için, örneğin sizi Android veya konteynırlar gibi korse kullanmaya devam ediyor. Bu onların arayüzlerini uyguladığınız ve sizi aradıkları anlamına gelir.

Kendi tecrübelerime göre kodun çoğu uzun sürmüyor. Bununla birlikte, özelliğinizi uygulayarak hızlı ilerleyin. Er ya da geç (çoğu zaman), özellikle çalışmakta olan karmaşık parçaları bir araya getirdiğiniz için bir sonraki özellik nedeniyle mevcut kodunuzu elden geçirmeniz / düzeltmeniz gerekir. Sorunsuz yeniden yapılandırmayı mümkün kılmak için uygun otomatik testlere dikkat edin. Android gibi yukarıda sözü edilen platformlarla ilgili olarak: çoğu zaman otomatik testler, yakın bağlanma ve test edilebilirlik için tasarım olmaması nedeniyle kolay değildir. Ardından, test tabanınızı daha yüksek bir seviyeye kaldırabilirsiniz, örneğin entegrasyon testi.

Başlangıç ​​hakkında bazı ipuçları verebilecek bir makale yazdım: https://medium.com/@ewaldbenes/start-lean-why-its-best-to-split-your-next-coding-project-by-feature-70019290036d