Làm thế nào để bạn đi sâu vào các cơ sở mã lớn?

Những công cụ và kỹ thuật nào bạn sử dụng để khám phá và tìm hiểu một cơ sở mã chưa biết?

Tôi đang nghĩ về các công cụ như grep, ctagskiểm tra đơn vị, kiểm tra chức năng, trình tạo sơ đồ lớp, biểu đồ cuộc gọi, số liệu mã như sloccount, v.v. Tôi sẽ quan tâm đến trải nghiệm của bạn, những người trợ giúp bạn đã sử dụng hoặc tự viết và quy mô của cơ sở mã mà bạn đã làm việc.

Tôi nhận ra rằng làm quen với cơ sở mã là một quá trình xảy ra theo thời gian và sự quen thuộc có thể có nghĩa là từ "Tôi có thể tóm tắt mã" đến "Tôi có thể cấu trúc lại và thu nhỏ nó xuống 30% kích thước". Nhưng làm thế nào để bắt đầu?

những gì tôi luôn làm là như sau:

Mở nhiều bản sao trình soạn thảo của tôi (Visual Studio / Eclipse / Any) và sau đó gỡ lỗi và thực hiện ngắt dòng qua mã. Tìm hiểu dòng mã, xếp chồng dấu vết để xem các điểm chính nằm ở đâu và đi từ đó.

Tôi có thể xem phương thức sau phương thức - nhưng thật tuyệt nếu tôi có thể nhấp vào một cái gì đó và sau đó xem nơi mã được thực thi và làm theo. Hãy để tôi cảm nhận về cách nhà phát triển muốn mọi thứ hoạt động.

Làm thế nào để bạn ăn một con voi?

Một lần cắn một lúc :)

Nghiêm túc, tôi cố gắng nói chuyện với các tác giả của mã đầu tiên.

Tôi có phải hack cho đến khi tôi hoàn thành công việc

Ở một mức độ lớn, có (xin lỗi).

Phương pháp bạn có thể cân nhắc:

1. Cố gắng tìm hiểu những gì mã được cho là để làm, trong điều khoản kinh doanh.
2. Đọc tất cả các tài liệu tồn tại, cho dù nó xấu như thế nào.
3. Nói chuyện với bất cứ ai có thể biết một cái gì đó về mã.
4. Bước qua mã trong trình gỡ lỗi.
5. Giới thiệu những thay đổi nhỏ và xem những gì phá vỡ.
6. Thực hiện các thay đổi nhỏ cho mã để làm cho nó rõ ràng hơn.

Một số điều tôi làm để làm rõ mã là:

1. Chạy trình chỉnh sửa mã để định dạng mã độc đáo.
2. Thêm ý kiến ​​để giải thích những gì tôi nghĩ nó có thể làm
3. Thay đổi tên biến để làm cho chúng rõ ràng hơn (sử dụng công cụ tái cấu trúc)
4. Sử dụng một công cụ làm nổi bật tất cả việc sử dụng một biểu tượng cụ thể
5. Giảm sự lộn xộn trong mã - nhận xét mã, bình luận vô nghĩa, khởi tạo biến vô nghĩa và vv.
6. Thay đổi mã để sử dụng các quy ước mã hiện tại (một lần nữa sử dụng các công cụ tái cấu trúc)
7. Bắt đầu trích xuất chức năng thành các thói quen có ý nghĩa
8. Bắt đầu thêm các bài kiểm tra khi có thể (không thường xuyên có thể)
9. Loại bỏ số ma thuật
10. Giảm trùng lặp nếu có thể

... Và bất cứ cải tiến đơn giản nào khác mà bạn có thể thực hiện.

Dần dần, ý nghĩa đằng sau tất cả sẽ trở nên rõ ràng hơn.

Còn nơi bắt đầu? Bắt đầu với những gì bạn biết. Tôi đề nghị đầu vào và đầu ra. Bạn thường có thể nắm được những thứ được cho là và những gì chúng được sử dụng cho. Theo dõi dữ liệu thông qua ứng dụng và xem nó đi đâu và thay đổi như thế nào.

Một trong những vấn đề tôi gặp phải với tất cả điều này là động lực - nó có thể là một khẩu hiệu thực sự. Nó giúp tôi nghĩ về toàn bộ công việc kinh doanh như một câu đố và để ăn mừng cho sự tiến bộ mà tôi đang thực hiện, dù nhỏ đến đâu.

Tình hình của bạn là thực sự phổ biến. Bất cứ ai phải bước vào một công việc mới, nơi có sẵn mã để làm việc sẽ xử lý một số yếu tố của nó. Nếu hệ thống là một hệ thống di sản thực sự khó chịu, thì nó rất giống với những gì bạn đã mô tả. Tất nhiên, không bao giờ có bất kỳ tài liệu hiện tại.

