Apakah batasan Pengembangan yang Didorong Uji (dan Agile secara umum) praktis relevan?


30

Dalam Test Driven Development (TDD) Anda mulai dengan solusi suboptimal dan kemudian menghasilkan yang lebih baik dengan menambahkan kasus uji dan dengan refactoring. Langkah-langkahnya seharusnya kecil, yang berarti bahwa setiap solusi baru akan entah bagaimana berada di lingkungan yang sebelumnya.

Ini menyerupai metode optimasi lokal matematika seperti gradient descent atau pencarian lokal. Keterbatasan yang terkenal dari metode tersebut adalah bahwa mereka tidak menjamin untuk menemukan optimum global, atau bahkan optimum lokal yang dapat diterima. Jika titik awal Anda dipisahkan dari semua solusi yang dapat diterima oleh sebagian besar solusi buruk, tidak mungkin untuk sampai ke sana dan metode ini akan gagal.

Untuk lebih spesifik: Saya sedang memikirkan sebuah skenario di mana Anda telah menerapkan sejumlah kasus uji dan kemudian menemukan bahwa kasus uji berikutnya akan memerlukan pendekatan yang sangat berbeda. Anda harus membuang pekerjaan sebelumnya dan memulai lagi dari awal.

Pemikiran ini sebenarnya dapat diterapkan pada semua metode gesit yang berjalan dalam langkah-langkah kecil, tidak hanya untuk TDD. Apakah analogi yang diajukan antara TDD dan pengoptimalan lokal ini memiliki kelemahan serius?


Apakah Anda mengacu pada sub-teknik TDD yang disebut triangulasi ? Dengan "solusi yang dapat diterima", apakah yang Anda maksudkan adalah solusi yang benar atau dapat dipertahankan / elegan / dapat dibaca?
guillaume31

6
Saya pikir ini adalah masalah nyata. Karena itu hanya pendapat saya, saya tidak akan menulis jawaban. Tapi ya, karena TDD disebut-sebut sebagai praktik desain , itu adalah cacat yang dapat mengarah ke maxima lokal atau tidak ada solusi sama sekali. Saya akan mengatakan secara umum TDD TIDAK cocok untuk desain algoritmik. Lihat diskusi terkait pada batasan TDD: Memecahkan Sudoku dengan TDD , di mana Ron Jeffries membuat kelakuannya sendiri sambil berjalan berputar-putar dan "melakukan TDD", sementara Peter Norvig memberikan solusi aktual dengan benar-benar mengetahui tentang pokok permasalahan,
Andres F.

5
Dengan kata lain, saya akan menawarkan (semoga) pernyataan tidak kontroversial bahwa TDD baik untuk meminimalkan jumlah kelas yang Anda tulis dalam masalah "dikenal", karena itu menghasilkan kode yang lebih bersih dan sederhana, tetapi tidak cocok untuk masalah algoritmik atau untuk masalah kompleks di mana sebenarnya melihat gambaran besar dan memiliki pengetahuan khusus domain lebih berguna daripada menulis tes sedikit demi sedikit dan "menemukan" kode yang harus Anda tulis.
Andres F.

2
Masalahnya ada, tetapi tidak terbatas pada TDD atau bahkan Agile. Mengubah persyaratan yang berarti desain perangkat lunak yang ditulis sebelumnya harus berubah terjadi setiap saat.
RemcoGerlich

@ guillaume31: Tidak perlu triangulasi tetapi teknik apa pun yang menggunakan iterasi pada tingkat kode sumber. Dengan solusi yang dapat diterima, maksud saya yang lulus semua tes dan dapat dipertahankan dengan cukup baik ..
Frank Puffer

Jawaban:


8

Keterbatasan yang terkenal dari metode tersebut adalah bahwa mereka tidak menjamin untuk menemukan optimum global, atau bahkan optimum lokal yang dapat diterima.

Untuk membuat perbandingan Anda lebih memadai: untuk beberapa jenis masalah, algoritme pengulangan berulang sangat mungkin menghasilkan optima lokal yang baik, untuk beberapa situasi lain, mereka bisa gagal.

