Bir programı geliştirme aşamasından yayınlamaya nasıl geçirirsiniz?


67

Bir noktada bir program geliştirilme aşamasındadır. Özellikler her zaman ekleniyor veya kaldırılıyor veya değiştiriliyor. Her sürüm bir prototipten başka bir şey değildir. Bu yüzden bu noktada süper temiz kod yazmak için fazla zaman harcamam çünkü, bir şeyin ne kadar süreceğini asla bilemiyorum. Elbette kod kalitesini belirli standartlarda tutmaya çalışıyorum ama zaman her zaman bir sorun.

Ardından programın bittiği noktaya gelir ve karar vericiler "işte bu" derler. Bu noktada çalışan bir prototipim var, ancak içerideki kod geliştirme aşamasında tüm ileri geri dağınık. Test / son hata ayıklama işlemine başlamam bekleniyor ancak bağırsaklarım şimdi bakım veya daha kolay hale getirecek uygun mimariyi vermek için bir şekilde temizlemem ve ya da yeniden yazmam gerektiğini söylüyor.

İşler test edilip onaylandıktan sonra, yeniden yazmaya gerek yoktur. Düzenli olarak orada çalışan bir 'bitmiş' prototip ile duruyorum ve test sırasında hata alıyorum ve bunun tüm geliştirme sürecinin bir sonucu olan akıllı olmayan kodlamanın bir sonucu olduğunu görüyorum. Testin tam ortasındayım ve bugfix bir yeniden yazma olurdu ... bu bir karışıklık!

Eminim daha iyi / ders kitabı yolları vardır. Ancak, her şeyin ders kitabı olmadığı gerçek bir çalışma ortamında çalışmak zorundayım.

Peki çalışma prototipimi kararlı bir kod temelli bir sürüm sürümüne nasıl geçiririm? Belki de bir kez yaptığım gelişmenin bitmiş olduğunu düşünmemeliyim ve bunu gerçekten temizlik aşaması olarak görmeliyim ... Bilmiyorum, burada yardıma ihtiyacım var.

DÜZENLE

Birkaç şeyi açıklığa kavuşturmak istiyorum.

  • Ben hemen önce ve sonra değil, temiz ve okunabilir kod yapma tarafında% 100'üm. Ama aynı zamanda işleri halletmek zorundayım ve kodun güzelliğini tamamen temiz ve parlak göremiyorum. Bir uzlaşma bulmalıyım.

  • Genellikle yeni bir özellik gerçekten sadece denemek ve böyle bir şey uygulamak için mantıklı olup olmadığını görmek istediğimiz bir şeydir. (özellikle mobil uygulamalarda, gerçek bir cihazda gerçek bir görünüm ve his elde etmek için) Bu nedenle (imho) ilk "haydi görelim" yinelemesinde çok fazla çalışmayı haklı çıkarmayacak kadar küçük bir şeydir. Ancak bazen soru ortaya çıkıyor, bu teknolojiye NE ZAMAN ödeme yapıyorum? Bu tam olarak bununla ilgili.

Bir gün sonra özelliklerin yarısının düşeceğini bilirsem (şu anda şirketimizde yeterli deneyim) Gerçekten de, sorunuma yaklaşmanın en iyi yolunun, her şeyi temiz yazmak için bile olsa fazladan zaman harcamak olduğuna inanmanın zor olduğunu düşünüyorum. çoğu kısa bir süre sonra bırakılacak. Her şey katı olduğunda büyük bir temizlik yaparsam zaman kazanacağım ve bu yüzden sorum olacak.


68
Sorunuz "Kendimi bir deliğe soktum; nasıl çıkarım?" Standart cevap elbette birinci adımdır, DUR DIGGING DEEPER. Geliştirme süreciniz "muazzam miktarda teknik borç üretmek ve daha sonra vadesi geldiğinde yok saymak" olarak özetlenebilir. Bu bir problemse, gelişim süreçlerinizi değiştirin. Sadece dikkatlice yazılmış şartnamelerine uygun temiz, çalışma, hata ayıklama, dikkatlice gözden geçirilmiş kodları kontrol edin. Borç alma, borçtan çıkmak zorunda kalmazsın.
Eric Lippert

