Yazdığın çirkin kod ile nasıl baş edebilirsin? [kapalı]

Müşterin sizden bazı kodlar yazmanızı istiyor, siz de yazıyorsunuz. Daha sonra beklendiği gibi, üzerindeki özellikleri değiştirir ve siz iyi bir küçük çocuk gibi yeni özelliklerini özenle uygularsınız. Bunun dışında ... yeni özellikler eski özelliklerle bir çeşit çelişki gösteriyor, bu yüzden şimdi kodunuz bir karışıklık. Sen gerçekten geri dönmek ve bunu düzeltmek istiyorum, ama o yeni şeyler talep eden tutar ve bir şeyler temizledikten her zaman, tekrar bir karmaşa rüzgarlar.

Ne yaparsın? Bir OKB manyağı olmayı bırak ve sadece ne yaparsan yap kodunu bozmayacağını kabul et, ve sadece bu canavarlığın özelliklerini takip etmeye devam et. Temizlemeyi sürüm 2 için saklayın?

Başka bir iş bul ve başkalarının da ilgilenmesine izin ver. Muahahahhahahaa.

.....

Sadece şaka yapıyorum. :)

Ama tüm ciddiyetle: tahmini doldurma senin arkadaşın. Genel olarak iyi bir gerçekçi tahmin yapıyorum, sonra iki katına çıkarıyorum. Bu aşırı gelebilir ve bazen de öyle, ama biraz fazla abartmak ve hatta bazen biraz yavaş görünmek daha iyidir - buggy kodunu açıp her zaman tahminlerini üfleyerek kötü izlenimler bırakmaktan daha iyidir. Ve elbette, kod tabanının bozulmasına izin vererek teknik borcunuz var.

Başka bir (ilgili) ipucu: Her zaman görünüşte küçük olduğunu tahmin et, iyi bir büyüklükte bir blokta daha ince işler yap. Mesela - basit bir satırlık 30 saniyelik bir değişiklik olacak, neredeyse kesin olduğundan emin olduğunuz bir ürün - 1 saat verin (ya da zaman çizelgenizde veya CR sisteminizde en düşük zaman bloğu ne olursa olsun, örneğin 15 dakika / 0.25 saat) . Ve biraz daha büyük ama yine de oldukça önemsiz nesneler için yarım günlük veya 1 günlük bloklar verin.

Bunun nedeni psikolojiktir: Bence küçük değişiklikleri hızlıca yapma alışkanlığına sahip olursanız, işin aceleye geldiğini hissediyorsunuz ve asla geri oturmaktan, hisse senedi almaktan ve yeniden canlandırılması gereken şeyleri yeniden düzenlemekten vazgeçmiyorsunuz. Ayrıca, pratik düzeyde: küçük ama önemsiz değişiklikler bazen patlar ve sürekli programın gerisinde olduğunuzu ve böcek ateşini söndürdüğünüzü hissetmek istemezsiniz. Kod üslerinin zaman içinde neden hacklendiğinin bir parçası ve paketi.

Son olarak, insanların tahminlerinizi bir şekilde doldurduğunuzu bilmek zorunda olmadıklarını daima unutmayın . Yetkili bir geliştirici olduğunuz ve iyi bir tempoda işten attığınız sürece, bu dolgu maddesi fark edilmeyecektir. yani PHB'ye "İlk tahminim iki saat sürecek, ancak bana yarım gün ver" demeyin. Sadece ona "Sanırım yaklaşık yarım gün alacağını düşünüyorum." ve orada bırak.

Bir sonraki özellikleriniz için gereken süreyi kasten abartın. Temizlemek için bu ekstra zamanı kullanın.

Bakımı hiçbir zaman haklı çıkaramayacaksınız ve müşteri ne olursa olsun buna ihtiyaç duyuyor, bu yüzden onlara acı ilaçları (bir sonraki özellikler için biraz artan maliyetler) verin, böylece daha iyi olabilirler.

Yeni özellikleri entegre ederken doğru şekilde yeniden tasarlamayı deneyin. Daha sonra yok. Yeniden tasarlama olmadan sürekli daha fazla değişiklik ve yeni özellikler için daha fazla sürtünme ekliyorsunuz.

Bir noktada, her şeyin yaşlanmaya başladığı durma noktasına yakın bir taşlamaya geleceksiniz. Çoğu şirket muhtemelen bu noktada büyük yeniden yazma için tercih ediyor, sürüm 2. Oldukça zayıf bir ekonomiye sahip ve müşterinin kendini eğik hissederse farklı bir geliştirme partisi denemesi için iyi bir an.

