Bagaimana orang yang melakukan TDD menangani kehilangan pekerjaan saat melakukan refactoring besar

37

Untuk sementara saya mencoba belajar menulis unit test untuk kode saya.

Awalnya saya mulai melakukan TDD sejati, di mana saya tidak akan menulis kode apa pun sampai saya menulis tes gagal terlebih dahulu.

Namun, saya baru-baru ini memiliki masalah pelik yang harus diselesaikan yang melibatkan banyak kode. Setelah menghabiskan beberapa minggu baik menulis tes dan kemudian kode, saya sampai pada kesimpulan yang disayangkan bahwa seluruh pendekatan saya tidak akan berhasil, dan saya harus membuang dua minggu kerja dan mulai lagi.

Ini adalah keputusan yang cukup buruk untuk muncul ketika Anda baru saja menulis kode, tetapi ketika Anda juga telah menulis beberapa ratus unit tes menjadi lebih sulit secara emosional untuk membuang semuanya.

Saya tidak dapat menahan diri untuk berpikir bahwa saya telah menghabiskan 3 atau 4 hari usaha untuk menulis tes-tes itu ketika saya dapat menyatukan kode untuk bukti konsep dan kemudian menulis tes-tes itu setelah saya puas dengan pendekatan saya.

Bagaimana orang yang berlatih TDD menangani situasi seperti itu dengan benar? Apakah ada kasus untuk menekuk aturan dalam beberapa kasus atau apakah Anda selalu menulis tes dengan rendah hati, bahkan ketika kode itu ternyata tidak berguna?

tdd refactoring

— GazTheDestroyer
sumber

6

Kesempurnaan tercapai, bukan ketika tidak ada lagi yang ditambahkan, tetapi ketika tidak ada lagi yang tersisa untuk diambil. - Antoine de Saint-Exupery

— mouviciel

12

Bagaimana mungkin semua tes Anda salah? Tolong jelaskan bagaimana perubahan dalam implementasi membatalkan setiap tes yang Anda tulis.

— S.Lott

6

@ S.Lott: Tesnya tidak salah, mereka tidak relevan lagi. Katakanlah Anda sedang memecahkan bagian dari masalah menggunakan bilangan prima, jadi Anda menulis kelas untuk menghasilkan bilangan prima dan menulis tes untuk kelas itu untuk memastikan itu berfungsi. Sekarang Anda menemukan solusi lain yang sama sekali berbeda untuk masalah Anda yang tidak melibatkan bilangan prima dengan cara apa pun. Kelas itu dan tes itu sekarang mubazir. Ini adalah situasi saya hanya dengan 10 kelas bukan hanya satu.

— GazTheDestroyer

5