11
@NikkyD Doğru uygulama için zamanınız yoksa, yazılımın kalitesi üzerindeki etki hakkında yöneticinizle görüşmeniz gerekir. Buradaki herkesin size ne dediğini anlayın: zamana yatırım yapmamak , daha sonra verimli çalışabilmenize zarar verir. Onlarla konuşmak istediğiniz başka bir konu: şirketten ayrılacaksanız (veya bir otobüsün önüne geçecekseniz ), yeni geliştiricilerin kodu tanımaları çok pahalı olacaktır . Şimdi biriktirdiklerini düşündükleri para daha sonra onlara mal olacak.
jpmc26

32
Bir özellik için önerilen bir kullanıcı arayüzü ile alay etmek için küçük bir özellik dalı yapıyorsanız, bu harika. Bunu istediğiniz kadar çabuk ve kirli yapın, müşteriye gösterin ve ardından o dalı silin . Otomobil üreticileri yeni tasarımlarla alay etmek için arabaları kilden ve kağıttan yaptıklarında, o zaman kil modeline bir motor koymaya çalışmazlar. Özelliğin yapılmaya değip değmeyeceğini belirleme süreci ucuz olmalıdır. Özelliği yapmaya karar verdikten sonra , temiz koddan başladığınızdan ve her zaman temiz kod ürettiğinizden emin olun , çünkü bu kod artık üretim kodudur .
Eric Lippert

10
"Kodun güzelliğini tamamen temiz ve parlak göremiyorum" Bu, "temiz kod" un ne anlama geldiğinin temel bir yanlış anlaşılmasıdır. Temiz kod, bir öğleden sonrayı sekmelerinizi aynı hizaya getirerek geçirdiğiniz anlamına gelmez, böylece kodu yazdırabilir ve çerçevelendirebilirsiniz. Temiz kod olduğunu iyi kod ve iyi kod olduğunu temiz kodu. Temiz kod düzgün çalışan, hata ayıklanabilen ve anlaşılan koddur. Baştan itibaren temiz kod yazmak için zamanınız yoksa, o zaman kesinlikle dağınık kod yazmak ve daha sonra da düzeltmek için zamanınız yok. Görev bu kadar sürüyor.
GrandOpener

8
“Ayrıca işleri halletmek zorundayım ve kodun güzelliğini tamamen temiz ve parlak olarak hayal edemem. Bir uzlaşma bulmalıyım.” Bir uzlaşma, her iki taraf için "yeterince iyi" olan bir orta yol anlamına gelir. Eğer kodunuz dağınıksa - özellikle de onu korumakta zorlanacağınızı düşündüğünüz yeterince karışıksa - o zaman bu "yeterince iyi" değildir ve daha iyi bir uzlaşma bulmanız gerekir.
anaximander

Yanıtlar:


98

Bu yüzden bu noktada süper temiz kod yazmak için fazla zaman harcamam çünkü, bir şeyin ne kadar süreceğini asla bilemiyorum.

Bir şeyin ne kadar sürdüğünü bilmemek, asla terslik için bir mazeret olmamalıdır - tam tersi. En temiz kod IMHO, bir şeyi değiştirmek zorunda olduğunuzda size gelmeyen koddur. Yani benim tavsiye: her zaman yapabilirsiniz en temiz kod yazmak deneyin - özellikle bir prototip kodlama yaparken. Çünkü bir şeylerin değiştirilmesi gerektiğinde (ki kesinlikle olacak) uyarlamak çok daha kolay olacaktır.

