Có nhiều bình luận tốt hơn trong môi trường doanh thu cao?

Tôi đã nói chuyện với một đồng nghiệp ngày hôm nay. Chúng tôi làm việc trên mã cho hai dự án khác nhau. Trong trường hợp của tôi, tôi là người duy nhất làm việc với mã của tôi; trong trường hợp của cô, nhiều người làm việc trên cùng một codebase, bao gồm cả những sinh viên hợp tác đến và đi khá đều đặn (trong khoảng 8-12 tháng). Cô ấy nói rằng cô ấy tự do với những bình luận của mình, đặt chúng ở khắp mọi nơi. Lý do của cô là nó giúp cô nhớ mọi thứ ở đâu và mọi thứ làm gì vì phần lớn mã không phải do cô viết và có thể được thay đổi bởi một người khác không phải cô. Trong khi đó, tôi cố gắng giảm thiểu các bình luận trong mã của mình, chỉ đưa chúng vào những nơi có cách khắc phục hoặc lỗi không rõ ràng. Tuy nhiên, tôi hiểu rõ hơn về mã của mình một cách tổng thể và có nhiều quyền kiểm soát trực tiếp hơn.

Ý kiến ​​của tôi trong đó các bình luận nên tối thiểu và mã sẽ nói lên hầu hết câu chuyện, nhưng lý luận của cô ấy cũng có ý nghĩa. Có bất kỳ sai sót trong lý luận của cô? Nó có thể làm lộn xộn mã nhưng cuối cùng có thể khá hữu ích nếu có nhiều người làm việc với nó trong ngắn hạn đến trung hạn.

Bình luận không làm lộn xộn mã.

Và khi họ làm, tốt, mỗi một nửa IDE tốt có thể ẩn / gấp các bình luận. Lý tưởng nhất là câu chuyện nên được kể bằng mã của bạn, tài liệu yêu cầu của bạn, lịch sử cam kết và các bài kiểm tra đơn vị của bạn chứ không phải bằng nhận xét. Tuy nhiên, bình luận quá mức chỉ có thể gây tổn thương khi các bình luận tập trung vào cách thức chứ không phải lý do tại sao, tuy nhiên đó là một cuộc thảo luận khác .

Tôi nghĩ rằng cả bạn và đồng nghiệp của bạn đều "đúng", tất nhiên, sự khác biệt là bạn làm việc một mình và cô ấy trong một nhóm, thường bao gồm các nhà phát triển thiếu kinh nghiệm. Bạn không có quá nhiều triết lý khác nhau về nhận xét, nhưng yêu cầu rất lớn về việc truyền đạt mã của bạn. Đối số "nó giúp tôi nhớ" cũng có thể xuất phát từ thực tế là cô ấy giao dịch với nhiều mã hơn bạn và quan trọng hơn là mã được sản xuất bởi những người khác nhau, mỗi người có sở thích và yêu cầu riêng.

Vào cuối ngày, các bình luận mã, mặc dù sai sót rõ ràng của chúng, là cách đơn giản nhất và nhanh nhất để truyền đạt mã của bạn. Tùy thuộc vào thành phần và tổ chức nhóm, nó thậm chí có thể là cách duy nhất áp dụng cho mẫu số chung thấp nhất. Tôi thường thấy mình tuân theo triết lý bình luận của bạn khi làm việc một mình và thích nghi với đồng nghiệp khi làm việc trong nhóm, đặc biệt nếu đó là một kỹ năng nhóm không cân bằng khôn ngoan.

Những bình luận sôi nổi trong loại môi trường đó đang che đậy cho một vấn đề cần được giải quyết theo cách khác.

Chất lượng, mã có thể đọc được không bao giờ cần thêm ý kiến ​​để giải thích những gì nó làm. Thời gian duy nhất để bình luận là khi bạn muốn giải thích tại sao một cái gì đó được thực hiện theo một cách cụ thể. Và thậm chí sau đó, những bình luận đó có thể được cho là trong các thông điệp cam kết kiểm soát nguồn.

