Halo, Habr!
Saya membawa perhatian Anda pada terjemahan dari artikel "
Simple Hickey " oleh Robert C. Martin (Paman Bob).
Rich Hickey menyampaikan kuliah istimewa tentang Strange Loop berjudul Simple, Easy. Saya sangat menyarankan Anda menghabiskan satu jam mendengarkannya. Kinerja ini bernilai setiap detik.
Akan ada beberapa hal dalam kuliah ini yang tidak Anda setujui. Ketika ini terjadi, berhentilah dan pikirkan - pikirkan dengan serius - apakah Anda benar-benar tidak setuju. Mungkin Anda seharusnya tidak berpikir begitu.
Sebagai contoh, Rich mengatakan beberapa hal yang tampaknya meremehkan tentang TDD dan Agile dan Refactoring, sapi suci dari Komunitas Agile. Jika Anda berkomitmen pada komunitas ini, Anda dapat bereaksi negatif. Tidak perlu Kaya tidak mengabaikan praktik. Dia mengabaikan agama - kecerobohan - kesembronoan.
Rich membandingkan pengujian unit dengan rel pengaman. Lalu dia membuat poin yang sangat bagus. Dia mengatakan bahwa ketika Anda memiliki kesalahan, maka kesalahan ini lulus tes Anda. Dan sekarang apa? Anda sekarang harus menemukan kesalahan. Dan jika sistemnya tidak sederhana, itu tidak akan mudah. (Harap perhatikan bahwa saya menggunakan kata-kata di sini secara sederhana dan mudah. Awal dari pidato Rich dihubungkan dengan definisi berbeda yang dimiliki oleh kata-kata ini. Saya sarankan Anda berhenti di tempat ini dan mendengarkan sepuluh menit pertama pidatonya, dan kemudian kembali ke paragraf ini lagi.)
Rich menekankan bahwa pelari cepat, tetapi tidak lama. Dia kemudian mengatakan bahwa Agile "memecahkan" masalah ini dengan hanya menembakkan pistol mulai lagi dan lagi secara berurutan. Dia menyeringai dan hadirin tertawa. Dia kemudian melanjutkan dengan mengatakan bahwa sprint berkelanjutan tidak selalu membuat sistem sederhana, dan kesederhanaan adalah kunci kecepatan.
Tentu saja dia benar. Martin Fowler membicarakan hal ini dalam artikelnya “Flaccid Scrum”. Dan itulah yang banyak dari kita dalam komunitas Agile telah ungkapkan. Iterasi singkat seperti itu tanpa praktik teknis yang baik tidak mengarah pada perkembangan yang cepat. Sebaliknya, itu menyebabkan kekacauan.
Rich menertawakan ide bahwa test suite akan memungkinkan Anda untuk mengubah kode. Dia mengatakan bahwa tes adalah jaring pengaman, tidak lebih. Kami TDDers tahu bahwa test suite diperlukan jika kami ingin mengubah kode tanpa rasa takut. Tapi Rich benar tentang jaring pengaman. Sistem keamanan dapat membantu Anda menyederhanakan sistem Anda jika sudah sederhana. Tetapi sistem keamanan di bawah gumpalan tanah besar akan memiliki sedikit bantuan dalam mengungkap kekacauan. Oh, jangan salah paham. Saya perlu tes ini! Namun pekerjaan itu tidak akan mudah. (lagi kata ini).
Berikut ini pembicaraan lain dari Rich: Hammock Driven Development, di mana ia mendorong kita untuk berpikir, dan tidak hanya menulis potongan-potongan kode.
Jadi ini dia. Rich khawatir, dan memang benar, bahwa kita memiliki budaya yang kompleks. Ketika tugas diatur untuk programmer, mereka berjalan maju dan menulis banyak kode yang membingungkan, menggunakan kerangka kerja dan alat "sederhana", tanpa memberikan masalah signifikansi yang tepat. Apa yang kita bingungkan ringan dengan kesederhanaan. (Misalnya, Rails itu mudah, tetapi itu tidak mudah.) Keluhannya tentang tes adalah bahwa kami menggunakannya untuk mengganti pikiran. Yang baik bagi kami, karena kami menulis tes, tetapi pada kenyataannya kami tidak menghabiskan cukup waktu pada masalah yang layak. Kami tidak menyederhanakan masalah. Kami hanya melakukan apa yang mudah.
Jadi, sebenarnya, komunitas Agile dan seluruh komunitas perangkat lunak terinfeksi dengan penyakit ini. Terlalu sering kita melakukan apa yang mudah, karena apa yang sederhana. Jadi kami membuat kekacauan. Tapi itu bukan nilai kelincahan sekarang dan tidak akan pernah ada. Dan ini, tentu saja, bukan nilai penguasaan perangkat lunak! Memang, melakukan apa yang sederhana, tidak seperti apa yang mudah, adalah salah satu ciri khas penyihir perangkat lunak.
Pada akhirnya, saya pikir persepsi TDD Rich terdistorsi oleh apa yang dilihatnya di industri. Jujur, saya pikir dia melewatkan beberapa detail. Dan saya pikir dia akan mengerti bahwa latihan ini akan bermanfaat baginya juga bagi saya. Bukan sebagai cara untuk menghindari berpikir dan membuat diri Anda berantakan, tetapi sebagai cara yang disiplin untuk detail, hati-hati dan bijaksana.
Sekarang tanyakan pada diri sendiri apa arti TDD bagi Anda. Apakah TDD disiplin yang Anda gunakan untuk mempermudah? Atau apakah itu disiplin yang Anda gunakan untuk berpikir, berhati-hati dan tidak mempersulit?