Beni yanlış anlamayın - "en temiz kod" anlayışımın, güzelliğin uğruna kodu güzelleştirmekle hiçbir ilgisi yok. Bu gerçekten seni yavaşlatan bir şey. Benim görüşüme göre, temiz kod çoğunlukla kendi kendini açıklayan (çok fazla dokümana gerek yok - hızlanmaya neden oluyor), anlaşılması kolay (daha az hata, daha az hata ayıklama - daha hızlı, doğru zamanı bulmak için daha az zaman gerekli - değiştirilecek yer - hızlanma), verilen sorunu en az gerekli kodla çözer (hata ayıklamak için daha az kod - belirgin hızlanma), KURU (bir şeyin değiştirilmesi gerektiğinde değiştirilecek yalnızca bir yer - hızlanma - ve daha az risk verme riski) ikinci bir yeri değiştirmeyi unutarak yeni böcekler), kodlama standartlarını izler (düşünmek daha az hantal şeyler - hızlanma), küçük kullanır,

Test / son hata ayıklama işlemine başlamam bekleniyor, ancak bağırsaklarım şimdi bakımımı kolaylaştıran uygun bir mimari sağlamak için bir şekilde temizlemem ve ya da yeniden yazmam gerektiğini söylüyor

Daha sonra "temizleme" yapmak asla işe yaramaz. Yeni bir özellik uygulamadan önce ya da uygulamaya başlarken, ancak sonrasında kullanmayacağınızı düşünün . Örneğin, bir özellik için bir yönteme dokunmaya başladığınızda ve 10 satırdan daha uzun sürdüğünü fark ettiğinizde , özelliği tamamlamadan hemen önce daha küçük yöntemlere yeniden yansıtmayı düşünün . Mevcut bir değişkeni veya fonksiyon adını tespit ettiğinizde ne anlama geldiğini tam olarak bilmiyorsunuz, bunun ne için iyi olduğunu bulun ve başka bir şey yapmadan önce o şeyi yeniden adlandırın . Bunu düzenli olarak yaparsanız, kodunuzu en azından "yeterince temiz" durumda tutmalısınız. Ve Başlamadan zaman tasarrufu - Eğer hata ayıklama için çok az zaman gerekir çünkü.

Testin tam ortasındayım ve hata düzeltmesi yeniden yazma olacak

... yukarıda yazdıklarımın gerçek kanıtı: "kirli" olmak, kodunuzu hata ayıklamaya başladığınızda hemen size göz yumar ve sizi yavaşlatır.

Temizleme işlemini hemen yaparsanız, neredeyse tamamen önleyebilirsiniz. Ardından, hata düzeltmeleri çoğunlukla kodda küçük değişiklikler yapılması, ancak hiçbir zaman büyük bir mimari değişiklik olmaması anlamına gelir. Sınama sırasında bir mimari gelişime ilişkin kanıtlar tespit ederseniz, geciktirin, sorun takip sisteminize yerleştirin ve bir sonraki seferde bu değişiklikten yararlanan bir özellik ( bu özelliğe başlamadan önce ) uygulamanız gerektiğinde uygulayın.

