Làm cách nào để cải thiện kỹ năng đọc mã của tôi [đóng]

Câu hỏi nằm trong tiêu đề - làm cách nào để cải thiện kỹ năng đọc mã của tôi.

Môi trường phần mềm / phần cứng tôi hiện đang phát triển khá chậm về thời gian biên dịch và thời gian để toàn bộ hệ thống kiểm tra. Hệ thống này khá cũ / phức tạp và do đó việc chia nó thành một số tiểu dự án nhỏ hơn, dễ quản lý hơn là không khả thi trong một tương lai gần.

Tôi đã nhận ra rằng điều thực sự cản trở tiến trình phát triển là kỹ năng đọc mã của tôi. Làm cách nào để cải thiện kỹ năng đọc mã của tôi, vì vậy tôi có thể phát hiện ra hầu hết các lỗi và sự cố trong mã ngay cả trước khi tôi nhấn phím "do biên dịch", ngay cả trước khi tôi khởi động trình gỡ lỗi?

Đọc thêm mã

Tôi, trước hết, đã có kỹ năng đọc mã khá tốt của tôi từ việc đọc các câu hỏi chứng nhận, những điều này rất khó theo dõi, vì chúng được viết không đúng mục đích

Rốt cuộc, họ phải kiểm tra kiến ​​thức về ngôn ngữ của bạn (Java trong trường hợp của tôi).

Càng đọc nhiều mã, bạn càng tích lũy được nhiều kinh nghiệm, điều đó thật đơn giản

Tăng cường môi trường phát triển của bạn càng nhiều càng tốt để nó có thể cung cấp cho bạn thông tin phản hồi bạn có thể sử dụng.

IDE hiện đại có thể giúp rất nhiều nếu bạn có thể cung cấp cho họ thông tin cần thiết. Ví dụ là:

• Cú pháp tô màu: hằng số trong một màu, ý kiến trong một, định danh trong một thứ ba, chuỗi trong một thứ tư, vv Tôi tìm thấy gần đây một đoạn mã đó là ... lẻ ... Hóa ra là một biến được đặt tên như một hằng số sẽ là - màu sai cho nó đi.
• Bắt lỗi biên dịch đơn giản. Hầu hết các ngôn ngữ có một cú pháp đơn giản mà một trình soạn thảo có thể được dạy, vì vậy nó có thể cho bạn biết trước bạn sẽ có lỗi.
• Bắt lỗi biên dịch phức tạp. Nhiều trình biên dịch có thể tạo các tệp thông tin có thể được tải vào IDE của bạn để nó biết có bao nhiêu đối số mà một hàm đã cho, v.v.

Ngoài ra các chương trình tồn tại có thể xác định các lỗi logic trong chương trình của bạn, mà bạn có thể sử dụng để có thêm thông tin về chương trình bạn có thể học hỏi.

Ngoài ra, IDE của bạn có thể giúp bạn điều hướng nguồn của mình khi nó biết tất cả những điều này. Điều này cho phép bạn dễ dàng tìm kiếm mọi thứ thay vì phải ghi nhớ mọi thứ

Tôi đề nghị bạn chỉnh sửa câu hỏi của mình để cung cấp thêm thông tin về môi trường bạn làm việc và các chương trình bạn viết, để có đề xuất tốt hơn.

Ngoài những gì người khác nói, bạn cần kiên nhẫn nếu bạn sẽ đọc mã (đặc biệt nếu đó không phải là của bạn). Vâng, đọc trên mỗi dòng mã bằng trái tim cần thực hành nhưng tất cả đều đáng giá, và bạn cũng học được các kiểu / thủ thuật mã hóa của người khác. Đây là những gì tôi kiểm tra theo thứ tự:

1. tên biến, niềng răng phù hợp, nhập khẩu, vv
2. kiểm tra xem các điều kiện được đặt đúng chưa, và các lỗi được bắt
3. mọi thứ khác - sử dụng các chức năng, vv

Tôi đã quen với việc mã hóa trong trình soạn thảo văn bản đơn giản vì vậy Ctrl + F là bạn của tôi, nhưng IDE rất hữu ích, đặc biệt là khi bạn đọc từ nhiều tệp.

Bây giờ nếu bạn là người sẽ viết mã, đừng ngại đặt khoảng trắng và vết lõm và nhận xét. Thành thật mà nói, nếu nó không vừa mắt, nó sẽ trở thành nỗi đau trong đầu.

Ngay cả khi tôi có thể phát hiện ra tất cả các lỗi trước khi tôi nhấn biên dịch, tôi vẫn sẽ kiểm tra bằng cách kiểm tra và biên dịch. Tôi chỉ tin tưởng vào một bài kiểm tra tích cực và một chương trình đang chạy.

