Keeping Your Code Quality in a Team

Halo semuanya, kembali lagi di edisi agak telat #RabuSharing. Maaf ya dua minggu kemarin enggak sempet rilis postingan karena ada acara dinner dan balik-balik saya kecapekan. Jadi yaudahlah ya skip aja post di hari itu, dan sengaja enggak di made-up di hari Kamis atau setelahnya soalnya nanti gajadi #RabuSharing dong kalo gitu.

Okay back to topic, postingan kali ini agak nyambung dengan postingan yang sebelumnya ya, terkait technical interview, kok bisa?

Jadi berdasarkan pengalaman saya iseng daftar di beberapa company beberapa waktu ke belakang, ini jadi pertanyaan yang cukup sering ditanyakan pada saya, enggak tau apakah ini karena role yang saya apply itu Senior Frontend/Lead Frontend atau emang yaa ini question set aja ya. Tapi untuk role Frontend biasa, biasanya pertanyaan ini enggak diajukan sih ya.

Pertanyaan tersebut adalah “Gimana kamu menjaga kualitas kode tim kamu?” ini biasanya ada tambahannya kaya “dengan tim yang fast-paced” atau “dengan tim yang membernya mayan banyak”, dst. Tentu saja jawaban ini bukanlah jawaban benar/salah, karena dalam dunia programmer terutama dalam dunia programmer yang me-manage team, there’s no silver bullet. Enggak ada satu jawaban yang benar untuk semua, melainkan approach yang mungkin aja applicable di berbagai case. Inget ya, approach, not an aswer.

Dengan begitu biasanya (dan ini udah tak cross-verify juga), jawabannya akan berkutat di hal-hal berikut:

Establish Coding Standard and Guidelines

Sebuah tim perlu adanya guideline atau how-to dalam melakukan percodingan, supaya satu tim punya “bahasa” yang sama, biar ketika member yang lain bertanggung jawab atas file yang dibuat oleh member yang lainnya, kita atau mereka tidak akan merasa bingung how things work. Contoh sederhananya dalam ngasih nama variable kita mau pake formLogin atau loginForm, sideContentCard atau cardSideContent.

Terlihat sederhana ya, tapi ketika berurusan dengan codebase yang besar, naming convention kaya gini tuh bisa krusial loh, soalnya salah satu part paling susah dalam development adalah ngasih nama yang tepat ke variable. Kalau kita malas mikir nih, kita juga bisa ngeliat best practice aja yang udah umum dipakai di khalayak ramai, sehingga code kita pun enggak jele-jele amat lah. That’s point number one.

Point number two, untuk punya coding standard kita juga bisa utilize tools-tools kaya Prettier, ESLint, code spell checker, sehingga code kita lebih konsisten secara style, pattern, dan penamaan. Ini juga bisa save-up time untuk baca code kita karena dengan adanya kombinasi tiga hal ini, code kita jadi lebih rapih dan punya struktur yang sama. Misalnya kamu enable import-order, yaudah ketika ngecek apakah kamu sudah import package yang sesuai, kamu tinggal cek aja ke atas code kamu dan kamu akan menemui semua sudah di-group berdasarkan kriteria configmu.

Enggak perlu capek ini yang LoginForm yang mana deh, ini yang numeral ada dimana deh. Gitu-gitu.

Code Reviews

Tool is just a tool, at the end of the day, human do the communication.

Penggunaan tools di atas itu cuma akan membantu kita code sedikit lebih rapi dan terstruktur, untuk ngasih layer tambahan dalam code, kita juga perlu encourage adanya code review. Code review ini berguna banget untuk deteksi awal apakah code kita atau tim kita punya flaw dalam implementasinya, apakah logicnya muter-muter, apakah ada potensi vulnerability disitu, apakah akan ada potential performance issue disitu juga, tambahan juga apakah codenya readable untuk manusia yang lain. Karena yang baca code kita itu bukan komputer, tapi developer yang lain, kalo enggak readable ya ngapain ya kan.

Udah ngoding capek-capek, bisa-bisa direfactor gitu aja karena enggak bisa terbaca dengan baik.

Salah satu parameter saya dalam mengkoding adalah, temen kita harus bisa paham gimana code kita bekerja dalam sekali baca. Hayoloh piye wi

