Pushing Through: Individual Review #4

Published in

slovneek

6 min readApr 15, 2019

Halo! Kembali lagi bersama saya, Aci dari Slovneek! Bosen ga? Ehehehe, jangan dong. Tanggung tinggal 3 review lagi, terus nanti kangen deh eheee. Sebelum kangen-kangenan, kuy lah kita melanjutkan lagi membahas mengenai materi-materi yang dipelajari di PPL. Kali ini, kita akan membahas kembali mengenai TDD agar semakin nempel di otak! ̶t̶e̶r̶u̶t̶a̶m̶a̶ ̶o̶t̶a̶k̶ ̶s̶a̶y̶a̶ Selanjutnya kita bahas materi yang belum pernah kita sentuh, yaitu, Docker dan Refactoring & Design Pattern. Seru kan kedengerannya? Seru dong! Without further ado, let’s get started!

TDD

TDD oh TDD. Sebelum PPL sudah sering dengar, saat PPL apalagi. Apa sih itu? Tentu sudah diketahui bahwa TDD merupakan salah satu metode untuk melakukan testing. Tapi apa yang membuat TDD ini sangat spesial?

Pendeknya adalah bahwa TDD merupakan metode yang bagus untuk mendapatkan kode berkualitas sekaligus code coverage yang bagus.

Dari artikel ini, terdapat 3 aturan TDD yang, jika disimpulkan, terdapat 2 kesimpulan sederhana, yaitu:

Write only enough of a unit test to fail. Buatlah unit test secukupnya yang akan failed.
Write only enough production code to make the failing unit test pass. Buatlah kode production (kode produk sebenarnya) secukupnya agar unit test yang failed menjadi passed.

Red/Green/Refactor Cycle

Dalam kehidupan sehari-hari, kebanyakan orang akan langsung mencoba mengimplementasi kodingan sesuai kebutuhan client. Namun merujuk ke aturan TDD diatas, jalan berpikir ini tidak dapat diterima!

Dalam TDD kita harus membuat unit test terlebih dahulu yang sesuai dengan harapan atau kebutuhan client atas produk kita. Ini dilakukan dalam RED phase dari cycle TDD.

Setelah membuat unit test yang failed, barulah kita membuat production code yang cukup agar test menjadi passed. Mungkin banyak yang akan langsung mencoba mengimplementasikan algoritma yang kompleks dan menerapkan clean code sehingga performance optimal dapat langsung tercapai. Ini salah! Kebutuhan akan clean code dan performance tidak dilakukan dalam tahap ini, melainkan tahap Refactor. Dalam GREEN phase, yang dibutuhkan hanyalah implementasi minimal sehingga test dapat passed untuk mempermudah debugging.

Selanjutnya dalam REFACTOR phase, barulah implementasi dalam Green phase di-refactor dan dioptimalkan sehingga best practice namun tidak mengubah behavior dari implementasi. Sehingga hasil dari refactoring tetap GREEN.

So, why TDD?

Why? Terlihat jelas bahwa TDD membutuhkan waktu yang lama ketimbang langsung mengimplementasikan kode sebenarnya. Namun yang lama sebenarnya adalah memahami TDD serta men-setup environment testing, sehingga saat sudah fasih, TDD sebenarnya sangat menghemat waktu.

TDD juga sangat berguna dalam team. Membuat unit test yang minimal dan efisien dapat membantu teammates dalam memahami kodingan yang dibuat saat ingin digabungkan implementasinya dengan kodingan yang mereka buat. Ini juga sangat berguna saat handover project ke team atau orang lain.

Dan lastly, sebagai manusia yang tidak sempurna, kita sering melupakan kodingan kita sendiri sehingga dapat menyusahkan proses refactoring dan terjadi kemungkinan perubahan behavior dalam implementasi.

Software Environment: Deployment

Docker

Mungkin ada yang belum tahu bahwa di aplikasi yang dibuat kelompok saya menggunakan bermacam framework seperti: React untuk frontend, Django untuk backend, PostgreSQL untuk database, dan elasticsearch untuk search engine. Banyak juga ya? Nah, agar semua framework dapat berjalan dengan harmoni dalam satu aplikasi saat deployment, kita menggunakan software yang bernama Docker. Wah wah, apa ini? Dibandingkan dengan TDD diatas, Docker ini sangat tidak familiar ya? Apa itu?

Jadi, Docker merupakan platform pengembangan aplikasi yang memungkinkan pengguna untuk membuat, mengirim dan menjalankan aplikasi menggunakan container. Dengan adanya container, developer dapat menggabungkan berbagai package atau dependencies lainnya menjadi satu. Oleh karena itu, para developer tidak perlu khawatir aplikasi yang mereka buat dapat dijalankan di mesin Linux lain, terutama untuk setingan yang di-customize untuk kebutuhan aplikasi.

