Thực tiễn tốt nhất để bàn giao mã di sản

Trong một vài tháng, một đồng nghiệp sẽ chuyển sang một dự án mới và tôi sẽ kế thừa một trong những dự án của anh ấy. Để chuẩn bị, tôi đã đặt hàng hiệu quả của Michael Feathers với Legacy Code .

Nhưng cuốn sách này cũng như hầu hết các câu hỏi về mã kế thừa mà tôi tìm thấy cho đến nay đều quan tâm đến trường hợp kế thừa mã như vốn có. Nhưng trong trường hợp này tôi thực sự có quyền truy cập vào nhà phát triển ban đầu và chúng tôi có một thời gian để bàn giao có trật tự.

Một số nền tảng về đoạn mã tôi sẽ kế thừa:

• Chức năng của nó: Không có lỗi nào được biết đến, nhưng khi các yêu cầu về hiệu suất tiếp tục tăng lên, một số tối ưu hóa sẽ trở nên cần thiết trong tương lai không xa.
• Không có giấy tờ: Có khá nhiều tài liệu không ở cấp độ phương thức và lớp. Mặc dù vậy, những gì mã được cho là sẽ làm ở mức cao hơn, được hiểu rõ, bởi vì tôi đã viết chống lại API của nó (dưới dạng hộp đen) trong nhiều năm.
• Chỉ các thử nghiệm tích hợp cấp cao hơn: Chỉ có các thử nghiệm tích hợp thử nghiệm tương tác thích hợp với các thành phần khác thông qua API (một lần nữa, hộp đen).
• Mức rất thấp, được tối ưu hóa cho tốc độ: Vì mã này là trung tâm của toàn bộ hệ thống ứng dụng, rất nhiều trong số đó đã được tối ưu hóa nhiều lần trong nhiều năm và cực kỳ thấp (một phần có trình quản lý bộ nhớ riêng cho các cấu trúc nhất định /Hồ sơ).
• Đồng thời và không khóa: Mặc dù tôi rất quen thuộc với lập trình đồng thời và không khóa và thực sự đã đóng góp một vài phần cho mã này, nhưng điều này lại thêm một lớp phức tạp khác.
• Codebase lớn: Dự án cụ thể này có hơn mười nghìn dòng mã, vì vậy không có cách nào tôi có thể giải thích mọi thứ cho tôi.
• Viết bằng Delphi: Tôi sẽ chỉ đưa vấn đề này ra ngoài, mặc dù tôi không tin ngôn ngữ này là nguyên nhân của câu hỏi, vì tôi tin rằng loại vấn đề này là bất khả tri về ngôn ngữ.

Tôi đã tự hỏi làm thế nào thời gian cho đến khi khởi hành của anh ấy sẽ được dành tốt nhất. Dưới đây là một vài ý tưởng:

• Nhận mọi thứ để xây dựng trên máy của tôi: Mặc dù mọi thứ nên được kiểm tra trong kiểm soát mã nguồn, người đã không quên kiểm tra tệp một lần, vì vậy đây có lẽ nên là đơn hàng đầu tiên của doanh nghiệp.
• Kiểm tra thêm: Mặc dù tôi muốn có nhiều bài kiểm tra đơn vị cấp lớp hơn để khi tôi thực hiện thay đổi, bất kỳ lỗi nào tôi giới thiệu đều có thể được phát hiện sớm, mã hiện tại không thể kiểm tra được (các lớp lớn, phương thức dài, quá nhiều phụ thuộc lẫn nhau).
• Tài liệu gì: Tôi nghĩ cho người mới bắt đầu, tốt nhất nên tập trung tài liệu vào các khu vực trong mã mà nếu không khó hiểu, ví dụ như vì tính chất được tối ưu hóa / mức độ tối ưu cao của chúng. Tôi e rằng có một vài thứ trong đó có thể trông xấu xí và cần tái cấu trúc / viết lại, nhưng thực sự là những tối ưu hóa đã xuất hiện ở đó vì một lý do chính đáng mà tôi có thể bỏ lỡ (xem Joel Spolsky, Things You Should Không bao giờ làm, Phần I )
• Cách viết tài liệu: Tôi nghĩ rằng một số sơ đồ lớp của kiến ​​trúc và sơ đồ trình tự của các chức năng quan trọng kèm theo một số văn xuôi sẽ là tốt nhất.
• Ai là tài liệu: Tôi đã tự hỏi điều gì sẽ tốt hơn, để anh ấy viết tài liệu hoặc để anh ấy giải thích cho tôi, để tôi có thể viết tài liệu. Tôi sợ, rằng những điều rõ ràng với anh ta nhưng không phải tôi sẽ không được bảo hiểm đúng cách.
• Tái cấu trúc bằng cách sử dụng lập trình cặp: Điều này có thể không thực hiện được do hạn chế về thời gian, nhưng có lẽ tôi có thể cấu trúc lại một số mã của anh ta để làm cho nó dễ bảo trì hơn trong khi anh ta vẫn ở đó để cung cấp đầu vào về lý do tại sao mọi thứ lại như vậy.

