Perhatikan gambar di atas. Terdapat dua buah lemari, lemari untuk peralatan makan dan lemari untuk peralatan kendaraan. Anda diminta untuk mengambil piring. Secara intuisi, anda akan langsung membuka lemari peralatan makan. Tapi apa yang terjadi ketika anda membuka lemari yang anda buka ternyata isinya sangat berantakan. Piring, mangkok, garpu, sendok, pisau dan lain sebagainya tercampur baur. Yang pasti, anda akan kesulitan dalam mengambil piring-piring itu.

Sekarang, perhatikan gambar berikut

Lagi-lagi anda diminta untuk mengambil piring. Apa yang anda lakukan? anda akan langsung membuka lemari dengan tulisan piring, dan langsung mengambil isinya.

Bila anda ditanya, mana yang lebih mudah? apakah dengan susunan lemari gambar pertama atau dengan susunan lemari gambar kedua? Anda pasti menjawab : susunan lemari gambar kedua.

Mengapa susunan lemari gambar kedua lebih memudahkan kita untuk mengambil isinya? hal itu pasti karena isi dari tiap lemari tidak tercampur baur antara satu hal dengan hal lainnya. Mungkin itu adalah analogi yang mirip dalam pembuatan class.

Beberapa tahun saya sebagai developer dengan beberapa team pernah mengalami kebiasaan team yang berbeda-beda. Tapi yang paling sering saya alami adalah team yang relatif malas untuk memecah class yang besar. Biasanya class-class besar itu paling sering terjadi di layer manager / service. Semua bisnis logic masuk pada layer ini. Parahnya adalah sebuah class manager / service bisa memiliki ratusan (bahkan mungkin ribuan) baris code. Ini sudah pasti menyalahi aturan SRP (Single Responsibility Principle). Sekarang banyangkan bila ada kebutuhan untuk merubah bisnis proses di salah satu class manager. susah. susah. Ini sama seperti kita harus mengambil piring pada gambar pertama. Banyak kesemrawutan dalam class.

Saya mulai berpikir mengapa developer sering malas untuk memecah sebuah class agar mengikuti SRP. Salah satu jawaban yang saya miliki adalah mungkin developer takut dengan jumlah class kecil yang banyak daripada class besar yang sedikit. Mereka mungkin beranggapan bahwa untuk mengetahui bagaimana sesuatu bekerja harus melihat pada banyak class. Mereka lebih memilih untuk membuka sebuah lemari yang semrawut untuk mengambil piring, sendok dan garpu daripada harus membuka tiga buah lemari untuk mengambil piring, sendok, dan garpu.

Mungkin bila kita makan di warteg, kita akan terbiasa untuk melihat mereka mencapur tempat untuk piring, sendok dan piring. Tapi bila kita makan di restoran besar, kita akan melihat mereka selalu memisah-misahkan tempat antara piring, sendok ataupun piring. Lebih rapi. Lebih terorganisir. Dan Lebih cepat untuk mengaksesnya.

Sekarang pilihannya, kita akan memilih metode yang sering dilakukan oleh warteg, ataukah memilih metode yang sering dilakukan restoran?????

Membuat suatu kode program berjalan dengan membuat suatu kode program yang bersih (clean code) adalah dua buah hal yang berbeda. Pada saat develop suatu program, sering kali kita hanya memfokuskan pada suatu titik agar kode program kita dapat berjalan. Kita sering kali lupa (atau pura-pura lupa) bahwa kode program yang kita buat juga harus bersih.

Padahal, kode program yang bersih sangat berpengaruh dalam kecepatan pengembangan program. Berikut ini adalah grafik yang relatif memberikan gambaran clean code vs dirty code

Pada grafik di atas, terlihat bahwa pada awal pengembangan, penggunaan dirty code akan menghasilkan jumlah fitur yang sangat tinggi, sayangnya seiring dengan berjalannya waktu, kecepatan penambahan jumlah fitur mulai berkurang.

Pada clean code, awal pengembangan tidak menghasilkan jumlah fitur setinggi dirty code. Akan tetapi, dan pada suatu titik waktu, jumlah jumlah fitur yang dihasilkan oleh clean code melampaui dirty code.

