Làm thế nào để bạn theo dõi các dự án lớn?

Khi làm việc với một dự án có nhiều tệp khác nhau, tôi dường như luôn theo dõi cách các phần tương tác với nhau. Tôi chưa bao giờ thực sự gặp nhiều vấn đề khi hiểu các thành phần nhỏ hơn trong sự cô lập, nhưng khi sự phức tạp của dự án tăng lên, tôi thấy mình không thể xây dựng một sự hiểu biết về những gì đang diễn ra. Tôi nhận thấy điều này đặc biệt với các dự án OOP, vì số lượng phương thức và tệp nguồn tăng lên.

Nền tảng của tôi: Tôi là một lập trình viên tự học. Tôi đã xử lý chủ yếu với python cho các kịch bản nhanh và bẩn, nhưng tôi cũng đã thực hiện một vài dự án django cơ bản . Tôi thích các khung web như bình , vì trong sự đơn giản của bố cục một tệp, tôi có thể dễ dàng theo dõi (hầu hết) những gì đang diễn ra.

Bây giờ tôi thấy mình trong một tình huống cần phải tương tác với một dự án PHP Zend Framework lớn mà người khác đã phát triển và tôi choáng ngợp với việc cố gắng hiểu mã được phát tán ra nhiều tệp.

Những kỹ thuật và quy trình nào bạn thấy hữu ích để hiểu một cơ sở mã lớn mà người khác đã phát triển? Có sơ đồ cụ thể nào bạn tìm thấy giúp bạn nắm bắt bức tranh lớn hơn không?

Mẹo để hiểu một cơ sở mã lớn là không cố gắng hiểu tất cả về nó. Sau một kích thước nhất định, bạn không thể giữ một mô hình tinh thần trong đầu của bạn về toàn bộ. Bạn bắt đầu với một điểm neo có ý nghĩa cho bất kỳ nhiệm vụ nào bạn cần thực hiện trước tiên, sau đó phân nhánh từ đó, chỉ học những phần bạn cần và tin tưởng rằng phần còn lại của nó hoạt động như quảng cáo. Nó giống như hiểu đệ quy. Nếu bạn cố giữ toàn bộ chồng trong đầu, não bạn sẽ nổ tung.

Grep, debuggers và intellisense là những người bạn của bạn ở đây. Nếu bạn không biết làm thế nào một hàm kết thúc được gọi, hãy đặt một điểm dừng trên nó và tìm đường xuống theo dõi ngăn xếp.

Một điều khác cần lưu ý là các cơ sở mã lớn không mọc lên từ đâu cả. Nó càng lớn, càng có nhiều lập trình viên có kinh nghiệm về nó, vì vậy hãy hỏi họ bắt đầu từ đâu, nhưng hãy cụ thể. Đặt những câu hỏi như: "Tôi cần thêm một nhà cung cấp thanh toán mới. Tôi nên tìm mã ở đâu?" Chỉ tập trung vào nhiệm vụ đó thay vì cố gắng hiểu toàn bộ cơ sở mã, và từng mảnh một, sự quen thuộc của bạn sẽ tăng lên.

Không có phím tắt. Bạn chỉ phải chịu đựng nó.

Để trả lời câu hỏi của bạn về cách lấy sơ đồ, doxygen là những gì bạn muốn. AFAIK nó hoạt động với PHP.

Tổng quát hơn, tôi trải qua các giai đoạn sau đây khi gặp một cơ sở mã mới:

1. Hiểu những gì nó làm từ quan điểm của người dùng. Có thể tự mình thực sự sử dụng ứng dụng như một người sử dụng năng lượng. Hiểu cách người dùng cuối thực sự làm việc với nó. Điều này có thể yêu cầu ngồi xuống với họ cho đến khi bạn có được sự hiểu biết vững chắc về những gì họ làm.

2. Giao tiếp với các nhà phát triển ban đầu, nếu có thể. Lúc đầu, bạn sẽ có những câu hỏi về kiến ​​trúc được kích thích bởi trải nghiệm của người dùng cuối. Sau này, bạn sẽ có câu hỏi triển khai về các trường hợp cạnh và chi tiết. Có thể nhận được câu trả lời từ các nhà phát triển sẽ giúp nhiều hơn bất kỳ nhận xét hoặc tài liệu nào (không hoàn thành tốt nhất và thường gây hiểu lầm hoặc hoàn toàn không có).

3. Tìm hiểu về bất kỳ khuôn khổ nào bạn đang sử dụng. Tối thiểu, bạn sẽ có thể tạo ra một "thế giới xin chào" hoặc ứng dụng đơn giản khác với khung đó trước khi đi sâu vào ứng dụng sản xuất.

