Memetik ilmu dari pemogram senior

Apa yang dapat dipelajari dari maestro perangkat lunak dari bermacam perusahaan mulai dari IT konsultan, startup hingga perusahaan konvensional.

Saya bersyukur memiliki pengalaman untuk bekerja bersama para ahli IT di berbagai macam bidang. Ini merupakan rangkuman dari hal-hal baik yang dibagikan kepada kami.

Softskill

Rela untuk terus belajar

Di ranah IT teknologi terus bergerak dengan cepat, selain itu metodologi baru akan terus dikembangkan dan diperbarui semisal xtreme programming, agile, scrum. Bahkan pada bahasa yang sama semisal PHP niscaya terus bergerak versi serta frameworknya. Untuk itu kita harus senantiasa mengikuti perkembangan teknologi dan dapat membandingkannya apakah sesuai dengan kebutuhan. Namun di sisi lainnya tidak asal mengikuti tren masal (hype driven design) di seminar atau forum online tanpa melakukan analisis kelayakan.

Harus ada keseimbangan berapa persen kecocokan teknologi yang digunakan dengan kebutuhan bisnis, selain itu dipertimbangkan pula kemudahan merekrut tim sesuai kondisi pasar bila ada pertimbangan untuk bertumbuh dengan cepat. Serta tidak kalah penting bagaimana dukungan layanan serta komunitas yang matang untuk jangka panjangnya.

Poin lainnya, kita juga harus dapat mendengar pendapat tim kita tentang pemikirannya dalam mendesain atau memilih pendekatan bagaimana sistem dibuat sebelum melakukan koding untuk dapat melihat perspektif secara luas dan membantu kita menemukan celah bug yang mungkin tidak kita pikirkan sebelumnya.

Rela untuk berbagi

Terkadang kita takut kalau kita menjelaskan kode yang kita buat maka kita tidak mempunyai bargain untuk bertahan atau kata lain kita menjadi mudah tergantikan. Tapi dengan kita membagi konsep kita, ada nilai positif didalamnya. Pertama ketika kita liburan, kita tidak terganggu apabila ada bug sebab ada yang bisa menindaklanjuti. Kedua ketika kita berbagi kode yang kita buat, kita tertantang untuk mengerti basis kode yang kita buat serta menambah pemahaman kita sendiri dan memperoleh masukan yang lebih baik.

Menjaga integritas

Di indonesia untuk bidang IT saat ini, seringkali kita bekerja sama atau menemui rekan kerja yang itu itu saja. Elo lagi elo lagi kasarannya. Dan ketika kita pindah kerja ternyata kita punya kenalan dengan kolega yang sama atau setidaknya memiliki info si A seperti apa atau si B direkomendasikan bagus oleh banyak pihak. Sehingga nama baik dan relasi dalam dunia IT patut dijaga dalam bentuk integritas.

Referensi seringkali juga menjadi poin tambahan ketika ada perekrutan kerja. Apalagi ketika lowongan itu bersifat close recruitment atau tertutup.

Menjaga nama baik itu penting sebab dunia IT itu sempit

Menempatkan situasi sesuai tempatnya

Biarkan masalah ada yang di rumah tetap di rumah dan masalah di kantor tetap di kantor. Ini diluar kasus khusus semisal ada keluarga sakit atau berduka maka kita gunakan ijin kantor untuk fokus menanganinya. Sementara apabila kita berada pada jam kantor sebaiknya urusan personal dapat dikesampingkan karena salah satu amanah adalah menghabiskan jam kerja untuk urusan kerja.

Kalau kita kerja untuk keluarga, sepatutnya bila sudah di rumah kita dapat menghargai waktu untuk keluarga secara adil. Sebab kerjaan itu pasti selalu ada.

Jangan sampai cuti liburan masih membawa laptop atau membalas email.

Menjaga kesehatan

Membuat aplikasi bukan kontes lari sprint untuk beberapa hari atau minggu namun merupakan buah dari perjuangan maraton bulanan hingga tahunan usaha dan perjuangan tim.

Kebanyakan lembur malah akan mengurangi produktivitas dalam jangka panjang.

Kegiatan kecil seperti peregangan otot, jalan kecil dan minum air putih secara sering dapat mengurangi efek negatif kebanyakan duduk. Selain itu usahakan posisi mata sejajar monitor dan kurangi menunduk agar leher tidak sakit.

Hardskill

Penamaan variable

Pernahkan saat kita akan memperbaiki bug dan menemukan kode tersebut acak adut atau tidak jelas fungsinya apa, sehingga kita jengkel dan ketika melakukan git blame ternyata penulisnya adalah kita sendiri.

Penamaan variable sebisa mungkin bersifat eksplisit, jelas dan ringkas untuk apa variable itu digunakan. semisal sendSms hanya untuk mengirim sms, atau close_session untuk mengakhiri sesi yang dilakukan.

Selain itu penamaan variable sebisa mungkin tidak melampui fungsi didalamnya semisal sendSms ternyata juga melakukan pengiriman notifikasi pada fcm.

Penamaan yang spesifik juga membantu dalam pengkategorian test. Contoh apabila ada nama variable save_all , bisa terjadi ambiguitas atau pertanyaan susulan, fungsi yang disimpan itu model mana saja atau transaksi yang terjadi didalamnya apa saja. Apabila dipecah menjadi fungsi lebih kecil akan memudahkan batasan test atau cara mengetes variable ini.