Đầu tiên, nhiều người đã khuyến nghị làm việc hiệu quả với Bộ luật kế thừa của Michael Feathers. Đây thực sự là một cuốn sách hay, với các chương hữu ích như "Tôi không thể đưa lớp này vào khai thác thử nghiệm" hoặc "Ứng dụng của tôi không có cấu trúc" mặc dù đôi khi Feathers chỉ có thể mang lại nhiều thiện cảm hơn là giải pháp. Đặc biệt, cuốn sách và các ví dụ của nó chủ yếu hướng đến các ngôn ngữ niềng răng xoăn. Nếu bạn đang làm việc với các thủ tục SQL sởn gai ốc, nó có thể không hoàn toàn hữu ích. Tôi nghĩ chương này, "Tôi không hiểu mã này đủ tốt để thay đổi nó", nói lên vấn đề của bạn. Feathers đề cập ở đây những điều rõ ràng như ghi chú và đánh dấu danh sách, nhưng cũng có một điểm tốt là bạn có thể xóa mã không sử dụng nếu bạn có quyền kiểm soát nguồn. Rất nhiều người để lại phần bình luận của mã tại chỗ,

Tiếp theo, tôi nghĩ cách tiếp cận được đề xuất của bạn chắc chắn là một bước tốt. Bạn phải hiểu đầu tiên ở mức cao mục đích của mã là gì.

Chắc chắn làm việc với một người cố vấn hoặc một người nào đó trong nhóm nếu bạn phải trả lời câu hỏi.

Ngoài ra, hãy tận dụng cơ hội để hỗ trợ mã nếu các lỗi được tiết lộ (mặc dù đôi khi bạn không phải tình nguyện cho việc này ... lỗi sẽ tìm thấy bạn!). Người dùng có thể giải thích những gì họ sử dụng phần mềm và làm thế nào các khiếm khuyết ảnh hưởng đến họ. Đó thường có thể là một chút kiến ​​thức rất hữu ích khi cố gắng hiểu ý nghĩa của phần mềm. Ngoài ra, đi sâu vào mã với mục tiêu tấn công có mục đích đôi khi có thể giúp bạn tập trung khi đối mặt với "quái thú".

Tôi thích làm như sau khi tôi có một tệp nguồn thực sự lớn:

• Sao chép toàn bộ mớ hỗn độn vào clipboard
• Dán vào Word / textmate bất cứ điều gì
• Giảm cỡ chữ xuống mức tối thiểu.
• Cuộn xuống nhìn vào các mẫu trong mã

Bạn sẽ ngạc nhiên khi thấy mã quen thuộc kỳ lạ khi bạn quay lại trình soạn thảo bình thường.

Nó cần có thời gian

Đừng cảm thấy quá vội vàng trong khi cố gắng hiểu một cơ sở mã kế thừa, đặc biệt nếu nó sử dụng các công nghệ / ngôn ngữ / khung mà bạn không quen thuộc. Đó chỉ là một đường cong học tập không thể tránh khỏi cần một chút thời gian.

Một cách tiếp cận là đi qua lại giữa mã và hướng dẫn về các công nghệ liên quan. Bạn đọc / xem hướng dẫn, sau đó xem mã để xem người tiền nhiệm của bạn đã làm như thế nào, lưu ý bất kỳ điểm tương đồng và khác biệt, ghi chú và đặt câu hỏi cho bất kỳ nhà phát triển hiện có nào.

"Tại sao bạn làm phần này theo cách này"

"Tôi nhận thấy hầu hết mọi người trực tuyến đang làm theo cách này và tất cả các bạn đã làm theo cách khác. Tại sao lại như vậy?"

"Điều gì khiến tất cả các bạn chọn công nghệ X thay vì công nghệ Y?"

Các câu trả lời cho những câu hỏi này sẽ giúp bạn hiểu lịch sử của dự án và lý do đằng sau các quyết định thiết kế và thực hiện.

Cuối cùng, bạn sẽ cảm thấy đủ quen thuộc với nó để bạn có thể bắt đầu thêm / sửa chữa mọi thứ. Nếu tất cả có vẻ khó hiểu hoặc có vẻ như có quá nhiều "phép thuật" đang diễn ra, bạn đã không dành đủ thời gian để xem qua, tiêu hóa nó và lập sơ đồ. Tạo sơ đồ (sơ đồ trình tự, sơ đồ quy trình, v.v.) là một cách tuyệt vời để bạn hiểu một quy trình phức tạp, cộng với chúng sẽ giúp "chàng trai tiếp theo".

cscope có thể làm bất cứ điều gì ctags có thể làm cho C, ngoài ra, nó cũng có thể liệt kê nơi tất cả các hàm hiện tại được gọi. Thêm vào đó là rất nhanh. Cân dễ dàng đến hàng triệu LỘC. Tích hợp gọn gàng để emacs và vim.

Bộ đếm mã C và C ++ - cccc có thể tạo số liệu mã ở định dạng html. Tôi cũng đã sử dụng wc để lấy LỘC.

