I Can See The Light: Individual Review #5

Ola Amigos! Kembali lagi bersama saya (dan untuk terakhir kalinya?), Aci dari Slovneek! It’s been a wild ride my friends, dan pada akhirnya semua perjalanan harus berakhir. Meskipun begitu, keseruan PPL belum ada habisnya karena hari Sabtu kemarin diadakan DevOps Party untuk membantu deployment Docker. Penasaran sama hasilnya? Kuy baca terus!

Deployment

Sebelumnya untuk mendeploy ke Docker, kita harus mem-build image frontend & backend, push ke portainer, dan run image baru dalam portainer secara manual. Nah, di docker party kami semua dengan bantuan Pak GG (Pak Adin, bukan istilah Good Game, hehe) mencoba untuk menerapkan auto image build sehingga cukup melakukan request ke API yang dibuat pak GG dengan informasi nama folder portainer dan repo yang digunakan.

Script untuk build image frontend, .gitlab-ci.yml

Script untuk build image backend, .gitlab-ci.yml

Setelah menambahkan script auto image build ke dalam file gitlab-ci, kita lalu melakukan request ke API yang dibuat Pak GG di dalam script deployment:

Port, container, dan repo disensor untuk keamanan

CI/CD?

Continuous Integration dalam arti yang lebih luas bertujuan untuk mengintegrasikan seluruh sistem / solusi sesering dan sedini mungkin. Bagi kebanyakan orang, Continuous Integration berarti bahwa pengintegrasian seluruh sistem yang berjalan pada modul tunggal dari sistem. Sementara Continuous Deployment berarti untuk dapat langsung memasukkan integrasi baru ke dalam produksi. Yang mencegah suatu integrasi untuk tidak dapat langsung di-deploy adalah jika integrasi tersebut terdapat test atau build yang failed.

Nah, dengan melaksanakan auto deployment saat DevOps Party, kami berhasil mengimplementasi CI/CD pada aplikasi kami.

Software Architecture

Architecture Slovneek by Hilya our lovely hipster/hacker/hustler/semuanya

Docker, docker, dockeeeer. Banyak sekali pembahasannya, sekarang saya ingin membahas tentang architecturenya sehingga dapat menjadi sebuah aplikasi.

Pertama, kami membuat 3 image yang berbeda kebutuhan, yaitu: Frontend yang menggunakan framework React-Redux, Backend yang menggunakan Django Rest Framework, dan Database menggunakan PostgreSQL. Image tersebut lalu dimasukkan ke dalam container masing-masing dalam portainer. Agar image-image tersebut dapat saling berkomunikasi, dibuat 2 network yang berbeda, yaitu: antara frontend dengan backend dan antara backend dengan database. Semua image tersebut lalu dibungkus dalam satu aplikasi oleh Docker dan dideploy.

Dalam menggunakan aplikasi nyatanya, frontend akan menggunakan backend sebagai proxy untuk menghubungkan frontend dengan database, sehingga data-data dari database dapat ditampilkan pada user interface.

Clean Code

Sebelumnya, saya sudah pernah membahas Clean Code (Individual Review #2), tapi ada yang kurang, yaitu implementasi! Mari langsung kita check!

Komentar yang efisien dan Penamaan yang baik

Poin ini sebenarnya sangat simple tapi sangat crucial juga. Penamaan yang baik pada variabel dan fungsi adalah yang dapat menjelaskan kegunaan dari kode tersebut sehingga dapat meminimalisir atau bahkan sampai meniadakan kebutuhan akan adanya komentar.

Bandingkan kedua fungsi diatas, kira-kira mana yang sebaiknya digunakan? Tentunya yang handleMouseHover karena sudah jelas fungsi ini digunakan untuk meng-handle event dari mouse hover. Berbeda dengan yang handle yang tidak jelas ia meng-handle event apa.

Penulisan fungsi yang simple dan efektif

Menulis fungsi itu harus sesuai dengan penamaannya, serta hanya boleh melakukan satu hal. Ini dilakukan agar dapat memudahkan process dibugging yang dapat dilakukan pada fungsi satu per satu ketimbang dengan 1 fungsi yang panjang dan kompleks.

Pengkodean Error dan Exception Handling

Dalam ReactJS, ternyata ada cara mudah untuk melakukan error handling, yaitu dengan menggunakan salah satu React Life Cycle Methods, yaitu ComponentDidCatch.

Salah satu React Life Cycle Methods

Method ini dapat dengan langsung meng-catch error yang ada dalam kodingan kita saat merender suatu komponen dan melakukan error handling. Error ini dimasukkan ke dalam state dan berbentuk boolean.

Ternary Operator, jika error TRUE maka message error di-render, jika FALSE komponen akan di-render

Don’t Repeat Yourself

DRY! Kering? Bukan bukan. DRY adalah prinsip dimana kodingan yang dibuat tidak repetitif sehingga memenuhi codebase kita. DRY juga memudahkan proses debugging sehingga hanya butuh refactoring pada satu fungsi saja. Cara mencegah terjadinya DRY adalah dengan membuat satu fungsi universal yang dapat digunakan untuk menggantikan kode yang repetitif.

Terdapat kode repetitif yang dapat disubstitusikan

Dalam kedua fungsi diatas, terdapat satu baris kode yang mirip yaitu this.setstate(…) , kodingan ini dapat diubah menjadi:

Membuat fungsi handleInputChange agar kodingan DRY

Sehingga jika ada suatu bug di fungsi DRY kita, tinggal melakukan debugging pada satu fungsi itu saja.

Layout Formatting

Nah yang ini sepertinya hal yang sangat sepele, karena hanya fokus pada styling dari kodingan kita. TAPIIIIII, sangat penting untuk readability agar developer lain dapat membaca kodingan kita. Developer mungkin akan seharian berurusan dengan kodingan sehingga banyaknya format koding yang berbeda dapat membuat developer kebingungan dan akhirnya miss akan bug-bug yang mungkin ada. Untuk layout yang universal, dapat digunakan linter. Kita menggunakan eslint dari Airbnb yang merupakan linter ReactJS yang sangat terkenal dan mudah dibaca. Agar di VSCode error linter langsung terlihat, digunakan file .eslintrc.js

Error linter

Tidak ada error sesuai linter (YEY!)

Wah wah, semoga ini bukan yang terakhir ya. Tapi kalo ternyata ini yang terakhir, kuingin ucapkan

ADIOS AMIGOS

hehe bye, c u when i c u