Hızlı ve kirli programcılar doğru yaptıklarını nereden biliyorlar?

Programcılara neden temiz kod yazmaları gerektiğini sorarsanız, aldığınız bir numaralı cevap bakımdır. Listemde, ana nedenim daha acil ve daha az özgecil: Yeni kodumun çok kirli olup olmadığını doğru söyleyemem. Bireysel fonksiyonlara ve kod satırlarına o kadar odaklandığımı buldum ki, ilk taslağımı bitirip tekrar büyük resme bakmak için geri adım attığımda bazen çok iyi bir şekilde birbirine uymuyor. Temizlik için bir ya da iki kez yeniden yapılanmanın harcanması çoğu zaman kaba taslakta tespit edilmesi zor olan kopyalama / yapıştırma hatalarını veya sınır koşullarını ortaya çıkarır.

Bununla birlikte, bazı insanlar, "sonradan temizlemeyi" planlayan, nakliye yazılımının çıkarına yönelik kirli kodları kasten kontrol etmenin zaman zaman sorun olmadığını düşünüyor. Okunabilirlik idealin altında olduğunda kodlarının doğruluğuna güven veren bazı uygulanabilir teknikler var mı? Geliştirmeye çalışacak bir beceri mi? Yoksa, bazı insanların kabul etmeyi daha kolay bulduğu bir şeye güven eksikliği mi?

Kod muhtemelen doğru değil.

Ancak, önemli olmayabilir.

Çabuk ve kirli, şu durumlarda gitmek için doğru yol olabilir:

• Kodun ömrü kısa . Örneğin, geçici bir programla bir sürü veriyi standart bir formata dönüştürüyorsunuz.
• Başarısızlığın olumsuz etkisi düşük :
  • Dönüştürmekte olduğunuz veriler kritik değildir ve içindeki hatalar kolayca düzeltilebilir
  • Son kullanıcı, hata mesajlarını düşünecek ve çevrelerinde çalışacak, girdiyle masaj yapan sempatik bir programlayıcıdır.

Bazen kodun sağlam olması ve akla gelebilecek her girişi ele alması önemli değildir. Bazen sadece elinizdeki bilinen verileri ele alması gerekir.

Bu durumda, ünite testleri kodu daha hızlı yazmanıza yardımcı oluyorsa (bu benim için geçerlidir), sonra bunları kullanın. Aksi takdirde, hızlı ve kirli kod, işini halletmek. Tetiklemeyen böceklerin önemi yok. Anında tamir ettiğiniz veya üzerinde çalıştığınız hatalar önemli değil.

Kesinlikle hayati olan bu durumları yanlış teşhis etmemeniz. Kodun yalnızca bir kez kullanılacağından hızlı ve kirli kodlarsanız, birileri daha iyi kod gerektiren bazı projelerde kodu yeniden kullanmaya karar verirse, bu kod daha fazla dikkat edilmesini hak eder.

Yapmazlar. Şu anda "daha sonra temizleyebilecek" programcılar tarafından oluşturulan "hızlı ve kirli" bir kod tabanı üzerinde çalışıyorum. Çoktan gittiler ve kod devam ediyor, unutulmaya doğru ilerliyor. Kovboy kodlayıcıları , genel olarak, yazılımlarının sahip olabileceği tüm olası arıza modlarını anlamıyor ve şirketi (ve müşterileri) maruz bıraktıkları riskleri anlamıyor.

Tamam, aşırı oylama riski altında olma ihtimaline karşı, karşıt görüşümü "şeytanları savunacağım".

Geliştiricilerin uygun uygulama ve kod temizliği gibi şeyler hakkında aşırı endişe duyma eğiliminde olmalarını öneriyorum. Ben böyle şeyler önemli iken, düşündürmektedir Gönderebileceğiniz asla eğer hiçbiri önemli .

Bir süredir bu işte olan herkes muhtemelen bir parça yazılımla süresiz olarak çalışmanın mümkün olacağı konusunda hemfikirdir. Duke Nukem Forever, dostlarım. Bu güzel olması ya da çok acil yeniden yapılanma çalışmasının bir kenara bırakılması ve olayın DONE olarak adlandırılması gerektiği bir zaman gelir.

Meslektaşlarımla bunun hakkında birçok kez savaştım. HER ZAMAN bir tane daha çimdik var, “doğru” olması için “yapılması gereken” bir şey daha var. HER ZAMAN bunu bulabilirsin. Bir noktada, gerçek dünyada, yeterince iyi, sadece yeterince iyi olmak zorunda. Gerçek dünya yok, gerçek, nakliye yazılımı mükemmel. Yok. En iyi ihtimalle, yeterince iyi.