Saya sedang memikirkan sebuah skenario di mana Anda telah menerapkan sejumlah kasus uji dan kemudian menemukan bahwa kasus uji berikutnya akan memerlukan pendekatan yang sangat berbeda. Anda harus membuang pekerjaan sebelumnya dan memulai lagi dari awal.

Saya bisa membayangkan situasi di mana ini bisa terjadi dalam kenyataan: ketika Anda memilih arsitektur yang salah dengan cara yang Anda butuhkan untuk membuat ulang semua tes yang ada lagi dari awal. Katakanlah Anda mulai menerapkan 20 kasus pengujian pertama Anda dalam bahasa pemrograman X pada sistem operasi A. Sayangnya, persyaratan 21 mencakup bahwa seluruh program perlu dijalankan pada sistem operasi B, di mana X tidak tersedia. Dengan demikian, Anda perlu membuang sebagian besar pekerjaan Anda dan mengimplementasikan kembali dalam bahasa Y. (Tentu saja, Anda tidak akan membuang kode sepenuhnya, tetapi port itu ke bahasa dan sistem baru.)

Ini mengajarkan kita, bahkan ketika menggunakan TDD, adalah ide yang baik untuk melakukan beberapa analisis & desain secara keseluruhan sebelumnya. Namun, ini juga berlaku untuk jenis pendekatan lain, jadi saya tidak melihat ini sebagai masalah TDD yang melekat. Dan, untuk sebagian besar tugas pemrograman dunia nyata Anda hanya dapat memilih arsitektur standar (seperti bahasa pemrograman X, sistem operasi Y, sistem basis data Z pada perangkat keras XYZ), dan Anda dapat relatif yakin bahwa metodologi iteratif atau gesit seperti TDD tidak akan membawa Anda ke jalan buntu.

Mengutip Robert Harvey: "Anda tidak dapat menumbuhkan arsitektur dari unit test." Atau pdr: "TDD tidak hanya membantu saya mencapai desain akhir terbaik, ini membantu saya sampai di sana dalam upaya yang lebih sedikit."

Jadi sebenarnya apa yang Anda tulis

Jika titik awal Anda dipisahkan dari semua solusi yang dapat diterima oleh sebagian besar solusi buruk, tidak mungkin untuk sampai ke sana dan metode ini akan gagal.

mungkin menjadi kenyataan - ketika Anda memilih arsitektur yang salah, Anda cenderung tidak mencapai solusi yang diperlukan dari sana.

Di sisi lain, ketika Anda melakukan perencanaan keseluruhan sebelumnya dan memilih arsitektur yang tepat, menggunakan TDD harus seperti memulai algoritma pencarian berulang di area di mana Anda dapat mencapai "global maksimum" (atau setidaknya maksimum cukup baik) ) dalam beberapa siklus.


20

Saya tidak berpikir TDD memiliki masalah maxima lokal. Kode yang Anda tulis mungkin, seperti yang telah Anda perhatikan dengan benar, tetapi itulah sebabnya refactoring (menulis ulang kode tanpa mengubah fungsi) sudah ada. Pada dasarnya, ketika tes Anda meningkat, Anda dapat menulis ulang bagian signifikan dari model objek Anda jika Anda perlu sambil menjaga perilaku tidak berubah berkat tes. Tes nyatakan kebenaran invarian tentang sistem Anda yang, oleh karena itu, harus valid baik secara lokal maupun maksimum.

Jika Anda tertarik pada masalah yang berkaitan dengan TDD, saya dapat menyebutkan tiga yang berbeda yang sering saya pikirkan:

  1. Masalah kelengkapan : berapa banyak tes yang diperlukan untuk menggambarkan sistem sepenuhnya? Apakah "pengkodean dengan contoh kasus" merupakan cara lengkap untuk menggambarkan suatu sistem?

  2. Masalah pengerasan : apa pun antarmuka pengujian, perlu memiliki antarmuka yang tidak dapat diubah. Tes mewakili kebenaran invarian , ingat. Sayangnya kebenaran-kebenaran ini tidak diketahui sama sekali untuk sebagian besar kode yang kita tulis, paling-paling hanya untuk objek yang menghadap ke luar.

  3. Masalah kerusakan pengujian : untuk membuat pernyataan dapat diuji, kita mungkin perlu menulis kode suboptimal (misalnya, kurang performan). Bagaimana kita menulis tes sehingga kodenya sebagus mungkin?


