Sprint Blog #1

Halo! perkenalkan nama saya Bram Sedana. Saya adalah salah satu hacker pada kelompok Slovneek.

Pada post ini, saya akan menulis tentang pengalaman saya dengan React dan Clean Code, penggunaan metodologi Test Driven Development, penerapan Agile Development.

React

Apa itu React? Bagaimana cara menggunakannya?

Pertanyaan tersebut adalah hal yang saya tanyakan saat pertama kali mendengar tentang React. Pada sprint ini, saya mempelajari beberapa hal tentang React.

React merupakan Front end Framework, menggunakan bahasa pemrograman JavaScript. React termasuk sebuah User Interface library yang bersifat stateful. Berbeda dengan web development biasa.

Komponen utama dalam menggunakan React yaitu Component dan Container. Component yaitu komponen web yang sering digunakan sehingga dibuat menjadi objek baru agar reusable. Component tersebut kemudian digunakan dalam Container. Container berisikan Component yang disusun sedemikian menjadi web page yang bisa ditampilkan.

Contoh Component Card

Clean Code

Pada sprint ini, saya mempelajari beberapa hal tentang Clean Code, di post ini saya ingin membagi apa saja yang telah saya pelajari.

Dalam mengerjakan proyek ini, penerapan Clean Code sangatlah penting. Clean Code merupakan sebuah kebiasaan kita sebagai developer agar kode yang ditulis sesuai dengan best practice yang ada. Hal ini ditulis dalam buku yang ditulis oleh Robert C. Martin berjudul Clean Code: A Handbook of Agile Software Craftsmanship.

Buku tersebut dibagi menjadi tiga, yang pertama menjelaskan tentang prinsip, pola dan penerapannya. Bagian kedua berisi studi kasus yang semakin lama semakin kompleks, tiap studi kasus adalah latihan membersihkan kode. Bagian ketiga berisi list heuristik dan smell yang digunakan untuk membuat studi kasus.

Berikut adalah beberapa practices yang termasuk penerapan Clean Code:

• Komentar yang efisien
• Penamaan yang baik
• Penulisan fungsi simple dan efektif
• Penyusunan error code dan Exception Handling
• Kurangi duplicate code (DRY)
• Layout Formatting
• Penamaan variable yang konsisten, seperti konsisten camelCase atau snake_case
• Dalam pembuatan test untuk TDD, terdapat acuan F.I.R.S.T yaitu Fast, Isolated, Repeatable, Self-validating dan Timely.

Kenapa kita harus menerapkan Clean Code?

Ada beberapa alasan untuk menjawab pertanyaan tersebut,

Pertama yaitu sebagai programmer, kita lebih sering membaca kode, memikirkan apa yang harus dilakukan dan bagaimana cara melakukannya, serta debugging dibandingkan dengan menulis kode itu sendiri. Kita dapat menghemat waktu tersebut dengan menerapkan Clean Code agar pembacaan kode dan debugging dapat lebih mudah dilakukan.

Alasan kedua yaitu dalam pembuatan suatu program, setiap line kode yang kita tambahkan dapat berpotensi menjadi bug, dengan menggunakan clean code kita dapat mengurangi kemungkinan hal itu terjadi sehingga tidak banyak menghabiskan waktu kita.

Sebagai developer, kita berada di Front line. Setiap bad code yang kita tulis bakal terus roll kebawah dan mempengaruhi aspek-aspek lain dari produk. Untuk mencegah itu kita dapat menerapkan Clean Code.

Test Driven Development

Dalam mengerjakan proyek PPL ini, kami menerapkan metodologi Test Driven Development.

Test Driven Development atau biasa disingkat TDD adalah proses software development yang memprioritaskan pembuatan test suatu fungsi sebelum mengimplementasikan fungsi tersebut. Test yang dibuat akan menjadi Guideline untuk apa yang akan dibuat dan agar implementasi fungsi tersebut sesuai dengan tujuan awalnya.

