Sejak awal tahun 2018, saya telah memegang jawatan sebagai ketua/bos/pembangun utama dalam pasukan - panggil apa yang anda mahukan, tetapi intinya ialah saya bertanggungjawab sepenuhnya untuk salah satu modul dan untuk semua pembangun yang bekerja di atasnya. Kedudukan ini memberi saya perspektif baharu tentang proses pembangunan, kerana saya terlibat dalam lebih banyak projek dan lebih aktif terlibat dalam membuat keputusan. Baru-baru ini, terima kasih kepada dua perkara ini, saya tiba-tiba menyedari betapa besarnya ukuran pemahaman mempengaruhi kod dan aplikasi.
Perkara yang saya ingin nyatakan ialah kualiti kod (dan produk akhir) berkait rapat dengan tahap kesedaran orang yang mereka bentuk dan menulis kod tentang apa yang mereka lakukan.
Anda mungkin berfikir sekarang, “Terima kasih, Kap. Sudah tentu, adalah baik untuk memahami apa yang anda tulis secara umum. Jika tidak, anda juga boleh mengupah sekumpulan monyet untuk menekan kekunci sewenang-wenangnya dan biarkan sahaja." Dan anda betul-betul betul. Oleh itu, saya mengambil mudah bahawa anda menyedari bahawa mempunyai idea umum tentang apa yang anda lakukan adalah perlu. Ini boleh dipanggil tahap kefahaman sifar, dan kami tidak akan menganalisisnya secara terperinci. Kami akan melihat secara terperinci apa sebenarnya yang anda perlu fahami dan bagaimana ia mempengaruhi keputusan yang anda buat setiap hari. Sekiranya saya mengetahui perkara ini lebih awal, ia akan menjimatkan banyak masa terbuang dan kod yang boleh dipersoalkan.
Walaupun anda tidak akan melihat satu baris kod di bawah, saya masih percaya bahawa semua yang dinyatakan di sini adalah sangat penting untuk menulis kod ekspresif yang berkualiti tinggi.
Tahap pemahaman pertama: Mengapa ia tidak berkesan?
Pembangun biasanya mencapai tahap ini sangat awal dalam kerjaya mereka, kadangkala tanpa bantuan daripada orang lain - sekurang-kurangnya dalam pengalaman saya. Bayangkan anda menerima laporan pepijat: beberapa fungsi dalam aplikasi tidak berfungsi, ia perlu diperbaiki. Bagaimana anda akan meneruskan?
Skim standard kelihatan seperti ini:
- Cari sekeping kod yang menyebabkan masalah (cara melakukan ini adalah topik yang berasingan, saya mengupasnya dalam buku saya tentang kod warisan)
- Buat perubahan pada coretan ini
- Pastikan pepijat telah dibetulkan dan tiada ralat regresi telah berlaku
Sekarang mari kita fokus pada perkara kedua - membuat perubahan pada kod. Terdapat dua pendekatan untuk proses ini. Yang pertama adalah untuk menyelidiki apa sebenarnya yang berlaku dalam kod semasa, mengenal pasti ralat dan membetulkannya. Kedua: bergerak mengikut rasa - tambah, katakan, +1 pada pernyataan atau gelung bersyarat, lihat jika fungsi berfungsi dalam senario yang diingini, kemudian cuba sesuatu yang lain, dan seterusnya ad infinitum.
Pendekatan pertama adalah betul. Seperti yang dijelaskan oleh Steve McConnell dalam bukunya Code Complete (yang saya sangat mengesyorkan, dengan cara ini), setiap kali kita menukar sesuatu dalam kod, kita seharusnya dapat meramalkan dengan yakin bagaimana ia akan mempengaruhi aplikasi. Saya memetik daripada ingatan, tetapi jika pembetulan pepijat tidak berfungsi seperti yang anda jangkakan, anda sepatutnya berasa sangat cemas dan anda harus mempersoalkan keseluruhan pelan tindakan anda.
Untuk meringkaskan apa yang telah diperkatakan, untuk melakukan pembetulan pepijat yang baik yang tidak merendahkan kualiti kod, anda perlu memahami kedua-dua struktur keseluruhan kod dan punca masalah tertentu.
Tahap pemahaman kedua: Mengapa ia berfungsi?
Tahap ini difahami dengan lebih kurang intuitif daripada tahap sebelumnya. Saya, semasa masih pemaju pemula, mempelajarinya terima kasih kepada bos saya, dan seterusnya berulang kali menerangkan intipati perkara itu kepada pendatang baru.
Kali ini, mari kita bayangkan bahawa anda menerima dua laporan pepijat serentak: yang pertama ialah tentang senario A, yang kedua ialah tentang senario B. Dalam kedua-dua senario, sesuatu yang salah berlaku. Oleh itu, anda menangani pepijat pertama terlebih dahulu. Menggunakan prinsip yang kami bangunkan untuk pemahaman Tahap 1, anda mendalami kod yang berkaitan dengan masalah, mengetahui sebab ia menyebabkan aplikasi berkelakuan seperti yang dilakukan dalam Senario A dan membuat pelarasan munasabah yang menghasilkan hasil yang anda inginkan. dijangka . Semuanya berjalan lancar.
Kemudian anda beralih ke senario B. Anda mengulangi senario itu dalam percubaan untuk mencetuskan ralat, tetapi—mengejutkan! — kini semuanya berfungsi sebagaimana mestinya. Untuk mengesahkan tekaan anda, anda membuat asal perubahan yang anda buat semasa mengusahakan pepijat A dan pepijat B kembali. Pembetulan pepijat anda menyelesaikan kedua-dua masalah. Bertuah!
Anda tidak mengira ini sama sekali. Anda telah menghasilkan cara untuk membetulkan ralat dalam senario A dan tidak tahu mengapa ia berkesan untuk senario B. Pada peringkat ini, adalah sangat menarik untuk berfikir bahawa kedua-dua tugasan telah berjaya diselesaikan. Ini agak logik: maksudnya adalah untuk menghapuskan ralat, bukan? Tetapi kerja itu belum selesai lagi: anda masih perlu memikirkan mengapa tindakan anda membetulkan ralat dalam senario B. Mengapa? Kerana ia mungkin bekerja pada prinsip yang salah, dan kemudian anda perlu mencari jalan keluar lain. Berikut adalah beberapa contoh kes sedemikian:
- Memandangkan penyelesaian tidak disesuaikan dengan ralat B, dengan mengambil kira semua faktor, anda mungkin telah melanggar fungsi C tanpa disedari.
- Ada kemungkinan terdapat juga pepijat ketiga yang mengintai di suatu tempat, berkaitan dengan fungsi yang sama, dan pembetulan pepijat anda bergantung padanya untuk pengendalian sistem yang betul dalam senario B. Semuanya kelihatan baik sekarang, tetapi suatu hari nanti pepijat ketiga ini akan disedari dan diperbaiki. Kemudian dalam senario B ralat akan berlaku lagi, dan ia adalah baik jika hanya ada.
Semua ini menambah huru-hara pada kod dan suatu hari nanti akan jatuh di kepala anda - kemungkinan besar pada saat yang paling tidak sesuai. Anda perlu mengumpulkan kemahuan anda untuk memaksa diri anda meluangkan masa untuk memahami mengapa semuanya kelihatan berkesan, tetapi ia berbaloi.
Tahap pemahaman ketiga: Mengapa ia berfungsi?
Wawasan saya baru-baru ini berkaitan dengan tepat pada tahap ini, dan ia mungkin yang akan memberi saya manfaat paling banyak jika saya mendapat idea ini lebih awal.
Untuk menjadikannya lebih jelas, mari kita lihat contoh: modul anda perlu dibuat serasi dengan fungsi X. Anda tidak begitu biasa dengan fungsi X, tetapi anda diberitahu bahawa untuk serasi dengannya anda perlu menggunakan rangka kerja F. Lain-lain modul yang berintegrasi dengan X berfungsi tepat dengannya.
Kod anda tidak pernah berhubung dengan rangka kerja F sama sekali sejak hari pertama hayatnya, jadi melaksanakannya tidak akan begitu mudah. Ini akan mempunyai akibat yang serius untuk beberapa bahagian modul. Walau bagaimanapun, anda terlibat dalam pembangunan: anda menghabiskan masa berminggu-minggu menulis kod, menguji, melancarkan versi perintis, mendapatkan maklum balas, membetulkan ralat regresi, menemui komplikasi yang tidak dijangka, tidak memenuhi tarikh akhir yang dipersetujui, menulis beberapa kod lagi, menguji, mendapatkan komunikasi maklum balas, membetulkan ralat regresi - semua ini untuk melaksanakan rangka kerja F.
Dan pada satu ketika anda tiba-tiba menyedari - atau mungkin mendengar daripada seseorang - bahawa mungkin rangka kerja F tidak akan memberikan anda keserasian dengan ciri X sama sekali. Mungkin sepanjang masa dan usaha itu telah salah sepenuhnya untuk itu.
Sesuatu yang serupa berlaku sekali semasa mengerjakan projek yang saya bertanggungjawab. Mengapa ini berlaku? Kerana saya kurang memahami apakah fungsi X dan bagaimana ia berkaitan dengan rangka kerja F. Apakah yang sepatutnya saya lakukan? Minta orang yang memberikan tugas pembangunan untuk menerangkan dengan jelas bagaimana tindakan yang dimaksudkan membawa kepada hasil yang diingini, dan bukannya mengulangi apa yang telah dilakukan untuk modul lain atau mengambil kata-kata mereka bahawa inilah yang perlu dilakukan oleh ciri X.
Pengalaman projek ini mengajar saya untuk menolak untuk memulakan proses pembangunan sehingga kita mempunyai pemahaman yang jelas tentang mengapa kita diminta melakukan perkara-perkara tertentu. Tolak mentah-mentah. Apabila anda menerima tugas, dorongan pertama adalah untuk segera mengambilnya supaya tidak membuang masa. Tetapi dasar "membekukan projek sehingga kami mengetahui semua butiran" boleh mengurangkan masa yang terbuang mengikut urutan magnitud.
Walaupun mereka cuba memberi tekanan kepada anda, untuk memaksa anda memulakan kerja, walaupun anda tidak memahami rasional untuk ini, tahan. Mula-mula, fikirkan mengapa anda diberi tugas sedemikian, dan tentukan sama ada ini adalah jalan yang betul untuk mencapai matlamat. Saya terpaksa belajar semua ini dengan cara yang sukar - Saya harap contoh saya akan memudahkan hidup mereka yang membaca ini.
Tahap kefahaman keempat: ???
Selalu ada lagi yang perlu dipelajari dalam pengaturcaraan, dan saya percaya saya hanya menconteng permukaan topik pemahaman. Apakah tahap pemahaman lain yang telah anda temui selama bertahun-tahun bekerja dengan kod? Apakah keputusan yang anda buat yang mempunyai kesan positif terhadap kualiti kod dan aplikasi? Apakah keputusan yang ternyata salah dan memberi anda pelajaran berharga? Kongsi pengalaman anda dalam komen.
Sumber: www.habr.com