Tại sao lại sai khi nhận xét mã và sau đó xóa dần nó để theo dõi những gì tôi đã làm và những gì còn phải làm?

Bất cứ khi nào tôi phát hiện ra rằng một phần lớn mã của tôi cần phải được thay đổi, vì nó không chính xác hoặc vì nó cần phải được điều chỉnh theo các thay đổi kiến ​​trúc chính được yêu cầu bởi các lý do khác, đây là điều tôi thường làm:

1. Tôi nhận xét tất cả các mã mà tôi nghi ngờ tôi có thể phải thay đổi. Tôi coi mã nhận xét là một loại danh sách TODO của mình.
2. Tôi dần dần xem lại mã nhận xét và các phần không ghi chú của mã này hoặc sao chép-dán chúng ở nơi khác và sau đó chỉnh sửa chúng khi cần thiết hoặc viết lại các phần của mã này từ đầu, xem mã nhận xét để tham khảo. Bất cứ khi nào tôi nghĩ rằng tôi đã hoàn thành với một phần của mã nhận xét, tôi sẽ xóa nó.
3. Tôi tiếp tục điều này cho đến khi tôi không thể thấy thêm mã nhận xét.

Tôi nên lưu ý rằng phần lớn tôi đang làm điều này trong dự án cá nhân mà tôi đang phát triển một mình.

Tuy nhiên, tôi đã nói rằng tôi nên ngừng làm việc này. Tôi được cho biết rằng thay vào đó, tôi nên bắt đầu sử dụng git, tham khảo các cam kết cũ để xem mã cũ, thay vì để lại mã nhận xét. Tôi đã nói:

Nhận xét mã là một thói quen xấu cần được xóa sạch. Bạn thiếu kinh nghiệm nên bạn không hiểu điều đó. Nếu trong một vài năm, bạn thấy mã của một người khác thích bình luận mã, bạn sẽ tự bắt đầu chửi rủa người này. Bất cứ khi nào tôi thấy mã nhận xét, tôi loại bỏ toàn bộ mã, thậm chí không cần nhìn vào mã, vì thông thường mã như vậy là hoàn toàn vô giá trị. Bạn chắc chắn sẽ không nhìn thấy nhược điểm của việc bình luận mã trong các dự án nhỏ, một người; nhưng nếu bạn tìm được một công việc và giữ thói quen này thì đó sẽ là một sự xấu hổ.

Tôi có thể hỏi những nhược điểm của những gì tôi đang làm mà tôi không thấy bây giờ không?

Tôi phải nói rằng tôi không thực sự quan tâm đến việc chỉ sử dụng git để xem mã trong quá khứ. Như tôi đã nói, tôi coi việc bình luận mã là một loại danh sách việc cần làm; trong khi git sẽ chỉ cho tôi cách mã được sử dụng để tìm kiếm, nó sẽ không hiển thị rõ cho tôi phần nào của mã vẫn cần được xem xét và phần nào đã được thực hiện. Tôi sợ rằng tôi có thể bỏ lỡ một phần của mã và giới thiệu lỗi.

Để đầy đủ, tôi cảm thấy tôi nên nói thêm rằng người tôi đang trích dẫn là một nhà phát triển có kinh nghiệm và là người hâm mộ "Mã sạch" của chú Bob - và chú Bob đã chỉ trích bình luận mã một cách gay gắt trong cuốn sách của ông.

Nếu cuối cùng bạn loại bỏ tất cả các mã nhận xét, tôi thấy không có vấn đề thực sự với điều này. Để lại mã nhận xét trong cơ sở mã của bạn là một thực tiễn tồi nhưng đó không phải là điều bạn đang làm nếu bạn làm việc với tất cả và loại bỏ nó. Tôi nghi ngờ người bạn đang nói chuyện không hiểu quá trình bạn đang sử dụng hoặc đang giáo điều.