Test Driven Development Cycle

Terdapat beberapa fase pada proses TDD:

• RED: pada fase ini, dibuat fungsi kosong beserta test-test nya. Test tersebut mencakup semua kegunaan dari fungsi tersebut. Karena fungsi tersebut masih kosong, sehingga tidak apa-apa jika CI/CD failed saat dipush. Pada commit message biasa ditulis “[RED] <message>”
• GREEN: pada fase ini, diimplementasikan fungsi sesuai dengan test yang sudah dibuat sebelumnya. Implementasi fungsi tersebut harus bisa membuat kode memenuhi keinginan test sehingga CI/CD success. Pada commit message biasa ditulis “[GREEN] <message>”
• REFACTOR: pada fase ini, kode yang sudah dibuat dirapikan agar lebih mudah dibaca tanpa merusak fungsionalitasnya. Setelah melakukan refactor, kode tersebut tetap harus berjalan sesuai dengan test yang sudah dibuat. Pada commit message biasa ditulis “[REFACTOR] <message>”

Selain itu, ada hal lain yang biasanya diperhatikan saat menggunakan metodologi TDD ini, yaitu Code Coverage.

Nah apa itu Code Coverage? Code Coverage ini menunjukkan berapa persen bagian dari kode yang berhasil di-cover oleh test yang dibuat. Kalau dari pengertian tersebut, maka bisa dibilang bahwa sebuah test itu bagus jika Code Coverage tinggi, tapi kenyataannya tidak begitu. Code Coverage hanya menunjukkan seberapa banyak bagian kode yang dijalankan oleh test yang dibuat, namun tidak menjamin kualitas dari test itu sendiri. Sehingga untuk membuat suatu test yang bagus, harus memperhatikan Code Coverage dan kualitas dari test-nya.

Tadi sudah ditulis bahwa kegunaan dari test yaitu agar implementasi kode tetap sesuai dengan rencana awal. Tapi test juga memiliki kegunaan lain juga seperti:

• Sebagai Code Guard: Kadang saat kita mengimplementasikan fungsi B, namun fungsi A menjadi tidak bisa digunakan. Hal ini tidak akan terjadi kalau menggunakan TDD, karena jika ada perubahan fungsionalitas pada suatu fungsi, maka test yang sebelumnya sudah passed akan menjadi failed.
• Sebagai dokumentasi code: Jika kita bingung dalam membaca kode orang, kita bisa melihat test-nya. Dengan membaca test, kita bisa mengetahui input yang dibutuhkan suatu fungsi dan juga output yang dikeluarkan sesuai dengan assertion yang digunakan. Sehingga cukup membaca test saja untuk mengetahui maksud dari kode.

Agile Development

Agile Development lifecycle

Agile Software Development adalah sebuah pendekatan terhadap software development yang bersifat fleksibel. Kata Agile menjadi populer karena adanya Manifesto for Agile Software Development. Isi dari manifesto tersebut adalah:

• Individuals and Interactions over processes and tools
• Working Software over comprehensive documentation
• Customer Collaboration over contract negotiation
• Responding to Change over following a plan

Pada mata kuliah ini, kita diharapkan dapat mempelajari hal-hal tersebut secara langsung. Dan pada sprint pertama ini, kita benar-benar sudah merasakan penggunaan Agile Development secara langsung serta arti kata Agile dalam Agile Development.

Di hari yang sama dengan deadline mockup, client kita meminta perubahan drastis terhadap design mockup, sehingga banyak yang harus dilakukan oleh hipster kami di hari itu juga.

Selain itu, di saat kami melakukan sprint planning pukul 10.00, di saat pukul 10.30 tiba-tiba kami mendapatkan sebuah email dari product owner kami bahwa terdapat perubahan terhadap design produk kami dan penambahan fitur ke dalam MVP kami.

Dari beberapa pengalaman tersebut kami diajarkan bagaimana cara kerja Agile Development sebenarnya di kehidupan nyata.