Bu elbette biraz disiplin ve biraz kodlama deneyimi gerektiriyor. "Teste dayalı geliştirme" nin arkasındaki fikir gibi benzer bir fikir, daha sonra bunları yapmak yerine bunları önceden yapmak (TDD de yardımcı olabilir, ancak benim yazdıklarım TDD'yi kullanmadığınızda bile işe yarıyor). Sonuç olarak bunu yaptığınızda, serbest bırakmadan önce herhangi bir özel "temizleme aşamasına" ihtiyacınız olmayacaktır.


40
@NikkyD Doc Brown tarafından yapılan öneriler, uzun süreler boyunca çok zaman alan ve çok gerçekçi olan alışkanlıklardır. Her bir değişikliğe ihtiyaç duyduğunuzda nasıl kırılmayacağını anlamak için kodunuzu incelemeye gerek yoksa ne kadar zaman kazanacağınızı düşünün . Kazanç, "avla ve gagala" yazmadan, dokunmaya başlamayı öğrenmeye geçişe benzer. Öğrenirken başlangıçta daha uzun sürebilir, ancak alışkanlık bir kez orada inkar edilemez bir şekilde daha iyidir ve kariyerinizin geri kalanında size fayda sağlayacaktır. Denememeyi seçersen, oraya asla ulaşamazsın.
Daniel

44
@NikkyD: Zaman dilimini şişirmez. Zaman dilimi zaten şişmişti; Sadece vermedi hesap yazılımı yazdım ve bütçelemedikleri teknik borca girince kabartmak için.
Eric Lippert

7
@NikkyD: Size İdolü Kil Feet ve Teknik Borç kavramını sunuyorum . İlki, titrek temeller üzerine ses yazılımı oluşturabileceğiniz anlamına gelir; ikincisi, yapı sağlam olmadığında üstesinden gelmeye çalıştığınız özelliklerin yaşadığı "ilgilenen" (ek maliyet).
Matthieu M.

10
@NikkyD: hayır, kodunuzu bir bilardo uzmanının toplarını oynamasına benzer şekilde yazmanızı öneririm: her atış yabancı için basit görünüyor, çünkü atıştan sonra topları yeni bir "basit atış" için durur. Ve bilardoda ya da kodlamada bu işlem birkaç yıl sürecektir ;-)
Doc Brown

16
@NikkyD: deneyimlerime göre, "küçük bir özellik eklemek çok fazla yeniden düzenleme gerektiriyorsa", kod zaten bir karışıklık yaratıyor ve "yeniden düzenleme çok" için ihtiyaç duyduğunuzda, yaptığınız bir işlevi veya sınıfı değiştirmeniz gerekiyor Geçmişte yeterince temiz tutmuyorum. İşlerin o kadar uzağa gitmesine izin verme. Ancak bu durumdaysanız, bir uzlaşma bulun. En azından "boyscout kuralını" takip edin ve kodu siz eklemeden önce olduğundan daha iyi bir durumda bırakın. Bu nedenle, özellik önümüzdeki hafta kaldırılsa bile, kodun öncekinden daha iyi durumda olması gerekir.
Doktor Brown

22

Her ikisi de aynı semptomla (özensiz kod) iki ayrı sorununuz var:

Sorun # 1: Yetersiz gereksinim kontrolü Paydaşlarınızın gereksinimlerinizi çok sık değiştirdiği anlamına gelmiyor, bir hata düzeltme / test döngüsü sırasında gereksinim değişikliklerine izin verdiğiniz anlamına geliyor. Çevik metodolojiler bile bunu desteklemiyor; inşa ediyorsun, test ediyorsun, teslim ediyorsun, yeni gereksinimler enjekte ediyorsun

Sorun # 2: Yazdığın şeyin "şimdilik" yazılım geliştirmede "şimdilik" kodunun çok nadir olduğuna inanıyorsun . Bir kullanıcı gereksinimini yerine getirdikten sonra, arz ve talebin zorluklarının geri dönmeyi ve "yapılan" bir özelliği tekrar uygulamanın haklı çıkmasının çok zor olduğunu farkettiniz. Peki bu konuda ne yapmalı? Her zaman üretim kodunu yaz. İşlevsel olarak sizin için, bu, paydaşlarınıza yönelik tahminlerinizin büyük ölçüde daha büyük olması gerektiği anlamına gelir;

Ayrıca, bir geliştirici olarak en zor konumda çalıştığınızı lütfen anlayın: Joel Spolsky'nin bir şirket içi geliştiricinin yaşamını üstlendiğini okuyun . Bu nedenle, akıl sağlığınız bozulmadan gelmek istiyorsanız ekstra uyanık olmalısınız.


21

