Sumber: DZone Memulakan permulaan adalah sukar, tetapi menulis perisian untuknya bukanlah lebih mudah. Untuk perisian berfungsi dengan baik, anda memerlukan kod yang baik. Tetapi bagaimana anda boleh memastikan kod anda benar-benar bagus? Semasa bekerja dengan kod pelanggan, kami mendapati bahawa banyak pembangun bebas dan juga syarikat IT mengabaikan ulasan kod. Oleh kerana pasukan kami menganggap semakan kod sebagai langkah kerja standard, kami memutuskan untuk menerangkan pandangan kami. Jadi mari kita mulakan dengan beberapa istilah asas.
Apakah semakan kod?
Ia adalah pemeriksaan sistematik kod sumber perisian untuk mencari ralat dan menilai kualiti. Semakan kod terdiri daripada langkah-langkah berikut:
Menentukan cara yang paling berkesan untuk menyelesaikan tugas;
Cari ralat logik;
Cari kelemahan yang paling biasa;
Pengesanan perisian hasad ialah jenis pemeriksaan kod khas untuk mencari cebisan kod yang mencurigakan atau mencari dan mana-mana perisian hasad yang disepadukan ke dalam perisian.
Mengapa anda memerlukan semakan kod?
Terdapat beberapa sebab mengapa semakan kod dianggap sebagai bahagian pembangunan yang perlu. Sebab pertama ialah pengurangan risiko. Katakan anda mempunyai perisian yang ditulis oleh pekerja bebas atau agensi, tetapi anda tidak pasti tentang kualiti kerja kerana pembangun yang baik pun boleh terlepas sesuatu. Jadi semakan dua kali adalah idea yang baik. Selain itu, dengan bekerjasama untuk mempelajari kod, setiap ahli pasukan boleh menghasilkan penyelesaian yang lebih bijak yang akan meningkatkan prestasi keseluruhan projek. Perkara utama yang perlu diingat tentang semakan kod ialah ia perlu dilakukan SEBELUM pasukan pembangunan baharu anda mengambil pangkalan kod atau projek. Semakan kod sebelum melancarkan projek memberi peluang kepada pasukan anda untuk menyemaknya dan menentukan kualiti kod dan sama ada penambahbaikan diperlukan.
Panduan untuk Semakan Kod
Berdasarkan pengalaman kami, kami memutuskan untuk menyediakan panduan ringkas untuk pembangun yang akan menyemak kod sumber projek mereka.
Bahagikan ulasan kod kepada selang masa
Jangan cuba menganalisis keseluruhan projek sekaligus. Pakar menasihatkan supaya tidak menyemak lebih daripada 400 baris kod sekaligus. Lebih-lebih lagi, pemeriksaan sekali perlu mengambil masa tidak lebih daripada satu jam. Manusia tidak dapat memproses jumlah maklumat ini dengan cekap, terutamanya dalam jangka masa yang panjang. Apabila anda melebihi markah ini, keupayaan untuk mengesan ralat berkurangan dengan ketara, jadi anda mungkin terlepas beberapa ralat penting.
Minta bantuan rakan sepasukan anda
Satu kepala itu bagus, tetapi dua lebih baik. Anda mungkin terkejut betapa kualiti ulasan anda akan bertambah baik jika anda berkongsi proses ini dengan orang lain. Kami sudah biasa melakukan semakan kod kolaboratif menggunakan Atlassian's Crucible . Alat ini membolehkan anda menetapkan penyemak tambahan, membincangkan baris kod sumber, fail atau keseluruhan set perubahan yang dipilih. Semakan kod kolaboratif bukan sahaja menambah baik perisian, tetapi juga meningkatkan kecekapan pasukan dengan berkongsi pengetahuan melalui perbincangan.
Penunjuk merekod
Sebelum semakan bermula, pasukan harus menetapkan matlamat yang tepat, seperti "memotong separuh kadar kecacatan." Matlamat "mencari lebih banyak pepijat" adalah terlalu abstrak dan oleh itu mustahil untuk dicapai. Semasa semakan, rekodkan penunjuk seperti kelajuan semakan, bilangan ralat ditemui setiap jam dan purata bilangan ralat setiap baris kod. Memantau hasil semakan yang berterusan akan menunjukkan kepada anda gambaran sebenar proses dalaman.
Kekalkan sikap positif
Semakan kod kadangkala boleh memburukkan hubungan dalam pasukan. Tiada siapa yang suka dikritik, jadi sangat penting untuk mengekalkan suasana mesra melainkan anda mahu rakan sekerja anda hilang motivasi. Daripada melihat setiap pepijat secara negatif, anggap ia sebagai peluang baharu untuk meningkatkan kualiti kod anda secara keseluruhan.
Sediakan proses pembetulan ralat
Jadi pasukan anda telah menyelesaikan semakan kod, tetapi bagaimana pula dengan membetulkan sebarang pepijat yang ditemui? Kami terkejut apabila mengetahui bahawa tidak semua pasukan pembangunan mempunyai kaedah yang ditetapkan untuk membetulkan ralat yang ditemui. Nasib baik, kami secara kolektif bekerja bukan sahaja untuk mencari kesilapan, tetapi juga untuk membetulkannya. Semua pepijat dibincangkan dengan pencipta (kecuali apabila kami menyemak kod pasukan lain) dan semua perubahan sentiasa diluluskan sebelum ditolak ke sumber.
Merumuskan
Semakan kod harus menjadi proses penting dalam mana-mana syarikat pembangunan kerana ia membantu mengekalkan standard pengekodan berkualiti tinggi. Bekerjasama dalam semakan kod menyatukan pasukan dan memberi peluang untuk berkongsi pengetahuan dan pengalaman dalam syarikat. Jadi sama ada anda menjalankan permulaan atau menyerahkan projek kepada pasukan lain, sentiasa lakukan semakan kod untuk memastikan perisian anda berkualiti terbaik.
Sindrom penipu ialah kawan baik pembangun
Sumber: Catalins.tech Selepas membaca tajuk, anda mungkin fikir ada sesuatu yang tidak kena dengan saya. Tetapi saya akan katakan sekali lagi: sindrom penipu adalah kawan baik pembangun jika disalurkan ke arah yang betul. Saya juga percaya bahawa sindrom penipu begitu meluas dalam pembangunan perisian kerana jumlah pengetahuan yang anda mesti ada dan perubahan berterusan dalam alat dan bahasa pengaturcaraan. Bahasa pengaturcaraan dan alatan yang anda gunakan hari ini mungkin sudah lapuk dalam tempoh setahun. Ini bermakna anda sekali lagi perlu "bermula dari awal" sedikit sebanyak. Pembangunan perisian ialah persekitaran yang sangat dinamik di mana anda perlu sentiasa belajar. Tetapi, walaupun menghadapi kesukaran, anda boleh membiasakannya. Oleh itu, hampir mustahil untuk menyingkirkan sindrom penipu. Mengapa tidak kemudian belajar untuk hidup dengannya?
Kebanyakan kita mempunyainya
Biar saya beritahu awak sesuatu yang lain. Hampir semua daripada kita mengalami sindrom penipu. Selalu ada yang lebih baik dari kita. Selalu ada sesuatu yang kita tidak tahu. Sentiasa ada sesuatu untuk dipelajari. Setiap hari alat baru keluar. Dari semasa ke semasa, teknologi atau bahasa pengaturcaraan baharu muncul. Anda tidak akan dapat mempelajari semuanya. Mencuba untuk bersaing juga sangat sukar. Dan ini adalah bagaimana sindrom itu muncul. Anda mula bertanya kepada diri sendiri: "Adakah saya akan dapat melakukan ini?", "Adakah saya akan dapat melakukan x, y, z?", "Adakah saya akan mengenali teknologi x, y, z? ", "Bagaimana jika saya seorang penipu?", dan senarai itu diteruskan. Jawapannya ya, ya dan ya. Ngomong-ngomong, sindrom penipu adalah lebih teruk bagi pemula yang merasakan bahawa mereka tidak akan berjaya dalam bidang ini. Saya juga melalui ini. Anda boleh mengatasi sindrom dengan kerja keras.
Bayangkan
Anda bukan satu-satunya yang bertanya kepada diri sendiri soalan-soalan ini. Rakan sekerja anda mempunyai masalah yang sama. Pembangun yang anda ikuti di Twitter juga mempunyai soalan yang serupa. Dan blogger video dengan 50,000 pelanggan. Dan soalan-soalan ini juga muncul di hadapan saya, walaupun saya mempunyai pekerjaan dan semuanya baik-baik saja. Soalan bukan sahaja mengganggu anda. Sindrom penipu adalah sebahagian daripada profesion kami. Sudah tentu, sesetengah orang menanganinya dengan lebih baik, jadi tidak begitu jelas bahawa mereka juga mempunyai masalah. Tetapi percayalah: hampir semua daripada kita mempunyainya.
Apa nak buat?
Pertama sekali, anda mesti faham bahawa sindrom penipu boleh menjadi kawan baik anda. Lagipun, dia mendorong anda untuk menjadi lebih baik. Perasaan seperti anda tidak sesuai untuk industri, atau anda tidak tahu banyak, boleh menjadi insentif untuk mengetahui lebih lanjut. Hasilnya, anda menjadi lebih baik setiap hari. Saya menggunakan sindrom penipu sebagai bahan api, sebagai motivasi untuk menjadi pembangun yang lebih baik, dan ia berfungsi dengan baik. Tetapi berhati-hati—ia boleh mendorong anda ke arah keletihan dengan cepat. Percayalah, anda tidak memerlukan ini. Setiap kali soalan dan fikiran tidak rasional muncul di kepala anda, INGAT bahawa semua pembangun mengalami sindrom yang sama. INGAT bahawa sentiasa ada pembangun yang lebih baik daripada anda. Tetapi juga INGAT bahawa sentiasa ada pembangun yang lebih teruk daripada anda. INGAT bahawa anda tidak boleh mengetahui segala-galanya, dan tidak mengapa. Anda hanya perlu mengetahui beberapa alatan yang berkaitan dengan pekerjaan anda. Dengan kegigihan, anda boleh menjadi pembangun yang baik. Adakah anda fikir anda akan menjadi pengaturcara terbaik? Kemungkinan besar tidak. Adakah anda akan bekerja untuk Amazon/Facebook/Google/Apple? Mungkin juga tidak. Adakah anda akan mendapat berjuta-juta? hampir tidak. Tetapi anda tahu apa? Ini baik. Anda tidak perlu melakukan mana-mana perkara ini untuk menjadi pembangun yang baik. Kerana pada hakikatnya, kebanyakan kita tidak pernah mencapai semua matlamat ini.
Ingat
Hampir semua daripada kita mempunyai sindrom penipu.
Anda boleh mencapai kejayaan dalam industri ini melalui ketabahan anda.
Anda tidak akan tahu segala-galanya, dan tidak mengapa.
Selalu ada pembangun yang lebih baik daripada anda, tetapi terdapat juga pembangun yang lebih teruk daripada anda.
Anda tidak perlu menjadi pengaturcara superstar. Ia cukup untuk menjadi baik dalam kerja anda.
Jadi mari kita mulakan dengan beberapa istilah asas.
Bahasa pengaturcaraan dan alatan yang anda gunakan hari ini mungkin sudah lapuk dalam tempoh setahun. Ini bermakna anda sekali lagi perlu "bermula dari awal" sedikit sebanyak. Pembangunan perisian ialah persekitaran yang sangat dinamik di mana anda perlu sentiasa belajar. Tetapi, walaupun menghadapi kesukaran, anda boleh membiasakannya. Oleh itu, hampir mustahil untuk menyingkirkan sindrom penipu. Mengapa tidak kemudian belajar untuk hidup dengannya?
GO TO FULL VERSION