Doğru yeniden tasarım / yeniden düzenleme, müşterilerinizin yatırımlarını koruyabilir ve işleri sürdürülebilir tutabilir. Bunu geliştirmeniz gerekir. Değişim için optimize edin, hafif hareket edin.

Aşırı kestirime ilişkin tüm yorumlar ile, ılımlı miktarda bir noktanın (iyi fırsat) kaçırıldığını düşünüyorum.

Bu, geçen süreyi tahmin etmekle ilgili değildir (sadece) ve sonra bazılarını da ekleyin, değişikliğin güvenli bir şekilde yapılabileceği bir noktaya getirmek için kodu (refactor!) Değiştirmek için gereken süreyi tahmin etmekle ilgilidir. değişim (muhtemelen biraz birbirine büründü). Tamam, bu aynı şeyi ifade ediyor ... ancak fuding veya uzatma veya aşırı tahmin etme sorunu yok, basitçe bunu yapmak için önce bunu yapmam gerektiğini ve bunun ne kadar süreceğini söylemesi meselesi. toplamda. Burada anahtar, sistemin değişime bağlı olduğu ve daha fazla olmayan bölümleri üzerinde çalışmanızdır - başka bir yerde korkunç kod varsa ... zor, oradayken yakalayın.

Asıl soruya geri biraz gelecek için - yıl bir sürü sonra sürece bir şey uygulamak zaman onun benim için bu kadar inmesi biliyor (? (Zanlıyı beklemeyin, inanmıyorum), düşünmüyorum ama biliyorum ek şeyler) Ayrıca bu şartı yerine getirmek için ihtiyacınız olanı yapmalı ve mümkün olduğunca düzenli ve şık bir moda almamalısınız.

Bir sonraki şeyi uygulamaya geldiğinizde - bir süre sonra - kod temeli (ve veritabanını ve her neyse) bu işlevselliği mümkün olduğu kadar düzenli ve şık bir şekilde uygulamak için gereken duruma getirmek için gereken adımları atarsınız. Bu yeniden düzenleme, bir proje geliştikçe doğal olarak ortaya çıkan karmaşa ile ilgilendiğiniz yerdir - ve umarım daha fazla karmaşa oluşturmaktan kaçının (veya en azından seviyeyi tutarlı tutun).

Buradaki tartışma alanlarından biri "Teknik Borç" - bir fazla ödeme yapmak gibi, geri ödemek zorundasınız ve ne kadar uzun süre bırakırsanız (bu durumda düzeltmek için gerekli olan zaman) tahakkuk edeceksiniz - bu size iyi bir sonuç veriyor teknik borçları en aza indirerek zamanınızın bir kısmını harcama argümanı.

Bu aynı zamanda, birim testlerinin ve diğer otomatik testlerin gelmeye başladığı yerdir (eğer yapabileceğimden emin olduğumu söylersem daha mutlu bir insan olacağım!), Uygun bir derleme sunucusuyla (en azından bazılarını çalıştırabilir) senin testlerin). Bunlarla birlikte - ancak kendi başlarına değerli - bağımlılık enjeksiyonu ve kontrolün tersine çevrilmesi gibi kalıplardır (bu ikisinin ne kadar “aynı” olduklarından asla emin değillerdir) çünkü sıhhi tesisatın değiştirilmesini kolaylaştırırlar ve bu nedenle de izolasyon.

Son olarak - unutma, kırılmadıysa tamir etmeyin. Kodunuzu yalnızca düzenleme amacıyla düzenlemek, tatmin edici olabilir , ancak hatalar ortaya koyma fırsatı da olabilir; bu nedenle, değiştirmek zorunda kalmazsanız ve bazı değişiklikler yapmazsanız acı verici olabilir. tek başına - düzeltme veya değiştirme fırsatı nihayetinde dönecektir!

1) Uygun değişim kontrolü arkadaşınızdır

Müşteri iyi olan spesifikasyonu değiştirirse, bu onun hakkıdır, ancak bu bir değişikliktir ve bunun için (veya proje yapısına / ilişkisine ne şekilde uygun olursa olsun maliyetlendirilir) ücretlendirilmelidir.