Hãy bình luận và thêm vào này. Vì không có đủ thời gian để làm tất cả những điều này, tôi đặc biệt quan tâm đến việc bạn sẽ ưu tiên như thế nào.

Cập nhật: Khi dự án bàn giao kết thúc, tôi đã mở rộng danh sách này bằng những kinh nghiệm của riêng tôi trong câu trả lời dưới đây .

Khi bạn có quyền truy cập vào nhà phát triển, bạn hãy hỏi: -

• Những mô-đun nào là khó khăn nhất để mã / thực hiện. Vấn đề là gì và chúng đã được khắc phục như thế nào.

• Những mô-đun đã tạo ra nhiều lỗi nhất.

• Những mô-đun đã dẫn đến khó khăn nhất để giải quyết lỗi.

• Những bit mã nào anh ấy tự hào nhất.

• Những đoạn mã nào anh ta thực sự muốn cấu trúc lại, nhưng, không có thời gian.

Những câu hỏi này sẽ cung cấp cho bạn cái nhìn sâu sắc về những gì sẽ gây ra cho bạn nhiều vấn đề nhất, và, có lẽ quan trọng hơn là xử lý các quá trình suy nghĩ và quan điểm của nhà phát triển ban đầu.

Khi dự án bàn giao đã kết thúc, tôi nghĩ rằng tôi sẽ dành thời gian và viết lên câu trả lời của riêng mình chứa những điều phù hợp nhất với tôi.

