Làm việc trên mã của người khác [đã đóng]

Tôi hầu như không có một năm kinh nghiệm về mã hóa. Sau khi tôi bắt đầu làm việc, hầu hết thời gian tôi sẽ làm việc với mã của người khác, hoặc thêm các tính năng mới so với các tính năng hiện có hoặc sửa đổi các tính năng hiện có. Anh chàng đã viết mã thực tế không còn làm việc trong công ty của tôi nữa. Tôi đang gặp khó khăn trong việc hiểu mã của anh ấy và thực hiện các nhiệm vụ của mình. Bất cứ khi nào tôi cố gắng sửa đổi mã, theo một cách nào đó, tôi đã gặp rắc rối với các tính năng làm việc. Tất cả những gì tôi nên ghi nhớ, trong khi làm việc với mã của người khác?

Mã có kiểm tra đơn vị không? Nếu không, tôi mạnh mẽ đề nghị bạn bắt đầu thêm chúng. Bằng cách này, bạn có thể viết các tính năng / sửa lỗi mới dưới dạng thử nghiệm thất bại và sau đó sửa đổi mã mà thử nghiệm vượt qua. Càng nhiều người bạn xây dựng, bạn càng có niềm tin rằng mã được thêm vào của bạn không bị phá vỡ thứ gì khác.

Viết bài kiểm tra đơn vị cho mã bạn không hiểu đầy đủ sẽ giúp bạn hiểu mã đã nói. Tất nhiên, các bài kiểm tra chức năng nên được thêm vào nếu chúng chưa tồn tại. Ấn tượng của tôi là những người đã tồn tại hình thành câu hỏi OP. Nếu tôi sai ở điểm đó, thì những bài kiểm tra chức năng này sẽ là bước đầu tiên của bạn.

Eagle76dk đưa ra một quan điểm tuyệt vời về việc đưa người quản lý của bạn lên tàu để thực hiện công việc này - chi tiết hơn trong bài đăng của Eagle76dk.

Ngoài ra, khi bạn viết các thử nghiệm này, tôi khuyến khích bạn thử viết các thử nghiệm để họ xác minh hành vi kinh doanh mà phương thức có thể đã cố gắng thực hiện, chứ không phải hành vi mã. Ngoài ra, đừng bao giờ cho rằng các hành vi kinh doanh mà bạn thấy trong mã là đúng - Nếu bạn có ai đó có thể cho bạn biết ứng dụng nên làm gì thì trong nhiều trường hợp có giá trị hơn những gì mã có thể nói với bạn.

Ngoài một câu trả lời khác có đề cập đến các bài kiểm tra đơn vị, tôi sẽ đề nghị bạn đảm bảo mọi thứ đều nằm trong kiểm soát phiên bản để bạn có thể hoàn nguyên các thay đổi của mình một cách dễ dàng. Và thực hiện các thay đổi nhỏ để làm cho mã dễ bảo trì hơn.

Theo tôi, cách nhanh nhất để tìm hiểu mã của người khác, (đặc biệt là khi thay đổi kích hoạt hành vi không mong muốn như bạn mô tả) là chuyển qua mã bằng trình gỡ lỗi .

Bắt đầu với việc bước qua những gì dường như là vòng lặp chính / phương thức chính của chương trình. Sử dụng các bước vào và bước ra các hàm để xem các phương thức khác nhau làm gì. Điều này sẽ dạy cho bạn cấu trúc chung của mã.

Sau đó, phân chia và chinh phục bằng cách bước qua và tìm hiểu các phần khác nhau của chương trình ở cấp độ sâu hơn. Trong hầu hết các trình gỡ lỗi, bạn có thể nghiên cứu các biến và giá trị hiện tại của chúng . Nghiên cứu cách họ thay đổi và khi nào.

Đặt ra các điểm dừng trên các phương thức kích hoạt các hành vi liên quan đến bạn. Ví dụ: nếu bạn đang cố gắng thay đổi một văn bản trong chương trình và văn bản tiếp tục thay đổi về giá trị ban đầu, hãy đặt các điểm dừng trên tất cả các vị trí mà văn bản được thay đổi hoặc cố gắng di chuyển tất cả các thay đổi này sang một phương thức duy nhất. Sử dụng ngăn xếp cuộc gọi để xem phương thức này được gọi từ đâu, v.v.

