Cách tốt nhất để làm quen với một codebase lớn là gì?

Question

Tham gia vào một nhóm hiện có với một bộ mã lớn đã có sẵn có thể gây khó khăn. Cách tiếp cận tốt nhất là gì;

• Rộng; cố gắng xem tổng quan chung về cách mọi thứ liên kết với nhau, từ mã
• Thu hẹp; tập trung vào các phần nhỏ của mã tại một thời điểm, hiểu cách chúng hoạt động hoàn toàn
• Chọn một đối tượng địa lý để phát triển và tìm hiểu khi bạn đi dọc theo số
• Cố gắng lấy thông tin chi tiết từ sơ đồ lớp và uml, nếu có (và cập nhật)
• Có điều gì khác hoàn toàn?

tôi đang làm việc trên những gì hiện một khoảng 20k dòng C++ ứng dụng & thư viện (Edit: nhỏ trong chương trình lớn của sự vật). Trong ngành công nghiệp, tôi tưởng tượng bạn sẽ được giới thiệu bởi một lập trình viên có kinh nghiệm. Tuy nhiên, nếu đây không phải là trường hợp, bạn có thể làm gì để bắt đầu thêm giá trị càng nhanh càng tốt?

-
Tóm tắt các câu trả lời:

• Bước qua mã trong chế độ debug để xem cách nó hoạt động
• Pair lên với một ai đó quen thuộc hơn với các cơ sở mã hơn bạn, lần lượt là người mã hóa và người xem/thảo luận. Xoay đối tác giữa các thành viên trong nhóm để kiến ​​thức được lan truyền xung quanh.
• Viết kiểm tra đơn vị. Bắt đầu với một xác nhận về cách bạn nghĩ mã sẽ hoạt động. Nếu nó xuất hiện như bạn mong đợi, bạn có thể hiểu được mã. Nếu không, bạn đã có một câu đố để giải quyết và hoặc một yêu cầu để thực hiện. (Cảm ơn Donal, đây là một câu trả lời tuyệt vời)
• Thực hiện các kiểm tra đơn vị hiện có cho mã chức năng, theo cách tương tự như trên
• Đọc UML, Doxygen tạo sơ đồ lớp và tài liệu khác để có được cảm nhận rộng về mã.
• Thực hiện các chỉnh sửa nhỏ hoặc sửa lỗi, sau đó từng bước xây dựng
• Ghi chú và không nhảy vào và bắt đầu phát triển; nó có giá trị hơn để dành thời gian tìm hiểu hơn là tạo ra mã lộn xộn hoặc không phù hợp.

bài này là một bản sao một phần của the-best-way-to-familiarize-yourself-with-an-inherited-codebase

Answer 1

Bắt đầu với một số nhiệm vụ nhỏ nếu có thể, gỡ lỗi mã xung quanh vấn đề của bạn. Bước qua mã trong chế độ gỡ lỗi là cách dễ nhất để tìm hiểu cách hoạt động của một số thứ.

Answer 2

Tôi nghĩ bạn cần phải kết hợp điều này với một tác vụ cụ thể. Khi bạn có thời gian trên tay, hãy tìm bất cứ cách nào bạn đang ở trong tâm trạng.

Khi bạn có thứ gì đó cần được hoàn thành, hãy tập trung vào việc thu hẹp và hoàn thành nó.

Answer 3

này khá phụ thuộc vào những gì sắp xếp của người học và những gì sắp xếp của lập trình viên bạn đang có, nhưng:

• Rộng đầu tiên - bạn cần một ý tưởng về phạm vi và quy mô. Điều này có thể bao gồm tài liệu lướt qua/uml nếu chúng tốt.Nếu đó là một dự án dài hạn và bạn sẽ cần một sự hiểu biết đầy đủ về tất cả mọi thứ, tôi thực sự có thể đọc các tài liệu đúng cách. Một lần nữa, nếu chúng tốt.
• Thu hẹp - chọn thứ gì đó có thể quản lý và cố gắng hiểu nó. Có được một "hương vị" cho mã.
• Chọn một đối tượng địa lý - có thể là một đối tượng địa lý khác mà bạn vừa xem nếu bạn cảm thấy tự tin và bắt đầu thực hiện một số thay đổi nhỏ.
• Lặp lại - đánh giá xem mọi thứ đã tốt như thế nào và xem bạn có thể hưởng lợi từ việc lặp lại bước đầu sâu hơn hay không.