• Nhận mọi thứ dưới sự kiểm soát phiên bản: Sau khi đảm bảo mọi thứ tôi cần để xây dựng đều nằm dưới sự kiểm soát phiên bản, tôi cũng đã tìm kiếm trên ổ cứng của nhà phát triển cũ, để tìm kiếm các tập lệnh hoặc tiện ích bổ sung hữu ích để triển khai và / hoặc thử nghiệm ứng dụng nhưng Đã kiểm tra.
• Từ trên xuống: Tôi sẽ bắt đầu với một cái nhìn cao cấp về các lớp học chính và một chuyến tham quan có hướng dẫn với nhà phát triển cũ của các khu vực chính. Sau đó, tôi sẽ tự đào sâu hơn vào phần còn lại, gắn cờ những thứ không có ý nghĩa với tôi bằng //TODOcác điểm đánh dấu.
• Tự viết tất cả tài liệu: Trong khi tôi có nhà phát triển cũ xem qua bài viết của mình để đảm bảo rằng tôi đã hiểu đúng, tôi vẫn khăng khăng tự viết mọi thứ. Bằng cách này, tôi chắc chắn rằng văn bản có ý nghĩa với tôi và không chỉ nhà phát triển cũ.
• Nhận xét ở mọi nơi: Tôi đã thêm các tóm tắt tài liệu XML cho mọi lớp và mọi phương thức. Bằng cách này, tôi chắc chắn rằng mình đã xem xét ít nhất mọi đoạn mã và có đủ sự hiểu biết để tóm tắt những gì nó đã làm trong một câu. Nó cũng giúp việc hiểu các phương thức sử dụng các phương thức / lớp tóm tắt dễ dàng hơn khi IntelliSense tiếp nhận thông tin này. Tôi cũng có thể dễ dàng xác định các khu vực của mã mà tôi vẫn phải xem xét.
• Tài liệu gần với nguồn: Để giúp kết nối giữa mã nguồn và tài liệu dễ dàng hơn, tôi đặt hầu hết tài liệu của mình ngay trong mã nguồn. Đối với tài liệu cấp cao mô tả sự tương tác giữa các hệ thống phụ khác nhau, tôi đã sử dụng wiki, vì việc đưa thông tin này vào một nơi duy nhất trong mã không hoạt động. Tất cả các thông tin phải là điện tử và có thể tìm kiếm toàn văn.
• Sơ đồ: Để có cái nhìn tổng quan cơ bản, tôi đã sử dụng các sơ đồ lớp có độ chi tiết khác nhau cho các hệ thống con khác nhau. Đối với các phần đồng thời, đối tượng và sơ đồ tương tác đã thực sự hữu ích; xem thêm câu hỏi khác của tôi về chủ đề này .
• Tái cấu trúc thành một cặp: Trong khi tôi thực hiện tái cấu trúc với nhà phát triển cũ để cảm nhận mã và làm cho mọi thứ dễ bảo trì hơn, đây là một quá trình tốn thời gian và cũng đầy rủi ro, vì thiếu công cụ tái cấu trúc tốt và một loạt các công cụ khó chịu phụ thuộc giữa các bộ phận khác nhau. Hoạt động hiệu quả của Michael Feathers với Legacy Code là một trợ giúp thực sự tốt cho việc này, mặc dù việc tái cấu trúc mà không có sự hỗ trợ công cụ phù hợp vẫn còn đau đớn. Trong khi tái cấu trúc, tôi sẽ cho anh ta điều khiển chuột và bàn phím, vì điều đó thú vị hơn với anh ta (xem thêm điểm đạn cuối cùng của tôi) và tôi được tự do viết ra những gì tôi đang học.
• Đăng ký riêng để nhận xét và thay đổi: Sau khi tôi vô tình đưa ra lỗi bằng cách viết nhận xét qua một override, tôi đã cẩn thận để nhận xét và thay đổi trong các lần đăng ký riêng. Tôi đã sử dụng một tiện ích nhỏ để loại bỏ tất cả các nhận xét từ mã nguồn trước khi kiểm tra một cái gì đó, vì vậy một khác biệt của một đăng ký chỉ nhận xét sẽ hiển thị 0 sự khác biệt. Tất cả các thay đổi (ví dụ: loại bỏ các trường không sử dụng) đã được xem xét cẩn thận với nhà phát triển cũ để đảm bảo tôi không xóa những thứ vẫn cần thiết.
• Từng dòng từng bước của các đoạn quan trọng: Đối với các đoạn được tối ưu hóa / phức tạp nhất, tôi sẽ đi qua từng đoạn mã với nhà phát triển cũ và đôi khi ngay cả với một đồng nghiệp thứ ba. Bằng cách này, tôi đã hiểu rõ về mã và khi nhiều người xem xét mã hơn, chúng tôi thực sự đã xác định được một vài lỗi cũng như một số điều có thể được tối ưu hóa hơn nữa.
• Hãy nhanh chóng và giữ cho nhà phát triển cũ có động lực: Tôi nhận thấy rằng nhà phát triển cũ ngày càng ít quan tâm hơn vì ngày cuối cùng của anh ta đang đến gần hơn (không đáng ngạc nhiên). Do đó, tôi sẽ đảm bảo các phần quan trọng nhất đã được bàn giao trước, phần còn lại để tôi tự mình tìm ra, nếu cần thiết. Tôi cũng đã cố gắng để lại những điều thú vị hơn (ví dụ như điều khiển bàn phím khi lập trình cặp) cho anh ấy và làm những việc nhàm chán như tự viết tài liệu.
• Xác định các yêu cầu tính năng: Tôi thấy hữu ích khi hỏi nhà phát triển cũ về danh sách các tính năng mà mọi người đã yêu cầu nhưng chưa được thêm. Có một vài điều mà đối với tôi có vẻ đơn giản để thêm vào, nhưng ở đó có một lý do chính đáng mà họ không thêm vào vì họ sẽ phá vỡ những thứ khác khi thực hiện theo cách mà tôi đã nghĩ lúc đầu.