Diedit untuk menanggapi komentar: inilah contoh mengecualikan maksimum lokal untuk fungsi "ganda" melalui refactoring

Tes 1: ketika input adalah 0, kembalikan nol

Pelaksanaan:

function double(x) {
  return 0; // simplest possible code that passes tests
}

Refactoring: tidak diperlukan

Tes 2: ketika input 1, kembalikan 2

Pelaksanaan:

function double(x) {
  return x==0?0:2; // local maximum
}

Refactoring: tidak diperlukan

Tes 3: ketika input 2, kembalikan 4

Pelaksanaan:

function double(x) {
  return x==0?0:x==2?4:2; // needs refactoring
}

Refactoring:

function double(x) {
  return x*2; // new maximum
}

1
Apa yang saya alami adalah desain pertama saya hanya berfungsi untuk beberapa kasus sederhana dan kemudian saya menyadari bahwa saya membutuhkan solusi yang lebih umum. Mengembangkan solusi yang lebih umum memerlukan lebih banyak tes sementara tes asli untuk kasus khusus tidak akan berfungsi lagi. Saya menemukan itu dapat diterima untuk (sementara) menghapus tes-tes itu sementara saya mengembangkan solusi yang lebih umum, menambahkannya kembali setelah waktu siap.
5gon12eder

3
Saya tidak yakin refactoring adalah cara untuk menggeneralisasi kode (di luar ruang "pola desain" buatan, tentu saja) atau keluar dari maxima lokal. Refactoring merapikan kode, tetapi itu tidak akan membantu Anda menemukan solusi yang lebih baik.
Andres F.

2
@ Klivvz Dipahami, tapi saya tidak berpikir itu bekerja seperti itu di luar contoh mainan seperti yang Anda posting. Juga, ini membantu Anda bahwa fungsi Anda bernama "ganda"; dengan cara Anda sudah tahu jawabannya. TDD pasti membantu ketika Anda lebih atau kurang tahu jawabannya tetapi ingin menuliskannya dengan "bersih". Itu tidak akan membantu untuk menemukan algoritma atau menulis kode yang sangat kompleks. Inilah sebabnya mengapa Ron Jeffries gagal memecahkan Sudoku dengan cara ini; Anda tidak dapat menerapkan algoritme yang tidak Anda kenal dengan TDD karena tidak jelas.
Andres F.

1
@VaughnCato Ok, sekarang saya dalam posisi mempercayai Anda atau bersikap skeptis (yang akan kasar, jadi jangan lakukan itu). Katakan saja, dalam pengalaman saya, itu tidak berfungsi seperti yang Anda katakan. Saya belum pernah melihat algoritma yang cukup rumit berkembang dari TDD. Mungkin pengalaman saya terlalu terbatas :)
Andres F.

2
@ Klivvz "Selama Anda bisa menulis tes yang tepat" adalah intinya: kedengarannya seperti memohon pertanyaan kepada saya. Apa yang saya katakan adalah bahwa Anda sering tidak bisa . Memikirkan algoritma atau pemecah masalah tidak menjadi lebih mudah dengan menulis tes terlebih dahulu . Anda harus melihat seluruh gambar terlebih dahulu . Skenario mencoba tentu saja perlu, tetapi perhatikan TDD bukan tentang menulis skenario: TDD adalah tentang tes mengemudi desain ! Anda tidak dapat menjalankan desain solver Sudoku (atau solver baru untuk game lain) dengan menulis tes terlebih dahulu. Sebagai bukti anekdotidal (yang tidak cukup): Jeffries tidak bisa.
Andres F.

13