Bu değişimin tahmini gerekli yeniden yapılanmanın maliyetini içermelidir . Müşteri, maliyeti yüksek göründüğü kadar iyi olabilir, ancak bu noktada ona kodun zaten yarıdan yazıldığı için gelecekte sağlam ve desteklenebilir olmasını sağlamak için yeniden yazılması gereken unsurlar olduğunu açıklamanız gerekir. Yapılmamışsa, gelecekteki destekle ilgili sorunları aşması ya da daha da pahalı hale gelmesiyle ilgili problemleri olması muhtemeldir.

2) Müşteriye Gerçek Uzun Vadeli Fayda Sağlayacak Şekilde Yeniden Yapılanma Yapılmalıdır.

Yeniden düzenlemeyi düşünürken, gerçekte neyin gerekli olduğunu ve neyin önemli olduğunu düşünmeniz gerekir ve yeniden yapılandırma çalışmasının para için gerçek uzun vadeli bir değer sağladığından emin olun.

Sonuçta, bunları yapmalıyız, böylece müşterinin yatırımının teorik mükemmellik için herhangi bir itici güçten ziyade geçerli kalmasını sağlamak için kod orta / uzun vadede genişletilebilir ve desteklenebilir kalır. Yeniden yapılanma çalışması (ve buna karşılık gelen tahminler) bununla birlikte kapsam dahilinde yapılmalı ve sadece bunu yapmanın biraz daha iyi bir yolu olabileceğini düşündüğünüz için değil.

Bazı programcılar, müşterileri ile bu sorunu kontrol etmenin bir yolunu, müşterinin başlangıç ​​şartnamesini imzalayıp onaylamak olduğunu öne sürmektedir. Daha sonra, ilk spesifikasyonda bulunmayan bir gereksinim değişikliği talep ettikleri zaman, ek masrafları ve zaman gecikmelerini hesaplamak için sözleşmeyi ve proje zaman çizelgesini gözden geçirmeniz gerektiğini söylüyorsunuz, ardından sözleşmeye bir ek yapmalısınız. Görünüşe göre müşterilerin yeni (öngörülemeyen) özellikler konusunda ısrar etmelerini önlemede harikalar yaratıyor.

Şu anda üzerinde çalışmakta olduğum bir kod tabanında şu yorumu yapıyorum:

/*
 * Every time I see this function, I want to take a shower.
 */

Tanımladığın durumu çok iyi biliyorum. Yaptığım şey, her şey yoluna girinceye kadar beklemek ve elimden gelenin en iyisini yapmaya çalışmak. O zamana kadar, muhtemelen piyasaya sürülecek bir şeyiniz olacak ve işleri temizlemek ve işleri biraz daha farklı bir şekilde uygulamak biraz zaman alabilir.

Tekrar tekrar çok sayıda küçük pisliği temizlemek için etrafta koşamazsınız. Bu sadece işinizi ve hayal kırıklığınızı üçe katlar. Daha büyük bir hale gelmesini bekleyin, ancak neredeyse hiç hareket etmeyen karmaşa ve sonra bunun hakkında bir şeyler yapabilirsiniz.

Tercihim bu durumu en başta önlemek.

Tüm özellikleri NASIL okuduğunuza bağlı. Onları taş tabletler olarak düşünmek kolaydır, ancak gerçekte çoğu özellik değişir. Kodunuzu tasarlarken, spesifikasyonun her bir parçasının değişme ihtimalinin ne olduğuna bir göz atın. Zamanla, bunu tahmin etmekte oldukça başarılı olacaksın.

Dağınıklık, tecrübe ve yargıya girmek çok önemlidir. Bu spagetti kodu yüzünden yeni böcek mi yazıyorsun? uygulamak daha mı uzun sürüyor? bunlar taktiksel bir refactöre işaret eder.

gelecek için, müşterinizle ortaklaşa çalışmanız gerektiği gibi geliyor. Onlara göre, "bu ürünün orijinal özelliklerin ötesinde genişlediğine bakın. Orijinal tasarım o seviye için iyiyken, X yönünde ve yöne doğru genişleyerek Y'nin tasarımda bir miktar yeniden yapılandırmaya ihtiyacı var" iyi idare edildi ve hatta Müşteri bunun için ödeme yapacak.

Saate göre ücretlendirme ve değişiklik yapılması isteniyorsa bunun doğru olduğunu söyleyin, ancak denklemi iyi bir kod yazmak için gereken zamanı ekleyin. Ayrıca düzenli kod yazmanın, bakımını yapmanız gerektiğinde uzun vadede ödeme yaptığını unutmayın. Şimdi zaman kazanmak size daha sonra mal olabilir.