Dalam pengerjaan suatu project, sering saya dihadapkan dengan 3 hal berikut :
1. Cost
2. Time
3. Feature
Dari ketiga hal itu, kita hanya dapat memilih maksimal 2 dari 3.
Bila kita memilih cost yang rendah dan waktu yang cepat, maka kita pasti mengorbankan jumlah fitur.
Bila kita memilih cost yang rendah dan jumlah fitur yang banyak, pasti kita akan membutuhkan waktu pengerjaan yang lama.
Bila kita memilih waktu pengerjaan yang cepat dengan jumlah fitur yang banyak, pasti membutuhkan cost yang besar.

Saya sangat senang dengan anime jepang, mengapa? karena anime-anime jepang selalu membawa semangat untuk mencapai tujuan mereka (mungkin itu beda Indonesia dengan Jepan). Coba lihat di anime Naruto, seorang anak yang tidak bisa apa-apa, akhirnya bisa menjadi seorang super hero. Coba lihat lagi di Bleach, seorang manusia bisa “menerobos” alam ghaib.

Kita mungkin bukan tokoh utama di Naruta atau di Bleach, tapi yang tidak boleh dilupakan adalah semangat mereka. atau mimpi-mimpi mereka. atau harapan-harapan mereka. Mungkin itu yang harus kita contoh sebagai orang yang bekerja dibidang software craftmanship. Saat ini kita mungkin hanya orang biasa di bidang kita. Tapi yang harus kita miliki adalah mimpi suatu saat kita akan menjadi master di software craftmanship. Bahwa suatu saat kita akan menggantikan kedudukan Martin Fowler, Kent Beck, Robert C. Martin, atau para master software craftmanship lainnya.

HARUS BISA!!!
MIMPI BISA DIRAIH DENGAN KERJA KERAS, BUKAN DENGAN JIWA CENGENG !!!

Unit test seharusnya menggunakan FIRST principles agar unit test memberikan nilai lebih dalam penggunaannya.  FIRST principles ini tertuang dalam buku Clean Code karangan Robert C. Martin.

First principles adalah singkatan dari :
1. Fast
2. Independent
3. Repeatable
4. Self-validating
5. Timely

1. FAST
Test harus berjalan dengan cepat.
Bila test berjalan dengan lambat, maka kita akan malas untuk menjalankan unit test. Bila kita malas untuk menjalankan test, maka kita tidak akan sering menemukan bug/error/code smell/design smell untuk diperbaiki. Dan pada akhirnya the software start to rotting!!!

2. INDEPENDENT
Test harus independent terhadap test lainnya.
Bila test tergantung dengan test lain dan terjadi error, maka proses diagnosis menjadi lebih sulit.

3. REPEATABLE
Test harus dapat dijalankan di environment apapun dan menghasilkan hasil yang sama setiap kali test dijalankan.
Bila test tidak menghasilkan behaviour yang sama pada environment yang berbeda, maka kita selalu memiliki alasan untuk mempertahankan diri bahwa program kita (bisa jadi) adalah benar.

4. SELF-VALIDATING
Test hanya boleh menghasilkan 1 dari 2 kondisi, yaitu sukses atau gagal.

5. TIMELY
Test code harus dibuat sebelum production code dibuat.

3. F.I.R.S.T
4. TDD on Three Index Cards

Ketika pertama kali mempelajari TDD, ada beberapa jargon yang menerangkan tentang TDD. Beberapa diantaranya adalah TDD cycle, Three laws of TDD, dan RED-GREEN-REFACTOR.

Setelah googling kesana dan kesini, akhirnya saya mendapat kesimpulan bahwa semua jargon-jargon itu menerangkan sesuatu yang sama persis.

Tetapi yang paling saya suka dari ketiga jargon itu adalah RED-GREEN-REFACTOR. Mengapa? karena dari namanya, saya langsung memahami pengertiannya.

Berikut adelah penjelasan singkat dari masing-masing jargon

TDD CYCLE

Jargon ini saya dapatkan dari buku Test Driven Development : By Example (Karangan Kent Beck)

THREE LAWS OF TDD

Jargon ini saya dapatkan dari buku Clean Code (Karangan Robert C. Martin)

