Sejak awal tahun 2018, saya menjabat posisi lead/bos/lead developer di tim - sebut saja sesuka hati, tapi intinya saya bertanggung jawab sepenuhnya terhadap salah satu modul dan seluruh developer yang bekerja. di atasnya. Posisi ini memberi saya perspektif baru mengenai proses pembangunan, karena saya terlibat dalam lebih banyak proyek dan lebih aktif terlibat dalam pengambilan keputusan. Baru-baru ini, berkat dua hal ini, saya tiba-tiba menyadari seberapa besar pengaruh ukuran pemahaman terhadap kode dan aplikasi.
Hal yang ingin saya sampaikan adalah bahwa kualitas kode (dan produk akhir) berkaitan erat dengan seberapa sadar orang yang merancang dan menulis kode terhadap apa yang mereka lakukan.
Saat ini Anda mungkin berpikir, “Terima kasih, Kap. Tentu saja, alangkah baiknya jika Anda memahami apa yang Anda tulis secara umum. Jika tidak, Anda sebaiknya menyewa sekelompok monyet untuk menekan tombol sembarangan dan berhenti di situ.” Dan Anda memang benar. Oleh karena itu, saya menerima begitu saja bahwa Anda menyadari bahwa memiliki gambaran umum tentang apa yang Anda lakukan itu perlu. Ini bisa disebut tingkat pemahaman nol, dan kami tidak akan menganalisisnya secara detail. Kami akan melihat secara detail apa sebenarnya yang perlu Anda pahami dan bagaimana pengaruhnya terhadap keputusan yang Anda buat setiap hari. Jika saya mengetahui hal-hal ini sebelumnya, ini akan menghemat banyak waktu terbuang dan kode yang meragukan.
Meskipun Anda tidak akan melihat satu baris kode pun di bawah ini, saya tetap yakin bahwa semua yang disebutkan di sini sangat penting untuk menulis kode ekspresif berkualitas tinggi.
Pemahaman tingkat pertama: Mengapa tidak berhasil?
Pengembang biasanya mencapai level ini di awal karier mereka, terkadang bahkan tanpa bantuan orang lain - setidaknya menurut pengalaman saya. Bayangkan Anda menerima laporan bug: beberapa fungsi dalam aplikasi tidak berfungsi, perlu diperbaiki. Bagaimana Anda melanjutkannya?
Skema standarnya terlihat seperti ini:
- Temukan potongan kode yang menyebabkan masalah (cara melakukan ini adalah topik terpisah, saya membahasnya di buku saya tentang kode lama)
- Buat perubahan pada cuplikan ini
- Pastikan bug telah diperbaiki dan tidak terjadi kesalahan regresi
Sekarang mari kita fokus pada poin kedua - membuat perubahan pada kode. Ada dua pendekatan untuk proses ini. Yang pertama adalah menyelidiki apa yang sebenarnya terjadi pada kode saat ini, mengidentifikasi kesalahan dan memperbaikinya. Kedua: bergerak berdasarkan perasaan - tambahkan, katakanlah, +1 ke pernyataan atau perulangan kondisional, lihat apakah fungsinya berfungsi dalam skenario yang diinginkan, lalu coba yang lain, dan seterusnya tanpa batas.
Pendekatan pertama benar. Seperti yang dijelaskan Steve McConnell dalam bukunya Code Complete (yang sangat saya rekomendasikan), setiap kali kita mengubah sesuatu dalam kode, kita harus dapat memprediksi dengan yakin bagaimana hal itu akan memengaruhi aplikasi. Saya mengutip dari ingatan, tetapi jika perbaikan bug tidak berjalan seperti yang Anda harapkan, Anda harus sangat khawatir dan Anda harus mempertanyakan keseluruhan rencana tindakan Anda.
Untuk meringkas apa yang telah dikatakan, untuk melakukan perbaikan bug yang baik dan tidak menurunkan kualitas kode, Anda perlu memahami keseluruhan struktur kode dan sumber masalah spesifik.
Pemahaman tingkat kedua: Mengapa ini berhasil?
Tingkat ini dipahami secara kurang intuitif dibandingkan tingkat sebelumnya. Saya, ketika masih seorang pengembang pemula, mempelajarinya berkat atasan saya, dan kemudian berulang kali menjelaskan inti permasalahannya kepada pendatang baru.
Kali ini, bayangkan Anda menerima dua laporan bug sekaligus: yang pertama tentang skenario A, yang kedua tentang skenario B. Dalam kedua skenario, terjadi sesuatu yang salah. Oleh karena itu, Anda mengatasi bug pertama terlebih dahulu. Dengan menggunakan prinsip-prinsip yang kami kembangkan untuk pemahaman Tingkat XNUMX, Anda menggali lebih dalam kode yang relevan dengan masalah, mencari tahu mengapa hal ini menyebabkan aplikasi berperilaku seperti dalam Skenario A, dan membuat penyesuaian wajar yang menghasilkan hasil yang Anda inginkan. . Semuanya berjalan baik.
Kemudian Anda melanjutkan ke skenario B. Anda mengulangi skenario tersebut dalam upaya menimbulkan kesalahan, namun—kejutan! — sekarang semuanya berjalan sebagaimana mestinya. Untuk mengonfirmasi tebakan Anda, Anda membatalkan perubahan yang Anda buat saat mengerjakan bug A, dan bug B muncul kembali. Perbaikan bug Anda memecahkan kedua masalah tersebut. Beruntung!
Anda tidak mengandalkan ini sama sekali. Anda telah menemukan cara untuk memperbaiki kesalahan dalam skenario A dan tidak tahu mengapa hal itu berhasil untuk skenario B. Pada tahap ini, sangat menggoda untuk berpikir bahwa kedua tugas telah berhasil diselesaikan. Ini cukup logis: intinya menghilangkan kesalahan, bukan? Namun pekerjaannya belum selesai: Anda masih harus mencari tahu mengapa tindakan Anda memperbaiki kesalahan dalam skenario B. Mengapa? Karena mungkin bekerja berdasarkan prinsip yang salah, dan Anda perlu mencari jalan keluar lain. Berikut adalah beberapa contoh kasus tersebut:
- Karena solusinya tidak disesuaikan dengan kesalahan B, dengan mempertimbangkan semua faktor, Anda mungkin tanpa sadar telah merusak fungsi C.
- Mungkin juga terdapat bug ketiga yang mengintai di suatu tempat, terkait dengan fungsi yang sama, dan perbaikan bug Anda bergantung padanya agar sistem dapat berfungsi dengan benar dalam skenario B. Semuanya tampak baik sekarang, tetapi suatu hari bug ketiga ini akan diketahui dan diperbaiki. Lalu di skenario B errornya akan terjadi lagi, dan ada baiknya kalau sampai disitu saja.
Semua ini menambah kekacauan pada kode dan suatu hari nanti akan menimpa Anda - kemungkinan besar pada saat yang paling tidak tepat. Anda harus mengerahkan tekad untuk memaksa diri Anda meluangkan waktu untuk memahami mengapa segala sesuatunya tampak berhasil, tetapi itu sepadan.
Pemahaman tingkat ketiga: Mengapa ini berhasil?
Pemahaman saya baru-baru ini berkaitan erat dengan tingkat ini, dan mungkin tingkat inilah yang akan memberi saya manfaat terbesar jika saya memikirkan gagasan ini lebih awal.
Untuk membuatnya lebih jelas, mari kita lihat sebuah contoh: modul Anda harus dibuat kompatibel dengan fungsi X. Anda tidak terlalu familiar dengan fungsi X, namun Anda diberitahu bahwa agar kompatibel dengannya Anda perlu menggunakan kerangka kerja F. Lainnya modul yang terintegrasi dengan X bekerja persis dengannya.
Kode Anda belum pernah berhubungan dengan kerangka F sama sekali sejak hari pertama digunakan, jadi mengimplementasikannya tidak akan mudah. Hal ini akan menimbulkan konsekuensi serius pada beberapa bagian modul. Namun, Anda terjun ke dalam pengembangan: Anda menghabiskan waktu berminggu-minggu untuk menulis kode, menguji, meluncurkan versi percontohan, mendapatkan umpan balik, memperbaiki kesalahan regresi, menemukan komplikasi yang tidak terduga, tidak memenuhi tenggat waktu yang disepakati sebelumnya, menulis beberapa kode lagi, menguji, mendapatkan komunikasi umpan balik, memperbaiki kesalahan regresi - semua ini untuk mengimplementasikan kerangka F.
Dan pada titik tertentu Anda tiba-tiba menyadari - atau mungkin mendengar dari seseorang - bahwa mungkin kerangka F tidak akan memberi Anda kompatibilitas sama sekali dengan fitur X. Mungkin semua waktu dan upaya yang dilakukan salah untuk hal itu.
Hal serupa pernah terjadi ketika mengerjakan proyek yang menjadi tanggung jawab saya. Kenapa ini terjadi? Karena saya kurang memahami apa itu fungsi X dan kaitannya dengan framework F. Apa yang harus saya lakukan? Mintalah orang yang menugaskan tugas pengembangan untuk menjelaskan dengan jelas bagaimana tindakan yang dimaksudkan akan menghasilkan hasil yang diinginkan, daripada sekadar mengulangi apa yang telah dilakukan untuk modul lain atau percaya bahwa inilah yang perlu dilakukan oleh fitur X.
Pengalaman proyek ini mengajarkan saya untuk menolak memulai proses pengembangan sampai kita memiliki pemahaman yang jelas mengapa kita diminta melakukan hal-hal tertentu. Menolak mentah-mentah. Saat menerima tugas, dorongan pertama adalah segera mengerjakannya agar tidak membuang waktu. Namun kebijakan “membekukan proyek sampai kita membahas semua detailnya” dapat mengurangi waktu yang terbuang dalam jumlah besar.
Bahkan jika mereka mencoba menekan Anda, memaksa Anda untuk mulai bekerja, meskipun Anda tidak memahami alasannya, tolaklah. Pertama, cari tahu mengapa Anda diberi tugas seperti itu, dan putuskan apakah ini jalan yang tepat untuk mencapai tujuan tersebut. Saya harus mempelajari semua ini dengan susah payah - saya harap contoh saya akan membuat hidup lebih mudah bagi mereka yang membaca ini.
Pemahaman tingkat keempat: ???
Selalu ada lebih banyak hal yang perlu dipelajari dalam pemrograman, dan saya yakin saya hanya menggores permukaan dari topik pemahaman. Tingkat pemahaman apa lagi yang Anda temukan selama bertahun-tahun bekerja dengan kode? Keputusan apa yang Anda ambil yang berdampak positif terhadap kualitas kode dan aplikasi? Keputusan apa yang ternyata salah dan memberi Anda pelajaran berharga? Bagikan pengalaman Anda di komentar.
Sumber: www.habr.com