Saya sudah pernah kerja bareng sama programmer programmer keren dari unicorn di indonesia, baik di perusahaan besar kaya Tokopedia, maupun di perusahaan kecil kayak startup. Mereka buka mata saya tentang "10x engineers" yang konon hanya mitos belaka, tapi ternyata beneran ada, hahaha!
Beberapa dari mereka bahkan udah nge-start perusahaan sendiri, nge-lead development project yang punya nilai besar!, atau udah jadi C-level di perusahaan yang bernilai miliaran rupiah di perusahaan teknologi besar sekarang.
Selama saya kerja bareng mereka, saya nangkep kalo semuanya punya kebiasaan yang sama di kode yang mereka hasilin.
Code for the human, not the computer
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler.
code itu untuk manusia, bukan cuma untuk komputer.
code itu untuk programmer yang ada di team kamu, yang baca, memelihara, dan build sesuatu diatas code yang sudah kamu buat.
code itu untuk para users, entah itu anak kecil di handphone mereka, developer yang menggunakan API kamu, atau diri kamu sendiri
programmer terbaik yang saya kenal itu punya mindset produk: mikirin gimana caranya mecahin masalah buat manusia duluan.
programmer terbaik yang saya kenal selalu memberi value dari kode mereka, buat semua orang yang bakal pake nantinya.
Kalo mereka meleset satu aja dari target tersebut, kode itu gak bakal masuk produksi.
Lepasin diri dari kode itu sendiri
programmer keren tetap bisa lepas dari kode itu sendiri.
Mereka gak takut buat hapus kodenya dan mulai dari awal, meskipun udah 90% jalan, kalo itu berarti hasil akhirnya bakal lebih baik secara keseluruhan.
Kode gak ada hubungannya sama personal, jadi jangan terlalu diambil hati, santai aja.
Kode gak sempurna. Gak ada yang peduli tentang kode yang sempurna. Yang mereka peduliin adalah kode yang bisa bawa perubahan.
Pakai standar yang konsisten
Pas nulis kode, patuhi standar dan gaya penulisan kode yang konsisten. Konsistensi bikin kode lebih gampang dibaca dan dimengerti, baik buat diri kamu sendiri maupun rekan tim kamu.
Guideline gaya yang konsisten memungkinkan tim dan kodebase untuk berkembang lebih mudah. Inilah cara perusahaan-perusahaan seperti Meta dan Google bisa nge-ship kode cepet banget tanpa kodebase jadi ga jelas dan ga bisa di-maintain seiring waktu.
Setiap orang yang luar biasa yang saya kenal selalu internalisasi standar kode tim mereka dan ngikutinnya seserapi mungkin, dan mendapat manfaatnya.
Tulis kode yang sederhana
Setiap programmer papan atas yang saya kenal selalu bikin kode yang mungkin rumit buat dibuat, tapi sederhana buat dibaca dan dimengerti pas udah jadi. Istilah terbaik buat ini menurut saya adalah bahwa kode mereka estetis, dan saya bisa sebut ngoding itu adalah seni.
Kode mereka bersih, rapi, terorganisir, dan logis. Setiap keputusan yang diambil di dalam kode mereka masuk akal, dan kalo ada sesuatu yang enggak, itu didokumentasikan dengan baik di dalam kode, biasanya menggunakan comment.
Cara bagus buat nulis kode bersih adalah dengan ngikutin design arsitektur atau principles, contohnya SOLID principles. Meskipun awalnya dirancang untuk pemrograman berorientasi objek (OOP), prinsip-prinsip ini bisa diperluas ke pemrograman secara umum:
Single Responsibility: Sebuah class harus dan hanya punya satu tanggung jawab saja.
Open-Closed: Objek-objek perangkat lunak (class, modul, dll.) seharusnya terbuka untuk melakukan ektensi tapi tertutup untuk modifikasi, memungkinkan kode yang dapat diprediksi dan dapat di-maintain.
Liskov Substitution: Subtipe harus bisa digantikan oleh tipe dasarnya tanpa memengaruhi ketepatan programnya.
Interface Segregation: Kode gak boleh tergantung pada interface besar yang gak semuanya digunakan. Sebaliknya, package seharusnya bisa berisi dan mengizinkan import dari interface yang lebih kecil dan spesifik.
Dependency Inversion: Modul tingkat tinggi gak seharusnya tergantung pada modul tingkat rendah; keduanya seharusnya bergantung pada abstraksi, memfasilitasi desain sistem yang lebih fleksibel dan terpisah.
Contoh dari ini adalah penggunaan nama. Penamaan yang bagus gak ada nilai ajaib atau magic, perbedaan yang jelas, nama fungsi yang deskriptif, dan variabel yang mudah dimengerti.
Jangan ada kejutan
Kode gak seharusnya ngasih kejutan. Ini bisa dihindari dengan ngikutin prinsip-prinsip kode dan nulis tes yang tepat.
Kode yang bagus itu bisa diprediksi.
Tes itu untuk memaksa kejelasan kode dan keberlanjutan kode. tes itu bisa bikin kita pede sama hasil program kita. dan tes otomatis yang baik memungkinkan tim kita untuk melakukan perubahan ke kode tanpa khawatir merusak sesuatu yang gak terlihat atau yang ga kita tau.
Beberapa jenis tes meliputi:
- Unit test untuk masing masing komponen dan fungsi yang terisolasi.
- Integration test untuk interaksi antara beberapa komponen.
- End-to-end test yang menilai seluruh fungsionalitas sistem dari sudut pandang pengguna atau users.
Tes seharusnya sederhana. Harus gampang nentuin apa yang salah ketika baca tes yang gagal.
Penting juga buat tahu apa yang gak perlu diuji.
Contohnya, kalo effort dari end-to-end test lebih gede daripada manfaat asli dari program, maka tes itu bisa diganti dengan dokumentasi yang dipikirkan dengan baik, monitoring, dan pemberitahuan kepada orang yang tepat (seperti pemilik kode).
Tes juga seharusnya gak menguji detail implementasi dalam kode, seperti menguji selector CSS tertentu di kode frontend dibandingkan dengan menggunakan data-attributes atau tes screenshot saja.
Lebih sering berkomunikasi
Gak ada sistem hebat yang dibangun sendirian. programmer yang hebat selalu melalui proses design, meminta masukan, dan terus mengulangi desain awal untuk kode mereka.
Semua orang pasti punya kekurangan dalam pengetahuan mereka yang bisa diisi oleh orang lain. Sudut pandang baru seringkali bisa membantu kode program jadi lebih jelas atau memberikan pendekatan baru yang mungkin belum pernah terpikir sebelumnya oleh kita.
programmer terbaik itu komunikatif dan kolaboratif - gak takut buat ngabisin waktu untuk kerja sama demi peluang hasil akhir yang lebih baik.
Ini bisa se-simple nge-chat temen tim buat minta revisi cepet di dokumen atau nambahin reviewer kode ekstra buat pull request penting.
kode dengan cepat...dan perlahan
programmer terbaik yang saya kenal menyelesaikan project dengan cepat... dengan cara nulis kode secara perlahan.
aneh, kan?
Semua prinsip dan kebiasaan di atas nambahin waktu untuk tahap pertama penulisan kode secara keseluruhan. Tapi itu memungkinkan programmer untuk maju dalam project, langkah demi langkah.
Dengan mengambil waktu untuk menggunakan standar, menguji dengan baik, menerapkan prinsip-prinsip, dan berkomunikasi secara teratur, mereka ngirit waktu mereka dalam jangka panjang.
Alternatifnya, seperti yang pernah saya alamin waktu saya magang dan jadi programmer junior, seperti yang pasti banyak orang alami, adalah buru-buru maju 3 langkah, ketemu hambatan, trus harus mundur 5 langkah lagi.
Jangan buta ikutin aturan
"Peraturan" dan "principles" di atas itu cuma panduan.
Gak semuanya bisa pas dan cocok buat dipaksa masuk ke panduan.
Kadang-kadang, kode yang lagi kamu tulis itu kayak kotak yang gak bisa muat ke dalam lingkaran. Itu gak masalah.
dalam kasus tersebut, pastikan untuk mendokumentasikan mengapa kode kamu ditulis dengan cara tertentu diluar aturan.
Kalo gak, nanti seseorang, misalnya diri kamu di masa depan, bisa datang lihat kode di masa depan dan mikir, "wow, dulu saya bodoh ya. Kenapa ini gak sesuai standar kita?"
Mereka nanti bakal ngabisin 20 jam buat nulis ulang supaya sesuai standar, padahal hasil akhirnya sama aja kayak sebelumnya. Kedengarannya akrab?
Kenyataan dalam software developers adalah gak semua kode bisa bersih atau rapi atau mengikuti aturan dengan sempurna.
Yang penting, bisa konsisten, bersih, rapi, mudah dimengerti, bisa diuji, dan valuable.
Top comments (0)