@GazTheDestroyer menurut saya membedakan antara kode uji dan kode fungsional adalah kesalahan - semua bagian dari proses pengembangan yang sama. Adalah wajar untuk dicatat bahwa TDD memiliki overhead yang biasanya dipulihkan lebih jauh ke bawah proses pengembangan dan bahwa tampaknya overhead itu tidak memberi Anda apa pun dalam kasus ini. Tetapi sama seberapa banyak tes menginformasikan pemahaman Anda tentang kegagalan arsitektur? Penting juga untuk dicatat bahwa Anda diizinkan (tidak, didorong ) untuk memangkas tes Anda dari waktu ke waktu ... meskipun ini mungkin agak ekstrem (-:

— Murph

10

Aku akan menjadi orang yang secara semantik pedantik dan setuju dengan @ S.Lott di sini; apa yang Anda lakukan bukanlah refactoring jika hasilnya membuang banyak kelas dan tes untuk mereka. Itu arsitek ulang . Refactoring, terutama dalam arti TDD, berarti tesnya hijau, Anda mengubah beberapa kode internal, menjalankan kembali tes, dan mereka tetap hijau.

— Eric King

33

Saya merasa ada dua masalah di sini. Yang pertama adalah Anda tidak menyadari sebelumnya bahwa desain asli Anda mungkin bukan pendekatan terbaik. Seandainya Anda mengetahui hal ini sebelumnya, Anda mungkin telah memilih untuk mengembangkan satu atau dua prototipe membuang- cepat , untuk mengeksplorasi opsi desain yang mungkin dan untuk menilai mana yang merupakan cara yang paling menjanjikan untuk diikuti. Dalam membuat prototipe, Anda tidak perlu menulis kode kualitas produksi dan tidak perlu menguji unit setiap sudut dan celah (atau sama sekali), karena fokus utama Anda adalah pada pembelajaran, bukan pada pemolesan kode.

Sekarang, menyadari bahwa Anda memerlukan prototipe dan eksperimen daripada memulai pengembangan kode produksi segera, tidak selalu mudah, dan bahkan tidak selalu mungkin. Berbekal pengetahuan yang baru saja didapat, Anda mungkin bisa mengenali kebutuhan untuk membuat prototipe di lain waktu. Atau mungkin juga tidak. Tetapi setidaknya Anda tahu sekarang bahwa opsi ini harus dipertimbangkan. Dan ini sendiri adalah pengetahuan penting.

Masalah lainnya adalah IMHO dengan persepsi Anda. Kita semua membuat kesalahan, dan sangat mudah untuk melihat dalam retrospeksi apa yang seharusnya kita lakukan secara berbeda. Inilah cara kita belajar. Tuliskan investasi Anda dalam unit test karena harga belajar bahwa prototyping mungkin penting, dan selesaikan. Berusahalah untuk tidak melakukan kesalahan yang sama dua kali :-)

— Péter Török
sumber

2

Saya memang tahu bahwa itu akan menjadi masalah yang sulit untuk dipecahkan dan bahwa kode saya akan agak eksploratif, tetapi saya bersemangat dengan keberhasilan TDD baru-baru ini, jadi saya melakukan tes tulis seperti yang telah saya lakukan karena itulah yang semuanya literatur TDD sangat menekankan. Jadi ya, sekarang saya tahu bahwa aturannya bisa dilanggar (itulah pertanyaan saya sebenarnya tentang itu). Saya mungkin akan menuliskan ini untuk pengalaman.

— GazTheDestroyer

3

"Saya melakukan tes tulis seperti yang telah saya lakukan karena itulah yang ditekankan oleh semua literatur TDD". Anda mungkin harus memperbarui pertanyaan dengan sumber ide Anda bahwa semua tes harus ditulis sebelum kode apa pun .

— S.Lott

1

Saya tidak punya ide seperti itu dan saya tidak yakin bagaimana Anda mendapatkannya dari komentar.

— GazTheDestroyer

1

Saya akan menulis jawaban, tetapi sebaliknya memilih Anda. Ya, sejuta kali ya: jika Anda belum tahu seperti apa arsitektur Anda, tulis prototipe sekali pakai terlebih dahulu, dan jangan repot-repot menulis unit test selama pembuatan prototipe.

— Robert Harvey

1

@ WarrenP, pasti ada orang yang berpikir TDD adalah One True Way (apa pun bisa berubah menjadi agama jika Anda berusaha cukup keras ;-). Saya lebih suka bersikap pragmatis. Bagi saya TDD adalah salah satu alat di kotak alat saya, dan saya menggunakannya hanya ketika itu membantu, bukannya menghambat, memecahkan masalah.

— Péter Török

8

Inti dari TDD adalah ia memaksa Anda untuk menulis sedikit peningkatan kode dalam fungsi-fungsi kecil , tepatnya untuk menghindari masalah ini. Jika Anda telah menghabiskan waktu berminggu-minggu menulis kode pada satu domain, dan setiap metode utilitas tunggal yang Anda tulis menjadi tidak berguna ketika Anda memikirkan kembali arsitekturnya, maka metode Anda hampir pasti terlalu besar. (Ya, saya sadar ini tidak benar-benar menghibur sekarang ...)

— Kilian Foth
sumber

3

Metode saya tidak besar sama sekali, mereka menjadi tidak relevan mengingat arsitektur baru yang tidak memiliki kemiripan dengan arsitektur lama. Sebagian karena arsitektur baru itu jauh lebih sederhana.