doxygen có thể tạo cú pháp được tô sáng và mã tham chiếu chéo trong html. Hữu ích trong việc duyệt cơ sở mã lớn.

Cách tôi khuyên dùng với Drupal và nó không thực sự cụ thể về Drupal: bắt đầu với trình theo dõi vấn đề. Chắc chắn sẽ có báo cáo lỗi cũ, chưa được tiết lộ. Bạn có thể tái tạo chúng? Nếu có, cập nhật vé xác nhận nó. Nếu không, hãy đóng nó xuống. Bạn sẽ tìm thấy cách này rất nhiều cách để sử dụng phần mềm và bạn có thể bắt đầu nhìn trộm vào cơ sở mã nơi nó gặp sự cố. Hoặc bạn có thể bắt đầu bước qua mã và xem cách nó đến nơi nó gặp sự cố. Bằng cách này, bạn sẽ không chỉ bắt đầu hiểu được codebase mà còn tích lũy được rất nhiều nghiệp và câu hỏi của bạn sẽ được cộng đồng chào đón nồng nhiệt.

Một điều quan trọng cần làm là sử dụng công cụ để tạo các biểu đồ phụ thuộc để khám phá kiến ​​trúc mã từ trên xuống. Trước tiên hãy trực quan hóa biểu đồ giữa các cụm hoặc các tệp .NET, điều này sẽ cho bạn ý tưởng về cách tổ chức các tính năng và các lớp, sau đó đào sâu vào các phụ thuộc không gian tên (bên trong một hoặc một vài cụm hoặc các cụm .NET) để có một ý tưởng mã nhỏ hơn cấu trúc và cuối cùng bạn có thể xem xét các phụ thuộc của lớp để hiểu cách tập hợp các lớp cộng tác để thực hiện một tính năng. Có một số công cụ để tạo biểu đồ phụ thuộc, chẳng hạn như NDepend cho .NET , đã tạo ra biểu đồ bên dưới.

Tôi đã từng có một kỹ sư phần mềm khá tuyệt vời nói với tôi rằng hình thức phân tích và bảo trì mã đắt nhất là đi qua mã, từng dòng một; Tất nhiên, chúng tôi là lập trình viên, và điều đó khá nhiều đi kèm với công việc. Phương tiện hạnh phúc, tôi nghĩ là (theo thứ tự này): 1. Lấy một cuốn sổ tay để tạo ghi chú cho cách bạn hiểu mã để làm việc và thêm vào đó khi thời gian trôi qua 2. Tham khảo tài liệu về mã 3. Nói chuyện với các tác giả hoặc những người khác đã hỗ trợ cơ sở mã. Yêu cầu họ "bỏ não" 4. Nếu bạn đến điểm mà bạn hiểu một số mối quan hệ của lớp cấp chi tiết, hãy thực hiện một số bước gỡ lỗi mã để thực hiện một số tổng hợp giữa cách bạn nghĩ mã hoạt động và làm thế nào mã thực sự hoạt động.

Trước tiên hãy hiểu những gì nó có nghĩa là làm - mà không có nghĩa là nó vô nghĩa. Nói chuyện với người dùng, đọc hướng dẫn, bất cứ điều gì.

Sau đó nhấn run và bắt đầu đi bộ mã cho những gì dường như là các chức năng chính.

Phân chia và chinh phục. Tôi nhìn vào từng chức năng và mã liên quan, bước qua chúng và đi tiếp theo, từ từ xây dựng một bức tranh tổng thể.

Nếu dự án có các bài kiểm tra đơn vị, tôi cũng muốn trải qua chúng, chúng luôn rất lộ liễu và khai sáng.

1. Chạy tất cả các bài kiểm tra, nếu bạn có bất kỳ và xem mã nào được bảo hiểm và mã nào không.
2. Nếu mã mà bạn cần thay đổi không được bảo hiểm, hãy thử viết bài kiểm tra để che nó.
3. Thay đổi mã. Đừng phá vỡ các bài kiểm tra.

Xem hiệu quả của Michael Feathers với Bộ luật kế thừa

Đây là danh sách ngắn của tôi:

1. Nếu có thể, hãy nhờ ai đó đưa ra một cái nhìn cấp cao về mã. Những mô hình nào đã được xem xét, những loại quy ước nào tôi có thể mong đợi được nhìn thấy, v.v. để hỏi khi tôi làm việc thông qua hành động của dự án đã có từ trước.

2. Chạy mã và xem (các) hệ thống trông như thế nào. Cấp cho nó có thể có nhiều hơn một vài lỗi, nhưng điều này có thể hữu ích để có được một ý tưởng về những gì nó làm. Đây không phải là về việc thay đổi mã, mà chỉ là xem cách chạy này. Làm thế nào để các phần khác nhau phù hợp với nhau để trở thành một hệ thống tổng thể?

