TDD yapan insanlar büyük refactoring yaparken iş kaybını nasıl ele alıyorlar?


37

Bir süredir kodum için birim testleri yazmayı öğrenmeye çalışıyorum.

Başlangıçta, gerçek bir TDD yapmaya başladım, ilk önce başarısız bir test yazana kadar herhangi bir kod yazmam.

Bununla birlikte, son zamanlarda, çok fazla kod içeren sorunu çözmek için ciddi bir sorun yaşadım. Testler ve kodları yazmak için birkaç hafta harcadıktan sonra, bütün yaklaşımımın işe yaramayacağı konusunda talihsiz bir sonuç çıkardım ve iki haftalık bir işi atıp tekrar başlamak zorunda kalacağım.

Bu, kodu henüz yazdığınızda verilecek kadar kötü bir karardır, ancak birkaç yüz ünite testi yazdığınızda, hepsini atmak daha duygusal olarak zorlaşır.

Konsepti kanıtlamak için kodu bir araya getirebildiğimde ve bu testleri yaklaşımımdan memnun kaldıktan sonra testleri yazdıktan sonra, bu testleri yazarken 3 veya 4 günlük çabamı harcadığımı düşünemiyorum.

TDD'yi uygulayan insanlar bu gibi durumları nasıl doğru şekilde ele alıyor? Bazı durumlarda kuralları esnetmek için bir dava var mı, yoksa her zaman slav bir şekilde ilk testler yazar mısınız, bu kod işe yaramaz hale gelse bile?


6
Kusursuzluk, eklenecek başka bir şey olmadığında değil, alınacak bir şey kalmadığında da başarılır. - Antoine de Saint-Exupery
mouviciel

12
Tüm testlerinizin yanlış olması nasıl mümkün olabilir? Lütfen uygulamadaki bir değişikliğin yazdığınız her testi nasıl geçersiz kıldığını açıklayınız .
S.Lott

6
@ S.Lott: Testler yanlış değildi, sadece artık alakalı değildi. Asal sayıları kullanarak bir problemin bir kısmını çözdüğünüzü söyleyin, böylece asal sayılar üretmek için bir sınıf yazıp, çalıştığından emin olmak için o sınıf için testler yazabilirsiniz. Şimdi, hiçbir şekilde asal içermeyen, probleminize tamamen farklı bir çözüm buluyorsunuz. Bu sınıf ve testler artık gereksiz. Bu benim durumumdu, sadece bir sınıf değil, sadece 10 sınıf.
GazTheDestroyer

5
@ GazTheDestroyer bana test kodu ile fonksiyonel kod arasında ayrım yapmanın bir hata olduğunu düşünüyor - hepsi aynı gelişim sürecinin bir parçası. TDD'nin genellikle geliştirme işleminde daha da iyileşen bir ek yüke sahip olduğunu ve bu ek yükün size bu konuda hiçbir şey kazandırmamış gibi göründüğünü unutmamak gerekir. Ancak, testler mimarinin başarısızlıkları konusundaki anlayışınızı ne ölçüde eşitledi? Ayrıca testlerinizin zaman içinde budanmasına izin verildiğine (hayır, teşvik edildiğine) dikkat etmek önemlidir. Bu muhtemelen biraz aşırı olsa da (-:
Murph

10
Anlamsal olarak sersem davranacağım ve burada @ S.Lott ile aynı fikirdeyim; Yaptığın şey, birçok dersi ve onlar için yapılan sınavları bir kenara atmakla sonuçlanırsa, yeniden yapılanma değildir . Bu yeniden mimarlık . Yeniden düzenleme, özellikle TDD anlamında, testlerin yeşil olduğu, bazı dahili kodları değiştirdiğiniz, testleri yeniden düzenlediğiniz ve yeşil kaldıkları anlamına gelir.
Eric King,

Yanıtlar:


33