Bu tür programcılar neredeyse doğru anladıklarını bilmiyorlar , sadece buna inanıyorlar . Ve fark algılanması kolay olmayabilir.

Birim testini öğrenmeden önce nasıl programladığımı hatırlıyorum. Ve ilk iyi birim testlerimi yaptıktan sonra, tamamen farklı bir seviyede güven ve güven duygusunun olduğunu hatırlıyorum. Daha önce var olan kodumda böyle bir güven olduğunu bilmiyordum.

Bu deneyimden yoksun olan biri için, farkı açıklamak mümkün değildir. Bu yüzden, yaşamları boyunca kod ve dua modunda geliştirmeye devam edebilirler, iyi niyetli (ve cahilce) durumları göz önünde bulundurarak en iyisini yaptıklarına inanarak.

Bununla birlikte, gerçekten de tüm problem alanını aklında tutmayı, tam bir akış durumunda tutmayı başardığında, gerçekten büyük programcılar ve istisnai durumlar olabilir. Böyle nadir anlar yaşadım, ne yazacağımı mükemmel bir şekilde bildiğimde, kod benden kolayca çıktı, tüm özel durumları ve sınır koşullarını öngörebildim ve ortaya çıkan kod işe yaradı . Şüphesiz, orada uzun süre boyunca ve hatta zamanlarının çoğunda bu tür akış halinde kalabilen programlama dehaları var ve ürettikleri şey, görünüşte çaba göstermeden güzel kodlar. Sanırım böyle insanlar zaten bildiklerini doğrulamak için cılız birim testleri yazmaya gerek duymayabilirler.. Ve eğer gerçekten böyle bir dehaysanız, tamam olabilir (her ne kadar olsa bile, sonsuza dek bu projenin etrafında olmayacaksınız ve halefleriniz hakkında düşünmelisiniz ...). Ama eğer olmazsa...

Ve bununla yüzleşelim, şansın siz değilsiniz. Ben, kendim için olmadığımı biliyorum. Çok nadir akan anlar yaşadım - ve genellikle kendi hatalarımın neden olduğu sayısız saatlerce keder ve keder. Dürüst ve gerçekçi olsa iyi olur. Aslında, en büyük programcıların kendi hatalarını ve geçmiş hatalarını tam olarak bildiklerine inanıyorum, bu yüzden bilinçli olarak varsayımlarını iki kez kontrol etme ve bu küçük birim testlerini yazma, kendilerini güvende tutmalarını sağlama alışkanlığını geliştirdiler. ( "Ben iyi bir programcı değilim - sadece büyük alışkanlıklara sahip iyi bir programcı." - Kent Beck.)

Birim testleri . Herhangi bir koda güvenmenin tek yolu (kirli veya değil).

Bir yan notta;

kısa yollar uzun gecikmelere neden olur (Pippin)

Ne kadar birim test ve kod ayarlaması yapılırsa yapılsın, makul karmaşıklığa sahip hiçbir yazılım sisteminin mükemmel olmayacağını kabul etmek iyidir. Beklenmeyen durumlara karşı bir dereceye kadar kaos ve güvenlik açığı her zaman kod içinde gizlenecektir. Bu, birinin iyi kod üretmeye çalışmaması veya birim testleri yapmaması gerektiği anlamına gelmez. Bunlar elbette önemlidir. Aranması gereken bir denge var ve bu projeden projeye değişecektir.

Geliştirilmesi gereken beceri, belirli bir proje için hangi düzeydeki “mükemmelliğin” kullanılması gerektiğinin anlaşılmasıdır. Örneğin, 12 aylık bir proje zaman çizelgesine sahip bir elektronik tıbbi kayıt uygulaması yazıyorsanız, bir kereye mahsus konferans kayıt web uygulaması için yaptığınız kodun test edilip korunmadığından emin olmak için çok daha fazla zaman ayırmak istersiniz. Cuma günü konuşlandırılması gerekiyor. EMR uygulamasını yapan biri özensizlediğinde veya kayıt uygulaması zamanında devreye alınmadığında, programcı kod ayarını yapmakla meşgul olduğu için sorunlar ortaya çıkıyor.