3. Tìm kiếm các bài kiểm tra và các chỉ số khác của tài liệu cơ bản có thể hỗ trợ xây dựng một mô hình tinh thần nội bộ của mã. Đây là nơi tôi có thể đề nghị ít nhất một vài ngày trừ khi có rất ít tài liệu và bài kiểm tra tất nhiên.

4. Làm thế nào để tôi biết các ngôn ngữ và khung được sử dụng trong dự án này? Điều quan trọng ở đây là sự khác biệt giữa việc nhìn vào một số thứ và sẽ, "Vâng, đã thấy rằng hàng chục lần trước đó và biết nó khá rõ" và "Điều gì trên thế giới đang được cố gắng ở đây? Ai nghĩ đây là một ý tưởng tốt?" loại câu hỏi mà trong khi tôi không nói to, tôi sẽ nghĩ chúng đặc biệt là nếu tôi đang xem mã kế thừa có thể khá mong manh và những người đã viết nó không có sẵn hoặc chỉ không nhớ tại sao mọi thứ đã được thực hiện theo cách họ đã được. Đối với các khu vực mới, có thể đáng để dành thêm thời gian để tìm hiểu cấu trúc là gì và tôi có thể tìm thấy các mẫu nào trong mã này.

Cuối cùng nhưng không kém phần quan trọng: Biết những kỳ vọng của những người điều hành dự án về những gì bạn phải làm vào từng thời điểm, đưa ra một vài ý tưởng sau đây về những gì có thể được mong đợi:

• Bạn đang đưa vào các tính năng mới?
• Bạn đang sửa lỗi?
• Bạn đang tái cấu trúc mã? Là những tiêu chuẩn mới đối với bạn hay chúng rất quen thuộc?
• Bạn có phải chỉ cần làm quen với cơ sở mã?

Tôi luôn cố gắng và bắt đầu với điểm vào chương trình, vì tất cả các chương trình đều có một (Ví dụ: phương thức chính, lớp chính, init, v.v.). Điều này sau đó sẽ chỉ cho tôi những gì bắt đầu và đôi khi cách mọi thứ được liên kết.

Sau đó tôi khoan xuống. Cơ sở dữ liệu và DAO được cấu hình ở đâu đó, vì vậy tôi hiểu được cách mọi thứ được lưu trữ. Có lẽ một số loại cá thể toàn cầu cũng được bắt đầu, và ở đó tôi có thể tìm ra những gì đang được lưu trữ. Và với các công cụ khúc xạ tốt, tôi có thể tìm ra ai gọi cái gì.

Sau đó tôi thử và tìm nơi giao diện được cấu hình và xử lý, vì đây là điểm nhập thông tin tiếp theo. Các công cụ khúc xạ, tìm kiếm và gỡ lỗi hỗ trợ tìm kiếm của tôi. Sau đó tôi có thể tìm ra nơi xử lý thông tin bắt đầu và kết thúc, làm việc theo cách của tôi thông qua tất cả các tệp lớp.

Sau đó tôi thử và viết dòng chảy xuống một số giấy, chỉ để ban đầu quấn lấy đầu tôi. Nút gửi được chuyển đến xác minh chung sau đó được chuyển đến DAO hoặc cơ sở dữ liệu và sau đó được lưu trữ trong cơ sở dữ liệu. Đây là một sự đơn giản hóa quá mức của hầu hết các ứng dụng, nhưng đó là ý tưởng chung. Bút và giấy cực kỳ hữu ích ở đây, vì bạn có thể ghi lại mọi thứ một cách nhanh chóng và không phải lo lắng về định dạng trong một chương trình được cho là sẽ giúp bạn.

Tôi sẽ nói bắt đầu với tài liệu, v.v., nhưng theo kinh nghiệm của tôi, độ sâu của tài liệu và kiến ​​thức địa phương thường tỷ lệ nghịch với tuổi, kích thước và độ phức tạp của một hệ thống.

Điều đó đang được nói, tôi thường cố gắng xác định một vài chủ đề chức năng. Theo chức năng, ý tôi là những thứ như đăng nhập, kéo xuống danh sách khách hàng, v.v ... Nếu các mẫu nhất quán, một chủ đề sẽ cung cấp cho bạn một mặt cắt ngang đẹp, không nhất thiết phải hoàn chỉnh của hệ thống. Cách tốt nhất để xác định xem các mẫu có nhất quán hay không là phân tích một số chuỗi.

Tôi nghĩ rằng điều này không cần phải nói, nhưng theo tôi, tốt hơn là hiểu hệ thống từ góc độ chức năng hơn là từ góc độ kỹ thuật. Tôi thường không lo lắng quá nhiều về các công cụ đang được sử dụng (ORM, thư viện ghi nhật ký, v.v.) và tập trung nhiều hơn vào các mẫu (MVP, v.v.) đang được sử dụng. Theo kinh nghiệm của tôi, các công cụ thường trôi chảy hơn theo mô hình đó.