Đã từng ở trong một tình huống tương tự, tôi tin rằng những điều sau đây cũng sẽ được xem xét:

• Hãy chắc chắn rằng bạn có thể thực hiện và kiểm tra việc triển khai: Tự triển khai sản phẩm của mình từ đầu - và xác minh rằng việc này giống hệt với việc thực hiện bởi người đã rời đi. Điều này sẽ đảm bảo rằng bất kỳ tập lệnh và hướng dẫn nào đều rõ ràng đối với bạn và sẽ nắm bắt mọi sự cố tình cờ như các thành phần chưa được kiểm tra trong hệ thống kiểm soát phiên bản của bạn. (Tôi không nói rằng điều này sẽ xảy ra, chỉ là nếu nó đã xảy ra, việc giải quyết bây giờ sẽ dễ dàng hơn rất nhiều, trước khi người đó rời đi)

  (Điều này có thể không phù hợp với bạn, ví dụ: nếu bạn đã thực hiện Tích hợp liên tục hoặc Triển khai liên tục, nhưng nó đáng được đề cập, chỉ trong trường hợp ...)

• Viết thêm bài kiểm tra: Đây là một cách thực sự tốt để kiểm tra sự hiểu biết của bạn về một hệ thống. Nó sẽ cho phép (hoặc buộc) bạn xem xét kỹ hơn các khu vực của mã và sẽ xác nhận rằng mã đó không có lỗi như bạn nghi ngờ, hoặc sẽ tiết lộ các khu vực mà bạn nghĩ bạn hiểu ý định, nhưng thực ra đó là bạn cần phải hỏi đồng nghiệp của bạn để làm rõ trước khi anh ta rời đi

• Viết cặp tài liệu: Đây là một cách hiệu quả để viết tổng quan. Tôi đề nghị bạn nên nhờ đồng nghiệp của mình mô tả một tính năng hoặc khu vực, sau đó bạn viết nó lên, trong tài liệu, bằng từ ngữ của riêng bạn. Chúng tôi thấy việc này dễ dàng hơn khi được thực hiện bởi hai người với nhau.

Cá nhân tôi muốn viết bài kiểm tra là ưu tiên cao hơn so với viết tài liệu, vì các bài kiểm tra có thể sẽ giúp bạn hiểu hơn - hoặc vững chắc hơn.

Về Tái cấu trúc bằng cách sử dụng lập trình cặp , điều duy nhất tôi muốn nói là có một mối nguy hiểm rằng điều này có thể trở thành một cái hố không đáy, đặc biệt là bạn đã nói rằng bạn chỉ có các bài kiểm tra cấp cao. Bạn có thể thấy nó kết thúc bằng cách sử dụng nhiều thời gian có sẵn hơn bạn dự định.

+1 cho câu trả lời bạn đã có trong câu hỏi của bạn!

Chuyến tham quan có hướng dẫn
10k dòng mã là rất nhiều, nhưng tôi nghĩ vẫn không thể để anh chàng kia đưa cho bạn một 'chuyến tham quan có hướng dẫn'. Bạn ngồi xuống cùng nhau trước mã và anh ấy đưa bạn vào một chuyến đi từ trên xuống dưới, làm việc xuống 'lớp'. Bạn cần phải làm điều đó trong những đợt ngắn - tất cả trong một lần sẽ giết cả hai bạn.

