Sejak awal tahun 2018, saya telah menjadi pemimpin / pemimpin / pengembang utama dalam tim - sebut saja apa yang Anda inginkan, tetapi intinya adalah saya sepenuhnya bertanggung jawab atas salah satu modul dan untuk semua pengembang yang mengerjakannya. Posisi ini memberi saya pandangan baru pada proses pengembangan, karena saya terlibat dalam lebih banyak proyek dan berpartisipasi lebih aktif dalam pengambilan keputusan. Baru-baru ini, berkat dua keadaan ini, saya tiba-tiba menyadari betapa ukuran pemahaman mempengaruhi kode dan aplikasi.
Pikiran yang ingin saya ungkapkan adalah bahwa kualitas kode (dan produk akhir) terkait erat dengan seberapa banyak orang yang merancang dan menulis kode mengetahui apa yang mereka lakukan.
Anda mungkin berpikir sekarang: “Terima kasih, cap. Tentu saja, akan lebih baik untuk memahami apa yang Anda tulis sama sekali. Kalau tidak, dengan kesuksesan yang sama, Anda dapat menyewa sekelompok monyet untuk memalu pada kunci sewenang-wenang, dan tenang dalam hal ini. " Dan Anda benar sekali. Karena itu, saya menerima begitu saja: Anda menyadari bahwa memiliki gagasan umum tentang apa yang Anda lakukan adalah perlu. Ini bisa disebut tingkat pemahaman nol, dan kami tidak akan menganalisisnya secara terperinci. Kami akan menganalisis secara terperinci apa yang sebenarnya perlu dipahami dan bagaimana hal itu memengaruhi keputusan yang Anda buat setiap hari. Jika saya mengetahui hal-hal ini sebelumnya, ini akan menghemat banyak waktu dan kode yang meragukan.
Meskipun Anda tidak akan melihat satu baris kode di bawah ini, saya masih berpikir bahwa semua yang dikatakan di sini sangat penting untuk menulis kode ekspresif berkualitas tinggi.
Pemahaman Tingkat Satu: Mengapa Tidak Bekerja
Pengembang biasanya mencapai tingkat ini pada tahap awal karir mereka, kadang-kadang bahkan tanpa bantuan dari orang lain - setidaknya menurut pengamatan saya. Bayangkan Anda mendapat laporan bug: beberapa fungsi dalam aplikasi tidak berfungsi, Anda harus memperbaikinya. Bagaimana Anda akan bertindak?
Skema standar terlihat seperti ini:
- Temukan potongan kode yang menyebabkan masalah (bagaimana ini dilakukan adalah topik yang terpisah, saya ungkapkan dalam buku saya tentang kode yang sudah kadaluarsa)
- Buat perubahan pada cuplikan ini
- Pastikan bug diperbaiki dan tidak ada kesalahan regresif
Sekarang mari kita fokus pada poin kedua - membuat perubahan pada kode. Ada dua pendekatan untuk proses ini. Pertama: untuk mempelajari apa yang sebenarnya terjadi dalam kode saat ini, mengidentifikasi kesalahan dan memperbaikinya. Kedua: pindah ke sentuhan - tambahkan, ucapkan, +1 ke pernyataan atau loop kondisional, lihat apakah fungsi ini berfungsi dalam skenario yang benar, lalu coba yang lain dan seterusnya hingga tak terhingga.
Pendekatan pertama benar. Seperti yang dijelaskan Steve McConnell dalam bukunya Code Complete (omong-omong, saya sangat merekomendasikannya), setiap kali kita mengubah sesuatu dalam kode, kita harus dapat memprediksi dengan pasti bagaimana ini akan mempengaruhi aplikasi. Saya mengutip dari memori, tetapi jika perbaikan bug tidak bekerja seperti yang Anda harapkan, Anda harus sangat dijaga, Anda harus mempertanyakan seluruh rencana tindakan Anda.
Meringkas di atas, untuk melakukan perbaikan bug yang solid yang tidak menurunkan kualitas kode, Anda perlu memahami seluruh struktur kode dan sumber masalah tertentu.
Pemahaman tingkat kedua: Mengapa itu berhasil?
Tingkat ini dipahami jauh kurang intuitif daripada yang sebelumnya. Menjadi pengembang pemula, saya mempelajarinya berkat bos saya, dan kemudian saya berulang kali menjelaskan esensi masalah ini kepada pemula.
Kali ini, mari kita bayangkan bahwa Anda menerima dua laporan bug sekaligus: yang pertama adalah tentang skenario A, yang kedua adalah tentang skenario B. Ada yang salah di kedua skenario. Oleh karena itu, Anda diambil pertama untuk bug pertama. Dipandu oleh prinsip-prinsip yang kami perkenalkan untuk tingkat pemahaman pertama, Anda mempelajari kode yang relevan dengan masalah, mencari tahu mengapa itu memaksa aplikasi untuk berperilaku persis seperti itu dalam skenario A, dan membuat penyesuaian yang masuk akal yang memberikan hasil persis seperti yang Anda inginkan. diharapkan. Semuanya baik-baik saja.
Kemudian Anda masuk ke skenario B. Anda mengulangi skrip dalam upaya untuk memprovokasi kesalahan, tapi - kejutan! - Sekarang semuanya berfungsi sebagaimana mestinya. Untuk mengonfirmasi dugaan Anda, Anda membatalkan perubahan yang dilakukan dalam proses mengerjakan kesalahan A, dan bug B kembali lagi. Perbaikan bug Anda menyelesaikan kedua masalah. Beruntung!
Anda sama sekali tidak mengandalkannya. Anda menemukan cara untuk memperbaiki kesalahan dalam skenario A dan Anda tidak tahu mengapa itu berhasil untuk skenario B. Pada tahap ini, ada godaan besar untuk memutuskan bahwa kedua tugas telah berhasil diselesaikan. Ini cukup logis: intinya adalah untuk menghilangkan kesalahan, bukan? Tetapi pekerjaan belum berakhir: Anda masih harus mencari tahu mengapa tindakan Anda memperbaiki kesalahan dalam skenario B. Mengapa? Kemudian, agar dia bekerja pada prinsip-prinsip yang salah, dan Anda perlu mencari cara lain. Berikut adalah beberapa contoh kasus tersebut:
- karena solusi tidak dapat ditargetkan secara spesifik untuk kesalahan B, dengan mempertimbangkan semua faktor, Anda mungkin secara tidak sadar telah merusak fungsi C.
- ada kemungkinan bahwa bug ketiga yang terkait dengan fungsi yang sama juga bersembunyi, dan perbaikan bug Anda membuat sistem bekerja dengan benar dalam skrip B di atasnya. Sekarang semuanya terlihat baik, tetapi suatu hari bug ketiga ini akan diperhatikan dan diperbaiki. Kemudian dalam skenario B, kesalahan terjadi lagi, dan yah, jika hanya ada.
Semua ini memperkenalkan keacakan ke dalam kode dan suatu hari nanti akan jatuh di kepala Anda - kemungkinan besar, pada saat yang paling tidak tepat. Anda harus mengumpulkan keinginan Anda untuk memaksa diri Anda menghabiskan waktu memahami mengapa segala sesuatu tampaknya berhasil, tetapi itu sepadan.
Tingkat Pemahaman Ketiga: Mengapa Itu Bekerja?
Wawasan saya baru-baru ini terhubung tepat dengan level ini, dan mungkin itu akan memberi saya manfaat paling besar jika saya sampai pada ide ini sebelumnya.
Untuk membuatnya lebih jelas, mari kita lihat sebuah contoh: modul Anda harus dibuat kompatibel dengan fungsi X. Anda tidak terlalu terbiasa dengan fungsi X, tetapi Anda diberitahu bahwa Anda perlu menggunakan kerangka kerja F. untuk kompatibilitas dengannya. Modul lain yang berintegrasi dengan X bekerja persis dengan dia.
Sejak hari pertama hidup Anda, kode Anda belum menyentuh kerangka F sama sekali, sehingga tidak akan mudah untuk mengimplementasikannya. Ini akan memiliki konsekuensi serius untuk beberapa komponen modul. Namun demikian, Anda menuju ke pengembangan: menulis kode selama berminggu-minggu, menguji, meluncurkan versi percontohan, mendapatkan umpan balik, memperbaiki kesalahan regresi, menemukan komplikasi yang tidak terduga, tidak masuk ke dalam kerangka waktu yang disepakati semula, menulis beberapa kode lagi, menguji, mendapatkan yang sebaliknya koneksi, kesalahan regresi yang benar - semua ini untuk menerapkan kerangka F.
Dan pada titik tertentu Anda tiba-tiba menyadari - atau mungkin mendengar dari seseorang - bahwa mungkin kerangka kerja F tidak akan memberi Anda kompatibilitas dengan fungsi X sama sekali. Mungkin selama ini dan usaha tidak diterapkan sama sekali untuk itu.
Sesuatu yang serupa terjadi sekali dalam perjalanan suatu proyek di mana saya bertanggung jawab. Mengapa ini terjadi? Karena saya kurang mengerti apa esensi fungsi X dan bagaimana hubungannya dengan kerangka kerja F. Apa yang harus saya lakukan? Minta orang yang mengatur tugas pengembangan untuk menjelaskan dengan jelas bagaimana rencana tindakan yang direncanakan mengarah ke hasil yang diinginkan, alih-alih hanya mengulangi apa yang dilakukan untuk modul lain, atau untuk mengambil kata bahwa fungsi X perlu berfungsi.
Pengalaman proyek ini mengajarkan saya untuk menolak memulai proses pengembangan sampai kita memiliki pemahaman yang jelas tentang mengapa kita diminta untuk melakukan tindakan tertentu. Menolak teks biasa. Ketika Anda menerima tugas, impuls pertama adalah mengambilnya segera agar tidak membuang waktu dengan sia-sia. Tetapi kebijakan "membekukan proyek sampai kita masuk ke semua rincian" dapat mengurangi waktu yang terbuang dengan perintah besarnya.
Bahkan jika mereka mencoba menekan Anda, memaksa Anda untuk mulai bekerja, meskipun Anda tidak mengerti bagaimana ini dibenarkan, lawanlah. Pertama, cari tahu tujuan Anda ditugaskan tugas seperti itu, dan putuskan apakah ini jalan yang benar ke tujuan. Saya harus mempelajari semua ini melalui pengalaman pahit - Saya berharap bagi mereka yang membaca ini, teladan saya akan membuat hidup lebih mudah.
Tingkat pemahaman keempat: ???
Selalu ada sesuatu untuk dipelajari dalam pemrograman, dan saya kira saya hanya menyentuh pada lapisan paling atas dari topik pemahaman. Tingkat pemahaman apa lagi yang Anda temukan selama bertahun-tahun bekerja dengan kode? Keputusan apa yang dibuat yang berdampak baik pada kualitas kode dan aplikasinya? Keputusan apa yang ternyata salah dan mengajari Anda pelajaran yang berharga? Bagikan pengalaman Anda dalam komentar.