Tôi đã làm rất nhiều ...

Đây là cách tiếp cận hiện tại của tôi cho các tình huống khi có "một cái gì đó hoạt động" và bạn cần làm cho nó "hoạt động theo một cách khác".

1. Nhận mục tiêu, hệ thống đó sẽ giải quyết (nếu chúng không được viết) - viết nó. Hỏi người quản lý, nhân viên khác, thậm chí trước đây nếu họ có sẵn. Hỏi khách hàng hoặc tìm kiếm bất kỳ phần của tài liệu.
2. Nhận cụ thể. Nếu nó không tồn tại - viết nó. Không đáng để hỏi ai đó về điều đó, vì nếu nó không tồn tại, thì bạn sẽ rơi vào tình huống khi người khác không quan tâm nhiều. Vì vậy, cách duy nhất để viết riêng (sau này sẽ dễ dàng hơn nhiều để tham khảo nó).
3. Nhận thiết kế. Không tồn tại - viết nó. Cố gắng tham khảo bất kỳ tài liệu và mã nguồn càng nhiều càng tốt.
4. Viết thiết kế chi tiết đến một phần mà bạn cần thay đổi.
5. Xác định cách bạn kiểm tra nó. Vì vậy, bạn có thể chắc chắn rằng mã cũ và mới hoạt động theo cùng một cách.
6. làm cho hệ thống có thể được xây dựng trong một bước. Và kiểm tra với mã cũ. Đặt nó vào SVC nếu nó chưa có.
7. Thực hiện thay đổi. Không sớm hơn.
8. xác minh sau một tháng hoặc lâu hơn, không có gì bị hỏng.

Thêm một việc cần làm tùy chọn có thể yêu cầu giữa mỗi bước: f off manager (chủ dự án), người nói với bạn rằng "những thay đổi này nên được thực hiện vào ngày hôm qua". Sau một vài dự án, anh ta thậm chí có thể bắt đầu giúp đỡ để có được thông số kỹ thuật và tài liệu trước.

Nhưng thông thường (đặc biệt là đối với các tập lệnh), không thể thực hiện được trong phạm vi kinh doanh (chi phí sẽ quá cao, trong khi giá trị sẽ thấp). Một lựa chọn là không thực hiện bất kỳ thay đổi nào, cho đến khi đạt được khối lượng quan trọng và hệ thống sẽ ngừng sản xuất (ví dụ: hệ thống mới sẽ đến) hoặc ban quản lý quyết định rằng tất cả những điều này là đáng làm.

PS: Tôi nhớ một mã được sử dụng cho 5 khách hàng với các cài đặt khác nhau. Và mỗi thay đổi (tính năng mới) được yêu cầu nghĩ đến "phần nào được sử dụng" và "khách hàng có cấu hình gì" để không phanh bất cứ điều gì và không sao chép mã. Đặt cài đặt của họ vào cvs dự án và viết thông số kỹ thuật, giảm thời gian suy nghĩ này xuống gần như bằng 0.

In mã nguồn và bắt đầu đọc qua nó. Nếu nó đặc biệt lớn, chỉ in ra các phần được chọn của nó để hiểu rõ hơn về nó và tạo ra nhiều ghi chú / nhận xét mà bạn cần.

Theo dõi chương trình bắt đầu từ khi bắt đầu thực hiện. Nếu bạn được gán cho một phần cụ thể của cơ sở mã, hãy theo dõi việc thực thi trong phần đó và tìm ra cấu trúc dữ liệu nào được sử dụng.

Nếu bạn đang sử dụng ngôn ngữ hướng đối tượng, hãy thử tạo một sơ đồ lớp chung. Điều này sẽ cung cấp cho bạn một cái nhìn tổng quan cấp cao tốt.

Thật không may, cuối cùng, bạn sẽ phải đọc qua càng nhiều mã càng tốt. Nếu bạn may mắn, các lập trình viên trước đó đã viết càng nhiều tài liệu càng tốt để giúp bạn hiểu những gì đang diễn ra.

Điều đầu tiên bạn cần làm khi học một cơ sở mã mới là tìm hiểu về những gì nó phải làm, cách sử dụng và cách sử dụng nó. Sau đó bắt đầu xem tài liệu kiến ​​trúc để tìm hiểu cách đặt mã, cũng xem cách cơ sở dữ liệu tại thời điểm này. Đồng thời bạn đang học kiến ​​trúc là thời điểm tốt để xem xét bất kỳ luồng quy trình hoặc sử dụng tài liệu trường hợp. sau đó bắt đầu đi sâu vào và đọc mã sau khi bạn hiểu về bức tranh lớn, nhưng chỉ có mã liên quan đến bất kỳ công việc nào bạn có thể làm với mã này, đừng cố đọc tất cả mã. Điều quan trọng hơn là phải biết mã ở đâu để làm X hơn chính xác cách X được thực hiện, mã luôn ở đó để cho bạn biết làm thế nào nếu bạn có thể tìm thấy nó.