Phóng to, thu nhỏ
Ưu điểm của việc này là trong khi anh ta giải thích cho bạn, anh ta gần như chắc chắn sẽ có một số khoảnh khắc "ồ, vâng, đây cũng là" mà anh ta có thể không làm nếu anh ta chỉ cố gắng ghi lại trên quan điểm của anh ấy. Và câu hỏi của bạn sẽ giúp tập trung vào các bit rõ ràng với anh ấy nhưng không phải với bất kỳ ai khác. Kiểu tương tác phóng to / thu nhỏ này chỉ có thể thực hiện được một lần, cố gắng viết hoặc đọc một cái gì đó như thế là khó sử dụng.

Tài liệu
Tôi nghĩ rằng cả hai bạn nên độc lập tài liệu công cụ - anh ấy nên bắt đầu ở phía dưới (trong trường hợp bạn không có thời gian để đến đó cùng nhau), và bạn nên bắt đầu ở trên cùng, trên cơ sở những gì bạn đã hiểu về chuyến tham quan có hướng dẫn của anh ấy và như thể nó dành cho người khác [trong một công việc trước đây, tôi đã thừa hưởng một tải mã 'di sản' và chỉ có thời gian để ghi lại nó trước khi rời khỏi mình :)].

Ở đâu
Mục đích của hầu hết điều này là để bạn có thể cảm nhận được nơi xảy ra. Vì vậy, với một lỗi hoặc sửa đổi cụ thể, bạn có thể nhanh chóng tìm thấy vị trí trong mã mà bạn cần tập trung vào. Bạn có thể tự kiểm tra bằng cách lấy danh sách các lỗi cũ và xem liệu bạn có thể dự đoán chính xác vấn đề ở đâu không.

Bơm cho anh ta khô ráo
Không có vấn đề gì nếu cuối cùng anh ta ghét bạn (cười), công việc của bạn là lấy càng nhiều thông tin ra khỏi não của anh chàng đó càng tốt trong thời gian có sẵn. Hãy chắc chắn rằng bạn có được sự quản lý từ phía bạn và họ ưu tiên chuyển giao kiến ​​thức hơn "chỉ sửa một vài lỗi cuối cùng trước khi anh ấy rời đi" (trừ khi bạn sửa chúng cùng nhau ...).

Tôi đề nghị những điều sau đây (ngoài những gì đã được xác định) - Trước tiên, hãy yêu cầu người quản lý của bạn cho bạn thời gian để làm việc với anh chàng này càng nhiều càng tốt và cố gắng ngồi với anh ta bất cứ khi nào anh ta được giao nhiệm vụ thay đổi. Bạn không cần phải biết mọi thứ anh ấy đang làm nhưng cố gắng nắm bắt càng nhiều càng tốt. Quan trọng nhất là làm bạn với anh ấy.

Hãy coi việc bàn giao như một dự án và đưa ra một kế hoạch và liên quan đến việc quản lý.

0 - Đảm bảo bạn biết cách sử dụng hệ thống.

1 - Lập bảng kiểm kê rõ ràng về các thành phần giải pháp, nguồn gốc của từng thành phần và vị trí của nó (trong kho khác nhau)

2 - Nhận và nếu có thể, quản lý, mật khẩu cho các máy chủ khác nhau bắt đầu ngay bây giờ. Đảm bảo bạn có tất cả thông tin tài khoản quản trị viên

3 - Nhận giấy phép của từng thành phần bên ngoài trừ khi nó nằm ngoài phạm vi của bạn (ví dụ: dlls đặc biệt, cơ sở dữ liệu, v.v.)

4 - Nhận báo cáo bằng văn bản về tình trạng hiện tại của hệ thống từ nhà phát triển và khách hàng của bạn (nếu họ là người địa phương cho công ty của bạn)

5 - Lấy tài liệu cho các quy tắc kinh doanh, công thức tính toán, v.v. Bạn có thể làm điều này với anh ta. Yêu cầu anh ta cho email, thông tin cuộc họp, tài liệu yêu cầu người dùng, tài liệu thiết kế và muốn được cung cấp cho bạn.

6 - Nhận danh sách các sự kiện được lên lịch (chạy công việc hàng tháng, chạy công việc hàng tuần) mà phần mềm phải đáp ứng

7 - Tìm hiểu các thủ tục sao lưu / khôi phục

