Salah satu profesi yang paling bodoh adalah programmer. Bukan semuanya, tapi mereka yang tidak pernah menjadi programmer. Mereka yang berpikir bisa "meningkatkan" efisiensi (atau meningkatkan "efisiensi"?) dengan metode dari buku. Mereka bahkan tidak repot-repot membaca bukunya sendiriālagipula, ada video tentang pemrograman ala gipsi.
Mereka yang belum pernah menulis kode. Mereka yang menjadi inspirasi film-film Hollywood tentang programmerātahu kan, film-film di mana mereka memeriksa email menggunakan baris perintah. Mereka yang hanya peduli pada metrik, tenggat waktu, dan gaji mereka sendiri.
Mereka yang mayoritas.
Tapi mereka idiot karena alasan yang berbeda. Mereka menginginkan efisiensi, atau setidaknya efektivitas (ayolah, manajer, coba cari perbedaannya di Google), tanpa memahami keduanya. Mereka sama sekali tidak memahami esensi, proses pencapaian hasil, kerugian yang terjadi di sepanjang proses, atau biaya pengembangan. Singkatnya, bekerja dengan programmer itu seperti bekerja dengan kotak hitam.
Para programmer berbondong-bondong ke manajemen karena satu alasan: ada sensasi, uang, pasar, dan sekelompok orang yang sama bodohnya. Ada banyak ruang untuk bersembunyi.
Kalau produksi perakitan mekanik sedang heboh, orang-orang pasti akan berbondong-bondong ke sana. Mobil station wagon itu jelek. Saya tidak akan kaget kalau penjual pohon Natal di lingkungan kami bulan Desember itu manajer TI yang sedang liburan.
Singkatnya, kalau bisa, usir saja mereka. Jangan khawatir, mereka pasti akan dapat pekerjaan. Tak satu pun dari mereka akan pernah melakukan sesuatu yang layak sampai mereka sendiri menjadi programmer. Karena mereka tidak memahami esensi, mekanisme, atau logika proses yang mereka kelola.
Oke, cukup tentang manajer. Sekarang saatnya membahas hal yang sebenarnya, untuk para programmer. Bagaimana meningkatkan efisiensi pengembangan dengan belajar menulis kode berkualitas tinggi.
Untuk meningkatkan efisiensi, Anda perlu menyelesaikan masalah lebih cepat tanpa mengorbankan kualitas. Untuk menyelesaikan masalah lebih cepat, Anda harus mampu menulis kode berkualitas tinggi dengan segera. "Berkualitas tinggi," "tulis," dan "segera." Mari saya jelaskan dengan metafora.
Menulis kode berkualitas tinggi ibarat berbicara bahasa asing dengan lancar. Ketika Anda tidak menguasai bahasa tersebut, Anda menghabiskan banyak waktu untuk mencoba merumuskan pemikiran Anda dalam bahasa tersebut.
Jika Anda perlu mengatakan sesuatu dengan segera, Anda tinggal mengetik beberapa kata, seringkali kata yang salah, lupakan artikel, urutan kata yang benar, belum lagi tenses kata kerja dan pengucapan yang buruk.
Jika Anda punya waktu untuk merumuskan jawaban, Anda harus membuka kamus atau penerjemah daring dan menghabiskan banyak waktu untuk merumuskan pikiran Anda. Namun, perasaan itu tetap tidak menyenangkan: Anda memberikan jawaban, tetapi Anda tidak tahu apakah itu benar atau tidak. Sama halnya dengan kode: Anda sudah menulisnya, tampaknya berfungsi, tetapi apakah kualitasnya bagus atau tidakāentahlah.
Buang-buang waktu dua kali. Mencari jawaban butuh waktu. Merumuskan jawaban itu juga butuh waktuādan lumayan lama.
Jika Anda memiliki keterampilan menulis kode berkualitas tinggi, maka Anda dapat merumuskan jawaban Anda segera setelah kode tersebut terbentuk di kepala Anda, tanpa membuang waktu tambahan untuk menerjemahkannya.
Keterampilan menulis kode berkualitas tinggi sangat membantu dalam merancang arsitektur. Anda tidak akan membiarkan ide-ide yang salah, tidak praktis, atau canggung terbayang di benak Anda.
Singkatnya: keterampilan menulis kode berkualitas tinggi secara signifikan mempercepat pemecahan masalah.
Tapi bukan itu saja. Berkat manajer yang konyol, ada satu kendala: kami tidak punya insentif untuk menulis kode berkualitas tinggi. Manajer tidak melihat kodenya, dan klien tidak melihatnya. Kami jarang berbagi kode satu sama lain, hanya sesekali, pada proyek-proyek tertentu yang memiliki peninjau kode khusus atau refactoring berkala.
Ternyata, dalam kebanyakan kasus, kode yang buruk berakhir di tahap produksi atau di sisi klien. Koneksi saraf yang kuat terbentuk dalam diri orang yang menulis kode buruk: menulis kode yang buruk tidak hanya dapat diterima, tetapi bahkan diwajibkanāditerima, dan orang-orang bahkan membayarnya.
Akibatnya, keterampilan menulis kode berkualitas tinggi tidak memiliki peluang untuk berkembang sama sekali. Kode yang ditulis oleh seorang karyawan hipotetis tidak pernah ditinjau oleh siapa pun. Satu-satunya alasan mereka akan belajar pemrograman dengan baik adalah motivasi intrinsik.
Namun, motivasi internal ini bertentangan dengan rencana dan tuntutan efisiensi serta produktivitas. Konflik ini jelas tidak terselesaikan demi kode berkualitas tinggi, karena kode yang buruk bahkan tidak dikritik. Dan kegagalan memenuhi rencana tentu saja dikritik.
Apa yang harus dilakukan? Saya melihat dan menyarankan dua jalur yang bisa digabungkan.
Yang pertama adalah menunjukkan kode Anda kepada seseorang di perusahaan. Bukan secara reaktif (diminta atau dipaksa), tetapi secara proaktif (hei, bung, lihat kode saya, dong). Kuncinya di sini adalah menghindari basa-basi atau mencoba menutupi kritik kode dengan kata-kata yang sopan. Jika kodenya jelek, kami langsung bilang: kodenya jelek. Tentu saja dengan penjelasan dan rekomendasi tentang cara memperbaikinya.
Namun pendekatan ini juga bermasalah. Penerapannya bergantung pada titik kontak. Jika pekerjaan sudah dimasukkan ke tahap produksi dan ternyata kodenya buruk, tidak ada gunanya mengulanginya. Atau lebih tepatnya, tidak ada alasanāmetrik akan anjlok. Manajer akan turun tangan dan menghujani Anda dengan tuntutan kinerja. Dan jangan coba-coba menjelaskan kepada mereka bahwa kode yang buruk pasti akan muncul kembali sebagai bugāitu akan menjadi bumerang. Anda hanya bisa berkomitmen untuk tidak mengulanginya lagi.
Jika pekerjaan belum rampung, atau baru saja dimulai, maka menuangkan omong kosong pada kode (atau proyek, ide) dapat memiliki arti yang sangat praktis - orang tersebut akan melakukannya dengan benar.
Pilihan kedua, dan yang paling menarik, adalah mengembangkan perangkat lunak sumber terbuka di waktu luang Anda. Tujuannya adalah agar sekelompok programmerāatau lebih tepatnya, programmerāmelihat kode Anda dan mengomentarinya. Di dalam perusahaan, tidak ada yang punya waktu. Lagipula, programmer di seluruh dunia tidak punya kegiatan lain yang lebih baik, jadi jika Anda menulis sesuatu yang bermanfaat dari sudut pandang praktis, mereka pasti akan memperhatikannya.
Keuntungan utamanya, menurut saya, adalah menulis kode di luar jam kerja, karena tidak ada kompromi antara kualitas kode dan kecepatan penyelesaian. Anda bisa menghabiskan waktu setahun untuk mengembangkan proyek Anda sendiri. Anda tidak akan tertekan oleh tenggat waktu, spesifikasi, uang, atau atasan Anda. Kebebasan dan kreativitas sepenuhnya ada di sini.
Hanya melalui kreativitas bebas, Anda akan memahami dan merasakan betapa hebatnya kode, melihat keindahan bahasa dan teknologi pemrograman, serta merasakan serunya tantangan bisnis. Dan Anda akan belajar menulis kode berkualitas tinggi.
Memang, ini membutuhkan waktu pribadi. Sama seperti pengembangan lainnya. Anggaplah ini bukan sebagai pengeluaran, melainkan sebagai investasiāuntuk diri sendiri.
Sumber: www.habr.com