Tôi thấy rằng chỉ cần cố gắng nhảy vào và đọc mã mà không có mục tiêu ngoài việc học mã nói chung là không hiệu quả, cố gắng tự thay đổi nhỏ hoặc xem lại mã thay đổi của người khác là cách sử dụng thời gian hiệu quả hơn nhiều.

Nếu một cơ sở mã lớn, thì hãy tập trung sự chú ý của bạn vào các phần hiện đang làm việc. Nếu không, bạn sẽ cảm thấy choáng ngợp và có thể đầu bạn có thể nổ tung. Tôi nghĩ rằng một số tổng quan cấp cao là hữu ích (nếu nó có sẵn), nhưng rất có thể bạn sẽ dành nhiều thời gian cho trình gỡ lỗi để theo dòng chương trình. Đó là một ý tưởng tốt để có được một cái nhìn tổng quan về ứng dụng và thấy nó được sử dụng, vì vậy bạn có thể hiểu làm thế nào / cái gì / tại sao mã được sử dụng cho.

Tôi thường chạy một số loại công cụ phức tạp mã trên mã để cho tôi biết các khu vực có vấn đề. Các khu vực có điểm cao có lẽ rất khó cập nhật. Ví dụ, tôi chạy vào một chức năng đạt 450 trên thang đo chu kỳ. Chắc chắn, hàng trăm IF. Rất khó để duy trì hoặc thay đổi điều đó. Vì vậy, hãy chuẩn bị cho điều tồi tệ nhất.

Ngoài ra, đừng ngại đặt câu hỏi cho các nhà phát triển hiện tại, đặc biệt nếu họ làm việc trên hệ thống. Giữ suy nghĩ nội bộ của bạn và tập trung vào giải quyết các vấn đề. Tránh những bình luận có thể khiến các nhà phát triển khác trở nên buồn bã. Rốt cuộc, nó có thể là em bé của họ và không ai thích được nói rằng em bé xấu xí hơn.

Thực hiện các bước nhỏ, ngay cả thay đổi mã nhỏ nhất cũng có thể có tác động lớn.

Tôi thấy thật hữu ích khi đưa ra các luồng mã chương trình vì vậy nếu tôi đang thực hiện thay đổi, tôi có thể thực hiện tìm kiếm phụ thuộc để xem phương thức / hàm nào gọi là gì. Giả sử tôi đang thay đổi phương pháp C.

Nếu chỉ có 1 phương thức / hàm gọi C, thì đó là một thay đổi khá an toàn. Nếu 100 phương thức / hàm gọi C, thì nó sẽ có tác động lớn hơn.

Hy vọng rằng cơ sở mã của bạn được kiến ​​trúc, viết và duy trì tốt. Nếu vậy, sẽ mất một thời gian để hiểu nó nhưng cuối cùng thủy triều sẽ biến.

Nếu nó là một quả bóng bùn lớn, bạn có thể không bao giờ hiểu (hoặc muốn hiểu) hoạt động bên trong của nó.

Một số điều tôi làm ...

1) Sử dụng một công cụ phân tích nguồn như Giám sát nguồn để xác định các kích thước mô-đun khác nhau, số liệu phức tạp, v.v. để cảm nhận về dự án và giúp xác định các khu vực không tầm thường.

2) Đi sâu vào mã từ trên xuống dưới trong Eclipse (tốt để có một trình soạn thảo có thể duyệt các tài liệu tham khảo, v.v.) cho đến khi tôi biết được điều gì đang xảy ra và ở đâu trong cơ sở mã.

3) Thỉnh thoảng, tôi vẽ sơ đồ trong Visio để có được hình ảnh tốt hơn về kiến ​​trúc. Điều này có thể hữu ích cho những người khác trong dự án là tốt.

Điều này xảy ra rất nhiều. Cho đến khi tôi bắt đầu làm việc trên một nền tảng nguồn mở, tôi không nghĩ rằng mình đã từng bắt đầu một công việc không bắt đầu với một sự thừa nhận rằng mã có một số 'quirks'.

Bạn có thể đi một chặng đường dài với trình gỡ lỗi từng bước và rất nhiều sự kiên trì. Thật không may, thường phải mất thời gian và kinh nghiệm để học một quả bóng bùn lớn đặc biệt và thậm chí sau nhiều năm vẫn có thể có một hệ thống con nào đó mọc lên mà không ai có kiến ​​thức về nó.

Tôi khuyến khích bạn viết bài kiểm tra đơn vị trước khi bạn thay đổi bất cứ điều gì trong bóng bùn. Và chỉ thay đổi đủ mã tại thời điểm để làm cho các bài kiểm tra vượt qua. Khi bạn tái cấu trúc, hãy thêm các bài kiểm tra đơn vị trước khi bàn tay để bạn biết rằng chức năng kinh doanh đã không bị phá vỡ bằng cách tái cấu trúc.

