คอฟฟี่เบรค #79. ข้อผิดพลาด 10 ประการที่นักพัฒนา Java ทำซึ่งขัดขวางไม่ให้พวกเขาประสบความสำเร็จ คู่มือนักพัฒนาในการเขียนความคิดเห็นเกี่ยวกับโค้ดที่มีความหมาย

10 ข้อผิดพลาดที่นักพัฒนา Java ทำซึ่งขัดขวางความสำเร็จของพวกเขา

ที่มา: Dev.to จากประสบการณ์ของฉัน ฉันได้รวบรวมรายการข้อผิดพลาด 10 ข้อที่นักพัฒนาทำซึ่งทำให้ไม่ประสบความสำเร็จ:

1. อย่าเขียน Unit Test

Developer ที่ไม่ได้เขียน Unit Test มักจะทำโค้ดผิดพลาดมากขึ้น สิ่งนี้นำไปสู่ความไม่แน่นอนของผลิตภัณฑ์และความไม่พอใจของลูกค้า

2. พวกเขาไม่ได้ตรวจสอบรหัสด้วยตนเอง

แม้ว่าคุณจะครอบคลุมโค้ดของคุณด้วย Unit Tests แต่ก็ยังมีโอกาสที่คุณจะพลาดบางสิ่งบางอย่าง ขอแนะนำให้ทดสอบโค้ดของคุณด้วยตนเองก่อนส่งเข้ารับการตรวจสอบเสมอ วิธีนี้ทำให้คุณสามารถตรวจจับข้อผิดพลาดได้ในขั้นตอนการพัฒนา

3. พวกเขาคิดว่า “สิ่งนี้จะไม่เกิดขึ้น”

นักพัฒนามักจะทำผิดพลาดเมื่อเขียนโค้ดใหม่ โดยคิดว่าสถานการณ์บางอย่างจะไม่เกิดขึ้น ท้ายที่สุดปรากฎว่าพวกเขาคิดผิด จัดการทุกสถานการณ์ที่อาจเรียกใช้โค้ด วิธีการเขียนโปรแกรมเชิงป้องกันจะช่วยคุณในเรื่องนี้

4. อย่ารับคำติชม

ขอคำติชมจากนักพัฒนาและผู้ใช้รายอื่นเป็นประจำ แบ่งปันความคิดเห็นของคุณกับเพื่อนร่วมงานของคุณ

5. พวกเขาไม่ได้ตรวจสอบการทำงานของโค้ด

บ่อยครั้งที่นักพัฒนาเขียนโค้ดของตน แต่ไม่ได้ตรวจสอบฟังก์ชันการทำงานของโค้ด ผลก็คือเมื่อโค้ดถึงการใช้งานจริงก็เกิดปัญหาต่างๆ ตามมา

6.เขียนโค้ดขั้นตอนที่ยาว

มันง่ายมากที่จะเขียนวิธีการยาว ๆ พร้อมตรรกะมากมาย ด้วยการทำเช่นนี้ โปรแกรมเมอร์จะใช้ตรรกะเดียวกันในหลาย ๆ ที่ โปรเจ็กต์ที่มีวิธีการขนาดเล็กจำนวนมากจะมีการใช้โค้ดซ้ำได้ดีกว่ามากและดูแลรักษาได้ง่ายกว่ามาก

7. พวกเขาไม่รู้เครื่องมือ

เครื่องมือเป็นส่วนเสริมของมือคุณ ยิ่งคุณรู้จักพวกเขาดีเท่าไร คุณก็จะยิ่งมีประสิทธิผลมากขึ้นเท่านั้น คุณควรจะคุ้นเคยกับ IDE ที่คุณใช้เป็นอย่างดี เรียนรู้คำสั่งด่วน มีคำสั่งที่จะช่วยให้คุณทำงานได้อย่างมีประสิทธิภาพมากขึ้นอยู่เสมอ ใน IntelliJ IDEA สิ่งเหล่านี้คือ Sonar Lint, Spot bugs และ Code Metrics

8. ละเว้นปัญหาในโค้ด