Burada iki sorun olduğunu hissediyorum. Birincisi, orijinal tasarımınızın en iyi yaklaşım olmayabilir olabileceğini önceden farketmemişsinizdir. Bunu önceden bilmiş olsaydınız, hızlı atılabilir bir prototip geliştirmeyi , olası tasarım seçeneklerini araştırmayı ve hangisini takip etmenin en umut verici yol olduğunu değerlendirmeyi seçmiş olabilirsiniz . Prototip oluşturmada, üretimin kalite kodunu yazmanıza gerek yoktur ve tek odak noktanız kodu parlatma üzerine değil, öğrenmeye odaklandığından her köşede ve kafatasında (veya hiç) birim testi yapmanıza gerek yoktur.

Şimdi, üretim kodunun geliştirilmesine hemen başlamak yerine prototip ve deneylere ihtiyacınız olduğunun farkına varmak, her zaman kolay değildir ve her zaman mümkün değildir. Yeni edinilen bilgilerle donanmış, bir dahaki sefere prototipleme ihtiyacını tanıyabilirsiniz. Ya da olmayabilir. Ama en azından şimdi bu seçeneğin dikkate alınması gerektiğini biliyorsunuz. Ve bu kendi içinde önemli bir bilgidir.

Diğer mesele sizin algınızla IMHO. Hepimiz hata yaparız ve geçmişe bakıldığında farklı şekilde ne yapmamız gerektiğini görmek çok kolaydır. Bu sadece öğrendiğimiz yol. Prototiplemenin önemli olabileceğini öğrenme bedeli olarak birim testlere yaptığınız yatırımı yazın ve üstesinden gelin. Sadece iki kez aynı hatayı yapmamak için çaba sarf ediyorum :-)


2
Çözmenin zor bir sorun olacağını ve kodumun biraz keşfedici olacağını biliyordum, ancak son TDD başarılarımın coşkusuyla hareket ettim, bu yüzden yaptığım gibi testler yazmaya devam ettim. TDD literatürü çok fazla strese giriyor. Yani evet, şimdi kuralların ihlal edilebileceğini biliyorum (bu benim sorumun gerçekte ne olduğu) muhtemelen bunu deneyimlemeye davet ediyorum.
GazTheDestroyer

3
"Tüm TDD literatürünün bu kadar vurguladığı şey gibi yaptığım gibi yazma testlerini sürdürdüm". Muhtemelen soruyu, tüm testlerin herhangi bir koddan önce yazılması gerektiği fikrinizle güncellemelisiniz .
S.Lott,

1
Böyle bir fikrim yok ve yorumdan bunu nasıl aldığınızdan emin değilim.
GazTheDestroyer

1
Bir cevap yazacaktım ama onun yerine sizinkini oyladı. Evet, milyonlarca kez evet: mimarinizin henüz neye benzediğini bilmiyorsanız, önce basit bir prototip yazın ve prototip oluşturma sırasında birim testleri yazmakla uğraşmayın.
Robert Harvey,

1
@WarrenP, kesinlikle TDD'nin Tek Doğru Yol olduğunu düşünen insanlar var (yeterince zorlarsanız her şey bir dine dönüştürülebilir ;-). Ben pragmatik olmayı tercih ederim. Benim için TDD, araç kutumdaki bir araç ve sorunları çözmek yerine, engelleri kullanmak yerine sadece yardımcı olduğunda kullanıyorum.
Péter Török,

8

TDD'nin amacı, sizi bu fonksiyondan kaçınmak için küçük fonksiyonlarda küçük kod artışları yazmaya zorlamanızdır . Bir etki alanına kod yazmak için haftalar harcadıysanız ve yazdığınız her bir yardımcı yöntem , mimariyi yeniden düşündüğünüzde işe yaramaz hale gelirse, yöntemleriniz ilk etapta neredeyse kesinlikle çok büyüktür. (Evet, bunun şu anda tam olarak rahatlatıcı bir fikir olmadığını biliyorum ...)


3
Yöntemlerim büyük değildi, sadece eski mimariye benzemeyen yeni mimariye verilen önemsiz hale geldiler. Kısmen, çünkü yeni mimari çok daha basitti.
GazTheDestroyer

