Betapa pentingnya mempunyai development standard, apalagi ketika tergabung di sebuah tim
Photo by Markus Spiske on Unsplash
Sebagai developer kita tentu pernah denger kata-kata kaya gini
Any fool can write code that a computer can understand. Good programmers write code that human can understand.
- Martin Fowler
Ketika kita kerja sendiri kita mungkin bisa abai dengan pentingnya membuat suatu standar untuk development kita, tapi ketika dihadapkan di sebuah tim yang mana mungkin orang lain mengecek hasil kode kita atau sebaliknya mungkin suatu saat kita perlu untuk mengecek kode orang lain. Development standard punya peranan penting untuk membantu antar developer membaca dan memahami lebih mudah kode orang lain. Jadi developer punya satu rujukan atau kiblat yang sama ketika membaca dan memahami codingan.
Enggak lucu dong kita tiba-tiba mules atau pusing berkunang-kunang setelah baca code base orang/tim kita.
Selain itu sebuah development standard juga berguna untuk menjaga keberagaman dalam suatu code base. Suku, ras, bahasa yang beragam itu baik dalam kehidupan sehari-hari, tapi beda ceritanya ketika style coding yang beragam dimasukkan ke dalam satu code base, bukan baik yang datang justru bencana yang datang.
Kalau diibaratkan proses development kita seperti halnya sedang membuat robot Godzilla, development standard menjaga supaya enggak ada orang yang masang kulit buaya atau ekor kuda di robot Godzilla tadi. Kan enggak lucu juga robot godzilla punya ekor kuda atau punya hidung onta.
Aku sendiri beruntung mengalami proses untuk inisiasi development standard di tempat kerjaku. Awal aku datang, code base kami super berantakan, flow yang rumit, komponennya engga bisa diruntut dengan mudah, apalagi code base nya udah lumayan gede (kalo dihitung sama komponen sampah yang sebenernya udah enggak kepake).
Berbekal pengalaman internship di software house sebelumnya dan baca-baca dari berbagai sumber, aku coba propose sebuah development handbook buat tim frontend, alhamdulillah setelah diskusi dan beberapa revisi bareng-bareng team leaderku akhirnya handbook tadi diapprove dan mulai diterapkan di project-project yang ada.
Terus gimana development standard yang baik? Well, ini subyektif sih karena development standard ini bukan sesuatu yang saklek, jadi bahkan beda tim (antara frontend, backend, mobile) bisa beda standard, apalagi beda perusahaan. Semua disesuaikan dengan kebutuhan, pattern, behavior, tapi tetep ada satu hal yang harus diingat baik-baik, yaitu mengikuti kaidah mendasar dari development yang udah umum dipake di dunia software/web development, misalnya seperti penggunaan camel case, indentation, dan clean code.
Meskipun aku sebelumnya bilang subyektif, tapi ada juga beberapa yang bisa aku saranin untuk menuju development standard tim kamu, in case tim kamu belum punya development standard.
Clean code, tapi jangan terlalu diagungkan
Tentu standard paling dasar adalah menghindari code base kita dari spaghetti code. Spaghetti memang enak, tapi spaghetti code mungkin salah satu hal yang harus kamu hindari selain amukan massa atau anjing tetangga.
Mulailah pelajari penulisan kode yang bersih dengan penamaan fungsi yang jelas, hindari angka-angka ajaib yang entah ini dari mana asal-usulnya dan gunanya buat apa enggak ada yang tahu selain Tuhan dan developer yang bikin.
Tapi… jangan terlalu diagungkan. Maksudnya, ada beberapa developer yang terlalu mengagungkan clean code dan bilang “Kode yang baik adalah yang mendokumentasikan dirinya sendiri” atau “Apa itu comment di kode? Itu tandanya kodemu buruk!!!”
Aku juga sempat punya pemikiran serupa, tapi semakin ke sini, ada beberapa hal yang perlu didokumentasikan di comment yang mungkin akan kompleks jika kode kita terlalu dipaksakan “bersih dari komen”. Jadi di beberapa blok aku kadang menyelipkan JS Doc supaya aku sendiri tahu kenapa kode ini diperlukan atau hal-hal yang enggak tertulis secara implisit di blok kodenya.
Toh adanya fitur comment tentunya untuk membantu proses development, jadi enggak perlu anti-comment, tapi coba belajar menggunakan comment yang baik.
Unit test untuk kode yang lebih terjaga
Meskipun developmentmu belum menggunakan Test Driven-Development (TDD), menurutku penggunaan unit test tetap membantu. Unit test ini bisa membuat kita tahu gimana kode kita akan berjalan nantinya, errornya gimana, kalau ada error apakah udah dihandle atau belum, sebelum kita mencoba live view hasil kode kita.
Karena aku pake React untuk development sehari-hari, unit test yang aku pake itu Jest featuring Enzyme. Aku juga baru belajar pelan-pelan menggunakan unit test sejak akhir tahun kemarin, dari situ aku merasa dengan implemen unit test di code base yang sekarang membantu banget buat aku menghindari error-error yang remeh temeh.
Kelemahannya mungkin akan lebih lama di proses development, tapi kode yang di test dengan baik punya hasil yang lebih baik juga kok.
Dokumentasi
Manfaatkan fitur-fitur yang ada di tools-tools pengembangan yang kamu pake. Secara umum kamu bisa memanfaatkan README untuk mendokumentasikan dan menjelaskan tentang gimana aplikasimu, secara khusus misalnya kamu pake Github kamu bisa pake fitur Wiki nya untuk menjelaskan hal-hal lebih detail.
Kita ini produk 50.000 tahun yang lalu dan kita sering lupa, maka kita perlu untuk mendokumentasikan sesuatu yang kompleks. Jangan terlalu membebani otak kita mengingat-ingat, selagi ingat, dokumentasikan, jadi nanti kalo sewaktu-waktu lupa tinggal baca aja. Simple kan?
Perlu diingat kalo development standard memang bukan hal yang saklek, setiap tim punya standarnya masing-masing dan kode yang baik juga perlu proses, jadi enggak perlu kecewa kalo kode kita masih enggak bagus. Baca referensi yang banyak, pelan-pelan menuju kode yang baik minimal buat kita sendiri lah.
Proses penulisan kode yang baik
Jadi apa hal baru yang kamu pelajari dari tulisan ini? Apakah tim kamu udah punya development standard? Kalo belum, coba inisiasi! Have a good day!