Dari penjelasan tersebut, docker mirip dengan virtual environment. Namun bedanya adalah bahwa docker tidak membuat satu keseluruhan virtual operating system, melainkan menggunakan kernel Linux yang sama antar device dan mem-provide aplikasi yang belum ada di komputer host.

Development, Staging, and Production Environment

Development Environment adalah suatu environment pengembangan yang diperuntukkan dalam pengujian kode dan biasanya hanya dipergunakan dalam melakukan unit testing. Setiap percobaan untuk memeriksa apakah sebuah kode bisa berfungsi di sistem adalah pada environment development.

Staging Environment adalah environment untuk sprint review yang terdapat pada branch staging. Setiap user story dalam sprint yang di-deliver di merge ke dalam branch tersebut.

Production Environment merupakan tujuan deployment yang terdapat pada branch master. Aplikasi yang berjalan di environment ini harus merupakan hasil sprint review yang sudah di-approve oleh Product Owner.

Refactoring & Design Pattern

Refactoring

Menurut buku Martin Fowler berjudul “Refactoring: Improving the Design of Existing Code”, refactoring dapat diartikan sebagai teknik untuk memperbaiki desain dari code base yang sudah ada. Pokok dari teknik ini adalah melakukan modifikasi skala kecil secara bertahap tanpa mengubah behavior dari aplikasi yang mungkin terlihat sepele, namun hasilnya signifikan. Dengan melakukannya secara bertahap, risiko memunculkan error dapat berkurang. Hal ini juga dapat menghindari kerusakan sistem saat menjalankan refactoring.

Potongan kode untuk mengubah format tanggal dari UTC menjadi ‘hours:minutes’

Dari potongan kode diatas, diketahui bahwa sebelum refactoring (highlight merah), tidak ada format penamaan yang ditetapkan. Sehingga bentuk yang dimunculkan berupa dalam format UTC yang kurang readable oleh manusia seperti: ‘1994–11–05T08:15:30–05:00'. Karena informasi waktu yang diperlukan hanyalah jam dan menit, maka dilakukan refactoring diatas sehingga yang ditampilkan adalah ‘8:15’.

Best Practices

Dalam setiap framework, tentunya terdapat best practices untuk memudahkan pembacaan kodingan antar developer. Karena kelompok saya menggunakan framework React, maka tentunya kami menggunakan best practice React dalam implementasi. Best practice tersebut adalah:

Layout Direktori. Dalam React, untuk layout direktori untuk setiap komponen dipisah sehingga memudahkan pemanggilan single component. Untuk setiap page khusus, perlu dibuat folder terpisah lagi karena page tidak hanya memiliki satu fungsi, melainkan gabungan dari beberapa fungsi (komponen).

Folder components dan containers dipisahkan

CSS in Javascript. CSS biasanya tidak terlalu dipermasalahkan dalam development. Namun seiring dengan bertambah besarnya aplikasi kita, dapat terjadi naming collision, dimana CSS dari satu component ikut merubah CSS dalam component lain yang mungkin tidak ada hubungannya. Hal ini terjadi karena penamaan styling yang sama. Untuk menghindari ini, dapat digunakan salah satu dari CSS-in-JS solutions, yaitu:

Untuk di PPL, kami menggunakan StyledComponents karena merupakan solusi CSS-in-JS dengan komunitas besar terbesar dan kredibel.

Props. State-state dan function dalam suatu komponen dapat berasal dari komponen itu sendiri atau bisa berasal dari global/selector sehingga dibutuhkan pen-declare-an dari global tersebut. Agar dalam merender komponen behavior dari state dan funciton yang diambil tidak berubah, dimasukkan ke dalam props komponene tersebut. Hal itu dilakukan dengan mapStateToProps (untuk declare state) dan mapDispatchToProps (untuk declare function).

Design Pattern

Design Pattern adalah solusi umum yang dapat diulang untuk masalah yang biasa terjadi dalam desain perangkat lunak. Design pattern bukanlah desain akhir yang dapat ditransformasikan langsung menjadi kode. Ini adalah deskripsi atau template untuk cara menyelesaikan masalah yang dapat digunakan dalam berbagai situasi.

Dalam React design pattern yang umumnya digunakan itu satu, yaitu State Design Pattern. Masalah yang diselesaikan oleh State Design Pattern adalah mengubah behavior saat runtime tergantung dari state yang diberikan. Pattern tersebut sebenarnya sudah diimplementasikan dalam penggunaan Redux