Tôi nghĩ rằng kỹ năng đọc mã tốt có thể giúp bạn tiến xa hơn trong việc đưa ra giả thuyết về mã. "Có lẽ điều này sẽ đi sai!", Và kiểm tra điều đó. Và trong việc tìm ra lỗi "đây có thể là nguyên nhân cho phép kiểm tra nó"

Cách tốt nhất để đến đó là bằng cách tự viết mã. Cách tốt thứ hai là mã đơn giản là thực sự tốt và tự giải thích (nếu nó thực sự khó mã thì không tốt lắm)

Nếu đó không phải là mã của riêng bạn và nó không được viết tốt thì cách duy nhất để trở nên tốt hơn là làm, làm, làm. Đọc mã, thử những thứ khác nhau, viết các bài kiểm tra chống lại nó, tìm hiểu cơ sở mã, cấu trúc lại. Các công cụ có thể giúp đỡ, các công cụ có thể tìm thấy nơi các phương thức được sử dụng, nơi giao diện được triển khai, nơi các biến được khai báo, v.v. Và các công cụ cung cấp cho bạn cái nhìn tổng quan về không gian tên, mối quan hệ và số liệu về chúng.

Tôi đã có một vấn đề tương tự trong quá khứ - Bí quyết của tôi là viết một bài kiểm tra nhỏ, rời khỏi bàn làm việc một chút, quay lại và mô phỏng bài kiểm tra trên giấy. Bằng cách này, bạn có thể xem mã của mình bằng một giao diện mới và bạn có một giá trị cụ thể để kiểm tra (không giống như đi qua mã của bạn và nói "ahh .. ahh ... có ý nghĩa")

Có thể sẽ tốt khi tập trung vào việc học một kỹ năng đọc mã tại một thời điểm, giống như trong các đánh giá mã chính thức, mỗi người đánh giá có trách nhiệm khác nhau. Lấy một bộ mã và dành một tuần (giả sử) để tìm kiếm các tên biến xấu. Nhấn mã tương tự một lần nữa vào tuần tới để tìm kiếm con trỏ null tiềm năng; tuần tiếp theo tìm kiếm các khối mã trùng lặp; sau đó các vấn đề đa luồng, v.v.

Đã dành thời gian dành riêng để mài giũa các máy dò khác nhau, bạn có thể thấy rằng bây giờ bạn có thể đọc mã với một cặp - hoặc có thể là tất cả - trong số chúng đang hoạt động, do đó bạn có cảm giác mã phong phú hơn trong một lần đọc.

Nếu bạn đang nói về lỗi biên dịch, nó sẽ không xảy ra. Giải pháp tốt nhất cho các lỗi biên dịch là gán người đã phá vỡ bản dựng để giữ nguyên bản dựng cho đến khi có người khác phá bản dựng. Bạn đã phá vỡ nó, bạn sửa chữa nó.

Lỗi logic khó phát hiện hơn nhiều hãy ngăn chặn. Một kỹ thuật để ngăn chặn các trường hợp đơn giản là viết các bài kiểm tra đơn vị / hồi quy.

Một mẹo tôi nghe được sáng nay (On SE Radio) là lấy một tập tin và thu nhỏ nó xuống loại 3pt, sau đó tìm các mẫu trong văn bản. Bạn sẽ không thể đọc văn bản nhưng tất cả các loại mẫu sẽ xuất hiện. Đó là một mẹo hay.

Và đây là một trong những nơi dòng lệnh là bạn của bạn, grep và đường ống có thể làm rất nhiều điều hữu ích.

Tôi đã từng là một giảng viên lập trình trong vài năm. Trong thời gian này tôi đã dành rất nhiều thời gian để đọc mã và nhận xét về nó. Điều này liên quan đến lỗi phát hiện lỗi (chúng tôi không phải lúc nào cũng biên dịch mã của sinh viên), lỗi logic và thiết kế và các vấn đề tiêu chuẩn hóa.

Để làm tốt điều đó, chúng tôi đã phải phát triển một con mắt tinh tường cho loại lỗi này và để có thể "chạy khô" mã. Loại hoạt động này cũng cho tôi thấy nhiều phong cách mã hóa. Hôm nay kỹ năng đọc mã của tôi khá tốt nhờ vào thời kỳ đó.

Vì vậy, đề nghị của tôi cho bạn là:

• Làm mã xem lại với các đồng nghiệp của bạn.
• Tôi khuyên bạn nên đọc mã của họ một mình trước khi bạn xem qua mã đó để bạn sẽ tự tìm ra mã đó làm gì cho chính mình.
• Nhận xét về cấu trúc mã và độ sạch, tiêu chuẩn và logic.
• Điều này sẽ cải thiện chất lượng mã cũng như kỹ năng đọc mã của bạn.
• Mã xem lại mã của bạn một thời gian sau khi bạn hoàn thành mã hóa, bằng cách này, bạn sẽ có thể đánh giá nó "bằng con mắt mới" và học hỏi từ những sai lầm của bạn.

Chúc may mắn!