JavaRush /Blog Java /Random-MS /Coffee break #79. 10 kesilapan pembangun Java yang mengha...

Coffee break #79. 10 kesilapan pembangun Java yang menghalang mereka daripada mencapai kejayaan. Panduan Pembangun untuk Menulis Komen Kod Bermakna

Diterbitkan dalam kumpulan

10 Kesilapan Pembangun Java Menghalang Kejayaan Mereka

Sumber: Dev.to Coffee break #79.  10 kesilapan pembangun Java yang menghalang mereka daripada mencapai kejayaan.  Panduan Pembangun untuk Menulis Komen Kod Bermakna - 1 Berdasarkan pengalaman saya, saya telah menyusun senarai 10 kesilapan yang dibuat oleh pembangun yang menghalang mereka daripada mencapai kejayaan:

1. Jangan tulis ujian unit

Pembangun yang tidak menulis ujian unit membuat lebih banyak kesilapan dalam kod mereka. Ini membawa kepada ketidakstabilan produk dan ketidakpuasan hati pelanggan.

2. Mereka tidak menyemak kod secara manual

Walaupun anda menutup kod anda sepenuhnya dengan ujian unit, masih ada kemungkinan anda terlepas sesuatu. Anda sentiasa disyorkan untuk menguji kod anda secara manual sebelum menyerahkannya untuk semakan. Dengan cara ini anda boleh mengesan ralat pada peringkat pembangunan.

3. Mereka berfikir: "Ini tidak akan berlaku."

Pembangun sering membuat kesilapan semasa menulis kod baharu, memikirkan bahawa senario tertentu tidak akan berlaku. Akhirnya ternyata mereka salah. Mengendalikan semua senario di mana kod boleh dilaksanakan. Kaedah pengaturcaraan defensif akan membantu anda dengan ini.

4. Jangan dapatkan maklum balas

Selalu dapatkan maklum balas daripada pembangun dan pengguna lain. Kongsi pendapat anda dengan rakan sekerja anda.

5. Mereka tidak menyemak kefungsian kod.

Selalunya pemaju menulis kod mereka, tetapi tidak menyemak fungsinya. Akibatnya, apabila kod itu mencapai pengeluaran, ia menimbulkan pelbagai masalah.

6. Tulis kod prosedur yang panjang

Sangat mudah untuk menulis kaedah yang panjang dengan banyak logik. Dengan melakukan ini, pengaturcara melaksanakan logik yang sama di banyak tempat. Projek dengan sejumlah besar kaedah kecil mempunyai penggunaan semula kod yang lebih baik dan lebih mudah untuk diselenggara.

7. Mereka tidak tahu alatan

Alat adalah lanjutan tangan anda. Lebih baik anda mengenali mereka, lebih produktif anda. Anda sepatutnya sudah biasa dengan IDE yang anda gunakan. Belajar arahan pantas, sentiasa ada arahan yang akan membantu anda menjadi lebih produktif. Dalam IntelliJ IDEA ini ialah Sonar Lint, Spot bugs dan Code Metrics.

8. Abaikan masalah dalam kod

Pembangun yang mengusahakan produk yang paling berjaya sentiasa menukar kod. Jangan takut untuk memfaktorkan semula kod anda. Jika kod anda diuji unit, terdapat sedikit kemungkinan regresi. Pembangun sering mengabaikan kod bermasalah. Sebagai pembangun, anda bertanggungjawab untuk mengekalkan aplikasi dalam keadaan baik. Atas sebab ini, selesaikan sebarang masalah yang anda temui.

9. Mereka kod tanpa menyedari akibatnya.