Nếu thay đổi một dòng mã gây ra những thay đổi bất ngờ ở những nơi khác, hãy đặt một điểm dừng trên dòng đó và xem điều gì xảy ra ở đó, ví dụ bằng cách kiểm tra các giá trị của các biến hiện tại trong phạm vi, sử dụng bước vào hoặc ngăn xếp cuộc gọi để xem từ đâu Cuộc gọi đến.

Bằng cách thực hiện điều này rất nhiều, bạn sẽ bắt đầu tìm hiểu cấu trúc của mã nhanh một cách đáng ngạc nhiên. Tôi đã bắt đầu giống như bạn đã làm trong các công việc lập trình đầu tiên của tôi, với rất nhiều mã đã được viết từ nhiều năm trước và đã được thay đổi bởi nhiều người trong nhiều năm. Mã không chỉ của tôi vì ở đó những người khác làm việc cùng lúc. Tôi không thể viết lại tất cả vào thời điểm đó. Viết bài kiểm tra cho tất cả các mã đó sẽ mất tôi nhiều tháng hoặc nhiều năm. Trình gỡ lỗi thực sự đã cứu tôi, không biết làm thế nào tôi có thể học được mã mà không có nó ...

Điều đầu tiên cần ghi nhớ là dành nhiều thời gian hơn để đọc mã hơn là viết mã. Dành thời gian để hiểu cách anh chàng kia làm việc - phong cách và cách tiếp cận vấn đề.

Cố gắng áp dụng phong cách hiện có càng nhiều càng tốt - nếu không, anh chàng sau bạn sẽ có gấp đôi điều chỉnh để làm.

Đối phó với mã của người khác là tiêu chuẩn, không phải là ngoại lệ, bạn cần trở nên lão luyện để tìm ra cách người kia giải quyết vấn đề hoặc thực hiện một tính năng. Khi bạn đã thực hiện điều đó, bạn sẽ thấy việc xử lý mã của anh ta dễ dàng hơn.

Đừng quá nhanh để cho rằng mã của người kia bốc mùi.

Nhưng luôn luôn nghi ngờ.

Nhưng vâng, phải mất thời gian để hiểu mã của nhà phát triển khác. Càng nhiều chức năng hoặc đối tượng được sử dụng bởi nhiều bộ phận của hệ thống, bạn càng cần phải cẩn thận. Nếu bạn có thể giải quyết vấn đề gần hơn với triệu chứng, điều đó đôi khi có thể hữu ích. Ví dụ: bình thường hóa dữ liệu đến từ một đối tượng khác ở phía hàng rào của đối tượng có vấn đề sau khi dữ liệu được gửi nhưng trước khi có bất kỳ điều gì khác xảy ra.

Đó là một dấu hiệu xấu khi thay đổi một điều bất ngờ phá vỡ một điều khác. Nếu bạn có bất kỳ nhà phát triển có kinh nghiệm nào khác mà bạn có thể nhờ giúp đỡ, tôi khuyên bạn nên để họ xem xét những thứ gây ra sự cố cho bạn. Ít nhất bạn có thể chọn một vài thứ xem chúng gỡ lỗi.

Trong một thế giới lý tưởng, tất cả các mã được viết bởi một nhà phát triển nhất định sẽ được ghi lại tốt, có cấu trúc tốt và được kiểm tra toàn diện, cả với các công cụ tự động như kiểm tra đơn vị và sử dụng tập lệnh tình huống mà người dùng chạy qua để kiểm tra xem bạn có nhận được kết quả mong đợi hay không.

Tuy nhiên, điều đầu tiên bạn sẽ học là chúng ta không sống trong một thế giới lý tưởng!

Rất nhiều nhà phát triển không ghi lại mã của họ một cách chính xác, nếu có, họ trộn logic kinh doanh với mã không liên quan và thử nghiệm duy nhất họ làm là chạy nhanh qua những gì họ mong đợi là trường hợp sử dụng thông thường.

Khi làm việc với mã như thế này, điều đầu tiên bạn phải làm là thiết lập những gì nó có nghĩa là làm. Nếu có ý kiến ​​họ có thể cung cấp cho bạn manh mối, nhưng đừng tin vào điều đó. Đó là kinh nghiệm của tôi rằng nhiều lập trình viên không giỏi tự giải thích và ngay cả khi họ để lại bình luận, họ có thể là vô nghĩa. Tuy nhiên, trừ khi bạn là lập trình viên duy nhất trong công ty, chắc chắn ai đó phải có ít nhất một ý tưởng cơ bản về mã này để làm gì và nó có nghĩa là gì. Hỏi xung quanh!

