Kodumun büyük bir bölümünün büyük bir tasarım kusuru var. Bitirmek ya da şimdi düzeltmek mi? [kapalı]

Ben bir arkadaşımla bir C # projesinde çalışan benimle aynı beceri seviyesine sahip bir lise öğrencisiyim. Şimdiye kadar, 100 taahhütte yaklaşık 3.000 satır kod ve 250 satır test kodu yazdık. Okul yüzünden birkaç aylığına projeyi kapattım ve son zamanlarda tekrar geri alabildim.

Geri aldığımda, yazdığım kodun, işleyiciye aşırı iş parçacığı ekleme, öykünmüş CPU, GPU ve oyun kartuşu arasındaki etkileşimde yarış koşullarının zayıf önlenmesi gibi kötü tasarlandığını anladım. , ayrıca sadece gereksiz ve kafa karıştırıcı olan kod.

Sorun şu ki, programımın ana işlevselliğini bile tamamlamadım, bu yüzden gerçekten kırıcı olamıyorum ve kodumun tasarımının hatalı olduğunu tam anlamıyla fark etmekten vazgeçtiğimi hissediyorum. Aynı zamanda, projeyi terk etmek istemiyorum; önemli miktarda ilerleme kaydedilmiştir ve iş boşa gitmemelidir.

Birkaç seçeneğe sahip olduğumu hissediyorum: basit tasarımın işlevini zayıf tasarım etrafında çalışarak bitirmek ve daha sonra her şey çalıştıktan sonra yeniden yapılandırmak, her şeyi durdurmak ve işlevselliğin geri kalanı tamamlanmadan önce her şeyi çözmek için çalışmaya başlamak, projeye başlamak her şeyden önce, aklımda tekrar taze olması veya aşırı büyüklüğü nedeniyle (esas olarak "çizim tahtasına geri dönme" nedeniyle) projeyi terk etmekten tamamen vazgeçmek.

Başkalarının bu tür projelerdeki deneyimlerine dayanarak, kendimi doğru yola geri götürmenin kaynağı nedir? Bu sitedeki cevaplardan genel fikir birliği, yeniden yazmanın genellikle gereksiz olduğu, ancak kodun aşırı maliyet olmadan sürdürülemediği durumlarda mevcut bir seçenek olduğu yönündedir. Gerçekten bu projeyi sürdürmek isterim, ancak olduğu gibi, kodum devam etmem için yeterince tasarlanmamış ve umutsuzluk hissi beni devam etmekten alıkoyuyor.

Ayakkabının içinde olsaydım, muhtemelen şu şekilde denerdim:

• ilk önce mevcut projeyi - en azından kısmen - mümkün olan en kısa sürede ancak çalışma durumunda bitirin . Muhtemelen orijinal hedeflerinizi azaltmanız gerekir, "sürüm 1.0" da görmeniz gereken asgari işlevselliği düşünün.

• o zaman ve sadece o zaman sıfırdan bir yeniden yazmayı düşünün (bu "sürüm 2.0" olarak adlandıralım). Belki V1.0'daki bazı kodları tekrar kullanabilirsiniz. Belki de durumun üzerinde tekrar uyuduktan sonra V1.0'ı yeniden ateşe verebilir ve çoğunu kurtarabilirsiniz. Ancak elinizde “V1.0 konseptinin kanıtı” bulunmadan bu kararı vermeyin.

"1.0" çalışan bir program, kodun kötü olduğu durumlarda bile (başkaları tarafından rahatsız edilmeyecek) bile, başkalarına gösterebileceğiniz bir şeydir. Eğer V2.0 yaratmanın ortasında zamanın tükenmekte olduğunu fark edersen, yine de kısmen başarı olarak V1.0'a sahip olursun, bu da moralin için çok daha iyi olur. Ancak, önce V1.0'ı tamamlamazsanız, V2.0'ı asla tamamlamamanız için büyük bir şans vardır, çünkü yarı yolda kaldığınızda, tasarımdan tekrar memnun kalmamanız gereken bir nokta olacak ve sonra? V2.0'ı tekrar bırakıp V3.0'da çalışacak mısınız? Bu hiç bitmeyen bir çembere girme riski, asla sona ermeme riski vardır.

Bunu, bitmemiş bir durumda projeleri nasıl bırakacağınızı öğrenmek yerine, ara hedeflere nasıl ulaşacağınızı öğrenmek için bir fırsat olarak kabul edin.