Là lập trình cặp là một lựa chọn? Có một người khác để đưa ra ý tưởng là một ý tưởng tuyệt vời để đối phó với số lượng khó chịu đó.

Đây là một thủ tục chúng tôi sử dụng để loại bỏ trùng lặp.

• chọn một tiền tố nhận xét tiêu chuẩn cho các mục trùng lặp (chúng tôi sử dụng [dupe]ngay sau điểm đánh dấu nhận xét;
• viết thông số kỹ thuật với các nhóm của bạn về tên để sử dụng cho quy trình trùng lặp;
• vòng đầu tiên: mọi người lấy một số tệp và thêm [dupe][procedure_arbitrary_name]trước khi thủ tục trùng lặp;
• Vòng thứ hai: mọi người thực hiện một thủ tục hoặc một tập hợp con của thủ tục và gán một giá trị cho biết thứ tự khả năng của các triển khai cùng mục đích khác nhau (chuỗi sẽ là [dupe][procedure_arbitrary_name][n]:);
• vòng thứ ba: chịu trách nhiệm cho mỗi thủ tục viết lại nó trong lớp có liên quan;
• vòng bốn: grephạnh phúc!

Tôi nghĩ một trong những điều quan trọng nhất là có một tính năng đơn giản, chọn cách đơn giản nhất bạn có thể nghĩ và thực hiện nó. Nếu có một danh sách mong muốn được duy trì, hãy sử dụng hoặc nói chuyện với ai đó quen thuộc với cơ sở mã và yêu cầu họ đề xuất một tính năng. Thông thường tôi sẽ mong đợi điều này sẽ thay đổi với 5 ~ 20 LỘC. Điểm quan trọng không phải là bạn đang thêm một tính năng rất lạ mắt mà là bạn đang làm việc (hay đúng hơn là vật lộn :)) với cơ sở mã và trải qua toàn bộ quy trình làm việc. Bạn sẽ phải

1. Đọc mã để hiểu thành phần mà bạn đang sửa đổi
2. Thay đổi mã và hiểu làm thế nào mà tác động đến hệ thống xung quanh.
3. Kiểm tra sự thay đổi và do đó xác định cách các thành phần tương tác với nhau
4. Viết trường hợp thử nghiệm và hy vọng phá vỡ một hoặc hai trường hợp thử nghiệm để bạn có thể sửa chúng và hiểu các bất biến của hệ thống.
5. Xây dựng điều hoặc xem CI xây dựng nó và sau đó vận chuyển nó

Danh sách này tiếp tục nhưng điểm là một dự án nhỏ như thế này sẽ đưa bạn qua tất cả các mục trong danh sách kiểm tra của bạn để làm quen với một hệ thống và cũng dẫn đến thay đổi năng suất được thực hiện.

Một điều nhỏ tôi muốn thêm:

Một công cụ mà tôi đã bắt đầu sử dụng gần đây cho loại vấn đề này đã giúp ích rất nhiều là lập bản đồ tư duy. Thay vì cố gắng nhồi nhét tất cả các chi tiết về cách thực hiện một cái gì đó trong đầu, tôi sẽ xây dựng một sơ đồ tư duy mô tả cách hệ thống tôi đang trải qua hoạt động. Nó thực sự giúp tôi hiểu sâu sắc hơn những gì đang diễn ra và những gì tôi vẫn cần phải tìm ra. Nó cũng giúp tôi theo dõi những gì tôi cần thay đổi ở quy mô rất chính xác.

Tôi khuyên bạn nên sử dụng máy bay miễn phí trong số rất nhiều lựa chọn bản đồ tư duy.

Sẽ không có bất kỳ tài liệu nào hoặc sẽ có tài liệu ít ỏi, hoặc nó sẽ hết hạn. Tìm tất cả các tài liệu tồn tại. Nếu nó nằm trong kho lưu trữ nhóm, đừng tạo một bản sao. Nếu không, hãy đặt nó ở đó và yêu cầu người quản lý của bạn cho phép tổ chức nó, có thể với một số giám sát.

Nhận mọi thứ vào kho lưu trữ cho nhóm và thêm Thuật ngữ. Tất cả các cơ sở có biệt ngữ; tài liệu nó trong bảng chú giải. Tạo các phần cho các công cụ, sản phẩm, khách hàng cụ thể, vv

Tạo / Cập nhật tài liệu tạo môi trường phần mềm. Tất cả các công cụ, quirks, cài đặt lựa chọn, vv đi vào đây.