Bu yaygın bir sorundur - özellikle de esasen bir yazılım deneme balonu olanı oluştururken.

Yardımcı olabilecek birkaç yaklaşım var. Öncelikle TDD yaklaşımı, kod tabanının kesinlikle gerekli olana indirgenmesine yardımcı olabilir. Testleriniz kodunuzla el ele giderse, en azından kodunuzun olması gerektiği gibi davrandığından emin olabilirsiniz.

Giderken refactor'a zaman ayırın. Bir prototipiniz olduğunda ve müşteri ellerini ele geçirmek için çok istekliyse, (onlara) neyin tamamlandığını cilalamak için zamana ihtiyacınız olduğunu söylemek zor bir satış. Günlük bazda check-in yapmayı ve bunu takiben YMMV'den gelen bir refactor check-in yapmayı seviyorum.

Hızlıca kod yazan geliştiriciler genellikle talep görmektedir - son departmanımda böyle bir geliştiricimiz vardı. Her takım onu ​​istedi çünkü çok hızlı çalıştı. Ancak kodunu test etme ve serbest bırakma zamanı geldiğinde, tekerlekler hızla patladı. Sabit kodlanmış şeyler, her yerde kesmek ve kısayollar. Stokları yakında düştü - büyük miktarda.

Üretim kodunun baştan kesilmesi bir sürükleğe benzeyebilir , ancak ortamınıza bağlı olarak, Ghostdoc ve Stylecop gibi geliştirmelerden kurtulabilecek birçok araç vardır .

En başından beri doğru gelişme zihniyetine girmeye değer. Ne zaman bir duraksayan çözüm olduğu düşünülen bir geri dönüşlü paket sistemlerin köşe taşı uygulamaları haline geldiğine şaşıracaksınız.


Demek istediğim, her durak boşluğu çözümünün yazdığı, değil mi?
RubberDuck

4
Müşteriye gerekçe hakkında harika bir nokta. GUI yapıldığında uygulamanın da yapıldığını düşünen müşterilerle ilgili çok fazla deneyimim var. Arka plandaki kod henüz hazır değilken GUI'nin tamamlanmamış görünmesini sağladım ve sonuç olarak yalnızca kod (ve iş mantığı) olduğunda müşterinin cilalı göründüğünü gördüm. Müşteriye bitmiş görünen şeyin gerçekte teslim edilmesi bir veya iki ay alacağını açıklamak çok zor.
Luaan

11

devamlı olarak

Geliştirme hızı temiz, okunaklı ve test edilebilir kod yazmak için ana nedendir; güzellik ya da diğer soyut değerler için yapılmamıştır. Bunu neden kendime inkar edeyim ve sonradan gelecek programcılar için bunu daha sonra yapabilirim?

Elbette çoğunlukla kozmetik olan ve bu yüzden gerekli olmayan değişiklikler olabilir; Şu anda, geliştirme sırasında, şu anda bir karışıklığa sahip olmaktan ve daha sonra mükemmel yapmayı ummaktan çok güzel kodlara sahip olmanın çok daha faydalı olduğunu iddia ediyorum (ki, bununla yüzleşelim, olsaydı bile, asla olmayacak) zaman).


6
+1 ve kişisel bir bakış açısıyla, gündelik mesleğimde evdeki kişisel projeleri kırmak ve üretim kodu yazmaktan vites değiştirmeyi çok zor buldum. Hobilerimde profesyonel kod yazarken hemen temettü ödemesi yapıldı - kodun okunması daha kolaydı ve çok daha az hata vardı.
Robbie Dee

Bunun asla gerçekleşmemesinin bir nedeni, zamanla yaptığınız işte (daha iyi) daha iyi olmanızdır. Yani bir şeyi "temizlemek" için yarım yıl beklerseniz, temizliği güvenli bir şekilde yapmak için gereken tüm minutaları unutmazsınız, ayrıca öncekinden daha iyi bir programcı olacaksınız ve muhtemelen cazip olacaksınız Sadece her şeyi atıp yeniden başlamak için. Ve bu çok iş olduğundan (ve yine de genellikle kötü bir fikir), muhtemelen temizliği tekrar atlayacaksın.
Luaan