Apa yang Anda gambarkan dalam istilah matematika adalah apa yang kami sebut melukis diri sendiri ke sudut. Kejadian ini hampir tidak eksklusif untuk TDD. Di air terjun, Anda dapat mengumpulkan dan menuangkan persyaratan selama berbulan-bulan dengan harapan Anda dapat melihat global max hanya untuk sampai di sana dan menyadari bahwa ada ide yang lebih baik hanya di bukit berikutnya.

Perbedaannya adalah dalam lingkungan yang gesit yang Anda tidak pernah harapkan untuk menjadi sempurna pada titik ini sehingga Anda lebih dari siap untuk membuang ide lama dan pindah ke ide baru.

Lebih spesifik untuk TDD ada teknik untuk mencegah hal ini terjadi pada Anda saat Anda menambahkan fitur di bawah TDD. Ini adalah Prioritas Transformasi . Di mana TDD memiliki cara formal untuk Anda refactor, ini adalah cara formal untuk menambahkan fitur.


13

Dalam jawabannya , @Sklivvz dengan meyakinkan menyatakan bahwa masalahnya tidak ada.

Saya ingin berargumen bahwa itu tidak masalah: premis mendasar (dan raison d'être) dari metodologi iteratif secara umum dan Agile dan khususnya TDD pada khususnya, adalah bahwa tidak hanya optimum global, tetapi juga optimum lokal juga ' tidak diketahui. Jadi, dengan kata lain: meskipun itu masalah, tidak ada jalan lain untuk melakukannya dengan cara yang iteratif. Dengan asumsi bahwa Anda menerima premis dasar.


8

Dapatkah praktik TDD dan Agile berjanji untuk menghasilkan solusi yang optimal? (Atau bahkan solusi "baik"?)

Tidak persis. Tapi, itu bukan tujuan mereka.

Metode-metode ini hanya menyediakan "jalan aman" dari satu negara ke negara lain, mengakui bahwa perubahan memakan waktu, sulit, dan berisiko. Dan inti dari kedua praktik tersebut adalah untuk memastikan bahwa aplikasi dan kode tersebut layak dan terbukti memenuhi persyaratan dengan lebih cepat dan lebih teratur.

... [TDD] menentang pengembangan perangkat lunak yang memungkinkan perangkat lunak ditambahkan yang tidak terbukti memenuhi persyaratan ... Kent Beck, yang dianggap telah mengembangkan atau 'menemukan kembali' teknik tersebut, menyatakan pada tahun 2003 bahwa TDD mendorong sederhana mendesain dan menginspirasi kepercayaan. ( Wikipedia )

TDD berfokus pada memastikan setiap "potongan" kode memenuhi persyaratan. Secara khusus, ini membantu memastikan bahwa kode memenuhi persyaratan yang sudah ada sebelumnya, yang bertentangan dengan membiarkan persyaratan didorong oleh pengkodean yang buruk. Tapi, itu tidak membuat janji bahwa implementasinya "optimal" dengan cara apa pun.

Adapun proses Agile:

Perangkat lunak yang berfungsi adalah ukuran utama dari kemajuan ... Pada akhir setiap iterasi, pemangku kepentingan dan perwakilan pelanggan meninjau kemajuan dan mengevaluasi kembali prioritas dengan maksud untuk mengoptimalkan laba atas investasi ( Wikipedia )

Agility tidak mencari solusi optimal ; hanya solusi yang berfungsi - dengan tujuan mengoptimalkan ROI . Ini menjanjikan solusi yang bekerja lebih cepat daripada nanti ; bukan yang "optimal".

Tapi, tidak apa-apa, karena pertanyaannya salah.

Optimal dalam pengembangan perangkat lunak adalah fuzzy, target yang bergerak. Persyaratan biasanya dalam fluks dan penuh dengan rahasia yang hanya muncul, sangat memalukan Anda, di ruang konferensi yang penuh dengan bos bos Anda. Dan "kebaikan intrinsik" dari arsitektur dan pengkodean solusi dinilai oleh pendapat yang dibagi dan subyektif dari rekan-rekan Anda dan pendapat manajerial Anda - tidak seorang pun di antara mereka yang mungkin benar-benar mengetahui apa pun tentang perangkat lunak yang baik.

Dalam Paling tidak, TDD dan Agile praktek mengakui kesulitan dan mencoba untuk mengoptimalkan untuk dua hal yang yang obyektif dan terukur: . Bekerja v Tidak-Bekerja dan Sooner v Nanti..

Dan, bahkan jika kita memiliki "bekerja" dan "lebih cepat" sebagai metrik objektif, kemampuan Anda untuk mengoptimalkannya terutama bergantung pada keterampilan dan pengalaman tim.


Hal-hal yang dapat Anda tafsirkan sebagai upaya menghasilkan solusi optimal meliputi hal-hal seperti:

dll ..

Apakah masing-masing dari hal - hal itu benar-benar menghasilkan solusi optimal akan menjadi pertanyaan besar lain untuk ditanyakan!


1
Benar, tetapi saya tidak menulis bahwa tujuan TDD atau metode pengembangan perangkat lunak lain adalah solusi optimal dalam arti global optimal. Satu-satunya kekhawatiran saya adalah bahwa metodologi yang didasarkan pada iterasi kecil pada tingkat kode sumber mungkin tidak menemukan solusi yang cukup (baik) sama sekali dalam banyak kasus
Frank Puffer

@ Frank Jawaban saya ditujukan untuk mencakup optimum lokal dan global. Dan jawabannya adalah "Tidak, bukan untuk itulah strategi ini dirancang - mereka dirancang untuk meningkatkan ROI dan mengurangi risiko." ... atau semacam itu. Dan itu sebagian karena jawaban Jörg: "optimum" adalah target yang bergerak. ... Aku bahkan mengambilnya selangkah lebih maju; mereka tidak hanya bergerak target, tetapi, mereka tidak sepenuhnya objektif atau terukur.
svidgen

@ Frankpuffer Mungkin ada baiknya ditambah. Tapi, intinya adalah, Anda bertanya apakah kedua hal ini mencapai sesuatu yang sama sekali tidak dirancang atau dimaksudkan untuk dicapai. Lebih dari itu, Anda bertanya apakah mereka dapat mencapai sesuatu yang bahkan tidak dapat diukur atau diverifikasi.
svidgen

@FrankPuffer Bah. Saya mencoba memperbarui jawaban saya untuk mengatakannya lebih baik. Saya tidak yakin saya membuatnya lebih baik atau lebih buruk! ... Tapi, saya harus turun SE.SE dan kembali bekerja.
svidgen

Jawaban ini boleh saja, tetapi masalah yang saya miliki dengan itu (seperti dengan beberapa jawaban lainnya) adalah bahwa "mengurangi risiko dan meningkatkan ROI" tidak selalu merupakan tujuan terbaik. Mereka sebenarnya bukan tujuan dengan sendirinya. Ketika Anda membutuhkan sesuatu untuk bekerja, mengurangi risiko tidak akan memotongnya. Terkadang langkah-langkah kecil yang relatif tidak terarah seperti pada TDD tidak akan berhasil - Anda akan meminimalkan risiko dengan baik, tetapi pada akhirnya Anda tidak akan mencapai tempat yang berguna.
Andres F.

4

Satu hal yang tidak ada yang ditambahkan sejauh ini adalah bahwa "Pengembangan TDD" yang Anda gambarkan sangat abstrak dan tidak realistis. Mungkin seperti itu dalam aplikasi matematika di mana Anda mengoptimalkan suatu algoritma tetapi itu tidak banyak terjadi dalam aplikasi bisnis yang paling banyak dikerjakan oleh pembuat kode.

Di dunia nyata, tes Anda pada dasarnya menjalankan dan memvalidasi Aturan Bisnis:

Misalnya - Jika seorang pelanggan berusia 30 tahun yang tidak merokok dengan seorang istri dan dua anak, kategori premiumnya adalah "x" dll.

Anda tidak akan mengubah mesin penghitungan premium secara iteratif hingga benar untuk waktu yang lama - dan hampir pasti tidak saat aplikasi aktif;).