Bence yazilimin isletme ihtiyaçlari ile el ele gitmesi gerekiyor. Eğer atılabilir bir proje ise (her hafta yeni girdilerin gelmesiyle birlikte bir haftada yapılması gereken bir prototip gibi), o zaman kodun korunumu ve diğer şeyler için endişelenmenize gerek yok - zaman çok önemlidir ve kodunuzu olabildiğince hızlı bir şekilde kapıdan dışarı itin.

Ancak, uzun vadeli bir uygulama yazıyorsanız, tüm bunları dikkate almak mantıklıdır, çünkü yeni özellikler geliştirmenin, mevcut hataları düzeltmenin, diğer uygulamalara ve diğer şeylerle bütünleşmenin ne kadar uzun sürdüğü üzerinde oldukça büyük bir etkisi vardır. Bu, iş etkisine dönüşüyor (daha sonra ihtiyaç duyulan daha fazla zaman ve daha fazla maliyet nedeniyle).

Bu yüzden, karar vericiyi, gerektiğinde kodları yeniden düzenlememenin gerçek maliyetlerine hassaslaştırmak daha iyidir - benim tecrübeme göre, her iki seçeneğin de maliyetleri ve zaman etkisi, karar sahibine ölçülebilir şekilde açıklanırsa, karar, beyinsiz. İnsanların size 'evet iki kat daha uzun sürse ve bana fazladan bir fayda sağlamazken bile güzel kodlar yazmalarını' söylemelerini beklemeyin. Sadece bu şekilde çalışmıyor.

Bunu sürecinizin bir parçası haline getirin, ben "aşırı refactoring" diyorum ve büyük olacak! ;) Sadece hızlı bir şekilde bir şeyler yapın ve skar dokusu olduğu için yeterince yeni özellik eklendiğinde, yeniden düzenleyin. Sürekli kendinize "Şimdi sıfırdan başlasaydım, nasıl yapardım" diye sorun.

Önünde her şeyi tasarlayabileceklerini ve düşünebileceklerini düşünen insanlar çoğunlukla kendilerini kandırıyorlar, siz (ve müşteriniz) her zaman ilerlerken bir şeyler öğreniyorsunuz. Bu dersleri kullan.

Sizler iyi bir programcı olduğunuz için oldukça hızlı bir şekilde yeniden yönlendirebileceksiniz ve sürekli olarak yaptığınız gibi, kod "uygun şekli" almaya başlayacak, yani daha az bağımlılıkla daha esnek hale gelecektir.

İstemcileri, "işleri boşa harcayarak" "boşa harcadığınızı" bildiklerini bilmeleri halinde, bu yüzden sormama / anlatmama ve bu konuda gerçekten hızlı olmanıza yardımcı olabilir.

Bu şekilde geliştirilen kod, sonunda zamandan tasarruf etmenizi sağlayacak ve yeni özellikler eklemenizi giderek daha kolay hale getirecektir.

Ayrıca, kötü kodlamanın en büyük nedenlerinden birinin, bazı programcıların daha büyük yapısal yeniden düzenlemeler yapma korkusu olduğunu ve ne kadar uzun süre beklediğini daha fazla beklediğini söyleyebilirim.

Daha Fazla Güce Güvenin

Dua etmek istemem. Demek istediğim, sen ve müşteri arasında doyabilecek bir iş adamı (yani proje yöneticisi veya eşdeğeri) olduğundan emin ol. Eğer müşteri çok fazla şey talep ediyorsa, iş adamının ayaklarını yere koymasına izin verin ve “mümkün” ancak şartnameye uygun olup olmadığından emin değilim, bakınız [iş adamı] ”.

Normal bir proje akışında, genel bir gelişme, ciddi gelişme gerçekleşmeden önce dondurulmalıdır.

Birçok müşteri, izin verdiğiniz sürece değişiklikler / iyileştirmeler / geliştirmeler için araba kullanmaya devam edecektir. Birçoğu bu kabiliyeti kötüye kullanacaktır çünkü paralarını en iyi şekilde alıyorlar (projenizi sabote etse bile).

Şartnameyi erken mükemmelleştirmek ve dondurmak ve daha sonra uygulamak için görevli birini bulun.

Müşteri ile iyi bir karma için biraz fazladan bir şey yapmanın yanlış bir tarafı yoktur, ancak ellerinden alındığında daha yüksek bir gücü ertelemeye hazır olun. Eğer şartname çok miktarda değişiklik gerektiriyorsa, belki iş döngüsünden geri dönme ve sözleşmeyi yeniden değerlendirme ve / veya sözleşmeye ilaveler ekleme (adil parasal tazminatla) zamanı gelmiştir.