— GazTheDestroyer

Baiklah, jika benar-benar tidak ada yang dapat digunakan kembali Anda hanya dapat memotong kerugian Anda dan melanjutkan. Tetapi janji TDD adalah bahwa hal itu membuat Anda mencapai tujuan yang sama lebih cepat, meskipun Anda menulis kode uji di samping kode aplikasi. Jika itu benar, dan saya pikir itu benar, maka setidaknya Anda mencapai titik di mana Anda menyadari bagaimana melakukan arsitektur dalam "beberapa minggu" daripada dua kali lipat.

— Kilian Foth

1

@Kilian, kembali "janji TDD adalah bahwa hal itu membuat Anda mencapai tujuan yang sama lebih cepat" - tujuan apa yang Anda maksudkan di sini? Sangat jelas bahwa penulisan unit test bersama dengan kode produksi itu sendiri membuat Anda lebih lambat pada awalnya , dibandingkan dengan hanya mengaduk kode. Saya akan mengatakan TDD hanya akan membayar kembali dalam jangka panjang, karena peningkatan kualitas dan pengurangan biaya perawatan.

— Péter Török

@ PéterTörök - Ada orang yang bersikeras TDD tidak pernah memiliki biaya karena membayar untuk dirinya sendiri pada saat Anda telah menulis kode. Tentu saja bukan itu yang terjadi padaku tetapi Killian tampaknya mempercayainya untuk dirinya sendiri.

— psr