Trong thực tế, mã nhận xét là vô hại. Vấn đề là nó lộn xộn và gây khó đọc. Có những tội lỗi tồi tệ hơn nhiều nhưng đó là một điều rất đơn giản để loại bỏ. Là người đã nhận xét mã, bạn đang ở vị trí tốt nhất để xác định rằng nó có thể được gỡ bỏ hoàn toàn.

Rất nhiều IDE và trình soạn thảo mã hiểu một số loại cú pháp 'TODO' trong các bình luận. Đây là một cách thay thế để đánh dấu những gì cần phải thay đổi. Bạn có thể muốn xem xét điều này vì nó cung cấp thêm một chút thông tin về những gì bạn đã nghĩ khi bạn đánh dấu nó.

Vào cuối ngày, hãy làm mọi thứ theo cách mang lại kết quả tốt nhất cho bạn. Ngay cả khi đây là một dự án nhóm, miễn là bạn xóa tất cả các mã nhận xét mà bạn không phải gánh nặng cho bất kỳ ai khác.

Tôi có thể hỏi những nhược điểm của những gì tôi đang làm mà tôi không thấy bây giờ không?

Có thể cho rằng, không có gì nếu bạn làm việc một mình và không sử dụng kiểm soát phiên bản và cảm thấy ổn khi làm theo cách này.

Trong thực tế, không có kiểm soát phiên bản, việc bạn làm bất cứ lúc nào trong "thời gian" không quan trọng vì mã luôn ở trạng thái mà tệp hiện tại được "lưu" như trong hệ điều hành.

Nếu bạn sử dụng kiểm soát phiên bản và bạn có vô số bình luận là "danh sách việc cần làm" của mình, và bạn sửa một số và xóa nhận xét, sau đó lặp lại, sau đó lặp lại, v.v ... bạn đã lưu mã "đang tiến hành" và nhận xét trong lịch sử sửa đổi của bạn. Đây sẽ không phải là vấn đề nếu bạn không bao giờ cần quay lại cam kết khác hoặc thậm chí là "chọn anh đào" sau này (ví dụ này là nơi bạn thực hiện các cam kết cụ thể và kéo chúng vào một chi nhánh khác để sử dụng). Nhưng nếu không nó có thể là một vấn đề.

Có thể cho rằng điều này có thể được so sánh với "snap snap" của phần mềm ổ cứng, giống như Windows đã có (điều Khôi phục). Nếu nó chụp ảnh nhanh với virus, bạn sẽ diệt virus, nhưng sau đó cần quay lại, bạn có thể quay lại điểm mà virus lại xuất hiện.

Cách tiếp cận này cũng có thể là một vấn đề khi bạn sử dụng kiểm soát phiên bản và làm việc với các nhà phát triển khác, vì sau đó họ phải xem danh sách việc cần làm của bạn mà không sử dụng được cho họ. Trên thực tế, đó chỉ là sự lộn xộn mà họ phải bỏ qua và làm việc xung quanh. Trong các nhóm của chúng tôi, chúng tôi luôn xóa tất cả các nhận xét, chẳng hạn như mã cũ hoặc "ghi chú". Trừ khi chúng hữu ích - tuy nhiên điều này rất hiếm vì chúng tôi có tài liệu về "cách thức hoạt động" và phần mềm để theo dõi những gì cần phải làm (còn gọi là việc cần làm).

Ngoài ra, khi làm việc trong một dự án lớn hơn, bạn có xu hướng hợp tác, và cam kết và thúc đẩy thường xuyên, vì vậy có thể chi nhánh của họ đang làm việc có danh sách TODO của bạn nếu họ sáp nhập chi nhánh của bạn với họ. Sau đó, danh sách TODO của bạn là việc của mọi người: D

Tóm lại, nếu bạn không làm việc một mình và đặc biệt là khi sử dụng kiểm soát phiên bản, nó sẽ làm xáo trộn lịch sử và có thể gây lộn xộn cho các nhà phát triển khác.