Terkecuali untuk transaksi yang bersifat atomik, semisal ketika melakukan debet akun, akun kreditnya juga harus ikut berubah.

Dokumentasi teknis

Dokumentasi teknis lebih baik berada dalam bentuk repository dibanding dokumen terpisah (kecuali high level documentation atau memang perjanjian dengan klien yang membutuhkan dokumentasi tertulis).

Alasan kenapa dokumentasi berada pada repository (commit message), sebab kode seringkali berubah sesuai kebutuhan di lapangan, dan seringkali dokumentasi yang terpisah jarang untuk diupdate.

Sebisa mungkin untuk commit message beri penjelasan singkat kenapa kode berubah dan kelompokkan berdasar kode yang berubah. Jangan melakukan 1 commit message untuk 100 kode yang berubah. selain membuat rancu dokumentasi ini juga lebih susah untuk direvert apabila ada kode yang ingin di rollback.

Untuk kode yang memerlukan api, bisa menggunakan swagger untuk dokumentasi input, output maupun test api didalamnya.

Untuk dokumentasi di dalam kode masukkan apabila ada aturan bisnis yang diperlukan mengapa kode itu perlu dibuat dan tidak semua fungsi perlu didokumentasikan asal penamaan kode jelas dan fungsi bersifat terbatas bukan kode sapu jagad.

Anda dapat melihat pendokumentasian teknis disini

TLDR anggap apa yang kita dokumentasikan ini menjadi petunjuk apabila ada developer baru itu masuk sehingga mengerti apa yang kita kerjakan.

Kode review

Kode review memberi aspek positif bagi reviewer dan pembuat request. Pembuat request dapat mendapat masukan bagaimana kode yang bekerja lebih efisien atau menghilangkan bug yang kasat mata. Bagi reviewer ia mendapat ilmu bagaimana tugas yang diberikan diterjemahkan dalam bentuk kode, fungsi baru yang diperkenalkan oleh pembuat request. Dan menjadi prasarana untuk transfer knowledge berbagi pengetahuan mengenai apa yang dikerjakan dan standar kode yang berlaku dalam organisasi tersebut.

Tips untuk kode review, sebisa mungkin jangan melakukan blaming tapi tanyakan pertanyaan secara konstruktif semisal:

Kalau fungsi ini dipisah ke beberapa fungsi kecil ini akan lebih mudah dibaca dan di-maintenance. dibanding Kenapa fungsi ini punya 100 baris kode?

Untuk pull request sebisa mungkin dipecah ke satuan task, sehingga pull request tidak terlalu besar dan menyebabkan reviewer menjadi pusing dan malas untuk mereview puluhan hingga ratusan perubahan file.

Apabila dirasa perubahan kode tidak bisa di masukkan ke branch master secara sedikit, coba buat feature branchyang berasal dari master atau lakukan feature flag untuk kode tersebut tidak langsung aktif ketika dimerge ke master.

Selain itu jangan baper di pull request, dan merasa ditekan. Ingat konflik hanya ada di atas komentar, tidak ada personal feeling di dalamnya.

Melakukan test

Ada dua tipe test yang setidaknya dibuat sebagai perekayasa perangkat lunak.

Unit test

Unit test merupakan unit terkecil pengecekan kode yang dibuat berdasar fungsi tiap kelas. 1 kelas unit test bertanggung jawab untuk mengecek 1 kelas yang ada.

Setidaknya ada 3 pengecekan yang dilakukan pada unit test:

• test yang dilakukan agar response berjalan sesuai dengan keinginan kita
• test yang dilakukan agar error ditemukan (predictable error)
• test yang dilakukan apabila input program tidak sesuai

Integration test / system testing

Tes ini dilakukan untuk menerjemahkan kebutuhan bisnis apakah sesuai dengan kode yang kita kembangkan.

Tes ini bersifat high level, tes ini bersifat apakah input yang diberikan user mempengaruhi modul mana saja, servis yang dijalankan dan tidak dijalankan mana saja, apakah ada validasi di model lain rusak ketika ada inputan dimasukkan.

Dan apabila ada skenario yang tidak normal, respon yang diberikan sesuai misal tidak error 500 tapi menampilkan halaman ilustrasi permintaan maaf.

Menghadapi error

Jangan kedepankan asumsi, coba lakukan beberapa pengecekan terlebih dahulu seperti.

• Apakah kode yang diproduksi merupakan kode yang paling terbaru. (bisa dilakukan dengan git logatau memasukkan versi program ketika release)
• Apakah konfigurasi yang dijalankan pada production sudah sesuai.
• Apakah database telah menggunakan skema yang paling baru apabila ada penambahan tabel atau kolom
• Cek log yang terjadi apakah pesan error yang terjadi (untuk itu pastikan ketika ada error sedapat mungkin jangan dilakukan catch exception karena ini dapat mengkaburkan penyebab error yang terjadi)
• Apabila ada sumber dayanya dan secara aturan diperbolehka. Gunakan monitoring seperti scout, new relic atau stackify. Ini akan mempermudah apabila error terjadi di production dan melakukan reka ulang kejadian.

- sekian, murid pamit dulu untuk menimba ilmu lainnya