Dari pengalaman gw magang pas di kampus, banyak dari program internal kami susah banget buat di maintain. Alesannya gampang, kami nggak tau apa yang dia lakukan di file itu + kodingannya kadang tidak berpola bikin makin jelimet buat baca ulang semua kodingan yang dia kerjain dengan penuh effort waktu itu. Hal ini sama sekali nggak bikin tim yang bakal gantiin kalian kedepan bisa bantu impruf.
Permasalahan lainnya adalah, aplikasi yang di develop itu web-based, artinya bakal sering banget diupdate librarynya. Terutama aplikasi servernya. Kodingan yang lama, nggak berpola dan maintainer yang saat ini sudah menghilang bakal bikin update benda-benda ini jadi makin susah. Kodingan lama yang sebetulnya bakal jadi masalah besar, kodingan yang udah outdated sering banget diprotes aplikasi versi baru karena emang udah nggak di dukung lagi. Kalo diganti, kita nggak tau kode mana aja yang bakal terpengaruh dan bug apa aja yang bakal ada. Satu-satunya solusi tiap error ini muncul ya itu, REFACTOR. Dan ya tentu kegiatan sakral itu bakal banyak banget makan effort.
Poin pertama: Kodingan harus memiliki standar.
Masuk ke bagian pencerahan, saat saya masuk UNPAR dan mau minta DPS (Daftar Perkembangan Studi [Semester]), kami diharuskan untuk mengisi formulir secara online. Proyek ini (BlueTape) dikembangkan secara open source, dan setiap orang bebas melaporkan masalah yang ada. Walaupun timnya nggak tiap kali berubah, tapi dari sini kita bisa lihat kalo proyek ini memiliki standar koding yang konsisten. Jadi kontributor yang ingin membantu dapat lebih mudah mengerti kodingan proyek tersebut.
Poin kedua: Gunakan Framework (kalo bisa yang cukup dikenal banyak orang atau mudah dimengerti).
Penggunaan framework sangat membantu, apalagi banyak masalah keamanan yang seringkali para pemula tidak tahu. Selain dari masalah keamanan, penggunaan framework memaksa contributor atau developer untuk mengikuti pola dan gaya yang sudah digunakan sejak pertama kali proyek dibuat dan dirancang.
Hal ini memudahkan kita untuk membaca, me-troubleshoot dan membantu pemilik proyek untuk mengatasi bug yang ada. Ini sangat memotong banyak sekali waktu untuk scroll sana-sini, karena kita harus menelusuri kodingan yang tidak berpola, satu per satu, baris per baris, fungsi per fungsi. Kebayang kan semenderita apa kita maintainnya?
Poin ketiga: Gunakan Package Manager untuk setiap library yang digunakan.
Package Manager sangat berguna untuk yang senang sekali pake Third Party. Library yang kalian gunakan itu yang kontribusi itu nggak dikit loh. Kebanyakan library, sering banget update. Terutama buat kalian yang seneng banget pake Node.Js. Javascript sekarang lagi gencar banget updatenya.
Kejadian yang dulu banget dialamin pas awal-awal belajar web. Pengen pake plugin A, tapi Plugin A butuh Plugin B yang paling baru… dan Plugin B yang dipake itu udah versi lawas banget, dan nggak pernah tau kalo itu di updatenya baru kemarin banget. Itu baru satu contoh, pernah kebayang yang plugin jsnya bersandar pada plugin lain, yang pluginnya yang lain itu bersandar pada puluhan plugin lainnya? Yep. Total disaster.
Poin keempat: (Opsional) Tetapkan Unit Testing.
Unit testing berguna banget buat yang workflownya cepet banget, contributor banyak, tapi yang maintain dan ngelakuin testing dikit. Selain dari skenario itu, kalo sistem kalian dipake banyak orang, dan kalian ngelakuin kesalahan, Unit Testing bakal mencegah hal ini kejadian.
Unit Testing ini bakal jadi saringan pertama buat para contributor yang ingin bantuin kalian, tapi masih nggak yakin kodingan mereka cukup baik untuk di cek oleh maintainernya. Benda ini bakal ngecek unit kalian satu per satu, mencegah bug pada tingkat data dasar dan ikutan validasi algoritma sederhananya. Memang sih yang ini bakal males bikinnya, tapi kalo yang contribute udah banyak banget, ini bakal sangat amat membantu.
Akhir kata, dari pengelaman sendiri tentang proyek Open Source, kerja di tim yang sering banget dirotate, dan lihat contoh langsung managemen proyek kampus, gw percaya kalo poin-poin diatas bisa bantu masalah yang bikin kesel karena kodenya udah nggak bisa dibaca dan penuh dengan bug.
Kalo kalian males maintain bug proyek itu, kalian buat Open Source, biarkan yang lain yang merasa tergerak ikutan bantu. Anda tinggal cek kode mereka, kasih feedback jika perlu, lalu merge, dan kasih tau ke pengguna lain kalo kodenya sudah di update, dan bugnya sudah disolve.
Credits
Photo by Jessica Favaro on Unsplash