Và, đây là một điều cá nhân trong một số khía cạnh, nhưng sử dụng một cơ sở mã làm "danh sách việc cần làm" của bạn thực sự không lý tưởng. Một ngày nào đó bạn có thể để lại một cái gì đó một cách tình cờ, hoặc quên bình luận hoặc bỏ qua nó do nhầm lẫn.

Cũng như rất nhiều cách tiếp cận về kiến ​​trúc, mã hóa và cách cá nhân bạn hoặc nhóm của bạn làm việc, mỗi kịch bản có thể gọi cho một cái gì đó khác nhau. Vì vậy, hãy xem xét các nhược điểm được đề cập và lợi ích của việc sử dụng kiểm soát phiên bản và quyết định xem nó có hiệu quả với bạn không .

Có vẻ như người đánh giá của bạn là một giáo điều nhỏ. Tôi không chắc chắn chửi rủa ai đó về việc nhận xét mã là PC ;-) hoặc thậm chí hữu ích ;-)

Nhưng nghiêm túc hơn, tôi nghĩ người đánh giá của bạn là đúng, rằng bạn nên nghiêm túc xem xét sử dụng git (hoặc một số hệ thống kiểm soát nguồn khác, nhưng git là một lựa chọn hợp lý).

Và làm như vậy có thể làm giảm bớt một số nhu cầu của bạn để nhận xét mã.

Nhưng có một danh sách TODO trong mã (cho dù danh sách gạch đầu dòng hoặc mã cũ) - theo tôi là khá hợp lý. Nhưng bạn có thể muốn xem xét lại một chút về cách bạn làm điều đó. Đối với một điều - tôi đề nghị suy nghĩ về người khác đọc mã của bạn. Rằng ai đó khác có thể là bạn, một năm sau khi bạn bỏ và tham gia lại một dự án. Hoặc nó có thể là một người khác hoàn toàn. JUST gặp mã nhận xét là một chút khó hiểu. Có lẽ một cái gì đó như:

/*
 * Need this sort of functionality added back before too long:
 * .... OLD CODE HERE
 */

Cá nhân, tôi nghiêng nhiều hơn về một cái gì đó như thế này:

 * TODO:
 *      @todo   Possible get rid of intermediate LRUCache_ object.
 *
 *      @todo   Find some reasonable/simple way to get
 *              LRUCache<PHRShortcutSpec, PHRShortcutSpec, PHRShortcutSpecNoAuthCacheTraits_>   sRecentlyUsedCache (kMaxEltsInReceltlyUsedCache_);
 *              Working with ONE T argument
 *              Add(elt2cache).
 ...

và tôi cảm thấy thoải mái khi ném 'đoạn mã' từ mã cũ là hữu ích.

Sử dụng git là khó (đáng buồn). Bạn sẽ mất một thời gian để tìm hiểu và có thể cảm thấy đó không phải là một phần của những gì bạn đang cố gắng thực hiện. Nhưng nếu bạn sẽ lập trình một cách hữu ích, bạn sẽ cần phải học cách làm như vậy như là một phần của một nhóm, và giao tiếp với một nhóm, và git chỉ là cách nó được thực hiện ngày nay. Và một khi bạn đã sử dụng nó, bạn sẽ tìm thấy một công cụ / nạng RẤT hữu ích, giúp cho việc phát triển phần mềm của bạn dễ dàng hơn.

May mắn nhất!

Có nhiều lý do để bình luận ra mã: -

• Điều đó chưa đúng và bạn sẽ không bình luận khi nó sẵn sàng.
• Bạn đang tạm thời nhận xét nó để thay đổi hành vi trong khi gỡ lỗi.
• Bạn không chắc có cần mã hay không, nhưng không muốn xóa nó cho đến khi bạn kiểm tra thêm.
• Mã này là cần thiết cho một số phiên bản của phần mềm, nhưng không phải là phiên bản này.
• Mã này đã lỗi thời, nhưng phải mất nhiều thời gian để viết và bạn cảm thấy gắn bó với nó. Bên cạnh đó, nó có thể hữu ích một ngày.