4. Nắm bắt toàn bộ quá trình triển khai (hoàn thành tốt nhất trong khi các nhà phát triển ban đầu đang nắm tay bạn). Nếu bạn không thể lấy cơ sở mã hiện tại và xây dựng nó và triển khai nó thông qua môi trường thử nghiệm / xác thực / sản phẩm, bạn sẽ nướng. Ngay cả thay đổi nhỏ nhất cũng sẽ yêu cầu nhảy qua tất cả các vòng triển khai, vậy tại sao không bỏ phần này xuống ngay lập tức? Làm như vậy, bạn sẽ được giới thiệu đến tất cả các máy chủ, cơ sở dữ liệu, dịch vụ và tập lệnh đáng yêu được sử dụng bởi ứng dụng-- bạn sẽ biết "nó sống ở đâu".

5. Hãy nắm bắt các bài kiểm tra chức năng (nếu có). Làm thế nào để bạn biết nếu điều đó đang chạy đúng? Những người hoạt động phải làm gì để chăm sóc và cho ăn ứng dụng?

6. Hiểu nhật ký của ứng dụng. Mặc dù tôi chưa bao giờ làm việc với PHP, tôi sẽ đoán mò và nói rằng bất kỳ ứng dụng PHP nghiêm túc nào cũng sẽ có một số loại ghi nhật ký. Nếu bạn hiểu nhật ký, bạn sẽ có một điểm khởi đầu tốt khi đến thời điểm sửa lỗi.

---- Lưu ý rằng cho đến đây, tôi thậm chí đã không đề cập đến việc xem xét kỹ về cơ sở mã. Có A LOT bạn có thể tìm hiểu về một dự án lớn mà không hề nhìn vào mã. Tại một số điểm, tất nhiên, bạn phải thoải mái với mã. Đây là những gì giúp tôi:

7. Đối với sơ đồ, doxygen là một công cụ tuyệt vời sẽ tạo biểu đồ cuộc gọi và các mối quan hệ khác cho bạn. Nó xảy ra để có khả năng PHP! Nếu bạn chưa thử doxygen, bạn hoàn toàn phải cho nó một vòng quay. Mặc dù tôi không thể đảm bảo mức độ dễ hiểu của mã trong khung, nhưng nó có thể giúp ích. Các nhà phát triển ban đầu thường bị sốc với những gì họ thấy khi được trình bày với các tài liệu doxygen tạo ra mã của họ. Tin tốt là nó thực sự giúp chạy bộ nhớ của họ và giúp bạn tốt hơn.

8. Nếu bạn có một bộ các bài kiểm tra đơn vị, xem xét kỹ chúng sẽ cung cấp một cửa sổ vào hoạt động bên trong của ứng dụng. Đây cũng sẽ là nơi đầu tiên để tìm kiếm các lỗi mà bạn có thể đã giới thiệu trong khi thực hiện các thay đổi.

9. Dấu trang IDE là vô giá để gắn thẻ các điểm nóng trong cơ sở mã. Có thể chuyển qua chúng nhanh chóng sẽ thúc đẩy sự hiểu biết.

10. Đọc các báo cáo lỗi gần đây và độ phân giải của chúng cũng có giá trị để hiểu các điểm nóng và sẽ giúp bạn bắt kịp tốc độ trên các phần có liên quan nhất của cơ sở mã.

Theo yêu cầu, đây là nhận xét của tôi như một câu trả lời.

Khi làm việc với mã của người khác, tôi có xu hướng tạo hoặc nếu có thể tạo sơ đồ lớp UML để cung cấp cho tôi tổng quan về cấu trúc tĩnh. Sơ đồ trực quan giúp tôi đặc biệt là khi tôi phải quay lại sau đó và đã quên bối cảnh của một lớp. Đôi khi tôi làm điều đó cho hành vi năng động cũng như để vạch ra các tương tác giữa các cộng tác viên, nhưng tôi không làm điều đó thường xuyên.

Nếu codebase chứa các bài kiểm tra (tích hợp hoặc đơn vị), đôi khi chúng cũng đáng để kiểm tra.

Tôi thực sự sẽ bắt đầu thực hiện điều này trong suốt tuần này khi một khách hàng mới cần các cải tiến cho một sản phẩm do một nhà phát triển khác để lại. Dưới đây là các bước cần tuân thủ:

a) Xác định khung lập trình được sử dụng, giúp biết cách ứng dụng chảy.

b) Xác định các dịch vụ phổ biến - ghi nhật ký, xử lý ngoại lệ, MVC, kết nối cơ sở dữ liệu, kiểm toán, xem (tạo trang) vì đây là những phần mà chúng tôi sẽ sử dụng nhiều nhất.