8 - Hiểu (các) khung được sử dụng để xây dựng ứng dụng

9 - Nhận biết các sửa đổi được yêu cầu / dự kiến ​​/ theo kế hoạch và trạng thái của bất kỳ yêu cầu người dùng đang chờ xử lý nào. Bắt đầu cố gắng xác định cách tự làm những việc đó.

10 - Đảm bảo môi trường thử nghiệm và phát triển của bạn rất giống nhau.

11 - Cố gắng xác định các phụ thuộc chính (trên các hệ thống khác hoặc giữa các thành phần) không thể dễ dàng phát hiện ra.

12 - Xác định và ghi lại các phiên bản bắt buộc của từng phần mềm sử dụng và liên hệ với nhà cung cấp phần mềm (nếu cần)

13 - Xác định bất kỳ công cụ đặc biệt nào anh ta đang sử dụng mà bạn không có, trong trường hợp nó có thể giúp bạn.

14 - Nhận một luồng hệ thống cấp cao. và bắt đầu xây dựng thư viện tài liệu của bạn

15 - Hiểu cách quản lý bảo mật người dùng cho ứng dụng

16 - Nhận nhật ký lỗi và cố gắng hiểu các hành động và cách hành động ảnh hưởng đến dữ liệu cũ hơn (nếu có)

17 - Biết các quy trình mất quá nhiều thời gian và những gì bạn cần xem (ví dụ: kích thước tệp bất thường, ftp của các tệp trùng lặp, v.v.) khi áp dụng.

18 - Kiểm tra đồng hồ máy chủ sản xuất

19 - Xác định cấu hình ở đâu và so sánh từng cấu hình môi trường với sản xuất để biết thông số nào khác nhau và tại sao

20 - Nhận thông tin liên lạc của anh chàng này

21 - Nếu hệ thống là nội bộ, hãy lên lịch một cuộc họp với người dùng hệ thống (bạn cần biết họ là ai và vai trò của từng người) và được giới thiệu với họ. Lắng nghe những gì họ nói về hệ thống và về các vấn đề hiện tại của họ nếu có. Đảm bảo bạn được đưa vào email càng sớm càng tốt (sau khi có sự chấp thuận của người quản lý)

22 - Đánh giá sự hiểu biết của bạn 1 tuần trước khi anh ấy rời đi và báo cáo bất kỳ vấn đề nào bạn thấy là rủi ro

Vì bạn đã đề cập rằng bạn không có cơ sở dữ liệu, danh sách này ngắn hơn.

Chúc may mắn.

Tôi sẽ xem xét các phần phức tạp nhất, tối ưu hóa cho hiệu suất đầu tiên. Tôi sẽ yêu cầu anh ấy ghi lại những phần đó trước và giải thích chúng cho bạn từng phần một, sau đó tôi sẽ cố gắng viết bài kiểm tra đối với những phần đó (bao gồm trước và sau khi kiểm tra hiệu suất, để bạn có thể xem liệu tối ưu hóa mới làm cho mọi thứ tốt hơn hay tồi tệ hơn ) và nhờ người khác xem xét các bài kiểm tra. Bằng cách này, anh ấy tài liệu và giải thích, bạn sử dụng lời giải thích để viết bài kiểm tra (trong khi anh ấy đang ghi lại một lĩnh vực khác), và đánh giá của anh ấy sẽ giúp đảm bảo bạn hiểu những gì bạn nên kiểm tra. Bằng cách đó, bạn cũng có được phạm vi kiểm tra bổ sung cho một số phần quan trọng nhất của ứng dụng và tài liệu về tối ưu hóa hiệu suất chuyên biệt.

Nếu có thời gian sau khi bao gồm những điều đó, tiếp theo tôi sẽ trải qua một quy trình tương tự với các phần của ứng dụng có sự thay đổi cần thiết nhất trong nhiều năm nhưng không nằm trong nhóm đầu tiên được ghi lại.

Sau đó, tài liệu bất cứ điều gì còn lại.