Answer 4

Tôi khuyên bạn nên chạy Doxygen để có sơ đồ lớp cập nhật, sau đó mở rộng trong một thời gian. Điều này mang lại cho bạn một bức ảnh lớn nhanh chóng mà bạn có thể sử dụng khi bạn nhận được gần gũi và bẩn với mã.

Answer 5

Một tùy chọn khác là viết các bài kiểm tra cho các tính năng mà bạn quan tâm. Thiết lập khai thác thử nghiệm là cách tốt để thiết lập những phụ thuộc hệ thống và trạng thái của nó. Mỗi bài kiểm tra bắt đầu với một xác nhận về cách bạn nghĩ rằng hệ thống sẽ hoạt động. Nếu nó quay ra để làm việc theo cách đó, bạn đã đạt được một cái gì đó và bạn đã có một số mẫu mã làm việc để tái sản xuất nó. Nếu nó không hoạt động theo cách đó, bạn đã có một câu đố để giải quyết và một dòng yêu cầu để làm theo.

Answer 6

Làm việc với một lập trình viên khác, người quen thuộc hơn với hệ thống để phát triển tính năng mới hoặc sửa lỗi. Đây là phương pháp mà tôi đã nhìn thấy hiệu quả nhất.

Answer 7

Tôi đồng ý rằng điều đó phụ thuộc hoàn toàn vào loại người học của bạn. Có nói rằng, tôi đã ở hai công ty có cơ sở mã rất lớn để bắt đầu. Thông thường, tôi làm việc như thế này:

Nếu có thể, trước khi xem bất kỳ mã chức năng nào, tôi sẽ thực hiện các bài kiểm tra đơn vị đã được viết. Những điều này nói chung có thể giúp đỡ khá nhiều. Nếu chúng không có sẵn, thì tôi làm như sau.

Đầu tiên, tôi phần lớn bỏ qua việc triển khai và chỉ xem các tệp tiêu đề hoặc chỉ các giao diện lớp. Tôi cố gắng để có được một ý tưởng về mục đích của mỗi lớp là gì. Thứ hai, tôi đi một mức độ sâu vào việc thực hiện bắt đầu với những gì có vẻ là khu vực quan trọng nhất. Điều này rất khó để đánh giá, vì vậy đôi khi tôi chỉ bắt đầu ở đầu và làm việc theo cách của tôi xuống trong danh sách tập tin. Tôi gọi đây là lần học đầu tiên. Sau bước đầu tiên này, tôi thường đi sâu hơn thông qua phần còn lại của mã. Giao diện đầu tiên giúp cải thiện/sửa bất kỳ ý tưởng nào tôi nhận được từ cấp độ giao diện và sau đó, giao diện sâu sắc cho tôi thấy các mẫu đã được sử dụng để triển khai hệ thống cũng như các ý tưởng thiết kế khác nhau. Theo chiều sâu đầu tiên, tôi có nghĩa là bạn về cơ bản bước qua chương trình bằng cách sử dụng trình gỡ lỗi, bước vào từng chức năng để xem nó hoạt động như thế nào, v.v. Điều này rõ ràng là không thể với các hệ thống thực sự lớn, nhưng 20k LOC không phải là nhiều. :)

Answer 8

Trước tiên, nếu bạn có thành viên nhóm có sẵn kinh nghiệm với mã, bạn nên sắp xếp để họ làm tổng quan về mã với bạn. Mỗi thành viên trong nhóm sẽ cung cấp cho bạn thông tin về lĩnh vực chuyên môn của họ. Nó thường có giá trị để có được nhiều người giải thích mọi thứ, bởi vì một số sẽ tốt hơn giải thích hơn những người khác và một số sẽ có một sự hiểu biết tốt hơn so với những người khác.

Sau đó, bạn cần phải bắt đầu đọc mã trong một thời gian mà không có bất kỳ áp lực nào (một vài ngày hoặc một tuần nếu sếp của bạn cung cấp). Nó thường giúp tự biên dịch/xây dựng dự án và có thể chạy dự án trong chế độ gỡ lỗi để bạn có thể bước qua mã. Sau đó, bắt đầu làm ướt đôi chân của bạn, sửa các lỗi nhỏ và thực hiện các cải tiến nhỏ. Bạn hy vọng sẽ sớm sẵn sàng cho một dự án cỡ trung bình, và sau đó, một dự án lớn. Tiếp tục dựa vào các đồng đội của bạn khi bạn đi - thường bạn có thể tìm thấy một người đặc biệt sẵn sàng cố vấn bạn.