“Neden bunu kendime inkar ettim ve sonradan gelecek bazı programcılar için bunu daha sonra yapabilirim?” Vahiy! Ve tahmin et ne oldu? Bazen (ve bazen, sık sık) gelecekteki programcısınız.
radarbob

@RobbieDee, Üstün gözlem! Bir röportajda Malcom Gladwell - "10.000 saatlik kuralı" popüler farkındalığa ( Outliers kitabında ) getiren adam - "kasıtlı bir uygulama" olması gerektiğini ya da sadece zaman harcadığını söyledi. İyileştirme odağı Anlamı, niyetiyle uygulama özelliklerini belirli vb beceri yönünü geliştirmek için
radarbob

@ThanosTintinidis, o zaman "hiçbir iyilik cezasız kalmaz" sorunu var. Böyle temiz bir kod yazdıktan sonra, birileri kaçınılmaz olarak onu kilitleyecektir. Başka biri temiz kodunuza dokunduğunda kod inceleme yapan olduğunuzdan emin olun. Eklenen basit bir yöntem , hatta belgelenmiş enkapsülasyonu ve tutarlılığı patlattı . Bir hafta boyunca öfkeliydim; ve bir yıl sonra, bu kodu her gördüğümde.
radarbob

4

Bunu "Sadece nasıl çalıştığını görmek için çalışıyorum" kodu ile "bu ürüne yönlendiriliyor" kodu arasında ayırarak yaparsınız. Bunu yapmanın birkaç yolu vardır.

Bunlardan biri dallanma veya kelime kontrol sisteminizde ne olursa olsun. Yeni rapor veya yeni içe aktarma düzeni veya başka bir şekilde bir şube oluşturursunuz. Eğer insanlar onu severse, onu ana şubeye geri götürme işi ayrı, izlenebilir bir işdir. Birine atanabilir ve bildirilebilir ve sadece sihirli bir şekilde gerçekleşmesi beklenmez, yönetim (veya satış) bu özelliğin ürüne ait olduğunu kabul eder.

Bir diğeri ise sivridir. Üründe bu değişikliği yapmazsınız. Sadece kod koyacak bir yere sahip olmanız için var olan süper basit, ayrı bir uygulamaya geçersiniz. İstediğin kadar karışık olabilirsin çünkü yeni API'yi veya başka bir şeyi araştırıyorsun. Ve yine, geri dönüp “evet, bunu yapabiliriz, bunun nasıl olduğunu anladım” diyerek rapor verirseniz, istediğiniz ürünü yapmak için üründe hazır kod yazmanın izlenebilir, raporlanabilir, atanabilir bir görevi olduğunu görürsünüz.

Her iki durumda da, ürün hazırlığı, okunabilir, düzenli, adlandırma standartlarını izleyerek, testlerle ve kod stilinize ve performans hedeflerinize bağlı kalmanızı sağlar. Her iki durumda da, bu işi görünür kılıyorsunuz. Birisi ürünü geri alma ihtimalinin oldukça yüksek olduğu durumlarda, tüm bu işleri yapmak istemediğinize katılıyorum. Ama bu işin de görünmez olmasına izin vermek istemezsin. Ürünün ayrı kopyalarında veya bir test donanımından çok daha fazlası olmayan ilgisiz bir üründe çalışmak, birisi bir şey istediğine karar verdiğinde ürünü hazır kod haline getirmek için çalışmaları yüzeylendirmenizi sağlar.