นักพัฒนาที่ทำงานเกี่ยวกับผลิตภัณฑ์ที่ประสบความสำเร็จสูงสุดจะเปลี่ยนรหัสอยู่ตลอดเวลา อย่ากลัวที่จะปรับโครงสร้างโค้ดของคุณใหม่ หากโค้ดของคุณเป็นการทดสอบหน่วย ก็มีโอกาสน้อยมากที่จะเกิดการถดถอย นักพัฒนามักเพิกเฉยต่อโค้ดที่มีปัญหา ในฐานะนักพัฒนา คุณมีหน้าที่รับผิดชอบในการดูแลรักษาแอปพลิเคชันให้อยู่ในสภาพดี ด้วยเหตุนี้ ให้แก้ไขปัญหาใดๆ ที่คุณพบ

9. พวกเขาเขียนโค้ดโดยไม่ได้ตระหนักถึงผลที่ตามมา

นักพัฒนาไม่ควรทำการเปลี่ยนแปลงโค้ดและเผยแพร่สู่การใช้งานจริงโดยไม่เข้าใจถึงผลที่ตามมา รหัสอาจให้ผลลัพธ์ที่ถูกต้องสำหรับค่าทดสอบที่กำหนด อย่างไรก็ตาม อาจมีสถานการณ์ที่อาจนำไปสู่ผลลัพธ์ที่คาดเดาไม่ได้และสร้างปัญหาร้ายแรง การเขียนโค้ดแบบ "คาดเดาไม่ได้" มักเกิดขึ้นเมื่อนักพัฒนาใช้ฟังก์ชันจากไลบรารีที่พวกเขาไม่เข้าใจอย่างถ่องแท้ สิ่งนี้สามารถเกิดขึ้นได้เมื่อนักพัฒนาแก้ไขปัญหาโดยไม่เข้าใจวิธีแก้ไข

10.อย่าขอความช่วยเหลือ

นักพัฒนาไม่ใช่คนเข้าสังคมมากนัก พวกเขาชอบแก้ไขปัญหาด้วยตัวเอง แต่ยุคที่นักพัฒนาคนหนึ่งสร้างผลิตภัณฑ์ตั้งแต่ต้นจนจบได้สิ้นสุดลงแล้ว การพัฒนาซอฟต์แวร์เป็นกิจกรรมของทีม เมื่อคุณประสบปัญหาขณะเขียนโปรแกรมให้ลองแก้ไขด้วยตัวเอง แต่อย่าเสียเวลามากเกินไปหากคุณไม่สามารถหาวิธีแก้ปัญหาได้ มีโอกาสสูงที่เพื่อนร่วมงานของคุณบางคนจะประสบปัญหาเดียวกันและรู้วิธีแก้ปัญหา สิ่งนี้จะช่วยประหยัดเวลาและเพิ่มผลผลิต

คู่มือนักพัฒนาในการเขียนความคิดเห็นเกี่ยวกับโค้ดที่มีความหมาย