Đừng quá khó khăn với bản thân nếu bạn gặp khó khăn - điều đó bình thường. Có thể mất một thời gian dài, có thể nhiều năm, để hiểu được một cơ sở mã lớn. Trên thực tế, nó thường là trường hợp mà ngay cả sau nhiều năm vẫn còn một số phần của mã mà vẫn còn một chút đáng sợ và mờ đục. Khi bạn nhận được thời gian chết giữa các dự án bạn có thể đào sâu vào các khu vực đó và bạn sẽ thường thấy rằng sau một vài lần thử bạn có thể hình dung ngay cả những phần đó.

Chúc may mắn!

Answer 9

Tôi thấy rằng chỉ cần nhảy vào mã có thể là một chút áp đảo. Cố gắng đọc càng nhiều tài liệu về thiết kế càng tốt. Điều này hy vọng sẽ giải thích mục đích và cấu trúc của từng thành phần. Tốt nhất của nó nếu một nhà phát triển hiện tại có thể đưa bạn qua nó nhưng điều đó không phải lúc nào cũng có thể.

Khi bạn cảm thấy thoải mái với cấu trúc mã cao cấp, hãy thử khắc phục một hoặc hai lỗi. điều này sẽ giúp bạn hiểu thấu mã thực tế.

Answer 10

Yêu cầu nhóm đưa bạn sửa lỗi trong hai tuần (nếu bạn có hai tuần). Họ sẽ rất vui khi có ai đó chịu trách nhiệm về điều đó, và đến cuối giai đoạn bạn sẽ dành rất nhiều thời gian giải quyết vấn đề với thư viện mà bạn có thể sẽ biết nó khá tốt.

Answer 11

Ghép nối với vòng quay nghiêm ngặt.

Nếu có thể, trong khi duyệt qua tài liệu/codebase, hãy thử sử dụng ghép nối với vòng quay nghiêm ngặt. Có nghĩa là, hai bạn ngồi cùng nhau trong một khoảng thời gian cố định (ví dụ, một phiên 2 giờ), sau đó bạn đổi cặp, một người sẽ tiếp tục làm nhiệm vụ đó trong khi người kia chuyển sang nhiệm vụ khác với người khác.

Theo cặp, cả hai bạn sẽ nhận một phần kiến ​​thức, sau đó có thể được cung cấp cho các thành viên khác của nhóm khi xoay vòng xảy ra. Điều tốt về điều này cũng là khi một cặp mới được kết hợp với nhau, người đã làm việc trong nhiệm vụ (trong trường hợp này, điều tra mã) có thể tóm tắt và giải thích các khái niệm theo cách dễ hiểu hơn. Theo thời gian, tất cả mọi người nên ở một mức độ hiểu biết tương tự, và hy vọng tránh được "Oh, chỉ có John biết rằng bit của mã" hội chứng.

Từ những gì tôi có thể nói về kịch bản của bạn, bạn có một số tốt cho điều này (3 cặp), tuy nhiên, nếu bạn được phân phối hoặc không hoạt động trong cùng một khoảng thời gian thì sẽ không thể thực hiện được.

Answer 12

Nếu thử nghiệm đơn vị (tôi cá là không). Bắt đầu nhỏ và chắc chắn rằng các bài kiểm tra đơn vị không thất bại. Nếu bạn nhìn chằm chằm vào toàn bộ codebase cùng một lúc, đôi mắt của bạn sẽ lóe lên và bạn sẽ cảm thấy bị choáng ngợp.

Nếu không có bài kiểm tra đơn vị, bạn cần tập trung vào đối tượng địa lý mà bạn muốn. Chạy ứng dụng và xem kết quả của những điều mà đối tượng địa lý của bạn sẽ ảnh hưởng. Sau đó, bắt đầu xem xét mã cố gắng tìm ra cách ứng dụng tạo ra những thứ bạn muốn thay đổi. Cuối cùng thay đổi nó và kiểm tra xem kết quả có xuất hiện theo cách bạn muốn hay không.

Bạn đã đề cập đến ứng dụng và thư viện. Đầu tiên hãy thay đổi ứng dụng và sử dụng thư viện với tư cách người dùng. Sau đó, sau khi bạn tìm hiểu thư viện, nó sẽ dễ thay đổi hơn.