Nếu bạn có bài kiểm tra đơn vị, thì chúng sẽ khiến cuộc sống của bạn trở nên dễ dàng hơn rất nhiều. Nếu bạn không, thì một phần của việc học codebase có thể liên quan đến việc viết các bài kiểm tra đơn vị cho mã đã tồn tại. Thông thường, điều này không được coi là thông lệ tốt vì nếu bạn viết các bài kiểm tra đơn vị để phù hợp với mã hiện có, bạn sẽ kết thúc với các bài kiểm tra đơn vị nghĩ rằng mã hoạt động như vậy (chúng sẽ được viết để cho rằng hành vi đó thực sự là một lỗi đúng), nhưng ít nhất nó cung cấp cho bạn một đường cơ sở. Nếu sau đó bạn phát hiện ra rằng một số hành vi mà bạn cho là đúng thực tế là sai, bạn có thể thay đổi bài kiểm tra đơn vị để kiểm tra xem kết quả mong đợi là gì thay vì kết quả mà mã đưa ra bây giờ. Khi bạn có bài kiểm tra đơn vị, bạn có thể thực hiện các thay đổi và đánh giá tác dụng phụ nào mà bất kỳ thay đổi nào bạn thực hiện có.

Cuối cùng, tài nguyên tốt nhất bạn có khi giao dịch với một đoạn mã không có giấy tờ là hỏi người dùng cuối. Họ có thể không biết gì về mã, nhưng họ biết ứng dụng họ muốn làm gì. Thu thập yêu cầu là giai đoạn đầu tiên trong bất kỳ dự án nào và nói chuyện với người dùng tiềm năng của hệ thống sẽ được phát triển luôn là một phần quan trọng trong đó. Chỉ cần nghĩ về nó như đang thực hiện giai đoạn nắm bắt yêu cầu cho một dự án mới vừa xảy ra đã được xây dựng.

Hãy nhớ rằng ngay cả mã được viết và tài liệu tốt cũng có thể khó hiểu đối với người ngoài. Mã về cơ bản là một biểu hiện về cách người viết nó đã suy nghĩ vào thời điểm đó và mọi người đều có quá trình suy nghĩ độc đáo của riêng họ. Bạn sẽ phải học cách kiên nhẫn một chút và trở thành một thám tử. Có thể tham gia vào quá trình suy nghĩ của người khác là khó, nhưng đó là một kỹ năng thiết yếu cho một lập trình viên thực hiện bảo trì mã hiện có. Vì hầu hết mã hóa (khoảng 70%) có liên quan đến việc duy trì mã hiện có, đây là một kỹ năng quan trọng để học.

Ồ, và bây giờ bạn đã thấy nỗi đau mà mã tài liệu kém, chưa được kiểm tra và lộn xộn có thể gây ra, bạn sẽ không làm điều đó với nhà phát triển nghèo tiếp theo, phải không? :) Tìm hiểu từ những sai lầm của người tiền nhiệm, nhận xét mã của bạn tốt, đảm bảo rằng mọi mô-đun đều có trách nhiệm được xác định rõ ràng và tuân thủ và đảm bảo bạn có một bộ kiểm tra đơn vị toàn diện mà bạn viết trước (đối với phương pháp TDD) hoặc ít nhất là bên cạnh mã được phát triển.

Hãy nhớ rằng khả năng đọc mã bạn chưa viết là một kỹ năng rất có giá trị, có thể có giá trị hơn so với viết mã. Thật không may, điều này được phổ biến rộng rãi và được giảng dạy tại các trường học.

Điều tôi đang cố nói là điều bình thường là bạn không luôn hiểu mã khi đọc nó lần đầu tiên (giống như bình thường khi bạn không viết mã hoàn hảo ngay lần đầu tiên). Nếu bạn chấp nhận rằng cần có thời gian để lấy mã nước ngoài, bạn sẽ không phải nỗ lực thêm. Một tóm tắt nhỏ:

• Các bài kiểm tra đơn vị sẽ là lý tưởng, nhưng không phải lúc nào cũng thực tế; đặc biệt nếu bạn làm việc trong một tổ chức lớn với sự quan liêu nặng nề.

• Tìm hiểu để sử dụng hệ thống Kiểm soát Phiên bản của bạn đúng cách; bạn sẽ không bao giờ phá vỡ hiện tại (không thực sự không bao giờ , nhưng đó là một mạng lưới an toàn tốt).

• Đừng cho rằng nó tệ chỉ đơn giản vì bạn không hiểu nó ngay lập tức. Đừng cho rằng nó tốt chỉ đơn giản vì nó hoạt động. Điều quan trọng là bạn hiểu kiểu mã của người bảo trì trước đó và điều chỉnh các dòng đã thêm của bạn theo kiểu của anh ta. Người bảo trì đến sau bạn sẽ cảm ơn bạn vì điều đó.

• Ở một số công ty, thật không may, khó đọc mã có thể được đánh giá thấp. Điều này là phổ biến trong các tập đoàn lớn với quy trình cứng nhắc. Họ thường (ngầm) thích bạn đẩy mã hoạt động nhanh hơn là dành thời gian của bạn để viết một cái gì đó sạch sẽ. Tôi sẽ để bạn quyết định nơi nhóm của bạn đứng ở điểm này.

• Cuối cùng, đừng bao giờ quên rằng đọc mã là một kỹ năng . Bạn càng làm điều đó, bạn sẽ nhận được nó tốt hơn. Một cách khác để nói điều này là cách duy nhất để có được nó tốt là thực hành nhiều lần. Giống như đã đề cập ở trên, đọc mã là và sẽ là một phần lớn hơn nhiều trong công việc của bạn so với viết.

Đánh giá từ các vấn đề của bạn với các công cụ vô tình phá vỡ, tôi sẽ cho rằng mã không được bao phủ bởi các kiểm tra tự động. Bước # 0 sẽ ngay lập tức đặt hàng và đọc Làm việc hiệu quả với Mã kế thừa của Michael Feathers. Nó chỉ đơn giản là vô giá.

Các bước cơ bản tôi muốn đề xuất:

• Che mã với các bài kiểm tra bao gồm các chức năng hiện tại.
• Tái cấu trúc cho đến khi dễ hiểu.
• Viết một bài kiểm tra cho các chức năng mới hoặc sửa đổi.
• Thực hiện các chức năng mới.
• Tái cấu trúc cho đến khi hài lòng.

Tôi cố tình bỏ qua việc chỉ định hương vị của các bài kiểm tra (đơn vị, tích hợp, ...) - chỉ cần nhận được một số loại bảo hiểm kiểm tra tự động.

(và, vâng, theo phong cách mã hóa về bố cục và đặt tên)

Như đã đề cập trước đó: chào mừng đến với thế giới thực. Tôi chỉ có thể đồng ý với câu trả lời trước đó. Tôi chỉ muốn mở rộng câu trả lời với kinh nghiệm làm việc của tôi về ước tính thời gian.

Một gợi ý tốt để làm cho ông chủ của bạn rõ ràng, sẽ mất thời gian để tìm hiểu cách các nhà phát triển khác nghĩ. Thông thường bạn sẽ trải nghiệm rằng giải pháp hiện tại thường phụ thuộc vào độ tuổi và kinh nghiệm của nhà phát triển.

Nếu bạn may mắn, nhiệm vụ trong tay phải được phân tích và hiểu tài liệu sẽ giúp bạn rất nhiều (nhưng điều này thường không phải là trường hợp).

Kinh nghiệm của tôi là khi sửa đổi mã của người khác, cố gắng không thay đổi mã không liên quan đến nhiệm vụ hiện tại của bạn. Bạn có thể biết một giải pháp tốt hơn hoặc nó có thể được viết theo cách trực quan hơn, nhưng việc thay đổi nó thường dẫn đến các vấn đề như:

• Nhiệm vụ sẽ mất nhiều thời gian hơn và ông chủ của bạn sẽ không hiểu nó.
• Mã bạn thay đổi phải được kiểm tra và chi phí. Các giải pháp hiện tại đã được thử nghiệm và phê duyệt.
• Sẽ rất khó để xem những thay đổi nào giải quyết được nhiệm vụ hiện tại và đó là những điều chỉnh 'chỉ'.