Tôi nghĩ rằng cách tốt nhất để tìm kiếm một số mã lớn là cách tiếp cận từ trên xuống. Cố gắng hiểu bức tranh lớn trước, rồi dần dần đào sâu vào từng thành phần.

Bây giờ ở mỗi cấp độ đào, yêu cầu anh ta ưu tiên các phần cần chú ý nhất. Nhờ anh ấy giải thích cho bạn nhiều nhất có thể, nhưng luôn tự mình làm tài liệu.

Phần tốt nhất về việc ghi lại tài liệu đó là khi bạn quay lại sau, bạn sẽ không gặp vấn đề gì khi nhớ lại trạng thái nhận thức giống như bạn, khi anh ấy giải thích cho bạn. Bạn có thể dễ dàng hiểu những gì bạn đã viết hơn những gì người khác đã làm. Theo kinh nghiệm của tôi, hai người viết cùng một đoạn mã không tạo ra các đoạn văn bản trông giống nhau.

Điều này, tôi đoán cũng giải quyết các vấn đề "những gì và làm thế nào để ghi lại". Khi anh ấy giải thích cho bạn mọi thứ, sau đó bạn có thể tự quyết định những gì bạn muốn được ghi lại khi bạn quay lại mã - và chỉ ghi lại những phần đó.

Ý tưởng là trước tiên phải hiểu hoàn toàn mã (với sự hiện diện của anh ấy), sau đó viết / làm mọi thứ sẽ giúp bạn có thể tự mò mẫm nó sau này (khi anh ấy vắng mặt).

Bằng cách hiểu hoàn toàn mã tôi có nghĩa là bạn cần cảm nhận về bức tranh lớn - và cách mỗi thành phần liên quan đến bức tranh lớn này. Tôi thấy nó đặc biệt hữu ích để theo dõi cách mỗi phần cộng lại. Đừng cố gắng hiểu bất cứ điều gì một cách cô lập - không bao giờ đánh mất bối cảnh của nó.

Cuối cùng, một khi bạn đã thực hiện những điều trên, chủ động kiểm soát. Tự quyết định những phần bạn cần bảo hiểm kiểm tra đơn vị cho. những phần nào cần được tối ưu hóa (hoặc có thể), làm thế nào bạn có thể cấu trúc lại một số thành phần, v.v. Tin tưởng rằng nếu bạn biết hệ thống, bạn có thể đưa ra tất cả các quyết định khi anh ta đi.

Tôi cảm thấy cho bạn.

Một vài gợi ý:

1. Băng mọi cuộc hội thoại bạn có với lập trình viên rời khỏi!
2. Yêu cầu động lực đằng sau các vấn đề "lớn". Thật tốt khi bạn hiểu API, nhưng đào sâu cho các quyết định nội bộ - tại sao mã được phân vùng như vậy? trách nhiệm là gì.
3. Hãy nỗ lực để thực sự nghiên cứu mã. Khi bạn đảm nhận nhiệm vụ bảo trì và hỗ trợ, đôi khi có áp lực phải "nghiên cứu mã trong khi tiến bộ". Chống lại nếu bạn có thể, và thực sự nghiên cứu mã.
4. Tìm kịch bản. Bạn biết API - xem cách mã hoạt động. Một ví dụ xuất hiện trong tâm trí là mô-đun Fax. Là người dùng API, bạn đã phải chuẩn bị trước một hình ảnh trang và gửi mã lệnh để truyền trang. Yêu cầu lập trình viên rời khỏi để theo dõi bạn trên mã để xem kịch bản này diễn ra như thế nào. Sau đó, tất nhiên, đi đến kịch bản "trang nhận".
5. 80/20 - cố gắng bao gồm các tình huống phổ biến hơn trước.
6. Hãy xem xét viết lại. Nếu mã đã cũ và các giao diện được xác định rõ, có thể công nghệ đã thay đổi đủ để biện minh cho nó.
7. Tôi ghét phải nói điều này, nhưng xem xét tìm kiếm một công việc mới.