Bitmiş BT projeleri, hatta hatalı olanlar, bitmemiş olanlardan çok daha iyidir.

Bitmemiş olanlar da size çok şey öğretebilir, fakat bitmiş olanlar kadar değil.

Şimdi göremeyebilirsiniz, ancak hatalı kodla bile çalışarak çok büyük bir değer elde edersiniz.

Oyum bitirme ve belki de yeniden düzenleme için de geçerli - gerekirse. Daha fazla projeyle çalışmaya başladığınızda, şaşırtıcı bir şekilde "yeniden kırılmak" anlamına gelen kısmın yıllarca el değmeden kaldığını ve diğer parçaların uzatıldığını göreceksiniz.

İstihdam açısından, çoğu durumda, bitmiş bir proje için daha fazla şeref alacaksınız.

Mutlu bir şekilde projeye başlardım.

Sen bir öğrencisin ve hala öğreniyorsun. Bu sizi bağlantı kurduğunuz sorudan çok farklı bir pozisyona getirir.

• Kodunuzla ilgili hiçbir profesyonel sorumluluğunuz yoktur; şu an tüm projeyi silip uzaklaşırsanız, herhangi bir sonuç almazsınız. Bu, geliştirici için büyük bir avantajdır. Bağlantınız olan soruda, bu geliştiriciler insanların parasını ödedikleri yazılımları korumaya çalışıyorlar ve küçük hatalar bile müşterilerle büyük sorunlara neden olabiliyor ve bu da sıfırdan yazmayı tehlikeli hale getiriyor. Bu sorunun yok.

• Kişisel bir proje olarak, yeni şeyler denemek ve hatalarınızdan ders almak için mükemmel bir fırsat. Eski kodunuzun sorunları olduğunu kabul etmeniz harika, çünkü bu daha iyisini nasıl yapacağınızı öğrendiniz. Deneme-yanılma deneyimleri, yeni başlayan programcılar için paha biçilmez olabilir.

• Projeniz nispeten küçük ve temelde testleriniz yok. Sıfırdan 3000 satır yazmak, özellikle bir dahaki sefere neyin daha iyi yapılması gerektiği konusunda fikirleriniz olduğundan, birkaç gece kısa olabilir.

• Bozuk bir kod tabanında çalışmak, moralinizdeki yeniden yazma işleminden çok daha büyük bir boşaltma olacaktır.

Bunun yanı sıra, birim testlerle daha modüler bir program yazmayı denemek için iyi bir şans olabilir. Bunu yapmak, uzun bir aradan sonra tekrar gelirseniz kodu anlamayı çok kolaylaştırır ve unutkanlık nedeniyle yanlışlıkla girebileceğiniz hataları önlemeye yardımcı olur.

Son olarak, burada daha büyük adımlar atmak için bazen geriye doğru adımlar atmanın bilgeliği üzerine bir görüş var.

Muhtemelen hala gelişiminizin "hızlı öğrenme" kısmındasınız. Bundan birkaç ay sonra, yeni ve harika tasarımınızın ne zaman başladığınızın bile farkında olmadığınız şekilde çok kırıldığını göreceksiniz.

İşleri bitirin - öğrenmeniz gereken en önemli şey budur. İnan bana, "bu projeye başlamadan önce çok şey öğrendiğimden beri en baştan başladım" döngüsüne sıkışmış birçok insan (sadece programcılar değil) biliyorum. Sorun asla bitmemesidir - siz yeni şeyler öğrenmeyi bırakana kadar, ki bu güzel bir yer değil :)

Ayrıca, bir şeyi gerçekten bitirebilmek için de önemlidir. Baştan başlamak heyecan verici, harika, eğlenceli ... ama bunu yalnızca öğrenirseniz, hiçbir şeyi bitiremezsiniz. Yine, bu çok kullanışlı bir yetenek değil ve aslında yararlı bir şey (veya eğlenceli) yapmak kadar iyi hissetmiyor. Hayat kısa, zaman sınırlı ve somut sonuçlarla pratik yapmaya devam edemezsiniz - bundan çok kızacaksınız. Çalışmaya başlayamayacağınızı düşünüyorsanız, çünkü hangi yaklaşımı uygulayacağınıza karar veremezsiniz, zaten tehlike bölgesinde bulunuyorsunuz.