Từ cách tiếp cận từ trên xuống, ứng dụng có thể có vòng lặp chính hoặc gui chính kiểm soát tất cả hành động. Nó là giá trị hiểu được dòng điều khiển chính của ứng dụng. Đó là giá trị đọc mã để cung cấp cho mình một cái nhìn tổng quan rộng về dòng chảy chính của ứng dụng. Nếu nó là một ứng dụng GUI, tạo ra một giấy cho thấy màn hình nào có và làm thế nào để có được từ một màn hình khác. Nếu đó là một ứng dụng dòng lệnh, cách xử lý được thực hiện.

Ngay cả trong các công ty, không có gì bất thường khi có cách tiếp cận này. Thường thì không ai hoàn toàn hiểu được cách một ứng dụng hoạt động. Và mọi người không có thời gian để chỉ cho bạn xung quanh. Họ thích những câu hỏi cụ thể về những thứ cụ thể để bạn phải tự mình đào sâu và thử nghiệm. Sau đó, một khi bạn nhận được câu hỏi cụ thể của bạn, bạn có thể cố gắng để cô lập nguồn kiến ​​thức cho phần đó của ứng dụng và yêu cầu nó.

Answer 13

Một điều mà tôi thường đề xuất với những người chưa được đề cập là điều quan trọng là trở thành người dùng có thẩm quyền của cơ sở mã hiện có trước khi bạn có thể là nhà phát triển. Khi các nhà phát triển mới tham gia vào dự án phần mềm lớn của chúng tôi, tôi đề nghị họ dành thời gian để trở thành người dùng chuyên gia trước khi lặn trong nỗ lực làm việc trên mã.

Có thể điều đó hiển nhiên, nhưng tôi đã thấy nhiều người cố gắng nhảy vào mã quá nhanh vì họ đang mong muốn bắt đầu tiến bộ.

Answer 14

Bạn có thể xem xét xem kỹ thuật đảo ngược mã nguồn công cụ. Có hai công cụ mà tôi biết:

• SWAG Kit (Linux) link
• Bauhaus academiccommercial

Cả hai công cụ cung cấp bộ tính năng tương tự bao gồm phân tích tĩnh mà tạo ra các đồ thị của các mối quan hệ giữa các mô-đun trong phần mềm.

Điều này chủ yếu bao gồm biểu đồ cuộc gọi và loại/lớp học. Xem thông tin này sẽ cung cấp cho bạn bức tranh tốt về cách các phần của mã liên quan đến nhau. Sử dụng thông tin này, bạn có thể đào sâu vào nguồn thực sự cho các phần mà bạn quan tâm nhất và bạn cần hiểu/sửa đổi trước.

Answer 15

Bắt đầu bằng cách hiểu 'miền sự cố' (có phải là hệ thống bảng lương? Khoảng không quảng cáo? Kiểm soát thời gian thực hay bất kỳ điều gì). Nếu bạn không hiểu thuật ngữ mà người dùng sử dụng, bạn sẽ không bao giờ hiểu được mã.

Sau đó, hãy xem mô hình đối tượng; có thể đã có một sơ đồ hoặc bạn có thể phải đảo ngược một kỹ sư (hoặc bằng tay hoặc sử dụng một công cụ theo đề xuất của Doug). Ở giai đoạn này, bạn cũng có thể điều tra cơ sở dữ liệu (nếu có), nếu cần theo mô hình đối tượng nhưng nó có thể không, và điều quan trọng là phải biết.

Hãy xem lịch sử thay đổi hoặc cơ sở dữ liệu lỗi, nếu có một khu vực xuất hiện nhiều, hãy xem xét bit đó trước. Điều này không có nghĩa là nó được viết sai, nhưng đó là bit mà mọi người đều sử dụng.

Cuối cùng, giữ một số ghi chú (tôi thích wiki).

• Những người hiện tại có thể sử dụng nó để đảm bảo kiểm tra các giả định của bạn và giúp bạn.
• Bạn sẽ cần phải tham khảo lại sau.
• Người mới tiếp theo sẽ thực sự cảm ơn bạn.

Answer 16

Tôi thích tất cả các câu trả lời cho biết bạn nên sử dụng công cụ như Doxygen để có biểu đồ lớp và trước hết hãy cố gắng hiểu bức tranh lớn. Tôi hoàn toàn đồng ý với điều này.

