Hầu hết mọi lập trình viên tiên tiến đều nói rằng việc đọc mã của các chuyên gia khác là rất hữu ích. Thông thường họ tư vấn nguồn mở.
Bạn có đọc nó hay không? Nếu bạn làm, tần suất và thủ tục đọc mã là gì? Ngoài ra, có một chút khó khăn cho người mới đối phó với SVN - một loạt các tệp. Giải pháp là gì?
Câu trả lời:
Bạn có đọc nó hay không?
Vâng.
Nếu bạn làm, tần suất
Hằng ngày. Không ngừng. Tôi làm việc với nhiều dự án nguồn mở (chủ yếu liên quan đến Python) và phải đọc nguồn vì đây là tài liệu chính xác nhất.
và thủ tục đọc mã là gì?
Ừm. Mở và đọc.
Ngoài ra, có một chút khó khăn cho người mới đối phó với SVN - một loạt các tệp. Giải pháp là gì?
Mở và đọc. Sau đó đọc thêm.
Nó không dẽ. Không có gì làm cho nó dễ dàng. Không có con đường Hoàng gia để hiểu. Nó làm việc
Có một vài lớp cho câu hỏi hóc búa mà bạn có. Đầu tiên, bắt đầu ở cấp độ cao, một cái nhìn mắt chim để nói. Khi bạn kiểm tra một dự án, sẽ có một loạt các tệp trong cấu trúc thư mục. Điều đó giống nhau cho dù bạn đang xem nguồn mở hay nguồn đóng (mã nguồn là mã nguồn). Vì vậy, bắt đầu với điều này:
Nó cần thực hành, nhưng nó chắc chắn là có thể làm được. Bạn càng biết nhiều về các thư viện và khung mà ứng dụng đang sử dụng, bạn càng biết cách mã cần được tổ chức và nơi để tìm câu trả lời cho các câu hỏi cụ thể. Một số mã khó theo dõi hơn một chút, đặc biệt nếu nó khá gián tiếp. Đó là lý do tại sao bạn cần bút chì và giấy. Cuối cùng, một bóng đèn tắt trong đầu bạn và bạn nhận được nó. Đó là khi đọc phần còn lại của mã có ý nghĩa hơn rất nhiều.
Nó không đọc giống như bạn đọc một cuốn tiểu thuyết, mà giống như cách bạn đọc một cuốn sách tham khảo. Một cách tốt là chọn một lỗi đã được sửa gần đây từ một thông báo kiểm tra, làm khác với những gì đã thay đổi và đọc các phần có liên quan cho đến khi bạn hiểu cả vấn đề và giải pháp. Các lỗ hổng bảo mật được công bố tốt là những lỗi thú vị để chọn vì có rất nhiều cuộc thảo luận về chúng trên các diễn đàn. Sau đó chọn một trong những lỗi "quả treo thấp" từ trình theo dõi lỗi và đọc cho đến khi bạn hiểu cách tự khắc phục. Hầu hết các chuyên gia đọc mã làm là ngẫu nhiên trong quá trình sửa lỗi hoặc thêm tính năng.
Thông thường các mẫu mã tốt nhất hầu như không đáng chú ý. Bạn sẽ ngay lập tức hiểu chúng mà không cần đọc qua chúng nhiều lần. Chúng làm cho nó trông giống như nó cực kỳ dễ viết, mặc dù mã tốt thường đi qua nhiều bản nháp. Nó tạo ra cảm giác nghịch lý rằng tất nhiên mã đã cho là cách rõ ràng để làm điều đó, mặc dù đó không phải là cách đầu tiên bạn nghĩ đến.
Khi bạn gặp mã như vậy, hãy cố gắng hiểu cái nhìn sâu sắc khi viết nó và các nguyên tắc thiết kế có liên quan, vì vậy khi bạn thấy mình trong một tình huống tương tự trong tương lai, bạn có thể hy vọng áp dụng các nguyên tắc tương tự.
Một mẹo tôi sử dụng khá thường xuyên khi đọc một số chức năng phức tạp, phân đoạn mã là bắt đầu tái cấu trúc nó thành một thứ dễ đọc hơn mà không thay đổi logic.
Làm thế nào là phải đối phó với "một loạt các tập tin" khó? Nó không khác với khi bạn viết mã của riêng mình, ngoại trừ bạn không có kiến thức trước về tổ chức của nó trừ khi nó được ghi lại.
Nếu bạn, với tư cách là một lập trình viên được yêu cầu, không thể tìm ra cấu trúc dự án từ "một loạt các tệp" hoặc đó là một dự án được tổ chức cực kỳ kém hoặc bạn là một lập trình viên không chuyên nghiệp (hoặc, trong trường hợp cực đoan, cả hai).
Bắt đầu đọc, cố gắng tìm một số điểm vào hoặc các lớp / phương thức trục chính cần thiết và xây dựng sự hiểu biết về cách tất cả kết hợp với nhau từ đó. Sẽ không ngay lập tức, sẽ mất thời gian, nhưng có thể được thực hiện ngay cả khi không có tài liệu nào cả.
Điều tốt nhất bạn có thể hy vọng khi đọc mã của dự án khác, đó là API hoặc phần mềm là các biến, hàm và tên macro không được viết tắt một cách mơ hồ hoặc được đặt tên để bạn có thể tìm ra ý định của chúng.
Nhưng khác với điều đó, cần một lượng kiến thức phong phú trải đều trên ngôn ngữ, kỹ thuật lập trình và cả về mục đích của chính mã để có thể đi sâu vào mã phức tạp.
Hiện tại tôi đang cố gắng xem Lua thực hiện một số điều kỳ diệu như thế nào , nhưng tôi đang đi đến điểm phía trên nơi có rất nhiều số nhận dạng được đặt tên một cách mơ hồ và được viết tắt đến mức tôi không thể tìm ra dòng nào đang thử để thực hiện điều mà tôi biết phải được thực hiện tại một số điểm trong mã chức năng ... Các biến đơn lẻ thường gặp và các tên hàm / macro được viết tắt khá phổ biến đang làm tôi suy nghĩ.
Sau khi xem "Đầu tiên, hãy bắt đầu ở cấp độ cao, chế độ xem mắt chim" khi @Berin Loritsch có đường, bạn có thể tìm kiếm những điều không mong muốn và / hoặc integrationtests nếu có.
unittests là thú vị để xem làm thế nào (api-) chi tiết hoạt động.
integrationtest thường cung cấp một cái nhìn tổng quan tốt về các quy trình busines.