First Law : You may not write production code until you have written a failing unit test.
Second Law : You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
Third Law : You may not write more production code than is sufficient to pass the currently failing test.

RED-GREEN-REFACTOR

Saya tidak tahu pasti darimana jargon ini, akan tetapi jargon ini sudah sangat terkenal untuk menjelaskan apa itu TDD.

Sudah beberapa tahun ini saya belajar dan bekerja dengan java. Pada awal saya belajar, saya mengutamakan penguasaan bahasa dan sertifikasi profesional. Setelah itu, fokus saya berubah pada penguasaan framework.
Saat ini fokus saya berubah lagi, tidak lagi pada penguasaan bahasa ataupun framework, melaikan belajar bagaimana bisa membuat code yang maintanable, clean code, sesuai prinsip OOD, pattern dan lain sebagainya.

Why? mmm, entah mengapa, saya juga bingung. Tapi yang pasti, fokus ini berubah karena ada insting bahwa good developer bukan hanya developer yang bisa menguasai bahasa atau framework secara 100%, tapi good developer adalah orang yang merasa  bahwa kode yang dia buat adalah bagian dari dirinya dan proses development adalah code craftmanship (ya, saya adalah artis yang sedang belajar).

Disini saya tidak mengatakan bahwa belajar framework adalah useless. Tidak. Tidak. Saya tidak mengatakan itu, tapi yang harus disadari adalah time curve belajar bahasa pemrograman ataupun framework relatif pendek. Dari pengalaman saya adalah sekita 2-3 minggu untuk mulai bisa bekerja dengan suatu framework.
Karena perubahan fokus belajar itulah, saya mulai mencari buku, referensi, blog, dsb. Ketika saya mempelajari referensi-referensi itu, timbul masalah baru. Bagaimana saya mempraktekkan semua yang telah saya pelajari?
Googling sana sini, akhirnya saya menemukan jawabannya : CODE KATA.

Untuk mengetahui apa itu code kata, anda bisa mulai dari sini dan sini. Point utama dalam code kata adalah practice!!!

Nb : Para master development seperti Robect C. Martin pun menggunakan code kata…..

Situs-situs yang bagus tentang code kata :
http://www.codekata.com
http://katas.softwarecraftsmanship.org
http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue
http://blog.objectmentor.com/articles/search?q=kata
http://codingkata.org/

TDD Cycle :

1. Add a little test.
2. Run all tests and fail.
3. Make a little change.
4. Run the tests and succeed.
5. Refactor.

Buku Test Driven Design By Example, Karangan Kent Beck (Chapter 1)

Sudah 3 tahun jadi developer java, tapi setiap hari semakin sadar kalo saya bodoh.
Beberapa sertifikasi java sudah saya dapat, tapi ternyata itu bukan jaminan bahwa kita benar-benar mengerti java.
Piuh
Satu yang saya sadar, meski kita terlibat dalam project java, belum tentu ilmu kita bertambah tiap hari.
Ok, mungkin ilmu kita bertambah ketika starting project (belajar framework, belajar konfigurasi, dll), but, ketika project sudah mulai berjalan, akan timbul hari-hari yang relatif monoton. Hari ini sama seperti kemarin, hanya domain masalah yang berbeda.
Ok ok ok, developer memang bisa menjadi matang dengan beberapa proses yang monoton, tapi satu yang saya rekomendasikan buat anda (dan terlebih buat saya sendiri) adalah kita meluangkan waktu tiap hari untuk mempelajari hal baru.
Contoh, hari ini saya telah belajar TDD, maka besok harus belajar refactoring. Lusa harus belajar DDD, dan selanjutnya.

Baru-baru ini saya harus mendebug bagian kode program yang dibuat oleh orang lain. Dan ini adalah pekerjaan yang sangat SUCK.Saya sama sekali TIDAK MEMILIKI KEBERANIAN untuk merubah kode-kode itu.
WHY??? ya, saya mendebug pasti dengan tujuan untuk menghilangkan BUG. Tapi bila kode program  yang harus saya debug itu tidak memiliki unit testnya, bagaimana saya bisa memastikan bahwa perubaahan yang saya buat justru tidak membuat bug baru???
Suck.