Apa yang sebenarnya Anda buat adalah jaring pengaman sehingga ketika metode perhitungan baru ditambahkan untuk kategori pelanggan tertentu, semua aturan lama tidak tiba-tiba rusak dan memberikan jawaban yang salah. Jaring pengaman bahkan lebih berguna jika langkah pertama debugging adalah membuat tes (atau serangkaian tes) yang mereproduksi kesalahan sebelum menulis kode untuk memperbaiki bug. Kemudian, satu tahun ke belakang, jika seseorang secara tidak sengaja menciptakan kembali bug asli, unit test istirahat sebelum kode bahkan diperiksa. Ya, satu hal yang memungkinkan TDD adalah bahwa Anda sekarang dapat melakukan refactoring dan merapikan barang-barang dengan percaya diri. tetapi itu seharusnya tidak menjadi bagian besar dari pekerjaan Anda.


1
Pertama, ketika saya membaca jawaban Anda, saya berpikir "ya, itulah intinya". Tetapi setelah memikirkan kembali pertanyaan itu, saya pikir itu tidak harus begitu abstrak atau tidak realistis. Jika salah memilih arsitektur yang sepenuhnya salah, TDD tidak akan menyelesaikannya, tidak setelah 1000 iterasi.
Doc Brown

@Doc Brown Setuju, itu tidak akan menyelesaikan masalah itu. Tapi itu akan memberi Anda serangkaian tes yang menjalankan setiap asumsi dan aturan bisnis sehingga Anda dapat memperbaiki arsitektur secara iteratif. Arsitektur sangat buruk sehingga perlu menulis ulang untuk memperbaikinya sangat jarang (saya harap) dan bahkan dalam kasus yang ekstrim tes unit aturan bisnis akan menjadi titik awal yang baik.
mcottle