Dezavantajı ise, bir şey istediklerine karar veremedikleri ve göndereceği (yarının konseptinin kanıtı olarak uyguladığın yarı-kıçlı, dağınık, denenmemiş, belgelenmemiş, muhtemelen yavaş olan yarı-sürümü anlamına gelir). O cepheye ilk kez bastığınızda, basitçe her seferinde uzun (daha pahalı) bir şekilde yapıp yapmamanız gerektiğini sorarlar, reddedilen özelliklerin yolunu yavaşlatırlar. Doğru sorarsanız, "hayır" alırsınız.


1

Gerçekten, sorunu zaten anladığını düşünüyorum. Sorun şu ki kodlama stiliniz çok fazla yeniden işlem yapmanızı gerektiriyor. Çok fazla tekrar çalışmanın gerekli olmasının nedeni (a) yetersiz öngörü ve planlama ile bir araya getirilmesi ve (b) geliştirme sırasında düzenli olarak yerleştirilen artımlı kısa vadeli yamalar birleştirilerek gerekli tüm çalışmaların karmaşıklığını arttırmasıdır.

Bu nedenle cevap,

(a) gelişim tarzınızı biraz daha şelaleye ve biraz daha çevik hale getirin. Her şeye rağmen gitmeyin, çünkü klasik şelalenin kendine özgü tuzaklar vardır. Olması gereken sağlıklı bir denge var. Bazen birkaç günlüğüne şeyler düşünmekle ilgili olabileceğini biliyorum, hiçbir gelişme olmamış gibi, ancak sürece güvenmek zorundasınız. Mühendislikte, bir şeyleri bir araya getiremezsiniz, sonra da üste bir şeyler çakar ve zarif bir çözümle ortaya çıkmayı umarsınız. Mimari ve daha üst seviye teknik tasarım yapan kimse yoksa, bu onun işi demektir. Bu işi ihmal etmenin bedelini ödedin.

(b) işleri yama yapmaktan kaçınmaya çalışmak. QA yapmak için zamanı geldiğinde uzun vadeli düşünmeyin. Gerçekten, inşa ettiğiniz her küçük parçayı, her zaman test etmeli ve aynı zamanda mutlu yolda olmayan tüm giriş vakalarını kapsamalısınız. Bir yama / kesmek neredeyse tanımı gereği, uzun vadeli bir maliyete sahip olabilecek kısa vadeli bir düzeltmedir, müşterilere sistemdeki Toplam Sahip Olma Maliyeti'ni vurur. Yine, baskı kod dışına çıkmaya başladı, bu yüzden denge olmalı. Ancak kısa vadeli düzeltmeleri yerine koymamaya çalışın, özellikle. Gerçekten sıkı bir şekilde bağlanması gereken bileşenleri sıkıca birleştirenler. Yeniden çalışma olacak, bu nedenle, zaman içinde toplanacak ve yönetilemez hale gelebilecek hack ve yamalardan kaçınmak için çok daha kolay hale getirmek için yapın.


2
Sadece bir not - çevik "düşüncesiz sık değişiklikler" veya "daha az tasarım" anlamına gelmez. Aslında, çevikliğin insanların genel olarak şelale dediklerinden çok daha fazla tasarım gerektirdiğini biliyorum. İyi tasarım eksikliği, şelalenin pratikte iyi çalışmamasının nedenlerinden biridir - aslında tasarıma doğru bir şekilde yatırım yaparsanız, tamamen iyi çalışır; aynı zamanda çevik olmaktan çok daha pahalı hale geliyor. Eğer tasarım kısmını çevik olarak atlarsanız, sadece willy-nilly kodunu birlikte vuruyorsunuz ve bu, tasarımdan kaçınan diğer uygulamalardan daha iyi çalışmayacak.
Luaan

Kısa yinelemelere, sprint'lere, prototiplerin hızlı şekilde yapılmasına odaklanan çevik odak, öndeki yeterli tasarımı ihmal etmek için mutlaka daha fazla baskı yapar
Brad Thomas

