Nghỉ giải lao #79. 10 sai lầm mà các nhà phát triển Java mắc phải khiến họ không đạt được thành công Hướng dẫn dành cho nhà phát triển để viết nhận xét mã có ý nghĩa

10 sai lầm mà các nhà phát triển Java mắc phải khiến họ không thành công

Nguồn: Dev.to Dựa trên kinh nghiệm của mình, tôi đã tổng hợp danh sách 10 sai lầm mà các nhà phát triển mắc phải khiến họ không đạt được thành công:

1. Đừng viết bài kiểm tra đơn vị

Các nhà phát triển không viết bài kiểm tra đơn vị sẽ mắc nhiều lỗi hơn trong mã của họ. Điều này dẫn đến sự không ổn định của sản phẩm và sự không hài lòng của khách hàng.

2. Họ không kiểm tra mã theo cách thủ công

Ngay cả khi bạn hoàn toàn kiểm tra mã của mình bằng các bài kiểm tra đơn vị, vẫn có khả năng bạn đã bỏ sót điều gì đó. Bạn nên kiểm tra mã của mình theo cách thủ công trước khi gửi mã để xem xét. Bằng cách này bạn có thể phát hiện lỗi ở giai đoạn phát triển.

3. Họ nghĩ: “Điều này sẽ không bao giờ xảy ra”

Các nhà phát triển thường mắc lỗi khi viết mã mới vì nghĩ rằng một số tình huống nhất định sẽ không bao giờ xảy ra. Cuối cùng thì hóa ra họ đã sai. Xử lý tất cả các tình huống mà mã có thể được thực thi. Phương pháp lập trình phòng thủ sẽ giúp bạn điều này.

4. Đừng nhận phản hồi

Thường xuyên thu hút phản hồi từ các nhà phát triển và người dùng khác. Chia sẻ ý kiến ​​​​của bạn với đồng nghiệp của bạn.

5. Họ không kiểm tra chức năng của mã

Thông thường các nhà phát triển viết mã của họ nhưng không kiểm tra chức năng của nó. Kết quả là, khi mã được đưa vào sản xuất, nó sẽ tạo ra nhiều vấn đề khác nhau.

6. Viết mã thủ tục dài

Rất dễ dàng để viết các phương thức dài với nhiều logic. Bằng cách này, các lập trình viên triển khai logic tương tự ở nhiều nơi. Các dự án có số lượng phương thức nhỏ đáng kể sẽ có khả năng tái sử dụng mã tốt hơn và dễ bảo trì hơn nhiều.

7. Họ không biết các công cụ

Công cụ là một phần mở rộng của bàn tay của bạn. Bạn càng biết rõ về chúng thì bạn sẽ càng làm việc hiệu quả hơn. Bạn phải rất quen thuộc với IDE bạn đang sử dụng. Tìm hiểu các lệnh nhanh, luôn có những lệnh sẽ giúp bạn làm việc hiệu quả hơn nữa. Trong IntelliJ IDEA, đây là Sonar Lint, Spot bug và Code Metrics.

8. Bỏ qua các vấn đề trong code

Các nhà phát triển làm việc trên những sản phẩm thành công nhất liên tục thay đổi mã. Đừng ngại cấu trúc lại mã của bạn. Nếu mã của bạn đã được kiểm tra đơn vị thì có rất ít cơ hội hồi quy. Các nhà phát triển thường bỏ qua mã có vấn đề. Là nhà phát triển, bạn có trách nhiệm duy trì ứng dụng ở tình trạng tốt. Vì lý do này, hãy khắc phục mọi sự cố bạn tìm thấy.

9. Họ viết mã mà không nhận ra hậu quả.

Các nhà phát triển KHÔNG BAO GIỜ nên thực hiện các thay đổi đối với mã và đưa nó vào sản xuất mà không hiểu hậu quả. Mã có thể tạo ra kết quả chính xác cho các giá trị thử nghiệm nhất định. Tuy nhiên, có thể có những tình huống trong đó điều này có thể dẫn đến những kết quả không thể đoán trước và tạo ra những vấn đề nghiêm trọng. Mã hóa “không thể đoán trước” thường xảy ra khi các nhà phát triển sử dụng các chức năng từ thư viện mà họ không hiểu hết. Điều này cũng có thể xảy ra khi nhà phát triển khắc phục sự cố mà không hiểu giải pháp.

10. Đừng nhờ giúp đỡ

Các nhà phát triển không phải là những người rất hòa đồng. Họ thích tự mình giải quyết vấn đề. Nhưng thời đại mà một nhà phát triển tự mình tạo ra một sản phẩm từ đầu đến cuối đã qua. Phát triển phần mềm là một hoạt động nhóm. Khi bạn gặp vấn đề trong khi lập trình, hãy cố gắng tự mình giải quyết. Nhưng đừng lãng phí quá nhiều thời gian nếu bạn không thể tìm ra giải pháp. Khả năng cao là một số đồng nghiệp của bạn đã gặp phải vấn đề tương tự và biết giải pháp. Điều này sẽ tiết kiệm thời gian và tăng năng suất.

Hướng dẫn dành cho nhà phát triển để viết nhận xét mã có ý nghĩa