Ketika saya mengatakan "arsitektur yang salah", saya memiliki kasus di mana orang perlu membuang test suite yang ada. Apakah Anda membaca jawaban saya?
Doc Brown

@DocBrown - Ya saya lakukan. Jika Anda bermaksud "arsitektur yang salah" berarti "mengubah seluruh test suite" mungkin Anda harus mengatakan itu. Mengubah Arsitektur tidak berarti bahwa Anda harus membuang semua tes jika didasarkan pada Aturan Bisnis. Anda mungkin harus mengubah semuanya untuk mendukung antarmuka baru yang Anda buat dan bahkan sepenuhnya menulis ulang beberapa, tetapi Aturan Bisnis tidak akan digantikan oleh perubahan teknis sehingga tes akan tetap. Tentu saja berinvestasi dalam unit test tidak boleh disangkal oleh kemungkinan yang tidak mungkin untuk sepenuhnya meningkatkan arsitektur
mcottle

yakin, bahkan jika seseorang perlu menulis ulang setiap tes dalam bahasa pemrograman baru, seseorang tidak perlu membuang semuanya, setidaknya satu dapat port logika yang ada. Dan saya setuju untuk Anda 100% untuk proyek-proyek besar dunia nyata, asumsi dalam pertanyaan ini sangat tidak realistis.
Doc Brown

3

Saya tidak berpikir itu akan menghalangi. Sebagian besar tim tidak memiliki siapa pun yang mampu menghasilkan solusi optimal bahkan jika Anda menuliskannya di papan tulis mereka. TDD / Agile tidak akan menghalangi mereka.

Banyak proyek tidak memerlukan solusi optimal dan yang diperlukan, waktu, energi dan fokus yang diperlukan akan dibuat di bidang ini. Seperti semua hal lain yang cenderung kita bangun, pertama, buat itu bekerja. Kemudian membuatnya cepat. Anda bisa melakukan ini dengan semacam prototipe jika kinerjanya begitu penting dan kemudian membangun kembali semuanya dengan kebijaksanaan yang diperoleh melalui banyak iterasi.

Saya sedang memikirkan sebuah skenario di mana Anda telah menerapkan sejumlah kasus uji dan kemudian menemukan bahwa kasus uji berikutnya akan memerlukan pendekatan yang sangat berbeda. Anda harus membuang pekerjaan sebelumnya dan memulai lagi dari awal.