Untuk mencapai kesana saya selalu encourage teman-teman saya untuk decouple things, misal function panjang banget, if nya banyak banget conditionnya, yaudah dipisah aja di taruh ke variabel yang lain. Jangan sampe bikin const someCondition = conditionA && conditionB && conditionC && conditionD. Contoh sederhananya, yang lebih kompleks juga ada, kapan kapan ya ges 😂

Automated Testing

Part yang enggak kalah penting adalah diintegrate dengan testing, both unit testing, integration testing, maupun end-to-end testing. A bit too much ya kalo semua diimplement, yaudah disesuaikan aja bosku, unit testing aja boleh (ini minimal lah), unit sama integration juga boleh.

Kegunaan dari testing ini adalah biar kita sebagai developer juga lebih pede dalam melakukan pengkodingan, karena dulu waktu saya di Kulina, pas kita belum pake unit test, ngoding mah ngoding aja, terus nanti ternyata error di user. Setelah ada unit test, kita bisa catch duluan “oh ternyata codinganku ada flaw disini to, oh belum ngecover requirement yang ini to” gitu-gitu, dan itu bisa dilakukan tanpa kita pelototin screen kita pas development. Hasilnya code yang dibikin punya peningkatan success rate sampe… ngga tau berapa sih, tapi jauh lebih tertekan aja gitu dulu risiko bug nya. Hehe.

Di tempat saya sekarang juga cukup strict urusan unit testing dan e2e testing, karena enggak ada QA nya 😂. Ini juga jadi solusi ketika tim kita belum besar, tapi butuh code yang reliable untuk dirilis diprod, meskipun di sisi lain ini jadi beban buat developer ya, tapi mau gimana lagi daripada bikin codingan banyak vuln nya ya to.

Reusable Component Design

Part selanjutnya juga sebenernya relate dengan point pertama, saya dulu selalu encourage team saya di Stockbit untuk pakai component dari Stockbit UI dulu, kalo enggak mengcover, baru boleh di-custom stylenya. Tujuannya ya biar secara code jadi punya pattern yang sama, punya source of truth yang sama, dan lebih gampang juga buat maintainnya.

Ini kenapa semakin kebawah semakin dikit deskripsinya ya? LMAO

Optimizing CI/CD

Ini sangat penting juga nih, CI/CD bisa berguna sebagai layer tambahan untuk gatekeep bahwa code kita udah layak masuk ke branch master/main/apalah itu pokoknya default branch kalian.

Kita bisa setup pipeline CI/CD kita untuk melakukan berbagai hal kaya build, testing, check code quality dengan sonar, untuk memastikan setiap commit kita udah ditest dan memenuhi standard sebelum Pull Request atau Merge Request kita di merge ke branch utama.

Enggak lucu dong codingan kita justru bikin break di branch utama.

Post-Release Review and Refactoring

Nah semua tadi adalah proses pra dan ketika coding kita, part terakir adalah part yang cukup krusial, yaitu maintain code kita. Kita harus tahu bahwa code kita seminggu yang lalu pasti enggak lebih baik dari code kita yang sekarang, sehingga code kita yang lebih lama pasti juga lebih busuk lagi, untuk menjaga agar code kita tetap relevan dengan standard yang ada kita perlu melakukan alokasi waktu untuk take a look ke code-code yang sudah lama dan ngerefactor code tersebut. Hal ini bisa mencegah code yang bisa tiba-tiba break karena issue deprecated library juga.

Selain itu proses maintain ini juga relate dengan adanya dokumentasi terkait bug yang ditimbulkan dari code kita, sehingga kita bisa cek root causenya dan jadiin hal tersebut sebagai lesson-learned di masa depan, biar kesalahan yang sama tidak terulang kembali, gitulah bosku.

Bonus: di tempat kerja saya sekarang encourage banget penggunaan AI, jadi mungkin bisa dipertimbangkan juga ya kawanku.

Aaannd, that’s it for our #RabuSharing today. Semoga bisa jadi bantuan untuk interview yang akan datang (xixixi), atau juga barangkali bisa diterapkan di tim kamu yang sekarang. Have a great day!