ที่มา: Stepsize ในกรณีส่วนใหญ่ คุณไม่ใช่คนเดียวที่ทำงานในโครงการหรือโค้ดเบสเดียวกัน ซึ่งหมายความว่าคนอื่นจะต้องเข้าใจโค้ดของคุณ สิ่งนี้ก็เป็นจริงสำหรับความคิดเห็นเกี่ยวกับโค้ดด้วย นักพัฒนามักจะเขียนความคิดเห็นที่ "รวดเร็วและสกปรก" โดยไม่มีบริบทมากนัก ทำให้เพื่อนร่วมงานสับสนเกี่ยวกับสิ่งที่ผู้เขียนพยายามจะพูด นี่เป็นการปฏิบัติที่ไม่ดีและสร้างความสับสนมากกว่าความชัดเจน การมีความคิดเห็นเกี่ยวกับโค้ดที่ชัดเจนช่วยนักพัฒนาคนอื่นๆ ความคิดเห็นเกี่ยวกับโค้ดที่อธิบายฟังก์ชัน เหตุผล อินพุต และเอาต์พุตจะช่วยเร่งกระบวนการเรียนรู้สำหรับนักพัฒนารายอื่น ในทางกลับกัน ความคิดเห็นเกี่ยวกับโค้ดทำให้เรามีคำถาม: มันคุ้มค่าที่จะเขียนมันหรือไม่? นักพัฒนากลุ่มสำคัญคัดค้านการเขียนความคิดเห็นเกี่ยวกับโค้ด เหตุผลก็คือว่าโค้ดในความเห็นของพวกเขานั้นอธิบายได้ในตัว หากนักพัฒนารายอื่นไม่สามารถเข้าใจวัตถุประสงค์ของโค้ดของคุณจากการดูได้ แสดงว่าเป็นโค้ดที่ไม่ถูกต้อง บางทีนี่อาจเป็นเรื่องจริง แต่ลองนึกถึงความพยายามเล็กๆ น้อยๆ ที่จำเป็นในการแสดงความคิดเห็นเกี่ยวกับโค้ดและประโยชน์ที่อาจเกิดขึ้นจากโค้ดนั้น ความคิดเห็นเกี่ยวกับโค้ดมีความสำคัญในการเร่งกระบวนการเริ่มต้นใช้งานสำหรับนักพัฒนา โดยเฉพาะรุ่นน้อง มาดูความคิดเห็นของโค้ดประเภทต่างๆ กัน

1. ความเห็นเกี่ยวกับเอกสารประกอบ

วัตถุประสงค์หลักของความคิดเห็นดังกล่าวคือการชี้แจงวัตถุประสงค์ของไฟล์หรือส่วนประกอบอย่างรวดเร็ว แทนที่จะอ่านโค้ดทั้งหมดของส่วนประกอบเพื่อทำความเข้าใจว่ามันทำอะไร คุณสามารถเพิ่มความคิดเห็นเกี่ยวกับโค้ดที่ด้านบนของไฟล์ `index` ได้ ซึ่งจะช่วยอธิบายว่าองค์ประกอบนี้ทำอะไรได้บ้าง ฉันไม่ใช่แฟนตัวยงของความคิดเห็นประเภทนี้เพราะมันทำให้โค้ดยุ่งเหยิงเล็กน้อย ฉันคิดว่าความคิดเห็นเกี่ยวกับสถาปัตยกรรมประเภทนี้ควรอยู่ในเอกสารภายในของคุณ ซึ่งคุณสามารถรักษาและหารือเกี่ยวกับสถาปัตยกรรมของโครงการของคุณจากส่วนกลางได้ อย่างไรก็ตาม โครงการโอเพ่นซอร์สต้องการสิ่งเหล่านี้จริงๆ

2. ความเห็นเกี่ยวกับฟังก์ชั่น

นี่เป็นความคิดเห็นประเภทที่มีประโยชน์ที่สุด โดยจะอธิบายวัตถุประสงค์ของฟังก์ชัน พารามิเตอร์ และเอาต์พุต

/**
 * @desc Creates a welcome message
 */
function sayHello(name) {
    return `Hello ${name}`;
}

3. ความคิดเห็นเชิงตรรกะ

เหล่านี้เป็นความคิดเห็นภายในฟังก์ชันเพื่อชี้แจงเส้นทางโค้ดที่ซับซ้อน ดังที่คุณอาจเดาได้ การแสดงความคิดเห็นดังกล่าวบ่งชี้ว่าโค้ดของคุณซับซ้อนเกินไป นอกจากนี้ ความคิดเห็นเชิงตรรกะมักจะมีข้อมูลที่มีรายละเอียดมากเกินไป ระดับรายละเอียดจะสร้างความโกลาหลมากขึ้นและลดความสามารถในการอ่านโค้ดของคุณ นี่คือตัวอย่างความคิดเห็นเกี่ยวกับโค้ดที่มีรายละเอียดมากเกินไป

let date = new Date(); // store today's date to calculate the elapsed time

การแสดงความคิดเห็นโค้ด: 4 แนวทางปฏิบัติที่ดีที่สุดสำหรับการแสดงความคิดเห็น