Ini bisa terjadi, tetapi yang lebih mungkin terjadi adalah ketakutan untuk mengubah bagian aplikasi yang kompleks. Tidak melakukan tes apa pun dapat menciptakan rasa takut yang lebih besar di bidang ini. Satu keuntungan dari TDD dan memiliki serangkaian pengujian adalah bahwa Anda membangun sistem ini dengan anggapan bahwa itu perlu diubah. Ketika Anda menemukan solusi optimal monolitik ini sejak awal, mungkin sangat sulit untuk berubah.

Juga, letakkan ini dalam konteks kekhawatiran Anda akan optimasi yang kurang, dan Anda tidak bisa tidak menghabiskan waktu untuk mengoptimalkan hal-hal yang seharusnya tidak Anda miliki dan menciptakan solusi yang tidak fleksibel karena Anda terlalu fokus pada kinerja mereka.


0

Dapat menipu untuk menerapkan konsep matematika seperti "optimal lokal" untuk desain perangkat lunak. Menggunakan istilah seperti itu membuat pengembangan perangkat lunak terdengar jauh lebih terukur dan ilmiah daripada yang sebenarnya. Bahkan jika "optimal" ada untuk kode, kita tidak memiliki cara untuk mengukurnya dan oleh karena itu tidak ada cara untuk mengetahui apakah kita telah mencapainya.

Gerakan gesit benar-benar merupakan reaksi terhadap keyakinan bahwa pengembangan perangkat lunak dapat direncanakan dan diprediksi dengan metode matematika. Baik atau buruk, pengembangan perangkat lunak lebih seperti kerajinan daripada sains.


Tapi apakah itu reaksi yang terlalu kuat? Ini jelas membantu dalam banyak kasus di mana perencanaan awal yang ketat terbukti sulit dan mahal. Namun, beberapa masalah perangkat lunak harus ditangani sebagai masalah matematika dan dengan desain awal. Anda tidak dapat TDD mereka. Anda dapat TDD UI dan desain keseluruhan Photoshop, tetapi Anda tidak dapat TDD algoritme-nya. Mereka bukan contoh sepele seperti menurunkan "jumlah" atau "ganda" atau "pow" dalam contoh TDD khas [1]). Anda mungkin tidak dapat menggoda filter gambar baru dengan menulis beberapa skenario pengujian; Anda benar-benar harus duduk dan menulis serta memahami formula.
Andres F.

2
[1] Sebenarnya, saya cukup yakin fibonacci, yang saya lihat digunakan sebagai contoh / tutorial TDD, lebih atau kurang bohong. Saya berani bertaruh tidak ada yang pernah "menemukan" fibonacci atau seri serupa dengan TDD'ing itu. Semua orang mulai dari yang sudah tahu fibonacci, yang curang. Jika Anda mencoba menemukan ini dengan menggunakannya, kemungkinan Anda akan menemui jalan buntu yang ditanyakan oleh OP: Anda tidak akan pernah bisa menggeneralisasikan seri dengan hanya menulis lebih banyak tes dan refactoring - Anda harus menerapkan matematika pemikiran!
Andres F.

Dua komentar: (1) Anda benar bahwa ini bisa menipu. Tetapi saya tidak menulis bahwa TDD sama dengan optimasi matematika. Saya hanya menggunakannya sebagai analogi atau model. Saya percaya bahwa matematika dapat (dan harus) diterapkan pada hampir semua hal selama Anda mengetahui perbedaan antara model dan hal yang nyata. (2) Sains (karya ilmiah) biasanya bahkan lebih mudah diprediksi daripada pengembangan perangkat lunak. Dan saya bahkan akan mengatakan bahwa rekayasa perangkat lunak lebih seperti karya ilmiah daripada seperti kerajinan tangan. Kerajinan biasanya membutuhkan lebih banyak pekerjaan rutin.
Frank Puffer

@AndresF .: TDD tidak berarti Anda tidak perlu berpikir atau mendesain. Itu hanya berarti Anda menulis tes sebelum Anda menulis implementasinya. Anda dapat melakukannya dengan algoritma.
JacquesB

@ Frankpuffer: OK, jadi nilai terukur apa yang memiliki "lokal optimal" dalam pengembangan perangkat lunak?
JacquesB
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.