Pembangun JANGAN PERNAH membuat perubahan pada kod dan mengeluarkannya ke dalam pengeluaran tanpa memahami akibatnya. Kod mungkin menghasilkan keputusan yang betul untuk nilai ujian yang diberikan. Walau bagaimanapun, mungkin terdapat senario di mana ini boleh membawa kepada keputusan yang tidak dapat diramalkan dan menimbulkan masalah yang serius. Pengekodan "tidak dapat diramalkan" sering berlaku apabila pembangun menggunakan fungsi daripada perpustakaan yang mereka tidak faham sepenuhnya. Ini juga boleh berlaku apabila pembangun membetulkan masalah tanpa memahami penyelesaiannya.

10. Jangan minta tolong

Pemaju bukan orang yang sangat bergaul. Mereka suka menyelesaikan masalah sendiri. Tetapi era apabila seorang pembangun sendiri mencipta produk dari awal hingga akhir sudah berakhir. Pembangunan perisian adalah aktiviti pasukan. Apabila anda menghadapi masalah semasa pengaturcaraan, cuba selesaikan sendiri. Tetapi jangan buang terlalu banyak masa jika anda tidak dapat mencari penyelesaian. Terdapat kemungkinan besar beberapa rakan sekerja anda telah pun menghadapi masalah yang sama dan mengetahui penyelesaiannya. Ini akan menjimatkan masa dan meningkatkan produktiviti.

Panduan Pembangun untuk Menulis Komen Kod Bermakna

Sumber: Saiz Langkah Dalam kebanyakan kes, anda bukan seorang sahaja yang bekerja pada projek atau pangkalan kod yang sama. Ini bermakna orang lain mesti memahami kod anda. Ini juga benar untuk ulasan kod. Pembangun sering menulis komen "cepat dan kotor" tanpa banyak konteks, menyebabkan rakan sekerja mereka keliru tentang perkara yang cuba dikatakan oleh pengarang. Ini adalah amalan buruk dan menimbulkan lebih banyak kekeliruan daripada kejelasan. Coffee break #79.  10 kesilapan pembangun Java yang menghalang mereka daripada mencapai kejayaan.  Panduan Pembangun untuk Menulis Komen Kod Bermakna - 2Mempunyai komen kod yang jelas membantu pembangun lain. Komen kod yang menerangkan fungsi, rasionalnya, input dan outputnya mempercepatkan proses pembelajaran untuk pembangun lain. Sebaliknya, komen kod membawa kita kepada soalan: adakah patut menulisnya? Sekumpulan besar pembangun menentang menulis komen kod. Sebabnya ialah kod itu, pada pendapat mereka, adalah jelas. Jika pembangun lain tidak dapat memahami tujuan kod anda dengan melihatnya, maka ia adalah kod yang tidak baik. Mungkin ini benar. Tetapi fikirkan tentang usaha kecil yang diperlukan untuk mengulas kod dan potensi faedah yang dibawanya. Komen kod adalah penting untuk mempercepatkan proses onboarding untuk mana-mana pembangun, terutamanya junior. Mari kita lihat pelbagai jenis komen kod.

1. Ulasan tentang dokumentasi.

Tujuan utama komen sedemikian adalah untuk menjelaskan tujuan fail atau komponen dengan cepat. Daripada membaca keseluruhan kod komponen untuk memahami fungsinya, anda boleh menambah ulasan kod di bahagian atas fail `indeks`. Ini akan membantu menjelaskan perkara yang dilakukan oleh komponen ini. Saya bukan peminat tegar komen jenis ini kerana ia mengacaukan kod sedikit. Saya rasa jenis komen seni bina ini harus ada dalam dokumentasi dalaman anda di mana anda boleh menyelenggara dan membincangkan seni bina projek anda secara berpusat. Walau bagaimanapun, projek sumber terbuka sangat memerlukannya.

2. Ulasan tentang fungsi.

Ini adalah jenis ulasan yang paling berguna. Mereka menerangkan tujuan fungsi, parameternya, dan outputnya.
/**
 * @desc Creates a welcome message
 */
function sayHello(name) {
    return `Hello ${name}`;
}

3. Komen yang logik.

