Chào mừng đến với Diễn đàn lập trình - Cộng đồng lập trình.
Kết quả 1 đến 6 của 6
  1. #1
    Bài này chỉ áp dụng cho những code có quy mô cỡ "bài tập lớn", hướng thủ tục.

    Còn nói chung đối với 1 hệ thống cỡ enterprise thì phải coi tài liệu mới mong hiểu nhanh được.

    Thêm nữa code viết phải sáng sủa, nhìn tên hàm là hiểu nó làm gì, chả ông nào ngu đi đọc hết hàm reverse(String) xem nó làm gì cả vì ai cũng biết nó đảo ngược một chuỗi.

    Những bài đa luồng thì đọc theo cách này bằng ??? niềm tin chăng [IMG]images/smilies/wave.gif[/IMG]

    Còn nhiều nhiều điều nữa...

    Nói chung muốn đọc code nhanh thì phải là tay code cứng + source code cũng phải thuộc dạng dễ hiểu, tuân thủ convention, tư duy thiết kế tốt...

  2. #2

    Kinh nghiệm đọc source code

    Đã là dân lập trình thì ai mà chẳng từng đọc source code của người khác, lấy ý tưởng và kỷ thuật của người ta làm kiến thức cho mình, đó cũng là cách để cho mình nhanh “lên tay” nhất. Nhưng sự thật thì không phải dể dàng như vậy vì làm sao mà hiểu được ý định của người khác muốn làm gì. Giả sử bạn có source của một chương trình dài 10 trang, đang đọc trang thứ 1 thì có lệnh gọi 1 hàm nào đó nằm ở trang thứ 7, lật qua trang thứ 7 đọc một hồi thì nó lại gọi 1 hàm khác ở trang thứ 5…, cứ như vậy thì bạn như là đang lạc trong một đám rừng vậy. Nếu tu vi nội công không thâm hậu thì rất dể bị tẩu hỏa nhập ma lắm à… Rỏ ràng là việc “chôm” của người khác cũng đâu có dể ăn, phải có kỷ thuật chớ bộ…
    Chúng ta cùng xét một ví dụ nhỏ sau:
    Giả sử chúng ta có một chương trình gồm có 5 hàm con và một hàm chính (Main) như sau:

    Code:
    Sub Main()
    ………
    Call Sub 3
    ………
    End Sub

    Sub 1()
    ………
    Call Sub 2
    ………
    End Sub

    Sub 2()
    ………
    Call Sub 4
    ………
    Call Sub 5
    ………
    End Sub

    Sub 3()
    ………
    Call Sub 1
    ………
    End Sub

    Sub 4()
    ………
    ………
    End Sub

    Sub 5()
    ………
    Call Sub 4
    ………
    End Sub


    Trước tiên chúng ta hãy đọc qua sơ lược chương trình xem nó gồm có những hàm nào, sau đó vẻ từng hàm đó ra (hình 1). Xem coi hàm đó gọi hàm nào, vẻ mũi tên đường đi của nó (hình 2).
    Sau khi đã có sơ đồ dòng chảy của chương trình rồi thì ta mới bắt tay vào việc đọc source code theo nguyên tắc sau: đọc hàm nào có mũi tên vô mà không có mũi tên ra.
    Như vậy với sơ đồ trên thì đầu tiên chúng ta phải đọc Sub 4 trước. Sau khi đọc và hiểu nó xong thì xóa nó và các đường dẩn tới nó đi (hình 3).
    Cứ tiếp tục như vậy chúng ta lần lượt có hình 4, hình 5, hình 6 và cuối cùng là hàm Main hình 7.

    Như vậy chúng ta thấy rằng với bất kỳ chương trình nào thì hàm Main cũng luôn là hàm được đọc sau cùng nhất. Điều này ắt hẳn sẽ trái ngược với cách đọc trước đây của rất nhiều người vì đa số chúng ta vô là chụp ngay hàm Main đọc trước không hà... điều đó cũng giống như là chưa có nội công mà đã luyện Càn Khôn Đại Na Di vậy đó.

    Cái này chỉ là kinh nghiệm mình học được của người khác thôi, có thể bạn có cách làm khác, hãy giới thiệu lên đây để cùng học hỏi nhé.

    ( Sưu tầm từ diễn đàn kế toán, thành viên hocketoan).

  3. #3
    Ngày tham gia
    Sep 2015
    Bài viết
    0
    Giả sử bạn có source của một chương trình dài 10 trang, đang đọc trang thứ 1 thì có lệnh gọi 1 hàm nào đó nằm ở trang thứ 7, lật qua trang thứ 7 đọc một hồi thì nó lại gọi 1 hàm khác ở trang thứ 5

  4. #4
    Ngày tham gia
    Sep 2015
    Bài viết
    0
    Đọc code trên giấy là điều không nên chút nào, trừ khi đấy là code trong một cuốn sách. Mà code trong một cuốn sách thì chẳng ai viết 10 trang liền cả. Code tren những trang như github, google code lại không có tài liệu, vậy để hiểu được code của họ bạn phải chạy được code đã. Import được vào các IDE tương ứng. Sau đó chạy code ở chế độ debug. Tìm mọi cách để debug được code. Debug được rồi thì vẽ lại work flow của code. Xem các hàm chạy như nào. Tác dụng từng hàm ra sao. Coi như nhìn code viết tài liệu vậy.

    Xong các bước trên thì đến bước chỉnh sửa code theo ý mình mà code vẫn chạy đúng. Sau bước này thì bạn tự code lại theo ý của bạn, lúc này bạn đã làm chủ được code của họ rồi. Bạn viết lại theo nhu cầu sử dụng của bạn. Không nên bê nguyên code của họ dùng mà không đọc rõ license.

  5. #5
    Ngày tham gia
    Sep 2015
    Bài viết
    0
    Các IDE hỗ trợ rất nhiều các cách để xem hiểu code dễ dàng hơn.
    Ví dụ:
    Eclipse có:
    CRTL+O: Xem nhanh outline
    CTRL+T: Xem nhanh cây phân cấp kế thừa
    CTRL+ALT+H: Xem chuỗi lời gọi
    F3: Nhảy đến định nghĩa
    CTRL+,: Vị trí trước
    CTRL+.: Vị trí sau
    -> Nên nhớ những cái phím tắt này.

    Eclipse có các plugin có thể sinh ra sơ đồ.

  6. #6
    Ngày tham gia
    Sep 2015
    Bài viết
    0
    sơ đồ thiết kế, cái gì cũng vậy đều có sơ đồ.

 

 

Quyền viết bài

  • Bạn Không thể gửi Chủ đề mới
  • Bạn Không thể Gửi trả lời
  • Bạn Không thể Gửi file đính kèm
  • Bạn Không thể Sửa bài viết của mình
  •