Çabuk ve kirli bir alt sistemde mükemmel şekilde iyidir . Çöp kutunuzla sistemin geri kalanı arasında iyi tanımlanmış bir arayüze sahipseniz ve çirkin hızlı ve kirli kodun doğru olanı yaptığını doğrulayan iyi bir ünite testi seti varsa, tamamen iyi olabilir.

Örneğin, belki de üçüncü taraflardan gelen bazı dosyaları ayrıştırmak için olağandışı ifadeler ve bayt ofsetleri habersizdir. Ayrıca örnek dosyaları ayrıştırmanın sonucunun beklediğiniz gibi olduğunu söyleyen bir test olduğunu varsayalım. Bunu temizleyebildiniz, böylece ... Bilemiyorum, bir üçüncü taraf bir dosya biçimini değiştirdiğinde daha hızlı tepki veriyor? Bu sadece yeterince sık olmuyor. Daha büyük olasılıkla tamamen yeni bir API'ye geçeceklerdir ve eski ayrıştırıcıyı çöpe atarsınız ve aynı API'ye uyan yeni bir tane eklersiniz, işte bitirdiniz.

Hızlı ve kirli sorun haline geldiğinde, mimariniz hızlı ve kirli olduğunda. Çekirdek etki alanı nesnenizin iyi düşünülmüş olması ve arabirimleriniz, ancak sisteminizin kenarları, pipere ödeme yapmak zorunda kalmadan genellikle dağınık olabilir.

İşte bildiğim hızlı ve kirli bir programcının hikayesi.

Birim açısından zaman kaybını test eden birini tanıyorum. Çok tartışmadan sonra nihayet bir tane yazdı. && ve | serpilir bir uzun yöntemden oluşuyordu. ve AssertTrue'a bir boolean döndü. İfade 20 satırdır. Sonra yine, her yöntemin bir satır ve bir tanesinde beyaz boşluk olmayan 1000 satırın olduğu bir sınıf yazdı. Bir metin duvarıydı. Kodunu incelediğimde ve bazı yeni satırlar girdiğimde 'neden' diye sordu. 'Okunabilirlik yüzünden' dedim. İçini çekti ve sildi. Üstüne bir yorum yaptı "Dokunma, işe yarıyor!"

Onunla son konuştuğumda, bir şirket için bir web sitesi kodladı. Bir hata bulmaya çalışıyordu. Son 3 günü bunu günde 8 saat boyunca geçirmişti. Bir süre sonra onunla tekrar konuştum ve takım arkadaşının edebi değeri değiştirdiği ve başka yerde güncellemediği ortaya çıktı. Sabit değildi. Böylece diğer edebi harfleri de değiştirdi, böylelikle böceği düzeldi. Takım arkadaşının spagetti kodundan şikayet etti. Bana 'Haha, hepimiz bütün gece hata ayıklayıcınızla kalacağınızın ne olduğunu bilmiyor muyuz, tek bir pis böcek üzerinde uyumayan "Bunun gerçekten iyi bir programcı olduğunu düşünüyor ve gerçekten de iyi hissediyor.

Ayrıca, programlama kitaplarını okuduğunu ve blogların faydasız olduğunu düşünüyor. 'Sadece programlamaya başla' diyor. Bunu 12 yıl boyunca yaptı ve mükemmel bir programcı olduğunu düşünüyor. / facepalm

İşte biraz daha.

Başka bir zaman web uygulamamız için bir DatabaseManager sınıfı yazıyorduk. Tüm veritabanı aramalarını içine koydu. Akla gelebilecek her şey için 50'den fazla yöntemi olan bir Tanrı sınıfıydı. Her bir denetleyicinin her veritabanı yöntemi hakkında bilgi sahibi olması gerekmediğinden, alt sınıflara bölmemizi önerdim. Kabul etmedi, çünkü tüm veritabanı için sadece bir sınıfa sahip olmak kolaydı ve gerektiğinde yeni bir yöntem eklemek hızlıdı. Sonunda DatabaseManager, kullanıcının kimliğini doğrulamaktan arkeolojik sit alanlarını sıralamaya kadar 100'den fazla ortak metoda sahipti.

Çabuk ve kirli olmaktan kaçınmak için gereken dersim, altı yıllık bir çalışmanın değeri olduğu tahmin edilen (düşük tahmin edilen) şeyleri teslim etmek için altı ayım olduğu zamandı. Çalışmaya başlamadan önce metodolojileri araştırmaya karar verdim. Sonunda üç aylık bir araştırmaya yatırım yaptım ve geri kalan üç ayda da sunabildim.