Nah ... jika Anda tidak percaya itu, sebenarnya jika Anda tidak percaya bahwa TDD memiliki hasil yang substansial daripada biaya, maka tidak ada gunanya melakukannya sama sekali, bukan? Bukan hanya dalam situasi yang sangat spesifik yang dijelaskan Gaz, tetapi juga sama sekali . Saya khawatir saya sekarang menggerakkan utas ini sepenuhnya di luar topik :(

— Kilian Foth

6

Brooks berkata "rencanakan untuk membuang satu; Anda akan, bagaimanapun". Sepertinya saya yang melakukan hal itu. Yang mengatakan, Anda harus menulis unit test Anda untuk menguji unit kode dan bukan petak besar kode. Itu adalah tes yang lebih fungsional dan karena itu harus atas implementasi internal.

Misalnya, jika saya ingin menulis pemecah PDE (persamaan diferensial parsial), saya akan menulis beberapa tes yang mencoba menyelesaikan hal-hal yang dapat saya selesaikan secara matematis. Itu adalah tes "unit" pertama saya - baca: tes fungsional dijalankan sebagai bagian dari kerangka kerja xUnit. Itu tidak akan berubah tergantung pada algoritma apa yang saya gunakan untuk menyelesaikan PDE. Yang saya pedulikan adalah hasilnya. Tes unit kedua akan fokus pada fungsi yang digunakan untuk mengkodekan algoritma dan dengan demikian akan spesifik algoritma - katakanlah Runge-Kutta. Jika saya mengetahui bahwa Runge-Kutta tidak cocok, maka saya masih akan menjalani tes tingkat atas (termasuk yang menunjukkan bahwa Runge-Kutta tidak cocok). Jadi iterasi kedua masih akan memiliki banyak tes yang sama dengan yang pertama.

Masalah Anda mungkin pada desain dan belum tentu kode. Tetapi tanpa rincian lebih lanjut, sulit untuk mengatakannya.

— Sardathrion - Pasang kembali Monica
sumber

Ini hanya perangkat, tetapi apa itu PDE?

— CVn

1

@ MichaelKjörling Saya kira itu Persamaan Diferensial Parsial

— foraidt

2

Bukankah Brooks mencabut pernyataan itu dalam edisi ke-2?

— Simon

Bagaimana maksud Anda Anda masih akan memiliki tes yang menunjukkan Runge-Kutta tidak cocok? Seperti apa tes itu? Apakah maksud Anda bahwa Anda menyimpan algoritma Runge-Kutta yang Anda tulis, sebelum menemukannya tidak cocok, dan menjalankan tes ujung ke ujung dengan RK dalam campuran akan gagal?

— moteutsch

5

Anda harus ingat bahwa TDD adalah proses berulang. Tulis tes kecil (dalam kebanyakan kasus beberapa baris sudah cukup) dan jalankan. Tes harus gagal, sekarang langsung bekerja pada sumber utama Anda dan cobalah untuk mengimplementasikan fungsionalitas yang diuji sehingga tes lulus. Sekarang mulailah dari awal lagi.

Anda sebaiknya tidak mencoba menulis semua tes sekaligus, karena, seperti yang telah Anda perhatikan, ini tidak akan berhasil. Ini mengurangi risiko membuang-buang waktu untuk menulis tes yang tidak akan digunakan.

— BenR
sumber

1

Saya pikir saya tidak bisa menjelaskan diri saya dengan sangat baik. Saya menulis tes berulang-ulang. Begitulah cara saya berakhir dengan beberapa ratus tes untuk kode yang tiba-tiba menjadi berlebihan.

— GazTheDestroyer

1

Seperti di atas - saya pikir itu harus dianggap sebagai "tes dan kode" daripada "tes untuk kode"

— Murph

1

+1: "Sebaiknya Anda tidak mencoba menulis semua tes sekaligus,"

— S.Lott

4

Saya pikir Anda mengatakannya sendiri: Anda tidak yakin tentang pendekatan Anda sebelum mulai menulis semua tes unit Anda.

Hal yang saya pelajari membandingkan proyek TDD kehidupan nyata yang saya kerjakan (tidak banyak sebenarnya, hanya 3 yang mencakup 2 tahun kerja) dengan apa yang saya pelajari secara teoritis, adalah bahwa Pengujian Otomatis! = Pengujian Unit (tanpa tentu saja saling terkait eksklusif).

Dengan kata lain, T dalam TDD tidak harus memiliki U dengan itu ... Itu otomatis, tetapi kurang tes unit (seperti dalam kelas dan metode pengujian) daripada tes fungsional otomatis: itu pada tingkat yang sama granularity fungsional sebagai arsitektur yang sedang Anda kerjakan. Anda memulai level tinggi, dengan beberapa tes dan hanya gambaran besar fungsional, dan hanya pada akhirnya Anda berakhir dengan ribuan UT, dan semua kelas Anda didefinisikan dengan baik dalam arsitektur yang indah ...

Tes unit memberi Anda banyak bantuan saat Anda bekerja dalam tim, untuk menghindari perubahan kode yang menciptakan siklus bug tanpa akhir. Tapi saya tidak pernah menulis sesuatu yang begitu tepat ketika mulai mengerjakan proyek, sebelum memiliki setidaknya POC global untuk setiap kisah pengguna.

Mungkin ini hanya cara pribadi saya untuk melakukan ini. Saya tidak memiliki pengalaman yang cukup untuk memutuskan dari awal apa pola atau struktur proyek saya akan miliki, jadi memang saya tidak akan membuang waktu saya menulis 100-an UT sejak awal ...

Secara umum, ide untuk menghancurkan segalanya dan membuang semuanya akan selalu ada. Sebagai "terus menerus" seperti yang bisa kita coba dengan alat dan metode kita, kadang-kadang satu-satunya cara untuk melawan entropi adalah memulai dari awal. Tetapi tujuannya adalah bahwa ketika itu terjadi, pengujian otomatis dan unit yang Anda laksanakan akan membuat proyek Anda sudah lebih murah daripada jika tidak ada di sana - dan itu akan terjadi, jika Anda menemukan keseimbangannya.

— GFK
sumber

3

kata baik - ini TDD, bukan UTDD

— Steven A. Lowe

Jawaban yang sangat bagus. Dalam pengalaman saya tentang TDD, penting bahwa tes tertulis fokus pada perilaku fungsional perangkat lunak dan jauh dari pengujian unit. Lebih sulit untuk memikirkan perilaku yang Anda butuhkan dari sebuah kelas, tetapi hal itu mengarah pada antarmuka yang bersih dan berpotensi menyederhanakan implementasi yang dihasilkan (Anda tidak menambahkan fungsionalitas yang sebenarnya tidak Anda butuhkan).

— JohnTESlade

4

Bagaimana orang yang berlatih TDD menangani situasi seperti itu dengan benar?

dengan mempertimbangkan kapan membuat prototipe vs kapan membuat kode
dengan menyadari bahwa pengujian unit tidak sama dengan TDD
dengan tulisan tes TDD untuk memverifikasi fitur / cerita, bukan unit fungsional

Penggabungan unit pengujian dengan pengembangan yang digerakkan oleh tes adalah sumber dari banyak kesedihan dan kesengsaraan. Jadi mari kita tinjau sekali lagi:

unit testing berkaitan dengan memverifikasi setiap modul dan fungsi individu dalam implementasi ; di UT Anda akan melihat penekanan pada hal-hal seperti metrik cakupan kode dan tes yang dijalankan dengan sangat cepat
pengembangan uji coba berkaitan dengan memverifikasi setiap fitur / cerita dalam persyaratan ; di TDD Anda akan melihat penekanan pada hal-hal seperti menulis tes terlebih dahulu, memastikan bahwa kode yang ditulis tidak melebihi ruang lingkup yang dimaksudkan, dan refactoring untuk kualitas

Singkatnya: pengujian unit memiliki fokus implementasi, TDD memiliki fokus persyaratan. Mereka bukan hal yang sama.

— Steven A. Lowe
sumber

"TDD memiliki fokus persyaratan" Saya benar-benar tidak setuju dengan itu. Tes yang Anda tulis dalam TDD adalah tes unit. Mereka melakukan verifikasi setiap fungsi / metode. TDD memang memiliki penekanan pada cakupan kode dan tidak peduli tentang tes yang dijalankan dengan cepat (dan mereka sebaiknya melakukannya, karena Anda menjalankan tes setiap 30 detik atau lebih). Mungkin Anda berpikir ATDD atau BDD?

— guillaume31

1

@ ian31: contoh sempurna dari penggabungan UT dan TDD. Harus tidak setuju, dan merujuk Anda ke beberapa bahan sumber en.wikipedia.org/wiki/Test-driven_development - tujuan dari tes ini adalah untuk menentukan persyaratan kode . BDD bagus. Tidak pernah mendengar ATDD, tapi sekilas memang terlihat seperti bagaimana saya menerapkan skala TDD .

— Steven A. Lowe

Anda dapat menggunakan TDD dengan baik untuk merancang kode teknis yang tidak terkait langsung dengan persyaratan atau kisah pengguna. Anda akan menemukan banyak contoh tentang hal itu di web, dalam buku, konferensi, termasuk dari orang-orang yang memprakarsai TDD dan mempopulerkannya. TDD adalah disiplin, teknik untuk menulis kode, itu tidak akan berhenti menjadi TDD tergantung pada konteks di mana Anda menggunakannya.

— guillaume31

Juga, dari artikel Wikipedia yang Anda sebutkan: "Praktik lanjutan pengembangan yang didorong oleh pengujian dapat mengarah pada ATDD di mana kriteria yang ditentukan oleh pelanggan diotomatiskan ke dalam tes penerimaan, yang kemudian mendorong proses pengembangan tradisional yang digerakkan oleh unit test-driven development (UTDD). [ ...] Dengan ATDD, tim pengembangan sekarang memiliki target spesifik untuk dipenuhi, tes penerimaan, yang membuat mereka terus fokus pada apa yang benar-benar diinginkan pelanggan dari kisah pengguna itu. " Yang tampaknya menyiratkan ATDD terutama difokuskan pada persyaratan, bukan TDD (atau UTDD seperti yang mereka katakan).

— guillaume31

@ ian31: Pertanyaan OP tentang 'membuang beberapa ratus unit tes' menunjukkan kebingungan skala. Anda dapat menggunakan TDD untuk membangun gudang jika diinginkan. : D

— Steven A. Lowe

3

Pengembangan yang digerakkan oleh tes dimaksudkan untuk mendorong pengembangan Anda. Tes yang Anda tulis membantu Anda menegaskan kebenaran kode yang sedang Anda tulis dan meningkatkan kecepatan pengembangan dari baris pertama dan seterusnya.

Anda tampaknya percaya bahwa tes adalah beban dan hanya dimaksudkan untuk pengembangan tambahan nanti. Garis pemikiran ini tidak sejalan dengan TDD.

Mungkin Anda dapat membandingkannya dengan pengetikan statis: meskipun seseorang dapat menulis kode tanpa menggunakan informasi jenis statis, menambahkan jenis statis ke kode membantu dalam menegaskan sifat-sifat tertentu dari kode, membebaskan pikiran dan memungkinkan fokus pada struktur penting sebagai gantinya, sehingga meningkatkan kecepatan dan kemanjuran.

— Dibbeke
sumber

2

Masalah dengan melakukan refactoring besar adalah Anda bisa dan kadang-kadang akan mengikuti jalan yang membuat Anda sadar bahwa Anda telah menggigit lebih banyak daripada yang bisa Anda kunyah. Refactoring raksasa adalah kesalahan. Jika desain sistem cacat sejak awal, maka refactoring hanya akan membawa Anda sejauh ini sebelum Anda harus membuat keputusan sulit. Baik meninggalkan sistem apa adanya dan bekerja di sekitarnya, atau berencana untuk mendesain ulang dan membuat beberapa perubahan besar.

Namun ada cara lain. Manfaat nyata dari kode refactoring adalah membuat segala sesuatunya lebih sederhana, lebih mudah dibaca, dan bahkan lebih mudah dipelihara. Di mana Anda mendekati masalah yang memiliki ketidakpastian, Anda lonjakan perubahan, melangkah sejauh ini untuk melihat di mana itu mengarah untuk mempelajari lebih lanjut tentang masalah, kemudian membuang lonjakan, dan menerapkan refactoring baru berdasarkan pada apa lonjakan mengajarimu. Masalahnya, Anda benar-benar hanya dapat meningkatkan kode Anda dengan pasti jika langkah-langkahnya kecil dan upaya refactoring Anda tidak menyerbu kemampuan Anda untuk menulis tes Anda terlebih dahulu. Godaannya adalah menulis tes, lalu kode, lalu kode lagi karena sebuah solusi mungkin tampak jelas, tetapi segera Anda menyadari bahwa perubahan Anda akan mengubah lebih banyak tes, jadi Anda harus berhati-hati untuk hanya mengubah satu hal pada satu waktu.

Karena itu jawabannya adalah jangan pernah menjadikan refactoring Anda sebagai yang utama. Langkah kecil. Mulai dengan mengekstraksi metode, lalu lihat untuk menghapus duplikasi. Kemudian pindah ke kelas penggalian. Masing-masing dalam langkah kecil satu perubahan kecil pada satu waktu. JIKA Anda mengekstraksi kode, tulis tes terlebih dahulu. Jika Anda menghapus kode, maka hapus dan jalankan tes Anda, dan putuskan apakah tes yang rusak akan diperlukan lagi. Satu bayi mungil melangkah sekaligus. Sepertinya itu akan memakan waktu lebih lama, tetapi sebenarnya akan mempersingkat waktu refactoring Anda.

Namun kenyataannya adalah bahwa setiap lonjakan tampaknya merupakan pemborosan usaha yang potensial. Perubahan kode terkadang tidak ke mana-mana, dan Anda menemukan diri Anda memulihkan kode dari vcs. Ini hanya kenyataan dari apa yang kita lakukan dari hari ke hari. Namun setiap lonjakan yang gagal tidak sia-sia, jika itu mengajarkan Anda sesuatu. Setiap upaya refactoring yang gagal akan mengajarkan Anda bahwa Anda mencoba melakukan terlalu banyak terlalu cepat, atau bahwa pendekatan Anda mungkin salah. Itu juga bukan buang-buang waktu jika Anda belajar sesuatu darinya. Semakin banyak Anda melakukan hal ini, semakin banyak Anda belajar dan semakin efisien Anda jadinya. Saran saya adalah hanya memakainya untuk saat ini, belajar untuk melakukan lebih banyak dengan melakukan lebih sedikit, dan menerima bahwa ini adalah hal yang mungkin perlu sampai Anda menjadi lebih baik dalam mengidentifikasi seberapa jauh untuk mengambil lonjakan sebelum itu membawa Anda ke mana-mana.

— S.Robins
sumber

1

Saya tidak yakin tentang alasan mengapa pendekatan Anda ternyata cacat setelah 3 hari. Bergantung pada ketidakpastian dalam arsitektur Anda, Anda dapat mempertimbangkan untuk mengubah strategi pengujian Anda:

Jika Anda tidak yakin tentang kinerja, Anda mungkin ingin memulai dengan beberapa tes integrasi yang menyatakan kinerja?
Ketika kompleksitas API adalah apa yang Anda selidiki, tulis beberapa tes unit kecil yang nyata, untuk mengetahui apa yang akan menjadi cara terbaik untuk melakukannya. Jangan repot-repot mengimplementasikan apa pun, buat saja kelas Anda mengembalikan nilai yang dikodekan atau buat mereka membuang NotImplementedExceptions.

— Boris Callens
sumber

0

Bagi saya tes unit juga sebagai kesempatan untuk menempatkan antarmuka di bawah penggunaan "nyata" (well, senyata unit test pergi!).

Jika saya dipaksa untuk melakukan tes saya harus menjalankan desain saya. Ini membantu menjaga hal-hal tetap waras (jika ada sesuatu yang begitu rumit sehingga menulis ujian untuk itu adalah beban, bagaimana rasanya menggunakannya?).

Ini tidak menghindari perubahan dalam desain, melainkan memperlihatkan kebutuhan mereka. Ya, penulisan ulang yang lengkap adalah rasa sakit. Untuk (mencoba) menghindarinya, saya biasanya membuat (satu atau lebih) prototipe, mungkin dengan Python (dengan pengembangan akhir dalam c ++).

Memang, Anda tidak selalu punya waktu untuk semua barang ini. Itulah tepatnya kasus ketika Anda akan membutuhkan jumlah waktu yang LEBIH BESAR untuk mencapai tujuan Anda ... dan / atau untuk menjaga semuanya terkendali.

— Francesco
sumber

0

Selamat datang di sirkus pengembang kreatif .

Alih-alih menghormati semua cara 'legal / masuk akal' untuk kode pada awalnya,
cobalah intuisi , terutama jika itu penting dan baru untuk Anda dan jika tidak ada sampel di sekitar yang Anda inginkan:

- Tulis dengan naluri Anda, dari hal-hal yang sudah Anda ketahui , tidak dengan mental dan imajinasi Anda.
- Dan berhenti.
- Ambil kaca pembesar dan periksa semua kata yang Anda tulis: Anda menulis "teks" karena "teks" dekat dengan String, tetapi "kata kerja", "kata sifat" atau sesuatu yang lebih akurat diperlukan, baca lagi dan sesuaikan metode dengan pengertian baru
. .. atau, Anda menulis sepotong kode memikirkan masa depan? hapus
- Benar, lakukan tugas lain (olahraga, budaya, atau hal lain di luar bisnis), kembali dan baca lagi.
- Semua cocok,
- Benar, lakukan tugas lain, kembali dan baca lagi.
- Semua cocok, beralih ke TDD
- Sekarang semuanya benar, bagus
- Coba patok untuk menunjukkan hal-hal yang akan dioptimalkan, lakukanlah.

Apa yang muncul:
- Anda menulis kode yang menghormati semua aturan
- Anda mendapatkan pengalaman, cara baru untuk bekerja,
- sesuatu berubah dalam pikiran Anda, Anda tidak akan pernah takut dengan konfigurasi baru.

Dan sekarang, jika Anda melihat UML yang terlihat seperti di atas, Anda akan dapat mengatakan
"Bos, saya mulai dengan TDD untuk ini ...."
itu adalah hal baru lainnya?
"Bos, saya akan mencoba sesuatu sebelum memutuskan cara saya akan kode .."

Salam dari PARIS
Claude

— cl-r
sumber