Bu sorunu yaşıyor olmanız, kodlama şeklinizle çok az ilgili. Bu, proje yöneticinizin projede yetersiz kullanıldığının bir işareti (sizin suçunuz, onun hatası veya her ikisi de olabilir).

Diğerlerinin birçok cevabında söylediği gibi, herhangi bir projede beklenmedik durumlar için bir zaman tamponu eklemek de gereklidir, ancak şartname donmuş ve müşteriye PM tarafından müşteriye teslim edilmeden önce kapalı kapılar ardında karar verilmesi gerekir.

İlk uygun tasarım sorunun önlenmesine yardımcı olamaz. Ve gelecekteki tüm "belki" gereklilikleri değerlendirmek neredeyse imkansızdır (veya çok çok zor). Yani bir süre sonra Büyük Yeniden Faktoring gelecektir. Ve en iyi çözüm, her şeyi yeniden yazmaktır.

Birkaç kelimeyle: kırmızı Ferrari'ye taret takmak yerine, gereksinimleri tekrar düşünün ve bir tank oluşturun.

Ateşle öldür.

Aka refactor en kısa sürede: örneğin çirkin bir kod son tarih için acele edildiğinde, son tarihten sonra yeniden refaktör olurum çünkü mevcut kod korunana kadar daha fazla özellik ekleyemezsiniz (veya en azından yapmamalısınız) gelecekteki kodlarda hata ayıklamayı bu kadar zorlaştıracak.

Mevcut durumu test eden projeleriniz için ünite testleri yazın ve zamanınız olduğunda yeniden toparlanın, böylece temizlemeye çalışırken projenizi bölmekten kaçının.

En basit cevap. Şu an istediği şey için kesin bir özelliği olana kadar her türlü kodlamayı keserdim.

Daha sonra, hangi özelliklerin şu anda olması gerektiğini ve daha sonra neler yapılabileceğini onaylamak için bu özellikler listesine öncelik vermeleri gerekir.

Her bir özelliğin zamanını / maliyetini belirlemek için deneyimlerinizi kullanın ve ardından bunu, isterlerse x zaman ve para alacağını söyleyin.

Büyük özellik kapsamındaki sürünme suçuyla başa çıkmanız, hiç bir şey yapılmayana ya da çok kötü bir şekilde yapılıncaya kadar sınırsızca özellik eklemeye devam edecekler.

Son bir listeye sahip olduklarında, tercih ettikleri gibi gelecekteki değişiklikler yapacağınızı, ancak şu anda sahip olmaları gereken ilk 15/20’e odaklanmaları gerektiğini söyleyin.

Daha sonra, tamamlanma zamanına göre, onlara söyleyin, bu yayınlandıktan sonra bir sonraki sürümü tartışmaya / beyin fırtınasına açık olacaksınız.

Mevcut sürüm için ne yapılması gerektiğine dair nihai bir karar verildikten sonra, tüm tartışmalar / fikirler / öneriler% 100 durdurulmalıdır.

Fikirlerini sonsuz bir şekilde alırsa, ona bir sonraki sürüm için kendi özellik listesinde yazmalarını söyleyin ve şu anda istedikleri en önemli özellikleri sağlamaya odaklanın.

Eğer zamanınızı boşa harcıyorlarsa fikrini değiştirmeye devam edin. Sonra sadece proje üzerinde çalışmayı bırakıp kararlarını verinceye kadar diğer projeler üzerinde çalışacağım.

Yapması zor, ancak özellik kapsamı sürünmesi zaman, enerji, motivasyon ve net düşünceyi çok fazla yıkıcı.

Bir projenin eksiksiz bakış açısından:

Ekibinizle birlikte koddan öğrenin, bir dahaki sefere neyin yenilenebileceğini ve yeniden kullanılabileceğini görün, sonra bir bira içmeye gidin.

Gelişimsel bir bakış açısıyla:

Gelişimin neden durduğunu sabırla açıklayın ve tüm özellikler masada görünene ve anlaşılmadıkça neden devam edemediğini açıklayın. O zaman git bir bira iç.

Bir planlama açısından:

Tüm özellikleri önceden isteyin ve geliştirme yolunu net bir şekilde anlamak için herkesle birlikte çalışın. Herkesin aynı sayfada olduğundan emin olmak için müşterileri / paydaşları mümkün olduğu kadar yakından dahil edin. O gecenin ilerleyen saatlerinde herkese bira ver. Yarın, projeye başla.