Ortak işlevleri belirleyerek ve bu gereksinimleri karşılamak için gerekli kütüphaneleri oluşturarak büyük kazançlar elde ettik. Kodlayıcıların mevcut kitaplık rutinleri olduğunda kendi kodlarını yazdığını hala görüyorum. Bu kodlayıcılar çoğu zaman aynı problemi daha sonra çözmeleri gerektiğinde, aynı kodu tekrar yazar veya en iyi ihtimalle kesip yapıştırır. Hata düzeltmeleri kaçınılmaz olarak yalnızca kod kopyalarının bazılarını yakalar.

Bir geliştirici kütüphane kodunu kullanmasını istediğimde bir cevap verdi: "Bu hile yapmıyor mu? Okuldaki tüm kodlarımı yazmak zorunda kaldım."

Bazı durumlarda, "tüm" hataları bulan ve davranışı doğrulayan, böylece hızlı ve kirli bir kodlama tekniğine izin veren geniş bir regresyon testi grubu olabileceğini tahmin ediyorum. Fakat çoğunlukla sadece kötü bir proje planlama meselesi ve doğru bir şekilde yapmaktan daha önemli olduğunu düşünen bir yönetici.

Ve "sonra temizle" yi unut, bu asla olmaz. Nadir durumlarda, programcı işin bir çok işi ilk seferinde yapmasından daha pahalı hale getiren kodun çoğunu unutmuş olacak.

Ürün gönderilir.

Kod bir boşlukta mevcut değil. Çabuk ve kirli ve kovboy kodlamasının sonuçlarıyla açıklanamayan keder yangını yaşadım. Ancak bazen ürünü bitirmek önceliklidir, en iyi kodu nasıl yazacağınızı bulmak değil. Sonuçta, eğer ürün yeterince gönderilirse ve iyi çalışırsa, kullanıcılar ve müşteriler içindeki kodun ne kadar "kötü" olduğunu bilmez veya umursamazlar ve kabul etmeyi hiç umursamadığım zamanlar olduğunu kabul edeceğim doğru "kapıdan çıkardığım sürece.

Evet, örgütsel bir konuda bu ve "asla olmamalı". Ancak, kötü yönetilen ve son teslim tarihine dayanan bir kuruluşta kod yazıyorsanız, bireysel programcı düzeyinde birinin seçenekleri sınırlıdır.

Kolayca bakımı yapılmazsa dürüstçe doğru düştüğünü söyleyebileceklerini sanmıyorum. Eğer "daha sonra temizlemek" zorunda olduklarını kabul ediyorlarsa, o zaman yeterince düşünmedikleri bir şey vardır. İyice test etmek, yalnızca kirli kodlarla ilgili sorunları gerçekten çözecektir.

Şahsen ben "kirli kod yazma" becerisini geliştirmek ve doğruluğu konusunda kendinden emin olmak istemem. İlk seferinde uygun kodu yazmayı tercih ederim.

Doğru yaptıklarını nereden biliyorlar? Test etmek basit cevaptır.

Eğer onların kodları iyi bir QA ekibi tarafından ayrıntılı bir şekilde test edilmiş ve başarılı olmuşsa, doğru anladığını söylerdim.

Hızlı ve kirli kod yazmak, alışkanlık olarak yapılması gereken bir şey değildir, aynı zamanda 20 dakika boyunca kirli olarak sınıflandırılabilecek kod yazarken ya da 4 saat içinde doğru kodu yapmak için 4 saat harcayabileceğiniz durumlar olabilir. İş dünyasında bazen 20mins işi yapmak için elverişli olan her şeydir ve son teslim tarihleriyle karşılaştığınızda hızlı ve kirli olması tek seçenek olabilir.

Kendimi bunun iki ucunda bulundum, kirli kodu düzeltmek zorunda kaldım ve geliştirmekte olduğum bir sistemin sınırlamaları etrafında çalışmak için kendi yazdıklarım vardı. Kodda kendime güvendiğimi söyleyebilirim. yazdı çünkü kirli ve biraz kesilmiş olmasına rağmen bazen tamamen test edildiğinden ve hata işlemede bir sürü hata olduğundan emin oldum, bu yüzden eğer bir şeyler ters giderse sistemin geri kalanını yok etmezdi.