c) Chạy qua các luồng người dùng phổ biến (trong ứng dụng) sau đó cố gắng căn chỉnh chúng theo cách trình bày mã

d) Cố gắng thực hiện một số thay đổi và xem cách chúng xuất hiện. Đây là bước lớn nhất vì cho đến khi bạn bắt đầu thay đổi, mã vẫn là hộp đen ....

Tôi sẽ cho bạn biết những ý tưởng khác mà tôi có được trong suốt hai tuần tới

Tôi nghĩ rằng bạn nên đọc tài liệu. Tôi biết tin tặc thích nói với bạn "mã là tài liệu" và sử dụng nó như một cái cớ để không viết bất kỳ tài liệu nào, nhưng họ đã sai. Nhìn vào nhân Linux, một dự án phần mềm khổng lồ gồm hàng triệu dòng mã: Tôi không nghĩ có ai thực sự có thể làm mới mà không cần đọc một cuốn sách và chỉ cần nhặt nó lên. Nếu mã bạn đang làm việc không được ghi lại (hoặc nhận xét tốt nếu một dự án nhỏ hơn) thì có lẽ đó không phải là mã tốt.

Nếu bạn đang làm việc với một cái gì đó thực sự lớn với tài liệu không (tôi cũng đã từng ở đó, thì thật là khó hiểu!), Điều tôi thấy hữu ích là cố gắng cô lập phần bạn đang làm việc. Trong phần đó của mã, hãy tìm hiểu cách dữ liệu / sự kiện / tin nhắn / tương tác truyền vào và ra khỏi đơn vị đó. Nói cách khác, kỹ sư đảo ngược giao diện. Viết nó ra. Lần tới khi bạn làm việc trên một đơn vị khác (tiền thưởng nếu nó nói chuyện với đơn vị bạn làm việc đầu tiên), hãy làm điều tương tự. Giữ tất cả tài liệu của bạn. Sau một vài tháng, bạn sẽ có một bức tranh đẹp về sự việc diễn ra.

Chỉ ra giao diện của một đơn vị nhỏ mà bạn đang làm việc và ghi lại để tham khảo sau. Theo thời gian, bạn sẽ khâu lại với nhau hầu hết cách nó hoạt động. Tìm những gì chương trình của bạn làm và theo dõi làm thế nào thông điệp đó chảy. Ví dụ: nếu hệ thống của bạn nhận một số thông báo mạng đầu vào và gửi một thông báo đầu ra, hãy theo dõi cách thông báo đó chảy qua hệ thống, mà không phải lo lắng về tất cả các chi tiết - chỉ cần xem nó đi đâu.

Những gì tôi làm là tạo một mô hình UML duy nhất từ ​​tất cả các tệp đã được đảo ngược từ java sang UML. Cách tiếp cận này có nghĩa là mô hình không còn là một cái nhìn trừu tượng về dự án mà bản thân dự án hoàn toàn được ánh xạ tới MOF và do đó là UML.

Những gì tôi nhận được là một mô hình đơn lớn được tạo bởi nhiều mô hình con, mỗi mô hình được tạo bởi các gói được tạo bởi các bộ phân loại, v.v. Làm việc ở cấp độ nhiều dự án cũng cho phép tôi theo dõi từng phân loại và các cuộc gọi phương thức ở cấp độ đa hướng. Ý tôi là cùng một phương thức có thể gọi một bộ phân loại trong dự án A và một bộ phân loại khác trong dự án B. Cách duy nhất để xem toàn bộ cấu trúc của dự án là đảo ngược cả hai cùng một lúc. Tôi không có thời gian để tạo sơ đồ thành phần và thông tin không thực sự chính xác. Tôi thích yêu cầu máy tính đảo ngược toàn bộ dự án cho tôi. Tôi làm ngược lại ở mỗi lần lặp với nhóm và tất cả các sơ đồ của tôi được cập nhật ngay lập tức. Kỹ thuật đảo ngược là tăng dần và sử dụng ánh xạ Java sang UML Ids. Ý tôi là mỗi phần tử java được ánh xạ tới một phần tử MOF duy nhất và duy nhất giống nhau trong suốt vòng đời dự án ngay cả khi được tái cấu trúc. Việc đó không mang lại giới hạn nào cho mô hình hóa UML và cho phép mô hình dự án rất lớn và phức tạp. Để biết thông tin của bạn, tôi làm việc với dự án có hơn 5 000 000 dòng mã OOP. Tất cả các dự án của tôi được đảo ngược đúng cách và điều hướng đồ họa là có thể

Tôi chỉ sử dụng sơ đồ lớp vì từ mô hình UML của tôi, tôi có thể tạo ra nhiều chế độ xem cần thiết luôn được cập nhật. Tôi cũng có thể mô hình các dự án rất phức tạp.