1. ใช้คำอธิบายประกอบโค้ดหรือแท็ก

ภาษาโปรแกรมหลายภาษากำหนดมาตรฐานสำหรับการแสดงความคิดเห็นโค้ด Java ใช้Javadocในขณะที่ JavaScript ใช้ ระบบแสดงความคิดเห็นโค้ด JSDocซึ่งได้รับการสนับสนุนโดยเครื่องมือเอกสารจำนวนมาก สำหรับฟังก์ชัน คุณต้องรวมแท็กโค้ดต่อไปนี้:

• @desc - คำอธิบายฟังก์ชันของคุณ
• @param - พารามิเตอร์อินพุตทั้งหมดที่ฟังก์ชันยอมรับ อย่าลืมระบุประเภทอินพุต
• @returns - เอาต์พุตที่ส่งคืน อย่าลืมระบุประเภทเอาต์พุต
• @throws เป็นประเภทของข้อผิดพลาดที่ฟังก์ชันสามารถโยนได้
• @example - หนึ่งตัวอย่างขึ้นไปที่แสดงอินพุตและเอาต์พุตที่คาดหวัง

นี่ คือตัวอย่างโค้ด Lodashสำหรับ ฟังก์ชัน 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. อธิบายเหตุผลในการกระทำของคุณ

นักพัฒนาหลายคนใช้ความคิดเห็นเพื่ออธิบายว่าโค้ดของตนทำอะไร เมื่อทำเช่นนั้น อย่าลืมระบุสาเหตุที่คุณสร้างคุณลักษณะหรือส่วนประกอบเฉพาะด้วย ข้อมูลนี้เรียกว่าบริบท บริบทเป็นสิ่งสำคัญในการให้ข้อมูลเพิ่มเติมแก่นักพัฒนาเกี่ยวกับการตัดสินใจออกแบบเบื้องหลังฟีเจอร์หรือส่วนประกอบ บริบทมีความสำคัญเมื่อนักพัฒนารายอื่นต้องการเปลี่ยนแปลงคุณสมบัติหรือส่วนประกอบของคุณ ด้านล่างนี้ คุณจะเห็นตัวอย่างที่ไม่ดีของการแสดงความคิดเห็นโค้ดโดยไม่มีบริบท

/**
 * Sets the label property of a new form.
 *
 * @param label text for label of form
 */
function setFormLabel(label) {
    // logic
}

3. อย่าลิงก์ไปยังเอกสารหรือความคิดเห็นอื่น

ไม่แนะนำให้ลิงก์ไปยังความคิดเห็นของโค้ดหรือเอกสารภายในอื่นๆ ที่อธิบายคุณลักษณะหรือส่วนประกอบ

/**
 * Sets the label property of a new form.
 *
 * @see {@link https://myinternaldocument.com}
 */
function setFormLabel(label) {
    // logic
}

4. เขียนความคิดเห็นขณะเขียนโค้ด

สิ่งนี้อาจดูเหมือนชัดเจน แต่นักพัฒนาหลายคน (รวมถึงตัวฉันเองด้วย) ละเลยกฎนี้ การแสดงความคิดเห็นไว้ทีหลังเป็นสิ่งที่ไม่ดี เพราะคุณอาจลืมตรรกะบางอย่างที่คุณเขียน ซึ่งจะทำให้ความคิดเห็นในโค้ดมีคุณภาพต่ำลง โดยเฉพาะอย่างยิ่งหากคุณทำงานกับคำขอดึงข้อมูลเดียวกันมาหลายวันแล้ว จะดีกว่าถ้าเขียนความคิดเห็นเมื่อคุณเพิ่งเสร็จสิ้นคุณลักษณะหรือโมดูล อย่าลืมให้ความคิดเห็นเกี่ยวกับโค้ดสั้นที่สุดเท่าที่จะทำได้ คุณไม่จำเป็นต้องใช้เวลาเขียนความคิดเห็นมากไปกว่าการเขียนโค้ดเอง