Vì vậy, vấn đề cô ấy giải quyết là cô ấy phải làm việc với những sinh viên không biết cách viết mã theo cách dễ đọc. Theo tôi, làm lộn xộn mã với các bình luận là một giải pháp yếu cho vấn đề đó.

Đánh giá mã nghiêm ngặt sẽ hiệu quả hơn nhiều, cả trong việc giữ mã gọn gàng và cải thiện những sinh viên đó cho tương lai, cho dù đó là trong cùng một công ty hay ở nơi khác.

Vấn đề với các bình luận là họ có xu hướng phát triển không đồng bộ với mã thực sự nhanh chóng. Điều này có nghĩa là thường có những nhận xét sai lệch hoặc thẳng thừng trong mã, vì vậy chúng làm tổn thương khả năng đọc nhiều hơn là chúng giúp.

Mục tiêu là làm cho một cơ sở mã dễ hiểu và sửa đổi. Bạn có thể làm điều này mặc dù sử dụng bình luận một cách tự do (mặc dù bạn có thể gặp phải vấn đề về nhận xét dữ liệu) hoặc bạn có thể viết mã tự viết tài liệu (càng nhiều càng tốt) và chỉ sử dụng nhận xét để giải thích "tại sao không tầm thường" "Câu hỏi. Cách tiếp cận có thể hoạt động, nhưng hãy lưu ý rằng để sửa đổi mã, bạn sẽ phải hiểu chính mã đó, và không chỉ các nhận xét. Vì vậy, trong khi các bình luận có thể giúp bạn hiểu mã, vào cuối ngày, bạn vẫn có thể sẽ phải tự hiểu mã. Như đã nói, tôi thích cách tiếp cận mã tự ghi. Nó dường như là một cách trực tiếp hơn để tạo ra một cơ sở mã sạch.

"Có nhiều bình luận tốt hơn trong môi trường doanh thu cao?"

Tôi nghĩ rằng họ có thể tồi tệ hơn:

• Các tác giả khác nhau sẽ sử dụng các phong cách và mức độ chi tiết khác nhau và sẽ ít cập nhật nhận xét của người khác.

• Ý kiến ​​của "Những gì cần bình luận" thay đổi từ người này sang người khác.

• Họ tiếp tục thực hành viết mã khó đọc với các bình luận để giải thích nó trái ngược với mã dễ đọc với tên mô tả.

• Duy trì định dạng và tính nhất quán của họ trở thành một công việc trong chính nó.

• Người dùng mới phải tìm hiểu tiêu chuẩn 'định dạng' trước khi có thể thực hiện các thay đổi nhanh chóng.

Điểm 1: Sự rõ ràng rất quan trọng trong môi trường doanh thu cao

Điểm 2: Độ dài không rõ ràng

Thêm ý kiến ​​vào mã của bạn có thể hoặc không thể cải thiện sự rõ ràng; nó phụ thuộc vào ý kiến ​​bạn thêm vào. Và một khi đạt được sự rõ ràng tối ưu, các bình luận bổ sung sẽ làm cho tình hình tồi tệ hơn, không tốt hơn.

Trong khi các bình luận là một thành phần của sự rõ ràng, chất lượng mã là một thành phần quan trọng hơn đáng kể. Khéo léo là trái ngược với sự rõ ràng . Nếu chức năng của mã không rõ ràng ngay lập tức thông qua cách đọc thông thường, thì mã không đặc biệt rõ ràng và các bình luận (cho dù các bình luận có chất lượng cao như thế nào) là một sự thay thế kém và không hiệu quả cho mã rõ ràng.

Ví dụ, nhét một lá cờ ở mức cao của một trường không liên quan có thể được phép hoàn toàn trong một số trường hợp nhất định và nó có thể có ý nghĩa từ góc độ hiệu suất trong một số trường hợp nhất định, nhưng nó luôn luôn là một ý tưởng tồi đối với sự rõ ràng , ngay cả khi bạn nhận xét địa ngục ra khỏi nó.