Điều đó nói rằng, điều này phần lớn phụ thuộc vào mức độ yếu tố mà mã sẽ bắt đầu.Nếu nó là một mớ hỗn độn khổng lồ, nó sẽ khó học. Nếu nó sạch sẽ, và được tổ chức đúng cách, nó không phải là xấu.

Answer 17

(tiếp thị không biết xấu hổ trước)

Bạn nên kiểm tra nWire. Nó là một plugin Eclipse để điều hướng và hiển thị các mã lớn. Nhiều khách hàng của chúng tôi sử dụng nó để đột nhập vào các nhà phát triển mới bằng cách in ra các hình ảnh hóa của các luồng chính.

Answer 18

Tôi đã có một tình huống tương tự. Tôi muốn nói rằng bạn sẽ thực hiện như sau:

• Nếu ứng dụng điều khiển cơ sở dữ liệu, bắt đầu từ cơ sở dữ liệu và sau đó quan hệ với các bảng khác.
• Sau khi sử dụng tốt cửa hàng cơ bản, hãy chuyển lên lớp ORM. Những bảng đó phải có một dạng biểu diễn nào đó trong mã.
• Sau khi thực hiện xong, hãy chuyển sang cách thức và vị trí của các đối tượng này. Giao diện? giao diện nào? Bất kỳ xác nhận? Tiền xử lý nào diễn ra trên chúng trước khi chúng đi đến kho dữ liệu?

Điều này sẽ làm quen với hệ thống. Hãy nhớ rằng cố gắng viết hoặc hiểu các bài kiểm tra đơn vị chỉ có thể khi bạn biết rất rõ những gì đang được thử nghiệm và lý do tại sao nó cần phải được kiểm tra trong chỉ theo cách đó.

Và trong trường hợp của một ứng dụng lớn mà không được điều khiển theo hướng cơ sở dữ liệu, tôi khuyên bạn nên một cách tiếp cận khác:

• gì mục tiêu chính của hệ thống?
• Các thành phần chính của hệ thống sau đó để giải quyết vấn đề này là gì?
• Tương tác của mỗi thành phần trong số đó có gì? Tạo biểu đồ mô tả các phụ thuộc thành phần. Hỏi ai đó đã làm việc trên đó. Những thành phần này phải trao đổi một cái gì đó với nhau để cố gắng tìm ra những thứ đó (như IO có thể trả về đối tượng File quay lại GUI và thích)
• Một khi thoải mái, hãy đi sâu vào thành phần ít phụ thuộc nhất. Bây giờ hãy nghiên cứu cách thành phần đó được chia thành các lớp và cách chúng tương tác với nhau như thế nào. Bằng cách này, bạn đã có một phần của một thành phần trong tổng số
• Di chuyển đến thành phần phụ thuộc ít nhất tiếp theo
• Đến cuối cùng, hãy chuyển sang thành phần cốt lõi thường sẽ phụ thuộc vào nhiều thành phần khác mà bạn đã giải quyết
• Trong khi xem xét thành phần cốt lõi, bạn có thể đang giới thiệu lại các thành phần bạn đã kiểm tra trước đó, vì vậy đừng lo lắng khi tiếp tục làm việc chăm chỉ!

Đối với chiến lược đầu tiên: Lấy ví dụ về trang web chồng xếp chồng này ví dụ. Kiểm tra kho dữ liệu, những gì đang được lưu trữ, làm thế nào được lưu trữ, những gì đại diện cho những mục có trong mã, làm thế nào một nơi mà những người được trình bày trên giao diện người dùng. Họ đến từ đâu và xử lý diễn ra gì khi họ quay trở lại kho dữ liệu.

Đối với mẫu thứ hai Lấy ví dụ về trình xử lý văn bản chẳng hạn. Có những thành phần nào? IO, giao diện người dùng, trang và muốn. Làm thế nào chúng tương tác với nhau? Di chuyển dọc theo khi bạn tìm hiểu thêm.

Hãy thư giãn. Mã viết là suy nghĩ của một ai đó, đóng băng logic và suy nghĩ theo phong cách và nó sẽ mất thời gian để đọc được suy nghĩ đó.

Answer 19

Xem this answer về cách sử dụng các công cụ kiểm tra để xác định mã cho đối tượng địa lý ưa thích mà không biết bất kỳ điều gì về tính năng đó hoặc cách trải rộng trên nhiều mô-đun.