Her zaman baştan başlamak için dürtü olacaktır. Bir öğrenme ortamında bile, bunlar muhtemelen kötü bir fikirdir. Bu, her bir prototipi üretime hazır bir uygulamaya, ondan uzak tutmanız gerektiği anlamına gelmez. Ancak, en azından çalışan bir prototip aşamasına geçmeniz gerekiyor - bu muhtemelen moralinize yardımcı olacaktır ve bu, herhangi bir geliştirici için çok faydalı bir özelliktir. İşleri hallet . İşin eğlenceli yanı, prototipinizle yapabileceğiniz, milyonlarca daha eğlenceli ya da faydalı şeylerin hızlı bir şekilde olduğunu göreceksiniz, "sıfırdan yeniden yazmak" yerine - ve çoğu zaman yeniden düzenleyerek. Yaptığın her şeyin bir bedeli var - en azından bu arada başka bir şey yapmış olabilirsin.

Yazılım geliştirmedeki "İş Yap, Doğru Yap, Hızlı Yap" ideolojisini takip ediyorum .

1. Çalışmasını Sağlayın : Projenin kullanılabilir olması için temel işlevleri yazın. Çirkin kod anlamına gelse bile her şeyin çalışması için yapmanız gerekenleri yapın.
2. Doğru Yapın : Okumak, anlamak ve bakımı daha kolay olacak şekilde hataları düzeltin ve kodu yeniden düzenleyin.
3. Hızlı Yapın : Hız, kaynak kullanımı ve sürdürülebilirlik arasında iyi bir denge kurmayı hedefleyerek programı optimize edin.

Şu anda, 1. adımı tamamlamadınız. Önce çalışmasını sağlayın, ardından kodunuzun ne kadar çirkin olduğu konusunda endişelenebilirsiniz. Aslında çalışan bir ürün oluşturmak, yeni geliştiricilerin yapması en zor şeylerden biridir, çünkü kodlarını ilk seferinde mükemmelleştirmeye çalışırken çok sarılırlar ve böylece Optimizasyon Cehennemi sıkışıp kalmazlar ve asla bitirme işine giremezler. tüm özelliklerin uygulanması. Yeniden yapılanma ve optimizasyonla ilgili tüm bu endişeleri bir kenara bırakmayı öğrenmeniz gerekir, böylece yazılımı işe koymaya odaklanabilirsiniz. Biraz daha tecrübe edindikten sonra, ilk defa doğal olarak daha fazla şey yapacaksınız, bu nedenle daha az yeniden düzenleme yapmak gerekiyor.

Akılda tutunuz: erken optimizasyon tüm kötülüklerin köküdür ( bu mükemmel Programcılar bölümüne bakınız . İyi bir tartışma için soru ). Kodunuzu nasıl daha iyi hale getireceğinizi düşünmek için çok zaman harcıyorsanız, analiz felsefesinde sıkışıp kalıyorsunuz . Bu projeyi öldürür. En iyi duruma getirmeye çalışmadan önce projeyi tamamlamanız daha iyi olur.

Harika bir motivasyonel konuşmacıdan alıntı yapmak için : sadece yapın .

Her zamanki gibi, ilgili bir xkcd var:

Yeniden yaz. Çalışmayan kodun değeri çok az ve üç bin satır çok fazla kod değil. Halihazırda sahip olduğunuz kodu yazmak için harcadığınız süre kadar sürmez ve çok daha iyi olur. Sık sık beş yüz veya bin satırlık kötü kod atmıştım ve yeniden yazma çoğu zaman beşte birdir.

"Yeniden yazma" konusundaki kavramların çoğu, önemli şeyleri yapan ve gelişen gereksinimleri karşılamak için sürekli değişiklikler geçiren büyük sistemlerle ilgilidir. Kullanımdaki karmaşık sistemlerin yeniden yazılması nadiren başarılı oluyor.

Durumun tam tersi. Kullanıcı içermeyen küçük bir uygulamanız var ve tek gereklilik, uygulamayı seçmeniz gerekenler. Öyleyse devam et ve tekrar yaz.