Tamam, tekrar kullanılabilir bir şey yoksa, sadece kayıplarını azaltabilir ve devam edebilirsiniz. Ancak TDD'nin vaadi, uygulama koduna ek olarak test kodu yazmanıza rağmen aynı hedeflere daha hızlı ulaşmanızı sağlamasıdır. Eğer bu doğruysa ve kesinlikle öyle olduğunu düşünüyorum, o zaman en azından iki kez değil, "birkaç hafta" da mimariyi nasıl yapacağınızı anladığınız noktaya ulaştınız.
Kilian Foth

1
@Kilian, yeniden "TDD'nin vaadi aynı hedeflere daha hızlı ulaşmanızı sağlıyor" - burada hangi hedeflerden bahsediyorsunuz? Ünite testlerinin üretim koduyla birlikte yazılmasının , kod çalkalama işlemine kıyasla başlangıçta sizi yavaşlattığı açıktır . TDD'nin uzun vadede daha iyi kalite ve düşük bakım maliyetleri nedeniyle geri ödeme yapacağını söyleyebilirim.
Péter Török,

@ PéterTörök - TDD'nin hiçbir zaman bir bedeli olmadığı konusunda ısrar eden insanlar var, çünkü kodu yazdığınız zaman ödeme yapıyor. Bu kesinlikle benim için durum böyle değil ama Killian buna inanıyor gibi görünüyor.
psr