Bu hızlı ve kirli programcılara baktığımızda, bir şeyi hatırlamamız gerekiyor, bir müşteri genellikle ürüne sahip olana kadar ödeme yapmaz, eğer gönderilirse ve UAT testine girerse ve hızlı ve kirli koddaki hataları buluyorsa, bu bir Çok daha az olasılıkla, önlerinde neredeyse çalışan bir ürün olduklarında ortaya çıkacaklardı, ancak hiçbir şeyleri yoksa ve "yakında tamir edeceğiz" ya da "x tamir ediyoruz" ya da "ertelendi çünkü" Sadece mükemmel çalışıyorsanız "vazgeçmeleri ve rakiplerle gitmeleri daha muhtemeldir.

Elbette bu görüntünün gösterdiği gibi hiç kimse hızlı ve kirli kod tehlikesini küçümsememelidir!

Bence o yola girmeye başlamalısın bile. Çabuk ve kirli, terbiye işleminin daha hızlı bitmesine geçici bir fayda sağlayabilir, ancak sonunda bunu yapmak için her zaman on kat ödeme yaparsınız.

Bence doğruluk için Q&D kodunu yargılamayı öğrenmek gelişmeye değer bir beceri değil çünkü bu sadece kötü bir uygulama. İşte nedeni:

"Hızlı ve kirli" ve "en iyi uygulama" nın bir araya geldiğini sanmıyorum. Çoğu kodlayıcı (kendim dahil), üçlü kısıtlamalarda çarpıklık nedeniyle hızlı ve kirli kodları temizledi . Bunu yapmak zorunda kaldığımda, bu genellikle sürekli yaklaşan bir son tarihle birleştirilmiş kapsam süngüşünün bir sonucuydu. Kontrol ettiğim kodun emildiğini biliyordum, ancak bir takım girdiler verilen doğru çıktıları tüketti. Çok önemli olarak paydaşlarımız için zamanında sevk ettik.

Orijinal CHAOS Raporuna bir bakış, soru ve cevapların iyi bir fikir olmadığı ve bütçeyi daha sonra (bakım veya genişletme sırasında) ortadan kaldıracağını açıkça göstermektedir. Q&D kodunun doğru olup olmadığına karar vermeyi öğrenmek zaman kaybıdır. Peter Drucker'in dediği gibi, "Yapılmaması gereken şeyi verimli bir şekilde yapmak kadar işe yaramaz bir şey yok."

Yeni kodumun çok kirli olup olmadığını doğru söyleyemem.

"Kirli" farklı insanlar için farklı şeyler ifade eder. Bana göre, çoğunlukla güvenmeniz gerektiğini bildiğiniz şeylere güvenmek, ancak yakın vadede çalışmayı beklediğinizi de bildiğiniz anlamına gelir. Örnekler: bir düğmenin yüksekliği hesaplamak yerine 20 piksel yüksekliğinde olduğu varsayılır; bir ad çözümlemek yerine bir IP adresini zor kodlamak; Diziyi sağlayan yöntem onu ​​garanti etmese bile, olduğunu bildiğiniz için dizilebilecek bir dizi üzerinde sayma.

Kirli kod kırılgandır - test edebilir ve şimdi çalıştığını bilebilirsiniz , ancak gelecekte bir noktada kırılacağı oldukça iyi bir bahis (ya da başkalarını kırmaktan korkan yumurta kabuğu üzerinde yürümeye zorlar).

Biraz tartışmalı görünme riski altında, kimsenin gerçekten kodlarının% 100 doğru ve hatasız% 100 olduğunu bilmediğini iddia ediyorum . Gerçekten iyi bir test kapsamına sahipseniz ve iyi BDD / TDD uygulamalarını titizlikle uyguladığınızda bile, hala hata içeren kodlar geliştirebilirsiniz ve evet, yan etkileri de içerebilir!

Sadece kod yazmak ve bunun işe yaradığını varsaymak, geliştiricinin geliştiricinin kendi yeteneklerini anlama konusundaki güvenine ve problemler ortaya çıktığında (kaçınılmaz olarak isterlerse), kodun hata ayıklama ve sürdürme çabalarının, özellikle de başka bir geliştiricinin ihtiyaç duyması halinde, pahalıya mal olacağını gösterir. Daha sonra kodu korumak için. Gerçek fark, kodunuzun çoğu zaman işe yarayacağına ve bir hatayla karşılaşırsanız, hata ayıklamanın daha kolay olacağına dair gerçek güvende olmanızı sağlayan iyi yazılım mühendisliği uygulamaları ile yapılır. ve daha sonra bu kod üzerinde çalışan kişiden bağımsız olarak değişiklik ve bakım yapmak çok daha az maliyetlidir.