Sau đó tải lên tài liệu Bắt đầu với "Tên sản phẩm" hoặc tương tự. Hãy để nó chỉ là dòng chảy tâm trí và tự tổ chức theo thời gian. Sau đó đi qua các tài liệu lỗi thời và đưa chúng trở lại ngày. Các nhà phát triển khác sẽ đánh giá cao nó, bạn sẽ đóng góp theo cách độc đáo trong khi học mã. Đặc biệt là ghi lại tất cả những thứ như vậy làm bạn bối rối hoặc bị đặt tên sai hoặc phản trực giác.

Khi đường cong nghiêng của bạn sắp kết thúc, đừng lo lắng về việc cập nhật tài liệu. Hãy để anh chàng mới tiếp theo làm điều đó. Khi anh ấy đến, chỉ cho anh ấy làm việc của bạn. Khi anh ta liên tục làm phiền bạn để trả lời, đừng trả lời anh ta. Thay vào đó, hãy thêm câu hỏi vào tài liệu của bạn và sau đó đưa cho anh ta url. Cần câu cá.

Một tác dụng phụ là bạn sẽ tạo ra một công cụ mà chính bạn có thể tham khảo hàng tháng kể từ bây giờ khi bạn quên.

Và mặc dù nó không phải là tài liệu, một vấn đề liên quan là tất cả các thủ tục nhỏ, chuyên sâu thủ công mà các đồng đội của bạn làm. Tự động hóa chúng với các lô, tập lệnh sql và tương tự, và chia sẻ chúng. Xét cho cùng, kiến ​​thức về thủ tục được cho là lớn như kiến ​​thức khai báo về mặt làm việc hiệu quả trong một môi trường mới. Dù đó là gì, đừng làm điều đó; đúng hơn, kịch bản nó, và chạy kịch bản. Cào cá lại đình công.

Tôi đã viết một bài viết khá dài về chủ đề này. Đây là một đoạn trích

Tôi đã nghĩ về vấn đề này trong một thời gian khá lâu. Tôi quyết định viết ra giải pháp cá nhân của riêng tôi như là một quá trình chung. Các bước tôi đã ghi lại như sau:

1. Tạo bảng từ vựng
2. Tìm hiểu ứng dụng
3. Duyệt tài liệu có sẵn
4. Giả định
5. Xác định vị trí thư viện của bên thứ ba
6. Mã phân tích

Quá trình này được viết trong ngữ cảnh của một ứng dụng máy tính để bàn lớn, nhưng các kỹ thuật chung vẫn có thể áp dụng cho các ứng dụng web và các mô-đun nhỏ hơn.

lấy từ: Một quá trình học tập một Codebase mới

Có một vài lời khuyên nhỏ tôi có thể chia sẻ.

Đối với một sản phẩm hiện có, tôi bắt đầu thử nghiệm chúng chuyên sâu. Nếu chọn / nhận nhiệm vụ, tôi sẽ tập trung vào tính năng cụ thể hơn.

• Bước tiếp theo sẽ là tìm mã nơi tôi có thể đột nhập và bắt đầu khám phá Trên đường đi, tôi sẽ tìm thấy các mô-đun, thư viện, khung công tác, v.v.

• Bước tiếp theo sẽ là tạo sơ đồ lớp đơn giản với trách nhiệm của nó (Giống như thẻ CRC)

• Bắt đầu thực hiện các thay đổi nhỏ hoặc khắc phục các lỗi nhỏ để khắc phục và cam kết. Vì vậy, chúng ta có thể tìm hiểu luồng công việc của dự án; Không chỉ là mã. Thông thường các sản phẩm lớn sẽ có một số loại giữ sách vì mục đích ủy quyền và kiểm toán (ví dụ: các dự án chăm sóc sức khỏe)

• Nói chuyện với những người đã làm việc trong dự án. Thể hiện ý tưởng, suy nghĩ của bạn và đổi lại nhận được kinh nghiệm và quan điểm của họ khi làm việc với dự án này trong thời gian dài. Điều này khá quan trọng vì điều đó cũng giúp bạn hòa nhập tốt với nhóm.

Đã lâu lắm rồi tôi mới phải tự mình đi sâu vào một cơ sở mã lớn. Nhưng trong vài năm gần đây, tôi đã cố gắng nhiều lần để đưa các nhà phát triển mới vào các nhóm nơi chúng tôi có một cơ sở mã hiện có, khá lớn.

Và phương pháp mà chúng tôi đã sử dụng thành công, và tôi muốn nói là cách hiệu quả nhất mà không cần hỏi IMHO, là lập trình cặp.

Trong 12 tháng qua, chúng tôi đã có 4 thành viên mới vào nhóm và mỗi lần, thành viên mới sẽ kết hợp với một thành viên khác làm quen với cơ sở mã. Ban đầu, thành viên nhóm lớn tuổi hơn sẽ có bàn phím. Sau khoảng 30 phút, chúng tôi sẽ chuyển bàn phím cho thành viên mới, người sẽ làm việc dưới sự hướng dẫn của thành viên nhóm cũ.

Quá trình này đã được chứng minh là khá thành công.