Nhưng đừng ngần ngại nói với sếp của bạn, nếu bạn thấy điều gì đó bạn nghĩ nên khác biệt (nó chỉ cho thấy bạn có thể nghĩ).

Cuối cùng, hãy chắc chắn rằng bạn có đủ thời gian để đưa ra giải pháp. Một giải pháp nhanh hơn đi kèm với kinh nghiệm. Nhưng hiếm khi có một giải pháp nhanh chóng, vì đây là lý do đầu tiên / chính gây ra lỗi và mã không thể nhầm lẫn.

Hãy nghĩ về nó giống như thực hiện một hoạt động trên một người.

Bạn nhìn vào bên trong để biết vấn đề bạn cần khắc phục và nhận thấy rằng hầu hết các động mạch, v.v. không được thiết lập theo cách bạn sẽ làm - vì vậy bạn cắt và băm chúng cho đến khi nó phù hợp với bạn và sau đó khắc phục vấn đề.

Thật đáng ngạc nhiên bệnh nhân của bạn chết gần như ngay lập tức.

Các ứng dụng kế thừa là như nhau. Họ đã có cách làm việc - bạn cần hiểu các thành phần khác nhau trong phần mềm và cách chúng liên quan với nhau và sau đó thực hiện thay đổi của bạn để nó hoạt động theo cùng một cách. Nó không phải là một thú vị như để cho sự sáng tạo của bạn phát huy, nhưng bạn có thể làm điều đó trên các dự án cá nhân.

Tôi sẽ yêu cầu một kỹ sư cao cấp ngồi lại với bạn trong khoảng một giờ vào mỗi thứ Hai và giải thích một khía cạnh khác của hệ thống. Ghi chú những gì anh ấy nói và gửi email ghi chú cho anh ấy và người quản lý của bạn để xem người quản lý của bạn có gì để thêm không. Bạn nên tăng tốc độ khá nhanh theo cách này.

Về cách không phá vỡ mọi thứ, trước hết hãy chắc chắn rằng bạn hiểu hệ thống làm gì. Kiểm tra trước - thực hiện thay đổi của bạn - kiểm tra sau đó. Không có công thức ma thuật; khi bạn có được kinh nghiệm, bạn sẽ trở nên tốt hơn - hoặc tôi bị đuổi việc!

Một điều mà tôi chưa từng thấy thực sự cảm động ở đây - đừng làm việc trên một hòn đảo.

Trừ khi bạn là lập trình viên duy nhất trong trang phục của bạn, chắc chắn sẽ có ai đó có nhiều kinh nghiệm hơn bạn, và hoàn toàn có thể có nhiều người mà bạn có thể dựa vào.

Hỏi câu hỏi. Rất nhiều trong số họ.

Đừng lo lắng về việc "làm phiền" người khác (theo lý do) - Tôi muốn ai đó ngắt lời tôi một hoặc hai câu hỏi trong một chu kỳ phát triển bình thường, hơn là phải dập lửa trong môi trường sản xuất sau này.

Khi bạn đã sẵn sàng để kiểm tra một cái gì đó, hãy xem lại với người cố vấn của bạn. Họ sẽ có thể nói với bạn không chỉ nếu một cái gì đó sẽ phá vỡ một cái gì đó khác, mà quan trọng hơn, tại sao. Xem lại mã cũng sẽ làm cho người cố vấn trở thành một lập trình viên tốt hơn, cho anh ta / cô ta một cái nhìn vào hệ thống mà họ có thể không nhìn vào thường xuyên.

Hãy nhớ rằng - bạn không chỉ học hệ thống như bất kỳ nhân viên mới nào sẽ cần phải làm, mà bạn còn học cách trở thành một lập trình viên.

Và năm năm sau, khuyến khích New Guy tiếp theo sử dụng bạn như một người cố vấn.

Khi nói đến mã gỡ lỗi, hãy nhớ: luôn có một lý do . Khi bạn đã cố gắng tìm và sửa cùng một lỗi ngu ngốc trong vài ngày và bạn không đạt được bất kỳ tiến triển nào, thật hấp dẫn khi bắt đầu nghĩ đến một hoặc nhiều:

• Tôi chỉ không đủ thông minh để tìm ra cách mã này hoạt động