Nếu bạn muốn tài liệu hợp lý mua một cách hợp lý một cách dễ dàng một bản sao của Trình phân tích Pascal (PAL) tôi đã sử dụng điều này trên các dự án Delphi và thật tuyệt - giờ đây họ có thể đã tách chức năng tài liệu thành một sản phẩm mà tôi không quen thuộc (Trình duyệt Pascal) vì vậy bạn có thể phải mua cả hai (<300 USD) nhưng PAL là một công cụ tuyệt vời để hiểu nơi các biến được sử dụng trong đó các hàm được gọi từ vv và chọn tất cả các loại vấn đề tiềm ẩn với mã.

Sử dụng PAL để có ý tưởng về cách cấu trúc của mã cộng với có thể là danh sách khoảng 1000 cải tiến được đề xuất nếu kinh nghiệm của tôi là bất cứ điều gì tiếp diễn. Làm việc thông qua danh sách sẽ cải thiện chất lượng mã, đơn giản hóa nó rất nhiều và làm cho cuộc sống của bạn dễ dàng hơn cho tương lai. Bản thân Delphi hỗ trợ tái cấu trúc trong các phiên bản gần đây (5 năm gần đây). Bạn cần phải bao gồm mọi thứ trong tệp dpr để nó thực sự hoạt động bình thường trở lại khi tôi đang thực hiện nó để ghi nhớ điều đó.

Nếu bạn muốn kiểm tra đơn vị, hãy tải xuống DUnit và bắt đầu tạo một số thử nghiệm với bộ mã gốc - đó có thể là một cách xây dựng để sử dụng ít nhất một chút thời gian của họ.

Mặc dù bạn chưa đề cập đến cơ sở dữ liệu phụ trợ nhưng giả sử có một cơ sở dữ liệu bạn nên

1. Lấy mô hình dữ liệu được ghi lại đặc biệt là các cột và PK-FK
2. Thiết lập theo dõi sql và ghi lại tất cả các truy vấn được kích hoạt trong khi sử dụng ứng dụng. Thứ tự thực hiện các truy vấn sẽ cho bạn ý tưởng tốt về luồng của ứng dụng và cũng giúp gỡ lỗi

Tôi đang ở trong tình trạng tương tự khi Kiến trúc sư của chúng tôi chuyển đến Úc và để lại rất nhiều di sản như anh ấy đã ở với công ty từ 8 năm trước. Anh ta tự thừa hưởng những thứ kế thừa từ Kiến trúc sư trước đây là một nhà thầu.

Bạn và những người khác đã đề cập đến những điểm tốt nhưng đây là những vấn đề chúng tôi gặp phải sau khi anh ấy rời đi có thể bạn có thể chuẩn bị tốt hơn ...

1) (Người kỹ thuật) Chi tiết liên lạc của khách hàng mà anh ta đang giao dịch.

2) Tài khoản của anh ấy theo đó anh ấy đã mua giấy phép phần mềm, các khóa cần được gia hạn hàng năm và các quy trình / chi phí để gia hạn chúng.

3) Tài liệu Thiết lập thư viện / thành phần và sản phẩm phần mềm của bên thứ ba tích hợp với các sản phẩm của bạn. Chúng tôi đã vật lộn trong 4 ngày để mang về một chiếc máy bị mất do IT dọn sạch không gian và một số chỉ dẫn sai được truyền cho họ.

4) Tài liệu / các bước anh ta được sử dụng để gửi mã nguồn cho phần mềm Các công ty tiền gửi, ví dụ như Ký quỹ.

5) Vẫn còn một danh sách dài nhưng có thể không áp dụng cho bạn. Không có số lượng tài liệu nào có thể thay thế người thật, vì vậy hãy giữ thông tin chi tiết của anh ấy, giữ các điều khoản tốt đẹp và may mắn :)

Ngoài ra tôi không biết nếu đây là lần đầu tiên cho bạn. Đối với tôi, tôi đã làm việc với 5/6 nhà tuyển dụng và luôn kế thừa mã với tài liệu xấu hoặc không có tài liệu nào cả. Vì vậy, cùng với tất cả các tài liệu chỉ cần tích cực :)