Vấn đề xảy ra khi bạn đặt mã lên giường, sau đó quay lại vài năm sau để bảo trì. Bạn sẽ tìm thấy các codebase rải rác với mã nhận xét. Nó sẽ không còn rõ ràng tại sao bất kỳ của nó ở đó, và bây giờ nó chỉ lộn xộn.

Nếu bạn sử dụng bất kỳ công cụ kiểm soát phiên bản nửa nào, bạn có thể mạnh dạn xóa bất kỳ mã nào bạn không cần nữa, an toàn với kiến ​​thức mà hệ thống kiểm soát phiên bản vẫn lưu trữ. Một tập tin khác nhau giữa các phiên bản sẽ tiết lộ những gì đã bị xóa. Khi bạn đã triển khai kiểm soát phiên bản, nhu cầu bình luận duy nhất là dành cho những thứ tạm thời. Nếu bạn từng tìm thấy mã nhận xét trong các tệp mà bạn không thực sự làm việc, bạn có thể xóa nó.

Tôi sẽ không nhắc lại lý do tại sao bạn nên sử dụng kiểm soát nguồn ngay cả đối với các dự án một người, vì có rất nhiều tài nguyên khác ngoài đó sẽ cho bạn biết điều này. Nhưng một nhược điểm chính liên quan đến phương pháp hiện tại của bạn là nếu bạn nhận xét mã, bạn sẽ ẩn nó khỏi IDE của mình (nếu bạn không sử dụng IDE, có lẽ bạn nên xem xét nó).

Ví dụ: nếu bạn muốn đổi tên một phương thức hoặc lớp hoặc thay đổi số lượng tham số mà phương thức cần, IDE của bạn nên có tùy chọn cấu trúc lại để thực hiện điều này sẽ tìm thấy tất cả các tham chiếu phù hợp và cập nhật chúng cho phù hợp - nhưng có lẽ nó đã thắng ' t tìm kiếm trong ý kiến.

Thay vì cố gắng đoán nơi bạn cần thực hiện thay đổi, chỉ cần thực hiện chúng và để IDE của bạn cho bạn biết những thay đổi của bạn đã khiến mọi thứ bị phá vỡ. Sau đó, bạn có thể nhận xét mã một cách phẫu thuật hơn và hy vọng trong một khoảng thời gian ngắn hơn trước khi bạn sửa bất kỳ lỗi nào.

Thật tệ và bạn nên dừng lại .

Lý do sôi nổi khi cố gắng thực hiện một số lượng lớn tái cấu trúc trong một lần.

Nếu bạn nhận xét các phần lớn của mã, sửa một chút và kiểm tra, thì bạn đã kiểm tra mã không có chức năng. và toàn bộ những thứ được bình luận ra mà những người khác sẽ cho là cũ và có thể bỏ qua

Nếu bạn không đăng ký thường xuyên, thì bạn đang tích lũy các xung đột hợp nhất và không ghi lại tiến trình từng bước.

Bạn cần thay đổi thực hành làm việc của mình để nếu bạn phải dừng giữa chừng thì mọi thứ vẫn hoạt động.

Thực hiện các bước bé và kiểm tra sau mỗi:

• trích xuất một giao diện
• viết một bài kiểm tra
• tái cấu trúc một hàm

Đừng đánh dấu các đoạn mã lớn là 'của bạn' bằng cách nhận xét chúng và tự mang chúng đi làm cho đến khi chúng hoàn thành hoặc bạn thất bại.

Nếu bạn cần theo dõi những gì cần phải làm, hãy sử dụng bảng nhiệm vụ như scrum hoặc trello