Belirgin nokta, iyi faktörlenmiş ve iyi test edilmiş kodun izin vermesidir DİĞERLER'in kodunuza güvenmesine vermesidir ; bu, çoğu durumda kendi güveninizden daha önemlidir.

Kirli kod iyi test edilirse, güvenilir olabilir. Sorun şu ki, kirli kodu test eden ünite genellikle çok zor ve zahmetlidir. TDD'nin bu kadar iyi olmasının nedeni budur; kir ve kokuları açığa çıkarır ve temizler. Ayrıca, birim testi genellikle zaman hazinesinden muzdarip olan ilk şeydir. Bu yüzden, en temiz adam şimdiye kadar yaptığı en temiz kodu koyarsa, zaman aşımından dolayı ünite testlerini atlarsa, yine de biraz güvenmezdim.

İyi programcılar (Çabuk ve Kirli ve başka türlü) doğru yaptıklarını varsaymak için kocalara sahip değillerdir. Tüm büyük sistemlerin hata ve kusurlara sahip olduğunu varsayıyorlar, ancak bir noktada kodun gönderebileceği yeterince düşük bir risk veya yeterince düşük başarısızlık maliyetine sahip olmak için yeterince iyi test edilip gözden geçirilebileceğini varsayıyorlar.

Öyleyse neden Quick & Dirty denilen programcılar var? Hipotezim Darwinist seçim. Uygulanabilir kodu hızlı bir şekilde gönderen, zaman zaman rekabet gemilerinden önce gönderilen veya bütçe tükenir veya şirket iflas eder. Bu nedenle, şirketleri hala temizlenmesi gereken karmaşadan şikayet etmek için yeni programcılar kullanıyor. Temiz kod da denir ancak Quick & Dirty kodlayıcıları neslinin tükenmesine neden olacak kadar iyi değil.

Muhtemelen, bir kodun optimal olmayan bir kısmının, kısa kullanım ömrü, iş dünyasında çok az etkisi veya bunu yapmak için çok az zamandan dolayı hiçbir fark yaratmayacağını düşünebilir. Doğru cevap, gerçekten bilmediğin. Ne zaman birisini "bu küçük bir özellik" diyen veya "yapabileceğimiz en hızlı ve basit yapalım" diyerek dinledim ve doğru tasarım hakkında düşünmeye yetersiz zaman harcadım, gerçekte ve ortaya çıkan iki şey şunlardır:

1-) Proje büyür ve takım motivasyonu azalır, "dikiş" koduyla çalışır. Bu durumda, proje kaosa doğru hızlı bir şekilde ilerleyecektir.

2-) Projenin optimal olmayan bir çözüm olduğu bilinir ve kullanımı yeni bir çözüm lehine veya yeni bir çözüm kadar pahalı olan bir yeniden düzenleme için teşvik edilmeye başlar.

Her zaman elinden gelenin en iyisini yapmayı dene. Yeterli zamanınız yoksa neden daha fazlasına ihtiyacınız olduğunu açıklayın. Kötü yapılan işlerle kendinizi riske atmayın. Her zaman daha iyi bir profesyonel ol. Mantıklıysanız kimse sizi bunun için cezalandıramaz. Eğer yaparlarsa, çalışmanız gereken yer orası değildir.

Kıdemli ile görüşün ve varsa başarısızlıkların etkisini değerlendirin. Örneğin, pisliği giderebileceğiniz bir durum 1 gün sürer ve sağlam bir kod, tasarım değişikliğinden etkilenen tüm iş akışlarını tam olarak doğrulamak için 4-6 ay + ek doğrulama süresi alabilen tasarım ve mimari değişiklik gerektirir.

Listedeki Zaman + Kapasite + Öncelikleri baz alarak karar vermeliyiz. Takımda yaşlılar veya daha yüksek deneyime sahip kişilerle yapılan iyi bir tartışma, takıma ve teslim edilebilirliğe en iyi uyan bir karara varmaya yardımcı olabilir.

Temiz kod, eskalasyonları kurtarmak için kirli kod, müşterilerin karar vermemesi / karar vermemesi, stoper göstermesi, söz konusu organizasyonun itibarını göstermesi ve kirli kodun temiz koda girdiği durumlarda daha pek çok şey olduğu ilk yaklaşımdır.