Nếu bạn thấy mình phải giải thích bằng văn xuôi những gì mã của bạn làm, thì hãy xem xét bất kỳ điều nào sau đây: Lưu ý rằng một số trong số này có thể ảnh hưởng đến hiệu suất, nhưng hiệu suất có thể không quan trọng bằng sự rõ ràng trong một số trường hợp nhất định.

• Tên biến và tên hàm tốt hơn
• Bố trí mã và khoảng cách tốt hơn
• Xóa mọi "mánh" mà bạn nghĩ là một ý kiến ​​hay
• Mã nhóm theo chức năng khái niệm (ví dụ: trích xuất mã cho một mục đích cụ thể thành một hàm có tên thích hợp, ngay cả khi bạn chỉ gọi nó một lần)
• Sử dụng thuật toán đơn giản hơn (điều kiện cho phép)
• Sử dụng các thư viện nổi tiếng cho chức năng chung

Một câu trả lời đơn giản: "Mã của bạn càng được đọc lại nhiều hơn, gánh nặng giải thích những gì bạn đang làm". Điều này có thể bằng cách làm cho mã dễ đọc hơn, bằng cách nhận xét nó, bằng cách tạo tài liệu chính thức, bằng cách tuân theo các tiêu chuẩn kiểu ... Xin lưu ý rằng có thể bạn đang đọc lại sau đó, mặc dù điều đó cũng đúng với những người khác trong một môi trường doanh thu cao.

Có một chủ đề tuyệt vời khác bao gồm việc có hay không bình luận là tài liệu.

Nhận xét hữu ích hơn trong một số tình huống hơn những người khác. Điều này rất cơ bản đến nỗi tôi lo lắng về cách giải thích nó giữa rất nhiều câu trả lời mà tôi cho là "chống bình luận".

Nếu mã của bạn có thể không được đọc trong nhiều năm, các bình luận quan trọng hơn so với việc bạn có tái cấu trúc mã thường xuyên, quyền sở hữu mã mạnh và đánh giá mã nhiều. Nếu ứng dụng của bạn phức tạp và sử dụng các kỹ thuật không rõ ràng ngay lập tức đối với người quan sát thành thạo ngôn ngữ đó, các bình luận sẽ quan trọng hơn nếu hệ thống là một "Hello World" được tôn vinh. Nếu cơ sở mã không nghiêm ngặt với các tiêu chuẩn như nó có thể, các bình luận quan trọng hơn so với việc bạn đang làm việc với sáu lớp QA. Nếu bạn đang làm việc trong một nhóm với tám người chỉ học ngôn ngữ, các bình luận sẽ quan trọng hơn so với việc nhóm của bạn có tám Pulitzers lập trình. Nếu bạn có một ứng dụng ngổn ngang rơi vào lòng,ý kiến ​​quan trọng hơn nếu bạn có thể xây dựng nó sạch sẽ từ đầu.

Nó sẽ tốt hơn trong hầu hết các kịch bản để khắc phục nguyên nhân cơ bản thay vì tăng sử dụng bình luận? Chắc chắn rồi. Nhưng đôi khi bạn bị mắc kẹt với một cơ sở mã có nhiều dấu vân tay hơn so với điện thoại thông minh thị trấn và cách tốt nhất để cải thiện nó là làm cho các thay đổi của bạn trở nên dễ đọc nhất có thể và nhận xét về nó.

Đối với vấn đề cụ thể của bạn: các bình luận không nên quá nhiều về việc làm lộn xộn mã. Một đoạn được viết tốt ở đầu chương trình con, mô tả lý do tại sao một hàm tồn tại và có thể tại sao nó sử dụng cách tiếp cận đó, thường là đặt cược tốt nhất để giúp lập trình viên tiếp theo có được vòng bi của họ.