Şey ... eğer inanmıyorsanız, aslında TDD'nin bir maliyetten çok önemli bir kazancı olduğuna inanmıyorsanız , o zaman bunu yapmanın hiçbir anlamı yoktur, değil mi? Gaz'ın tarif ettiği çok özel bir durumda değil, aynı zamanda . Korkarım bu konuyu tamamen konu dışı bıraktım :(
Kilian Foth

6

Brooks "birisini atmayı planla; her nasılsa yapacaksın" dedi. Bana öyle yapıyor gibisin. Bununla birlikte, birim testlerinizi büyük birim kodunu değil kod birimini test etmek için yazmalısınız. Bunlar daha fonksiyonel testlerdir ve bu nedenle herhangi bir iç uygulamada kullanılmalıdır.

Örneğin, bir PDE (kısmi diferansiyel denklem) çözücüsü yazmak istersem, matematiksel olarak çözebileceğim şeyleri çözmeye çalışan birkaç test yazardım. Bunlar benim ilk "birim" testlerim - okundu: xUnit çerçevesinin bir parçası olarak gerçekleştirilen fonksiyonel testler. PDE'yi çözmek için kullandığım algoritmaya bağlı olarak bunlar değişmeyecek. Tek umursadığım sonuç. İkinci birim testleri algoritmayı kodlamak için kullanılan fonksiyonlara odaklanacak ve böylece algoritmaya özgü olacaktır - örneğin Runge-Kutta. Eğer Runge-Kutta'nın uygun olmadığını öğrenseydim, o zaman hala üst seviye testlerim olurdu (Runge-Kutta'nın uygun olmadığını gösterenler dahil). Böylece, ikinci yineleme, birincisiyle aynı testlerin çoğuna sahip olacaktır.

Sorununuz belki tasarıma bağlı ve mutlaka kod değil. Ancak daha fazla ayrıntı olmadan söylemek zor.


Sadece çevre birimi, ama PDE nedir?
40’ta CVn

1
@ MichaelKjörling Kısmi Diferansiyel Denklem sanırım
foraidt

2
Brooks bu ifadeyi 2. baskısında geri çekmedi mi?
Simon,

Ne demek istiyorsun, Runge-Kutta'nın uygun olmadığını gösteren testlere hala sahipsin? Bu testler neye benziyor? Uygun olmadığını keşfetmeden önce yazdığınız Runge-Kutta algoritmasını kaydettiğinizden ve karışımda RK ile uçtan uca testlerin yapılmasının başarısız olduğunu mu demek istiyorsunuz?
moteutsch

5

TDD'nin yinelemeli bir süreç olduğunu unutmamalısınız. Küçük bir test yazın (çoğu durumda birkaç satır yeterli olmalıdır) ve çalıştırın. Test başarısız olmalı, şimdi doğrudan ana kaynağınız üzerinde çalışmalı ve testin geçmesi için test edilen işlevselliği uygulamaya çalışmalıdır. Şimdi tekrar başla.

Tüm testleri tek seferde yazmaya çalışmamalısınız, çünkü fark ettiğiniz gibi, bu işe yaramayacak. Bu, kullanılmayacak olan testler yazma zamanınızı boşa harcama riskini azaltır.


1
Kendimi çok iyi açıklayabileceğimi sanmıyorum. Tekrarlı olarak testler yazıyorum. Böylece birden fazla gereksiz hale gelen kod için birkaç yüz test yaptım.
GazTheDestroyer

1
Yukarıdaki gibi - " kod için testler" yerine "testler ve kodlar" olarak düşünülmesi gerektiğini düşünüyorum
Murph

1
+1: "Tüm testleri tek seferde yazmaya çalışmamalısınız,"
S.Lott

4

Bence kendin söyledin: tüm ünite testlerini yazmaya başlamadan önce yaklaşımından emin değildin.

Çalıştığım gerçek TDD projelerini karşılaştırdığımda öğrendiğim şey (aslında 2 yıl çalışmayı kapsayan sadece 3 yıl) teorik olarak öğrendiklerimle, Otomatik Test! = Birim Testi (elbette karşılıklı olmadan) hariç).

Başka bir deyişle, TDD'deki T'nin yanında bir U olması gerekmez ... Otomatikleştirilir, ancak otomatik bir işlevsel testten daha az bir birim testidir (test sınıfları ve yöntemlerinde olduğu gibi): aynı seviyede Şu anda üzerinde çalıştığınız mimari olarak işlevsel ayrıntı düzeyi. Birkaç testle ve yalnızca işlevsel büyük resimle üst seviyeye başlarsınız ve yalnızca sonunda binlerce UT ile sonuçlanırsınız ve tüm dersleriniz güzel bir mimaride iyi tanımlanır ...

Ünite testleri, sonsuz hata döngüsü yaratan kod değişikliklerini önlemek için takımda çalışırken size çok yardımcı olur. Ancak, bir proje üzerinde çalışmaya başlarken, her kullanıcı hikayesi için en azından küresel bir çalışma POC'su olmadan önce hiçbir zaman bu kadar kesin bir şey yazmadım.

Belki de bunu yapmam sadece kişisel yolumdur. Projemin hangi desen veya yapıya sahip olacağına sıfırdan karar vermek için yeterli deneyime sahip değilim, bu yüzden başlangıçta 100'lerce UT yazarak zamanımı boşa harcamam ...

Daha genel olarak, her şeyi kırma ve hepsini atma fikri her zaman orada olacaktır. Araçlarımız ve yöntemlerimizle olmaya çalışacağımız kadar “sürekli” olarak, bazen entropiyle savaşmanın tek yolu baştan başlamaktır. Ancak amaç, bu gerçekleştiğinde, uyguladığınız otomatik ve ünite testlerinin projenizi orada bulunmadıklarından çok daha az maliyetli hale getirecek olmasıdır - ve dengeyi bulursanız, olacaktır.


3
iyi dedi - bu TDD değil, UTDD değil
Steven A. Lowe

Mükemmel cevap TDD deneyimime göre, yazılı testlerin yazılımın işlevsel davranışlarına ve ünite testinden uzakta olmasına odaklanması önemlidir. Bir sınıftan ihtiyaç duyduğunuz davranışları düşünmek daha zordur, ancak temiz arayüzlere neden olur ve sonuçta ortaya çıkacak uygulamayı basitleştirir (aslında ihtiyacınız olmayan bir işlevsellik eklemezsiniz).
JohnTESlade

4
TDD'yi uygulayan insanlar bu gibi durumları nasıl doğru şekilde ele alıyor?
  1. ne zaman kod yazılacağını vs prototip dikkate alarak
  2. ünite testlerinin TDD ile aynı olmadığını fark ederek
  3. İşlevsel bir birimi değil, bir özelliği / hikayeyi doğrulamak için TDD testleri yazarak

Teste dayalı geliştirme ile birim testlerinin birleşmesi, çok acı ve acı kaynağıdır. Öyleyse bir kez daha gözden geçirelim:

  • Birim testi , uygulamadaki her bir modül ve fonksiyonun doğrulanması ile ilgilidir ; UT’de, kod kapsamı ölçümleri ve çok hızlı bir şekilde yürütülen testler gibi konulara vurgu görürsünüz
  • Test odaklı geliştirme , gereksinimlerdeki her bir özellik / hikayenin doğrulanması ile ilgilidir ; TDD’de, önce testi yazma, yazılı kodun istenen kapsamı aşmamasını sağlama ve kaliteyi yeniden düzenleme gibi konulara vurgu yapıldığını göreceksiniz.

Özetle: birim sınamasının uygulama odağı, TDD'nin gereksinim odağı var. Onlar aynı şey değil.


“TDD'nin bir gereksinim odağı var” Buna kesinlikle katılmıyorum. TDD'deki senin yazma testleri vardır birim testleri. Bunlar yapmak Her bir fonksiyon / metot olun. TDD yapar kod kapsama vurgu var ve yok (eğer testler her 30 saniyede bir çalışacak beri, ve daha iyi yaparım) hızla yürütmek testler hakkında bakım. Belki ATDD veya BDD'yi düşünüyordun?
guillaume31

1
@ ian31: UT ve TDD konfederasyonunun mükemmel bir örneği. Katılmamalı ve sizi bazı kaynak materyallere yönlendirmelisiniz. En.wikipedia.org/wiki/Test-driven_development - testlerin amacı kod gereksinimlerini tanımlamaktır . BDD harika. ATDD'yi hiç duymadım, fakat bir bakışta TDD ölçeklendirmeyi nasıl uyguladığım gibi görünüyor .
Steven A. Lowe

Bir gereksinim veya kullanıcı öyküsü ile doğrudan ilgili olmayan teknik kodu tasarlamak için TDD'yi mükemmel bir şekilde kullanabilirsiniz. Bunun sayısız örneğini web'de, TDD'yi başlatan ve popüler kılan insanlar da dahil olmak üzere kitaplarda, konferanslarda bulacaksınız. TDD bir disiplindir, kod yazma tekniğidir, kullandığınız içeriğe bağlı olarak TDD olmayı bırakmaz.
guillaume31

Ayrıca, bahsettiğiniz Wikipedia makalesinden: "Teste dayalı geliştirme konusundaki ileri uygulamalar, müşteri tarafından belirtilen ölçütlerin kabul testlerine göre otomatik hale getirildiği ATDD'ye yol açabilir, bu da geleneksel birim testine dayalı geliştirme (UTDD) işlemini yürütür. [ …] ATDD ile birlikte, geliştirme ekibinin, müşterilerin gerçekten bu kullanıcı hikayesinden gerçekte ne istediklerine odaklanmalarını sağlayan, kabul testlerini karşılamak için özel bir hedefi var. ” Hangi ima görünüyor ATDD öncelikle ihtiyaçlarına odaklanmış (onların tabiriyle veya UTDD) değil TDD edilir.
guillaume31

@ ian31: OP'nin 'birkaç yüz birim testini atma' ile ilgili sorusu bir ölçek karışıklığı olduğunu belirtti. İsterseniz bir kulübe oluşturmak için TDD kullanabilirsiniz. : D
Steven A. Lowe

3

Test güdümlü geliştirme anlamına gelir sürücü gelişiminizi. Yazdığınız testler, yazmakta olduğunuz kodun doğruluğunu kanıtlamanıza yardımcı olur ve geliştirme hızını ilk satırdan itibaren artırır.

Testlerin bir yük olduğuna ve daha sonraları yalnızca artan gelişim için olduğuna inanıyor gibisiniz. Bu düşünce hattı TDD ile uyumlu değildir.

Belki statik yazarak karşılaştırabilirsiniz: statik yazmasız bilgi kullanarak kod yazabilseniz de, koda statik yazım eklemek kodun belirli özelliklerinin belirlenmesine yardımcı olur, zihni serbest bırakır ve bunun yerine önemli yapıya odaklanır, böylece hızı arttırır ve etki.


2

Büyük bir yeniden yapılanma gerçekleştirmenin sorunu, bazen çiğneyebildiğinizden daha fazla ısırıldığınızı fark etmenize yol açan bir yolu izleyebileceğiniz ve takip edebileceğinizdir. Dev refactorings bir hata. Sistem tasarımı ilk etapta kusurlu ise, yeniden yapılanma işlemi ancak zor bir karar vermeden önce sizi o kadar uzağa götürebilir. Ya sistemi olduğu gibi bırakın ya da çalışın ya da yeniden tasarlayıp büyük değişiklikler yapmayı planlayın.

Ancak başka bir yol var. Yeniden düzenleme kodunun asıl faydası, işleri daha basit, okunması kolay ve bakımı daha kolay hale getirmektir. Belirsizliğe sahip olduğunuz bir soruna yaklaştığınızda, bir değişiklik gözetir, sorun hakkında daha fazla şey öğrenmek için nereye gidebileceğini görmek için o kadar ileriye gidersiniz, sonra başak atılır ve başakçının ne olduğuna bağlı olarak yeni bir yeniden düzenleme uygularsınız düşüncelisin. Mesele şu ki, yalnızca adımlar küçükse ve yeniden düzenleme çabalarınız önce testlerinizi yazma yeteneğinizi aşmazsa, kodunuzu kesin olarak geliştirebilirsiniz. Baştan çıkarıcı bir test yazmak, sonra kodlamak, daha sonra bazı kodları kodlamaktır, çünkü bir çözüm açık görünebilir, ancak yakında yaptığınız değişikliğin daha fazla testi değiştireceğini fark edersiniz, bu yüzden bir seferde yalnızca bir şeyi değiştirirken dikkatli olmanız gerekir.

Bu nedenle cevap, yeniden ateşlemenizi asla önemli bir şey yapmamaktır. Bebek adımları. Yöntemleri ayıklayarak başlayın, sonra çoğaltmayı kaldırmaya bakın. Sonra sınıfları çıkarmak için hareket ettirin. Her küçük adımda her seferinde bir küçük değişiklik. Kod çıkarıyorsanız, önce bir test yazın. Kodu kaldırıyorsanız, kodu kaldırın ve testlerinizi çalıştırın ve daha sonra testlerden herhangi birinin gerekip gerekmediğine karar verin. Bir seferde bir küçük bebek adım. Daha uzun sürecek gibi görünüyor, ancak aslında yeniden yapılanma sürenizi önemli ölçüde kısaltacak.

Ancak gerçek şu ki, her başak görünüşte potansiyel bir çaba kaybıdır. Kod değişiklikleri bazen hiçbir yere gitmez ve kodunuzu vcs'nizden geri yüklerken kendinizi bulursunuz. Bu sadece günden güne yaptığımızın bir gerçeğidir. Başarısız olan her başak, size bir şey öğretirse boşa gitmez. Başarısız olan her yeniden düzenleme çabası size ya çok fazla çabuk yapmaya çalıştığınızı ya da yaklaşımınızın yanlış olabileceğini öğretecektir. Ondan bir şey öğrenirseniz, bu da zaman kaybı değildir. Bu şeyi ne kadar çok yaparsanız, ne kadar çok şey öğrenirseniz o kadar verimli olursunuz. Benim tavsiyem şu an için sadece giymek, daha az yaparak daha fazlasını yapmayı öğrenmek ve bunun sizi hiçbir yere götürmeden önce ne kadar uzağa çıkacağınızı belirleme konusunda daha iyi hale gelene kadar muhtemelen olması gereken şey olduğunu kabul etmektir.


1

Yaklaşımınızın neden 3 gün sonra kusurlu olduğuna dair hiçbir fikrim yok. Mimarlığınızdaki belirsizliğinize bağlı olarak, test stratejinizi değiştirmeyi düşünebilirsiniz:

  • Performanstan emin değilseniz, performans gösteren birkaç entegrasyon testiyle başlamak isteyebilirsiniz?

  • API karmaşıklığı araştırdığınız şey olduğunda, bunun için en iyi yolun ne olacağını bulmak için gerçek çıplak, küçük birim testleri yazın. Hiçbir şeyi uygulamanın zahmetine girmeyin, yalnızca sınıflarınızın kodlanmış değerleri döndürmesini sağlayın veya NotImplementedExceptions'ı atmalarını sağlayın.


0

Benim için birim testleri aynı zamanda arayüzü "gerçek" kullanımın altına sokma zamanıdır (yani, birim testleri devam ettiği kadar gerçek!).

Eğer bir test yapmak zorunda kalırsam, tasarımımı uygulamak zorundayım. Bu, işlerin aklı başında tutulmasına yardımcı olur (bir şey o kadar karmaşıksa, bunun için bir test yazmak bir yüktür, onu kullanmak nasıl bir şey olur?).

Bu, tasarımdaki değişikliklerden kaçınmaz, onların ihtiyacını ortaya çıkarır. Evet, tam bir yeniden yazma bir acıdır. Önlemek için (denemek için), genellikle Python'da (c ++ 'da son geliştirme ile) genellikle (bir veya daha fazla) prototip hazırladım.