• Người viết mã này không biết mình đang làm gì

• Phép thuật có liên quan: ma thuật rất đen

Đó là tất cả các hình thức từ bỏ. Thuốc giải độc là luôn nhớ rằng máy tính mang tính quyết định: luôn có một lý do cho những gì chúng làm. Mã có thể có mùi như thủy triều thấp tại một hộp cá và giống như một bát linguine khổng lồ, nhưng bằng cách không ngừng lý trí và giữ một tâm trí cởi mở, bạn sẽ nhận ra điều đó .

Cho dù bạn viết các bài kiểm tra đơn vị khi có thể hoặc viết các ứng dụng nhỏ liên quan đến mã bạn đang sửa đổi, bạn sẽ phải xem, hiểu và sau đó ghi lại logic.

Nếu mã hoạt động chủ yếu - nghe có vẻ như vậy - thì tôi sẽ giữ nguyên kiểu định dạng mã cho mô-đun đó, cho dù đó là kiểu của bạn hay không. Nó giữ cho mọi thứ thống nhất. Tuy nhiên, những bình luận tốt không bao giờ lỗi mốt.

Tôi khuyên một hệ thống thử nghiệm và nền tảng thử nghiệm, nơi bạn có thể sửa đổi và kiểm tra mã này, mà không phá vỡ sản xuất.

Nếu bạn có thể loại bỏ các yếu tố của mã vào thư viện, tôi sẽ làm điều đó, trừ khi bạn đang làm việc trên thư viện.

Theo thời gian, một khi bạn hiểu logic, bạn có thể viết lại và kiểm tra.

Lời khuyên này được kiểm soát bởi ngôn ngữ bạn đang sử dụng, khả năng có được giường thử nghiệm và các ràng buộc khác mà bạn có.

Cố gắng sử dụng một số công cụ phân tích mã để tìm mã không sử dụng có thể bị xóa - vì vậy ít nhất bạn không phải lo lắng về mã này.

Nó đã được nhận xét ở trên rằng bạn cần phải hiểu mục đích của hệ thống, không chỉ là các chi tiết của mã. Một lập trình viên có đủ kinh nghiệm để viết một hệ thống nhập đơn hàng thường thoải mái với phần 'chuyển tiếp', bao gồm việc chọn sản phẩm, định dạng hóa đơn và xử lý thanh toán. Nơi họ gặp khó khăn là khi người dùng quyết định 'không bao giờ bận tâm' và bắt đầu sao lưu các giao dịch hoặc khi họ gặp lỗi trong quá trình xử lý thanh toán và nhấn nút 'quay lại'. Vào thời điểm đó, rất nhiều lập trình viên bị bối rối, bởi vì họ thấy mã "hiển thị ra khỏi hư không" và không thể hiểu tại sao nó lại ở đó.

Nói tóm lại, bạn phải hiểu không chỉ là "dòng chảy bình thường", mà tất cả các quay lui cần thiết nếu ai đó phạm sai lầm hoặc thay đổi suy nghĩ của họ. Điều này thậm chí còn tồi tệ hơn với các phần ghi đè của người giám sát, trong đó một số mã chỉ có thể được chạy với các đặc quyền tài khoản nhất định.

Nếu ai đó viết 10.000 dòng mã mỗi năm và một ứng dụng có 'vòng đời' mười năm, thì một lập trình viên chịu trách nhiệm chọn công việc của người khác có thể phải hiểu 100.000 dòng mã. Chia cho 50 dòng trên mỗi trang là 2000 trang. Nếu chương trình được viết theo mẫu thiết kế, lập trình viên sẽ thấy rằng sự hiểu biết về một "khối" dẫn đến ít nhất là sự hiểu biết chung về hầu hết các phần còn lại. Nếu không, thì cần phải đọc từng dòng chết tiệt cuối cùng.

Một số lập trình viên 'chỉ cần làm những gì họ nói' và viết spaghetti. Họ không bao giờ hiểu được "bức tranh lớn" - họ chỉ đơn giản là đưa ra các bản sửa lỗi khi người dùng phàn nàn. Trong trường hợp như vậy, một ý tưởng tốt là bắt đầu di chuyển bất cứ điều gì bạn có thể sang một mô hình thích hợp. Cuối cùng, điều này có thể có nghĩa là mã hóa lại những thứ không bị 'hỏng'. Đừng lo lắng về điều đó, chỉ cần đảm bảo rằng miễn là dự án của bạn ngày càng dễ bảo trì hơn.