Sıfırdan yeniden başlatmak, genellikle gerçek hayat projelerindeki kötü bir hamledir, çünkü gerçek hayattaki projeler, yeni bir geliştiricinin farkında olmadığı hata düzeltmelerini sağlar (örneğin, bkz . Joel'in Yazılım blogundan Yapmanız Gerekenler bölümüne bakın ).

Bununla birlikte, okul projeleri böyle bir tarihi miras almazlar ve genellikle hesaplama ve deneyim eksikliğinin kısmi bilgisi ile aynı anda kodlama ve tasarım yaparak başlarlar. İlk versiyonunuzu başarısız olmuş bir kavramın kanıtı olarak kullanılan bir prototip olarak kabul ederdim ve mutlu bir şekilde çöpe atarım ( Atılmaya karşı evrimsel prototipleme üzerine bir tartışma için bkz. Atılabilir ve evrimsel prototipler arasındaki farklar nelerdir? )

Doğru tasarım kafanızda olgunlaştı ve kodu yazmak için fazla zaman harcamamalı.

Yeniden yazmanın kötü bir fikir olduğuna dair önerilere saygıyla katılmıyorum.

Yazılım yaşam döngüsü alanında, bir hatayı düzeltmek için gereken zamanın ve çabanın yaşam döngüsündeki her katın büyüklüğüne göre arttığı kabul edilir. Diğer bir deyişle, gereksinim düzeyinde bir hatayı düzeltmek 1 saat sürerse, tasarımda 10 saat, kodlama testinde 100 saat ve hata düzeltmesi olarak 1000 saat sürecektir. Bu sayılar çirkin görünebilir, ancak bunlar yaklaşık olarak doğru olduğu kabul edilir. Açıkçası, daha küçük bir projede daha az, ancak genel fikir kalır. Projenizin temel bir tasarım kusuru varsa, o zaman bir öğrenme deneyimi denemek ve geri dönmek, başlangıç ​​gereksinimlerinizi gözden geçirmek ve yeniden tasarlamak daha uygundur.

Yapılandırılmış ünite testleri kullanarak Test Odaklı Gelişme modeli düşünmeyi de teşvik ederim. Acı vericidirler ve başlangıçta zaman kaybı gibi görünürler, ancak özellikle başkasının koduyla bütünleşirken hataları çözme yetenekleri fazlaca belirtilemez.

Beni bu cümleyle kaybettiniz:

Sorun şu ki, programımın ana işlevselliğini bile tamamlamadım, bu yüzden gerçekten kırıcı olamıyorum ve kodumun tasarımının hatalı olduğunu tam anlamıyla fark etmekten vazgeçtiğimi hissediyorum.

( Systemantics'te belirtilen ) ilkesine inanıyorum.

• Çalışan karmaşık bir sistemin her zaman çalışan basit bir sistemden evrimleştiği bulunmuştur.
• 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.

Yani, karmaşık bir sistem yazma içerir

• Basit bir sistem yazmak
• İşe yaradığından emin olmak

... yani aşağıdaki adımlar:

1. Biraz kod yaz
2. Çalıştığından emin olmak için test edin
3. Biraz daha kod yaz
4. Tekrar test et
5. Vb.

3. adımın şunları içerebileceğini unutmayın:

3. Biraz daha kod yaz
   1. Refactor var olan kodu yeni eklemeye hazırlamak için
   2. Hala çalıştığından emin olmak için refactoring'i test edin
   3. Yeni işlevler ekle

Ayrıca, Adım 2 "Çalışmasını sağlamak için sınayın" yoksa, yeniden yazmayı da içerebilir.

Eğer çürümüş bir kod temelini oluşturuyor olsaydım, daha fazla işlevsellik eklemek için mahrum kalırdım. Bu yüzden, uygulanacak bir sonraki çalışma parçası olarak “mevcut iş parçacığı uygulamasını basitleştirmek” gibi bir şey planlamaya meyilliyim. Devam ederken test yaptığınızı varsayarsak, bunu yeniden yapılanma alıştırması olarak görebilmelisiniz. Bu çalışma aşaması için başarı / çıkış kriterleri şöyle olacaktır:

• Kaynak kodu daha basittir
• Ve hiçbir yeni böcek ortaya çıkmadı
• (Ve bazı eski böcekler yok edildi)

Bu arada, "çalıştığından emin olmak için test etmek" mutlaka "birim testleri" anlamına gelmez - ekip yapısı basit olduğunda (basit) sistem testlerini kullanarak (basit) sistem testlerini test edebilirsiniz .

Böyle bir sorunla karşılaştığınızda karşılaştığınız sorunlardan biri, şu ana kadar bir şekilde veya başka bir şekilde yazmış olduğunuz koda duygusal olarak bağlı olmanızdır.

Bir meslektaşım üniversitede bir ünlü profesörden ders alırken bir program yazdığını söyledi (Dijkstra olduğuna inanıyorum). Profesörden bir aydan uzun süredir üzerinde çalıştığı kodlara bakmasını istedi. Profesör, yedek olup olmadığını sordu, hayır cevabını verdi. Profesör daha sonra kodunun tamamını silmiş ve tekrar yazmasını söyledi.

Sinirliydi, ancak 3 gün sonra programı daha temiz kod ve daha az hata ve daha az kod satırı ile tamamladı.

Proje için uygun olan zamanda hangi seçeneğin en iyi olduğuna dair dürüst bir tahmin yapmaya çalışın.

3 seçenek

• Sil (tamamen, geriye bakmadan)
• Eski tasarımda çalışmaya devam et
• Siz giderken refactor kodu.

10 yıldan fazla bir süredir profesyonel bir programcı olarak çalışıyorum ve çalışma alanımda son seçeneğin seçildiği zamanların çoğu olduğu sonucuna vardım, ancak her zaman en iyi seçenek değil.

Becerileriniz o dönemde büyük ölçüde artmış gibi görünüyor. Belki de bu proje üzerinde çalışmak buna katkıda bulundu. Bunu tekrar kullanımlık bir öğrenme deneyimi olarak tasarlamak verimli olacaktır.

Unutmayın, bu bir müşteri için çalışma programı olarak sunmanız gereken bir şey değil. Uygulama için özel olarak yazılmıştır. Bu nedenle, nakliye sorunları ve hatalı teslimat konusunda pratik yapmak istemiyorsanız, şu an "tasarım kaslarınızı" çalışmanın verimli olacağı bir gelişim aşamasındasınız.

Bunu yaparken, tasarım sürecine ve planlamaya odaklanın ve mevcut öğelerinizi etkileyin ve neleri daha iyi anladığınızı düşünün.

Elden Geçirme. Elden Geçirme. Refactor! Planı ayrı !!!!

Dürüst olmak gerekirse, bu ne kadar deneyimli olursanız olun, ortak bir sorundur. Kod yazdın, bir şey öğrendin ve yeni bilgiyi eski kodda kullanmak istiyorsun. Eski kodu yeni bilgiye karşı ölçmek istersiniz.

Bu işe yaramayacak. Bunu yaparsanız, uygulama / oyun asla bitmeyecek. Bunun yerine, zamanınızı projeye ayırmaya çalışın, böylece "görevlerinizin" bir kısmı hatalı kodu düzeltmek için. Örneğin, oyunu kurtarmak için korkunç bir yönteminiz olduğunu varsayalım. Oyunun kendisi üzerinde çalışmaya devam edin, ancak bu korkunç yöntemi yeniden canlandırmak için bir süre bulun. Refactors küçük tutmaya çalışın ve bu bir sorun olmamalıdır.

Bir refactor gerektiren uygulamanın büyük bir kısmına ulaştığınızda, yanlış bir şekilde yapıyorsunuz demektir. Refactoring'i daha küçük parçalara ayırın. Yedi saat kod yazarak ve bir saat yeniden sınıflandırma yapmaya çalışın.

Projeyle işiniz bittiğinde ve özellik donma noktasına geldiğinizde, o zaman yeniden canlandırma için büyük bir zaman harcayabilirsiniz. Şimdilik, oyunu bitirin ama yine de bazılarını düzeltmeye çalışın. Yapabileceğin en iyi şey bu.

Her zaman refactor için bir şey olacak.

Şu anda ne tür bir şifreniz olduğuna ve sorunların tam olarak nerede yattığına bağlı olarak biraz söyleyebilirim. Yani, temelleriniz iyi ise (çoğu yerde uygun sınıf tasarım, iyi ayrılma / uyum vb., Sadece bahsettiğiniz dişler gibi birkaç kötü seçenek), o zaman elbette çıplak kemikler 1.0 çıkarıp yeniden ateş düşürücü olsun yarın yok

Öte yandan, eğer derleyiciden bir şekilde çirkin tokatlanmış metin dosyalarının bir kısmı derleyiciden geçerse, ayırt edilebilir bir yapıya sahip değilse (başka bir deyişle, iş başında öğrenme prototipinin bir kavram kanıtı), sonra silmeyi ve baştan başlamayı tercih ederim.

Bir sonraki sürümünüzde çevik bir yaklaşım sergileyin: kendinize sabit bir yinelenen zaman çizelgesi ayarlayın, 2 hafta veya programınıza uygun olanı seçin. Her bir yığının başında (hadi sprint diyelim), 2 hafta içinde ulaşılabilecek hedefler belirleyin. Devam et ve yap, çalışmasını sağlamak için elinden geleni yap. Hedeflerinizi belirleyin, böylece her 2 haftada bir, sadece bazı soyut içsel çalışmalarda değil, bir arkadaşınıza gösterilebilecek bir şeye sahip olun. Google "scrum" ve "akıllı hedef". Bunu yapmak çok kolaydır, eğer yalnızsanız, birkaç hızlı not alan mermi noktasına sahip sadece bir kağıt parçası.

Bunu yapabilirseniz, baştan başlamak iyidir. Eğer derinlemesine başlıyorsanız, baştan başladıysanız, şu anda bulunduğunuz yerde, muhtemelen kodunuza sadık kalarak çalışmasını sağlayabilirsiniz.

Kendinizi işverenlerin ayakkabılarına koymak zorundasınız.

İşverenlerin çoğu için, bu şekilde giderseniz en değerli olacaksınız: - Yazdığınız yeni kod üzerinde% 100 testle bitirin. - Eski (kötü tasarlanmış) kod için testler ekleyin. - Bir tasarım olarak ne istediğinizi elde etmek için refactor.

Bunların hepsini iyi bir versiyonlama süreci, dallar ve etiketlerle yapın.

Yeniden yazma genellikle seksi bir fikirdir, ancak çoğu zaman yeni gelenlerin gerçek hayatta tehlikeli olduğu bir fikirdir. Daha önce yaptığınız işin kalitesini arttırmaya daha istekli olduğunuzu göstermek yerine, sıfırdan başlamanız ciddi bir insan olduğunuzu gösteren iyi bir işarettir.

Açıkçası yine de yeniden yazabilirsiniz, ancak o zaman başka bir proje yapın.

Sadece geçmiş tecrübelerimin bir kısmını karışıma eklemek için. Birkaç yıldan beri yedek bir projede çalışıyorum bir yıldan fazla bir süredir. Bu proje basit bir test odasından statik bir sınıfa, şu anda olduğu bir nesne yönelimli ince çizgili tasarıma geçti.

Tüm bu değişiklikler boyunca, hata düzeltmeleri ve performans avantajları (kodun mümkün olduğu kadar hızlı olması gerekir) hariç, kodun aynı işlevselliğini korudum. Yeniden yapılandırılmış olmasına rağmen aynı kod tabanı aynı kaldı ve bu yüzden kodu sıfırdan ve atık zamandan yeniden yazmak zorunda kalmadan kitlesel olarak geliştirdim.

Bu, kodu daha önce yapabileceğimden daha hızlı bir şekilde geliştirebileceğim anlamına geliyordu. Ayrıca, neyin çıkarılması gerektiğini, yani gereksiz sınıfları ve hala aklımdaki eski fikirle yeniden yazmaktan daha kolay ne kalacağını söylemek kolaylaştığım anlamına geliyordu.

Bu nedenle benim tavsiyem, kodunuzu yeniden gözden geçirmek ve oradan devam etmek ve gerektiğinde iyileştirmeler yapmak olacaktır. Sıfırdan yeniden yazmaya karar verirseniz, eski projenin iyi fikirlerini almalı ve nerede kusurlu olduklarını görmek için onlara yakından bakmalısınız. Yani sadece eski kodu yeni projeye kopyalamayın.

Cevap, "karmaşıklık tavanı" olarak adlandırmayı sevdiğim bir şeye dayanıyor. Bir kod tabanına gittikçe daha fazla ekledikçe, daha karmaşık, daha az ve daha az organize olma eğilimi vardır. Bir noktada, ilerideki ilerlemenin çok zorlaştığı bir “karmaşıklık tavanına” çarpacaksınız. Kaba kuvvet ile hareket etmeye devam etmek yerine, yedekleme yapmak, yeniden düzenlemek / yeniden yazmak ve daha sonra ilerlemeye devam etmek daha iyidir.

Kod tabanınız o kadar kötü mü, karmaşıklık tavanına yaklaşıyor musunuz? Bunun olduğunu düşünüyorsanız, devam etmeden önce temizlemek ve basitleştirmek için biraz zaman ayırın. Temizlemenin en kolay yolu bazı parçaları yeniden yazmaksa, sorun değil.

Ne? Her ikisi de?

Devam edin, mevcut tasarımı gözden geçirmek ve biraz da yeni işlevler eklemek için biraz zaman ayırın.

Açık saçık etkileşimleriniz varsa, başlamak için iyi bir yer olabilir ("işleyicide aşırı iş parçacığı", doğruluk sorunlarına neden olacak bir şey yerine verimsizliğe benziyor). Bakın ya yarışlardan (ve muhtemelen çıkmazlardan) kurtulmanın genel bir yolunu ya da en azından bunu yapmanın birden çok özel yolunu bulabilecek misiniz?

Kilitlenme ve yarış dedektörleri gibi şeylerin C # için ne kadar uygun olduğunu bilmiyorum, ancak varsa, hangi problemlerin olduğunu ve düzeltmelerinizin işe yaradığını doğrulamakta yararlı olabilirler.

Genel olarak, yararlı bir şey yapan kodla ilgili sorunları çözmek için baştan atmaktan ve yeniden baştan başlamaktan daha motive olduğumu biliyorum. Kavurucu alanın (yeşil alan ve kahverengi alanla benzer şekilde) gelişiminin daha tatmin edici olduğu durumlar vardır, ancak bu genellikle mevcut yaklaşımın artık yanlış olmaması gerektiği yerden çıkması gereken şeyler içindir.

Kodunuz modüler ise, kodun geri kalanını kötü yazılmış bileşenlerin etrafından bitirebilmeniz gerekir, ardından kötü yazılmış kısımları kodun geri kalan kısmını etkilemeden yeniden yazabilirsiniz.

Bu durumda, kötü yazılmış bileşenleri yeniden yazdığınızda size bağlıdır. Hatalı yazılmış bileşenler o kadar kötü yazılmışsa, bitmiş kod onlarla aynı şekilde çalışmazsa, kodun geri kalanını bitirmeden önce bunları yeniden yazmanız gerekir.

Kendinize sormanız gereken ilk soru "kusur ne kadar kötü?"

Tam olarak ne yanlış yaptın?

Bir şey o kadar kötüyse, sorunla çalışmaya çalışmakla tonlarca saati harcayacak, hassas verileri (şifreler / kredi kartları) ortaya çıkaracak veya kötü bir kırılganlığa neden olacaksa, o zaman belki düzeltmelisiniz, ancak çoğu zaman sahip olduklarınızı alın, tamamlayın ve sorunu daha sonra düzeltin.

Programcılar, uygulamalarını geliştirmeyi çok isterler, “olabilecekleri en iyi” olmalarını isterler ancak bu doğru bir yaklaşım değildir.

Uygulamanızı mümkün olan en kısa sürede yayınlarsanız,% 100 olmasa bile, herkese hata verir, sonra sürüm 1.1 için hataları ve diğer şeyleri düzeltmek için zaman ayırırken diğerlerinden FEEDBACK elde edersiniz . Diğer insanlar uygulamayı daha iyi hale getirmenize yardımcı olabilir ve insanların beğenmeyeceği bir şeyi yapmakla zaman kaybetmiş olabilirsiniz.

Yani, sizin durumunuzda, oradan çıkarın, biraz geri bildirim alın ve ardından sürüm 2.0'ı tüm değişikliklerle yapılandırabilir ve sahip olduğunuz açığı düzeltebilirsiniz.

Hatırlanması gereken bir başka şey de sürekli gelişmekte olduğumuzdur. Bir yıl öncesinden kodunuza bakıp, bunun kötü olduğunu görüyorsanız, bu hala gelişmekte olduğunuz anlamına gelir ve bu harika bir şey.

Kodunuzun ne kadar karışık olduğuna bağlı.

• Kodunuzu aşırı karmaşık veya ayrıntılı hale getiren gerçek n00b hataları yaptıysanız, bu kısımları yeniden yazmanızı öneririm.

• Yine de düzeltmeniz gereken ciddi hatalarınız olduğunu düşünüyorsanız, hatayı düzeltip düzeltmeyeceğinizi kontrol edebilecek bazı testler yazın (... çünkü programı henüz başlatamazsınız). Hataların erken düzeltilmesi ve kodun ne yaptığını hala hatırlarken hataların giderilmesi kesinlikle daha iyidir.

• Hangi yöntemlerin adlandırıldığını, hangi sınıfa ait olduklarını veya bunun gibi küçük şeyleri sevmiyorsanız, IDE'yi kullanın. (Unutmayın, bu C #, bazı javascript, python, perl, php, vb. Değildir) Sonra IDE'niz ağrısız hale getirirse yeniden ateş düşürücüdür.

Aksi takdirde çalışmasını sağlayın ve bir sonraki projede becerilerinizi geliştirin.

Başkalarının önerdiği gibi, bu kişisel bir proje olduğu için (henüz) profesyonel bir proje değil, ciddiyetle yeniden yazmayı düşünürdüm.

Ancak, bir deney yaparak, buradaki bilimsel yöntemi kullanabilirsiniz. İlk önce bir hipotezi düşünün. Benimki, "muhtemelen yeniden yazma vakti geldi." Zamandan tasarruf etmek için, başarısızlık maliyetini düşürün ve daha önce programlama yapmadan önce priori yanlılığı sınırlandırın, bir süre daha ("zaman kutusu") karar verin. Belki duvar saati olarak 4 saat önerebilirim. Ayrıca hipotezi değerlendirmek için bir metodolojiye karar verin. Bahisler düşük olduğu için bir metodoloji olarak önerebilirim, basitçe kendinize sorun: "Bunu yaptığım için mutlu muyum?" Şimdi deneye başlayın. Seçtiğiniz zaman kutusundan sonra, hipotezin değerlendirilmesi nedir? Örneğin, benim örneğimden, 4 saat boyunca harcadığınız için tekrar yazmaya başladığınıza memnun musunuz? O zaman muhtemelen doğru seçim.

Dünyadaki tüm önerileri isteyebilirsiniz, ancak ampirik olarak bir hipotezi test etmek gibisi yoktur.

Denemeniz olarak yeniden yazma seçimini düşünmeniz için birkaç neden:

• Deneyimlerime göre, genellikle daha eğlenceli. Yeniden yazmanın profesyonel durumlarda sıklıkla seçilmemesinin büyük bir nedeni, eğlencenin tek kriter olmaktan uzak olmasıdır. Ancak kodlama konusunda hala göreceli olarak yenisiniz, bu yüzden eğlence muhtemelen oldukça önemli bir kriterdir ve bu erken aşamada sizin için somut olabilecek diğer faktörlerin bir göstergesidir (eğlence, daha fazlasını öğrenmenizi önerir, vb.).
• Deneyiminiz ve muhtemelen sürükleyici bir vicdan anlayışı size bir yeniden yazmanın dikkate değer bir şey olduğunu söylüyor gibi görünüyor. Varsa o sesi dinleyin. Bu tavsiyeye uymasan bile tavsiye, en azından dinle. Gelecekte daha dış sesler olacak ve kendi mantığınızı dinleme pratiğine ihtiyacınız var.
• Bir yeniden yazmayla şüpheliyim, kodunu daha fazla modüle etme ihtimalin daha yüksek. Modüller oluşturduğunuzda, diğer projeler için kullanabileceğiniz daha yeniden kullanılabilir ve güvenilir bileşenlere sahipsiniz. Sonunda, ana projenizin sadece bir modülüne benzeyen şeyin yazdığınız en ilginç ve değerli kod parçası olduğunu bile görebilirsiniz.

Bir şeyi bitirmek iyi bir fikirdir, ancak bir boşlukta değil. Yeniden yazmaya başlarsanız, belirli bir alt modülü bitirerek bir şeyi bitirmeyi seçebilirsiniz. Yukarıdaki deneyden sonra bunu ilk hedef olarak belirleyebilirsiniz. Bitirme, henüz ana projenizi bitirmek anlamına gelmez. Bir modülü tamamladıktan sonra, bir başkasını vb. Tamamlayın, isterseniz kapsamın tamamını orijinal projenizi yeniden yazmayı tamamlayana kadar.