Hayır, daha küçük parçaların tasarlanmasına odaklanır. Ama genel olarak, çok fazla tasarım yapmalısınız , aksi halde sadece korkunç bir ürün üreteceksiniz. Anahtar, şeyleri küçük ve iyi tasarlanmış ve aynı zamanda değiştirilebilir hale getirmektir. Daha az çevik tasarım yaparsanız, kendiniz (ve müşterileriniz) bir kötülük yapıyorsunuz. Kısa yinelemeler, çevik kullanımın ön koşulu veya sürecin sadece bir parçası değil de kullanmanın yararıdır - her şeyi yeterince iyi elde ettiğinizde, kısa süreli yinelemeleri başka bir yolla değil de karşılayabilirsiniz .
Luaan

Küçük parçaların tasarlanmasına daha fazla önem vermek, büyük resmin gerçekten en büyük yeniden çalışma sebebi olduğu durumlarda büyük bir sorundur. Birden bire işine harcanan çok fazla para gördüm "ama bunu yapmak için ihtiyacımız var". gevşek bir şekilde bağlanmış küçük bileşen
Brad Thomas

Evet, ama bu noktada zaten kaybettin (ve çevik mi yoksa şelale mi çalıştığından bağımsız olarak). “Büyük resminiz” nispeten izole edilmiş birçok küçük parçadan oluştuğunda, elde ettiğiniz tek geniş kapsamlı bakım, hemen hemen her şeyi değiştirmeniz gereken zamandır. Hangi yaklaşım , sıfırdan başlamanız gerektiğinde her şeyi kaybetmenize neden olmaz ? NASA'nın tasarım seviyeleri bile arada bir “her şeyi değiştirmeliyiz”. Kendinizi esnek ve uyarlanabilir tutarak, küçük veya büyük değişiklikler yapmak için daha fazla manevra alanı elde edersiniz.
Luaan

0

Sen yaz:

Her sürüm bir prototipten başka bir şey değildir. Bu yüzden bu noktada süper temiz kod yazmak için fazla zaman harcamam çünkü, bir şeyin ne kadar süreceğini asla bilemiyorum. ...

Ardından programın bittiği noktaya gelir ve karar vericiler "işte bu" derler. Bu noktada çalışan bir prototipim var, ancak içerideki kod geliştirme aşamasında tüm ileri geri dağınık.

Check-in edilmiş bir versiyon, özellikleri kaçıran veya bazı özelliklerin aşınmadığı bir "prototip" olabilir, ancak teslim edilen tüm kodların, mutlaka temizlenmesi gerekmeyen üretim kalite kodu olması gerekir.

Bence "temizliği" çok erteliyorsun.

Benim kuralım:

  • (Alt) özelliği ile başla
  • Tamamlamayan ve içermeyen şeyler yazmaktan çekinmeyin, belki de uyguladıklarıma dair bir fikir edinmek için ya da kodlamanın son saat (ler) ini çizmem gerekirse (bunun TDD / testler ile el ele geçebileceğini unutmayın) , Sadece keşfediyorum uygulama alanı hakkında hızlı bir geri bildirim almak için her şeyi biraz tonda)
  • Alt özellik "çalışıyor" şimdilik yeterince iyi
  • Şimdi temizliği yapın: SCC taahhüdünden önce .
    • Neyin bariz olduğunu görmek için kodun üzerinden bakın
    • Değişiklikleri gözden geçirme ve belki de bazı problemleri yakalama konusunda en son sözü yerine getirme
    • Karalama kutumda not aldığım şeyleri düzelt
  • Şimdi taahhüt ediyorum - bu kod kalitesi gönderilmeye hazır

Bu noktada, işlenen kod hala temizlemenin iyi olacağı bazı geçici çözümler veya "teknik borçlar" içerebilir ve belki de aşağıdaki alt özellik için yapılacak doğal bir şey olduğunda temizleyeceğim, ancak Bu kod olduğu gibi yayınlanırsa tamam olur.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.