Nguồn: Stepsize Trong hầu hết các trường hợp, bạn không phải là người duy nhất làm việc trên cùng một dự án hoặc cơ sở mã. Điều này có nghĩa là người khác phải hiểu mã của bạn. Điều này cũng đúng đối với nhận xét về mã. Các nhà phát triển thường viết những bình luận “nhanh chóng và bẩn thỉu” mà không có nhiều ngữ cảnh, khiến đồng nghiệp của họ bối rối về những gì tác giả đang muốn nói. Đây là cách làm không tốt và tạo ra nhiều nhầm lẫn hơn là sự rõ ràng. Có nhận xét mã rõ ràng sẽ giúp ích cho các nhà phát triển khác. Một nhận xét mã mô tả một chức năng, cơ sở lý luận, đầu vào và đầu ra của nó sẽ tăng tốc quá trình học tập cho các nhà phát triển khác. Mặt khác, các nhận xét về mã dẫn chúng ta đến câu hỏi: có đáng để viết chúng không? Một nhóm đáng kể các nhà phát triển phản đối việc viết bình luận mã. Lý do là theo quan điểm của họ, mã này có tính tự giải thích. Nếu một nhà phát triển khác không thể hiểu được mục đích mã của bạn khi nhìn vào nó thì đó là mã xấu. Có lẽ điều này là đúng. Nhưng hãy nghĩ đến nỗ lực nhỏ cần có để nhận xét mã và những lợi ích tiềm tàng mà nó mang lại. Nhận xét mã rất quan trọng để tăng tốc quá trình giới thiệu cho bất kỳ nhà phát triển nào, đặc biệt là cấp dưới. Chúng ta hãy xem xét các loại bình luận mã khác nhau.

1. Nhận xét về tài liệu.

Mục đích chính của những nhận xét như vậy là để nhanh chóng làm rõ mục đích của một tệp hoặc thành phần. Thay vì đọc toàn bộ mã của một thành phần để hiểu chức năng của nó, bạn có thể thêm nhận xét mã ở đầu tệp `index`. Điều này sẽ giúp giải thích thành phần này làm gì. Tôi không phải là người thích kiểu bình luận này vì nó làm lộn xộn mã một chút. Tôi nghĩ những loại nhận xét về kiến ​​trúc này nên có trong tài liệu nội bộ của bạn, nơi bạn có thể duy trì và thảo luận một cách tập trung về kiến ​​trúc của dự án của mình. Tuy nhiên, các dự án nguồn mở thực sự cần chúng.

2. Nhận xét về chức năng.

Đây là loại bình luận hữu ích nhất. Chúng mô tả mục đích của hàm, các tham số và đầu ra của hàm.

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

3. Nhận xét logic.

Đây là những nhận xét trong các hàm nhằm làm rõ các đường dẫn mã phức tạp. Như bạn có thể đoán, sự hiện diện của những nhận xét như vậy cho thấy mã của bạn quá phức tạp. Ngoài ra, những bình luận logic thường chứa quá nhiều thông tin chi tiết. Mức độ chi tiết sẽ tạo ra nhiều sự hỗn loạn hơn và làm giảm khả năng đọc mã của bạn. Đây là một ví dụ về nhận xét mã quá chi tiết.

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

Nhận xét mã: 4 phương pháp hay nhất để nhận xét

1. Sử dụng chú thích hoặc thẻ mã

Nhiều ngôn ngữ lập trình xác định tiêu chuẩn cho mã bình luận. Java sử dụng Javadoc , trong khi JavaScript sử dụng hệ thống nhận xét mã JSDoc , được hỗ trợ bởi nhiều công cụ tài liệu. Đối với các chức năng, bạn phải bao gồm các thẻ mã sau:

• @desc - mô tả chức năng của bạn
• @param - tất cả tham số đầu vào mà hàm chấp nhận. Đảm bảo chỉ định loại đầu vào.
• @returns - kết quả trả về. Hãy chắc chắn để chỉ định loại đầu ra.
• @throws là loại lỗi mà hàm có thể đưa ra.
• @example - một hoặc nhiều ví dụ hiển thị đầu vào và đầu ra dự kiến.

Đây là một ví dụ về mã Lodash cho hàm 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. Giải thích lý do hành động của bạn

Nhiều nhà phát triển sử dụng nhận xét để mô tả chức năng của mã của họ. Khi làm như vậy, hãy nhớ nêu lý do tại sao bạn tạo một tính năng hoặc thành phần cụ thể. Thông tin này được gọi là bối cảnh. Bối cảnh rất quan trọng để cung cấp cho nhà phát triển thêm thông tin về các quyết định thiết kế đằng sau một tính năng hoặc thành phần. Bối cảnh rất quan trọng khi các nhà phát triển khác muốn thực hiện thay đổi đối với tính năng hoặc thành phần của bạn. Dưới đây bạn có thể thấy một ví dụ tồi về mã nhận xét không có ngữ cảnh.

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

3. Không liên kết tới tài liệu hoặc bình luận khác

Không nên liên kết tới các nhận xét mã khác hoặc tài liệu nội bộ giải thích một tính năng hoặc thành phần.

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

4. Viết bình luận trong khi viết mã

Điều này có vẻ hiển nhiên nhưng nhiều nhà phát triển (bao gồm cả tôi) lại bỏ qua quy tắc này. Để lại nhận xét sau này là không tốt vì bạn có thể quên một số logic bạn đã viết, điều này sẽ dẫn đến chất lượng nhận xét mã thấp hơn. Điều này đặc biệt đúng nếu bạn đã làm việc với cùng một yêu cầu kéo trong nhiều ngày. Sẽ tốt hơn nếu bạn viết bình luận khi bạn vừa hoàn thành một tính năng hoặc mô-đun. Hãy nhớ giữ các nhận xét về mã càng ngắn gọn càng tốt. Bạn không cần phải dành nhiều thời gian để viết bình luận hơn là viết mã.