Có một số câu trả lời thực sự tốt đẹp ở đây. Nhưng tôi nghĩ cũng có thể đáng để đề cập đến mức độ quen thuộc với các mẫu thiết kế tốt có thể giúp đỡ, để đọc (viết tốt) mã hiện có và viết mã có thể đọc được.

Tất nhiên nó có thể rất khó hiểu khi bạn gặp một SomethingFactorymã hiện có, điều đó không thực sự theo mô hình nhà máy . Nhưng nhiều như nhóm và khuôn khổ của bạn cho phép, có thể có lợi khi giữ những trường hợp như vậy ở mức tối thiểu.

Theo các mẫu thiết kế (nơi mà doanh nghiệp cần cho phép) cũng có thể giảm đáng kể việc sao chép mã, từ đó giảm lỗi trong các sửa đổi trong tương lai.

Một số nguồn tốt về các mẫu thiết kế là

http://sourcemaking.com/design_potypes

http://www.oodesign.com/

và tất nhiên cuốn sách

http://www.amazon.com/Design-Potypes-Elements-Reustom-Object-Orients/dp/0201633612

Theo dõi luồng kiểm soát giữa các phương pháp là rất quan trọng trong việc phát triển bản đồ tinh thần của logic kinh doanh.

Giải pháp của chúng tôi dựa trên sự thừa nhận rằng một trong số ít thông tin đáng tin cậy có sẵn khi tiếp cận một hệ thống cũ là chính hệ thống đang chạy. Cách tiếp cận của chúng tôi thống nhất các dấu vết thực hiện và sử dụng lập trình logic để thể hiện các bài kiểm tra về chúng.

Tạo mô hình dữ liệu quy trình công việc là cách tốt nhất để phân tích tất cả các đường dẫn mã:

Trong thực tế, việc xem xét mã trở nên khó sử dụng trong quy trình làm việc khoa học cũ. Nguồn gốc của các quy trình công việc như vậy có nghĩa là các thực hành kỹ thuật phần mềm có thể không được áp dụng trong quá trình phát triển, dẫn đến một cơ sở mã bị che khuất một cách hiệu quả. Trong khi phân tích tĩnh có các kỹ thuật phát triển tốt để phân tích dataflow, chúng không hỗ trợ hành vi trong quy trình công việc trong thế giới thực. Ví dụ: khi tệp cấu hình phải được tải để xác định cách xử lý dữ liệu hoặc khi sử dụng đánh giá mã động.

Và trực quan hóa quy trình làm việc là lý tưởng:

Một mô típ phổ biến, cho vay để phát triển thị giác, là sự trình bày một quy trình công việc dưới dạng biểu đồ. Điều này bảo vệ người dùng khỏi sự phức tạp tiềm ẩn của tài nguyên và thực thi

Người giới thiệu

• Hiểu quy trình công việc kế thừa thông qua phân tích thời gian chạy (pdf)
• Kiểm tra logic hệ thống theo hướng đối tượng Kiểm tra logic (pdf)
• console.trace () - API Web | MDN
• Truy tìm các cuộc gọi phương thức thông qua Proxy
• Làm thế nào để theo dõi các phương pháp Ruby của bạn
• Dễ dàng theo dõi các lệnh gọi hàm lồng nhau trong Python - trang web của Eli Bendersky
• Phương thức đăng nhập / thoát đăng nhập - Mitheron Kernow
• Trace: Thiết bị hiển thị các cuộc gọi chức năng
• -Xác định -
• GitHub - johnno1962 / SwiftTrace: Truy tìm phương thức Swift và Objective-C
• Debug :: Trace - Phần mở rộng Perl để theo dõi các cuộc gọi chương trình con - metacpan.org

Đảm bảo bạn đang sử dụng chương trình giúp bạn tìm nội dung trong tệp hiện tại. Không có gì tệ hơn là biết thứ bạn đang tìm kiếm trong tệp hiện tại, nhưng bạn cuộn và cuộn và không thể tìm thấy nó. Một khung nhìn phác thảo trong công cụ bạn sử dụng để chỉnh sửa mã thực sự giúp ích cho vấn đề đó.