Verilen, tüm bu güzellikler için her zaman zamanınız yok. Bunlar, hedeflerinize ulaşmak ve / veya her şeyi kontrol altında tutmak için BÜYÜK BİR zamana ihtiyacınız olacak durumlardır .


0

Yaratıcı geliştiricilerin sirkine hoş geldiniz .


Başlangıçta kodlamanın tüm 'yasal / makul' yoluna saygı göstermek yerine, sizin için önemli ve yeniyse ve istediğiniz gibi bir örnek varsa, istediğiniz gibi görünmüyorsa sezgiyi
deneyin : - İçgüdünüzle, zaten bildiğiniz şeylerden yazın , zihinsel ve hayal gücünle değil. - Ve dur. - Bir büyüteç alın ve yazdığınız tüm kelimeleri inceleyin: "metin", String'in yakınında olduğu için "metin" yazarsınız, ancak "fiil", "sıfat" veya daha doğru bir şeye ihtiyaç duyulduğundan, tekrar okuyunuz ve yöntemi yeni bir anlamla ayarlayın . .. ya da gelecek hakkında düşünen bir kod yazdınız mı? kaldır - Düzelt, başka bir iş yap (spor, kültür veya iş dışındaki diğer şeyler), geri gel ve tekrar oku. - Her şey yolunda







- Doğru, başka bir iş yap, geri gel ve tekrar oku.
- Her şey yolunda
, TDD'ye geç - Şimdi her
şey yolunda , iyi - İyileştirilecek şeyleri işaret etmek için kıyaslamayı dene, yap.

Görünüşe göre:
- tüm kurallara uygun bir kod yazdınız
- bir deneyim, iş için yeni bir yol,
- fikrinizde bir şeyler değişir, asla yeni bir konfigürasyondan korkmazsınız.

Bir UML yukarıdaki gibi bakarak görürsem Ve şimdi, sen söylemek mümkün olacak
"Patron, bunun için TDD başlar ...."
başka yeni bir şey mi?
"Patron, kodlarıma karar vermeden önce bir şeyler denerdim .."

PARIS
Claude'dan saygılarımla

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.