Ini adalah ulasan dalam fungsi untuk menjelaskan laluan kod yang kompleks. Seperti yang anda duga, kehadiran komen sedemikian menunjukkan bahawa kod anda terlalu kompleks. Di samping itu, komen logik selalunya mengandungi terlalu banyak maklumat terperinci. Tahap perincian akan mewujudkan lebih banyak huru-hara dan mengurangkan kebolehbacaan kod anda. Berikut ialah contoh ulasan kod yang terlalu terperinci.
let date = new Date(); // store today's date to calculate the elapsed time

Kod Mengulas: 4 Amalan Terbaik untuk Mengulas

1. Gunakan anotasi kod atau teg

Banyak bahasa pengaturcaraan mentakrifkan piawaian untuk mengulas kod. Java menggunakan Javadoc , manakala JavaScript menggunakan sistem ulasan kod JSDoc , yang disokong oleh banyak alat dokumentasi. Untuk fungsi anda mesti memasukkan tag kod berikut:
  • @desc - perihalan fungsi anda
  • @param - semua parameter input yang diterima oleh fungsi. Pastikan anda menentukan jenis input.
  • @returns - output yang dikembalikan. Pastikan untuk menentukan jenis output.
  • @throws ialah jenis ralat yang boleh dilemparkan oleh fungsi.
  • @example - satu atau lebih contoh yang menunjukkan input dan output yang dijangkakan.
Berikut ialah contoh kod Lodash untuk fungsi chunk .
/**
 * Creates an array of elements split into groups the length of `size`.
 * If `array` can't be split evenly, the final chunk will be the remaining
 * elements.
 *
 * @since 3.0.0
 * @category Array
 * @param {Array} array The array to process.
 * @param {number} [size=1] The length of each chunk
 * @returns {Array} Returns the new array of chunks.
 * @example
 *
 * chunk(['a', 'b', 'c', 'd'], 2)
 * // => [['a', 'b'], ['c', 'd']]
 *
 * chunk(['a', 'b', 'c', 'd'], 3)
 * // => [['a', 'b', 'c'], ['d']]
 */
function chunk(array, size = 1) {
  // logic
}

2. Terangkan sebab tindakan anda

Ramai pembangun menggunakan ulasan untuk menerangkan perkara yang dilakukan oleh kod mereka. Apabila berbuat demikian, pastikan anda memasukkan sebab anda mencipta ciri atau komponen tertentu. Maklumat ini dipanggil konteks. Konteks adalah penting untuk memberi pembangun lebih banyak maklumat tentang keputusan reka bentuk di sebalik ciri atau komponen. Konteks adalah kritikal apabila pembangun lain ingin membuat perubahan pada ciri atau komponen anda. Di bawah anda boleh melihat contoh buruk kod mengulas tanpa konteks.
/**
 * Sets the label property of a new form.
 *
 * @param label text for label of form
 */
function setFormLabel(label) {
    // logic
}

3. Jangan paut ke dokumen atau ulasan lain

Ia tidak disyorkan untuk memautkan kepada ulasan kod lain atau dokumen dalaman yang menerangkan ciri atau komponen.
/**
 * Sets the label property of a new form.
 *
 * @see {@link https://myinternaldocument.com}
 */
function setFormLabel(label) {
    // logic
}

4. Tulis komen semasa mengekod

Ini mungkin kelihatan jelas, tetapi banyak pembangun (termasuk saya sendiri) mengabaikan peraturan ini. Meninggalkan ulasan untuk kemudian adalah tidak baik kerana anda mungkin terlupa beberapa logik yang anda tulis, yang akan membawa kepada ulasan kod kualiti yang lebih rendah. Ini benar terutamanya jika anda telah mengerjakan permintaan tarik yang sama selama beberapa hari. Adalah lebih baik untuk menulis ulasan apabila anda baru sahaja menyelesaikan ciri atau modul. Ingat untuk memastikan ulasan kod sesingkat mungkin. Anda tidak perlu menghabiskan lebih banyak masa menulis komen daripada menulis kod itu sendiri.
Komen
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION