Chúng ta có trách nhiệm cải thiện bộ luật cũ không?

Tôi đã xem qua một số mã cũ mà tôi đã viết. Nó hoạt động, nhưng nó không phải là mã tuyệt vời. Tôi biết nhiều hơn bây giờ so với lúc đó, vì vậy tôi có thể cải thiện nó. Đây không phải là một dự án hiện tại, mà là mã sản xuất hiện tại, đang hoạt động. Chúng tôi có trách nhiệm quay lại và cải thiện mã mà chúng tôi đã viết trong quá khứ hay là thái độ đúng đắn "nếu nó không bị hỏng, đừng sửa nó"? Công ty của tôi đã tài trợ một lớp đánh giá mã vài năm trước và một trong những vấn đề lớn là đôi khi nó chỉ đủ tốt; tiến lên

Vì vậy, tại một số điểm bạn chỉ nên gọi nó là đủ tốt và tiếp tục, hoặc bạn nên cố gắng thúc đẩy các dự án để cải thiện mã cũ khi bạn nghĩ rằng nó có thể tốt hơn?

Trừ khi bạn sẽ thực hiện các thay đổi đối với "mã cũ" này để sửa lỗi hoặc thêm tính năng, tôi sẽ không cải thiện nó chỉ vì lợi ích của nó. Nếu cuối cùng bạn muốn cải thiện nó, hãy đảm bảo rằng bạn có các bài kiểm tra đơn vị sẽ kiểm tra mã trước khi bạn bắt đầu tái cấu trúc nó.

Bạn có thể sử dụng "mã cũ" để tìm hiểu các thực tiễn tốt hơn. Nếu bạn làm điều này, đó là một trải nghiệm học tập bán thời gian và bạn không nên hy vọng mã đó sẽ thay thế những gì hiện đang được phát hành hoặc triển khai bởi khách hàng / khách hàng.

Tái cấu trúc các khu vực mã bạn cần sửa đổi thường xuyên nhất . Vì bạn thường xuyên truy cập vào các khu vực này, nên việc tái cấu trúc sẽ cải thiện sự hiểu biết về mã và khả năng đọc của bạn khi bạn phải truy cập lại chúng, trong khi không có lý do nào để mã hóa lại, không ai sẽ nhìn lại.

Hơn nữa, nếu bạn chỉ cấu trúc lại các vùng mã khi bạn cần sửa đổi chúng, nó sẽ cung cấp cho bạn một lý do hợp lệ nếu việc tái cấu trúc của bạn gây ra hồi quy . Tất nhiên, hãy cố gắng bao gồm các phép tái cấu trúc của bạn bằng các bài kiểm tra đơn vị, nhưng điều này không phải lúc nào cũng có thể, đặc biệt là với mã kế thừa và bạn nên mong đợi các phép tái cấu trúc lớn sẽ tạo ra hồi quy mỗi lần.

Nếu bạn cần thêm các tính năng và thiết kế của bạn đang làm bạn chậm lại hoặc gây ra sự trùng lặp thì hãy cấu trúc lại . Khi tôi thiết kế mã, tôi gần như không bao giờ dự đoán chính xác những thay đổi sẽ cần trong tương lai. Tuy nhiên, khi tôi thêm các tính năng mới, tôi thường kết thúc việc cấu trúc lại mã được chia sẻ. Vào lúc đó, tôi đã thêm một chu kỳ tái cấu trúc / tính năng thứ ba, việc tái cấu trúc của tôi đã tự trả tiền và mã chia sẻ của tôi khá ổn định.

TLDR: tái cấu trúc khi cần thiết, không có nghĩa vụ.

Tất cả mọi thứ bạn làm đều có chi phí. Bạn có giới hạn thời gian để lập trình. Tất cả mọi thứ bạn làm trong lập trình nên được xem xét lại, "lợi ích của việc này là gì?" và "lợi ích của việc làm gì khác là gì?"

Nếu bạn không tính đến chi phí cơ hội (Chi phí để làm việc gì khác?) Thì chất lượng là miễn phí. Tốt hơn là cải thiện mã của bạn. Bạn sẽ học được điều gì đó. Nó sẽ chạy tốt hơn. Nó sẽ bán nhiều hơn.

Câu hỏi thực sự là điều tốt nhất tiếp theo bạn có thể làm với thời gian của mình là gì? Và sau đó bạn đã đánh đổi.

Nó sẽ bán nhiều phần mềm hơn?

Nó sẽ gây ra ít đau đầu để hỗ trợ?

Bạn sẽ học gì?

Nó sẽ trở nên thẩm mỹ hơn?

Nó sẽ cải thiện danh tiếng của bạn?

Đặt những câu hỏi này (và bất kỳ câu hỏi nào khác liên quan đến bạn) cho điều này và các hoạt động khác trong hàng đợi của bạn và điều đó sẽ giúp trả lời nếu nó đáng để sửa. Những sự đánh đổi này là lý do tại sao kinh tế là quan trọng đối với các lập trình viên. Joel đã nói điều đó trước khi tôi làm, và một người cố vấn cũ đã nói điều đó với tôi ngay cả trước Joel.

Hoặc nếu bạn muốn câu trả lời đơn giản hơn, chỉ cần dừng xem TV cho đến khi bạn sửa mã. :-)

Tôi nghĩ bạn nên bắt đầu bằng cách tự hỏi mình câu hỏi dường như đã bị bỏ qua. Mã xấu là gì? Và bằng cách này, bạn đang thực sự tự hỏi mình như sau:

• Có mã không làm những gì nó phải làm?
• Là mã gây ra vấn đề cho bạn khi bạn đang bảo trì phần mềm?
• Là mã hoàn toàn khép kín?
• Bạn có kế hoạch cập nhật hoặc thay thế mã bất cứ lúc nào trong tương lai gần không?
• Có một trường hợp kinh doanh đúng đắn mà bạn có thể thực hiện để cập nhật mã mà bạn quan tâm không?

Nếu có một điều tôi đã học được trong nhiều năm qua, đó là bạn không đủ khả năng để tự mình đoán thứ hai sau sự thật. Mỗi khi bạn giải quyết một vấn đề trong mã, bạn sẽ học được điều gì đó và có thể sẽ thấy cách giải pháp của bạn - hoặc một cái gì đó tương tự - có thể là một giải pháp tốt hơn cho một vấn đề bạn đã giải quyết cách đây nhiều năm. Đây là một điều tốt, bởi vì nó cho bạn thấy rằng bạn đã học được từ kinh nghiệm của bạn. Tuy nhiên, câu hỏi thực sự là liệu mã bạn viết trước đây có khả năng trở thành vấn đề di sản trở nên khó xử lý hơn theo thời gian hay không.

Điều chúng tôi thực sự đang nói ở đây là liệu mã làm phiền bạn dễ hay khó bảo trì và việc bảo trì có thể tốn kém như thế nào khi thời gian trôi qua. Đây thực chất là một câu hỏi về Nợ kỹ thuật, và liệu có đáng để trả hết khoản nợ đó bằng cách sử dụng một chút bảo trì phẫu thuật hay không, liệu khoản nợ đó có đủ nhỏ để bạn có thể để nó trượt một chút không.

Đây là những câu hỏi mà bạn thực sự cần phải cân nhắc với khối lượng công việc hiện tại và tương lai của bạn, và nên được thảo luận lâu dài với ban quản lý và nhóm của bạn để hiểu rõ hơn về nơi đầu tư tài nguyên của bạn và liệu mã cũ của bạn có đáng không thời gian bạn có thể cần phải dành cho nó - nếu có. Nếu bạn có thể tạo ra một trường hợp kinh doanh tốt để giới thiệu thay đổi, thì bằng mọi cách hãy làm như vậy, nhưng nếu bạn đang phải đối mặt với sự thôi thúc phải sửa đổi mã bởi vì bạn cảm thấy xấu hổ về cách bạn viết nó, thì tôi khuyên bạn không nên phòng cho niềm tự hào cá nhân khi nói đến việc duy trì mã cũ. Nó có thể hoạt động, hoặc không, và nó dễ bảo trì, hoặc tốn kém để duy trì, và nó không bao giờ tốt hay xấu chỉ vì kinh nghiệm ngày nay không có sẵn cho bạn ngày hôm qua.

Chắc chắn không cải thiện nó chỉ vì mục đích cải thiện nó. Như những người khác đã nói (và là lẽ thường), tất cả chúng ta đều trở nên tốt hơn (đối với một số giá trị "tốt hơn") khi thời gian trôi qua. Điều đó đang được nói, xem xét mã (chính thức hoặc không chính thức) thường chiếu sáng các bit và phần mà chúng ta có thể muốn không bao giờ nhìn thấy ánh sáng của ngày nữa.

Mặc dù tôi không tin rằng chúng tôi có trách nhiệm quay lại và cải thiện mã mà về cơ bản không bị hỏng, không an toàn hoặc phụ thuộc vào các tính năng trong danh sách / EOL không dùng nữa, đây là một số điều tôi đã làm trong quá khứ trong tình huống này :

• Xác định những người trong nhóm thực sự đào trở lại và cải thiện mã, như một loại công việc làm sạch não hoặc nhiệm vụ tốt, có kích cỡ cắn mang lại cảm giác hoàn thành và tìm thời gian trong lịch trình để họ thực hiện nó một cách thường xuyên. Tôi đã luôn có ít nhất một trong số những người như vậy trong một nhóm và cách tiếp cận này cũng có thể thúc đẩy tinh thần (hoặc ít nhất là tâm trạng) nếu tất cả chúng ta đang trong giai đoạn tạm lắng hoặc suy sụp.

• Sử dụng nó làm cơ sở cho một bài tập học tập. Đối với thực tập sinh, sinh viên hoặc thành viên mới / thành viên của nhóm, việc tái cấu trúc mã cũ với sự hướng dẫn từ các thành viên cao cấp của nhóm cho họ cơ hội giao tiếp với các thành viên mới của nhóm, hiểu thêm về hệ thống và tập thói quen viết / cập nhật kiểm tra đơn vị và làm việc với tích hợp liên tục. Điều quan trọng cần lưu ý là bài tập này được thực hiện với sự hướng dẫn và được đóng khung rõ ràng như một bài tập để làm cho mã tốt hơn vì nó không tuân thủ các tiêu chuẩn / quy phạm hiện hành.

Vì vậy, không có trách nhiệm sửa chữa nó, nhưng những thứ cũ có thể thực sự hữu ích. Và bài kiểm tra đơn vị và CI là bạn của bạn!

Không cần thiết. Tuy nhiên, nếu bạn đang thực hiện bảo trì mã và tình cờ tìm thấy thứ gì đó có thể tốt hơn, bạn có thể thay đổi nó với điều kiện bạn phải kiểm tra đơn vị phù hợp để đảm bảo bạn không tạo ra hồi quy.

Nếu không có thử nghiệm nào như vậy tồn tại và bạn không thể chắc chắn nó sẽ hoạt động chính xác như thế nào, tốt hơn hết là bạn nên để nó một mình.

Từ quan điểm của một kỹ sư, chắc chắn tôi rất muốn làm việc với mã cũ cho đến khi nó không thể được cải thiện nữa. Nhưng có một trường hợp kinh doanh cho nó? Vào cuối ngày, mã có mặt để đóng góp vào điểm mấu chốt, lợi nhuận của nơi làm việc của bạn. Nếu không, hãy để lại nó.

Có một sự cảnh báo lớn, nếu bằng cách cải thiện mã, bạn sẽ tránh được lỗi xảy ra, (nghĩ rằng những quả bóng Y2K lớn ở đây ..) Tôi chắc chắn sẽ đưa nó lên với ai đó cao hơn, có thể là người quản lý đơn vị kinh doanh của bạn, và thảo luận về hậu quả của việc cải thiện mã.

Đối với tôi, câu hỏi có thể được nhắc lại và khái quát: "Tại sao ai đó nên sử dụng thêm tài nguyên (thời gian, tiền bạc, tinh thần, v.v.) nếu đoạn mã cụ thể đó hoạt động tốt bây giờ? Không phải là lãng phí tài nguyên ? "

Mỗi lần tôi tìm thấy một mã kế thừa, tôi nghĩ về một số điều có vẻ quan trọng.

1. Điều gì cho tôi sẽ thay đổi?
2. Tôi có cần hỗ trợ mã này không? Bao lâu nó có thể xảy ra (tương lai gần / xa)?
3. Là mã này đủ thoải mái để làm việc với? (Ngay bây giờ)
4. Tôi có thể chắc chắn rằng tất cả những thay đổi mà tôi làm là an toàn không? Các xét nghiệm khác nhau thường giúp trả lời câu hỏi này.
5. Tôi có thể gặp hậu quả gì nếu tôi sẽ phạm lỗi trong quá trình sửa đổi mã? Có thể hoàn nguyên các thay đổi của tôi một cách nhanh chóng? Nó sẽ lãng phí thời gian?
6. ...

Thật ra, bạn nên tự hỏi mình rất nhiều câu hỏi. Không có một danh sách đầy đủ và cuối cùng của họ. Chỉ có bạn và có lẽ đồng đội của bạn có thể tìm thấy câu trả lời.

PS Tôi đã nhận thấy rằng tôi có xu hướng viết lại mã rất thường xuyên, trong khi bạn bè và đồng đội của tôi có xu hướng để nó không bị ảnh hưởng. Đó là bởi vì chúng tôi trả lời các câu hỏi được đề cập khác nhau. Và tôi phải nói rằng chúng tôi thường xuyên trả lời sai ... vì chúng tôi không thể dự đoán được tương lai.

Microsoft có cần cập nhật windows không? Có phải tất cả các * nix Distros phải tiếp tục phát triển? Hay một ví dụ thực tế hơn là mọi người vẫn lái xe của năm 1970?

Bạn thường có thể viết mã tốt hơn trong lần thứ hai, bạn đã tìm hiểu thêm về tên miền bằng cách viết nó ban đầu.

Không có câu trả lời đơn giản nào cho việc đó là giá trị bồi dưỡng. Nói chung, bạn không nên trừ khi a) đó là một trích đoạn học tập tốt cho bạn hoặc b) bạn sẽ tiết kiệm thời gian trong thời gian dài với mã tốt hơn. Hãy nhớ mọi thay đổi rủi ro lỗi.

Là một lưu ý phụ tôi sẽ ủng hộ mạnh mẽ các bài kiểm tra đơn vị. Rất dễ dàng để cải thiện việc bồi dưỡng đặc biệt là nếu bạn không có hành vi hiện tại được đánh dấu rõ ràng với phần còn lại tự động.

Tôi tin rằng chúng ta có trách nhiệm viết mã tốt nhất có thể hiện nay. Điều đó có nghĩa là sử dụng tất cả mọi thứ chúng ta đã học được trong quá khứ và từ chối thực hiện các bước cắt ngắn trong thiết kế của chúng tôi. Nếu áp lực lịch trình khiến thứ gì đó bị cắt giảm, tôi không tin rằng chất lượng phần mềm của chúng tôi thậm chí nên được xem xét, mặt khác, cái kẹp giấy hoạt hình nhỏ gọn đó ...

Bây giờ nếu bạn đang làm việc và thấy rằng mã mà bạn cần tương tác không được viết theo cấp độ bạn hiện có khả năng viết, thì việc sửa nó là hợp lý nếu bạn có thể thực hiện theo cách có kiểm soát. Cá nhân tôi có kinh nghiệm rất nhỏ với loại Tái cấu trúc này, giống như mọi người (gần như tất cả mọi người?) Tôi đã thử toàn bộ "cho phép thay đổi mọi thứ và cầu nguyện cho nó hoạt động" và bị cắn bởi điều đó đủ tệ. Tôi đề nghị xem xét các cuộc thảo luận của Martin Fowler (hoặc cuốn sách của ông hoặc một trong nhiều bài viết ) về vấn đề này. Ông dường như đã truyền cảm hứng cho hầu hết những suy nghĩ hiện tại về quá trình này.

Tất nhiên đôi khi bạn có thể không thể xóa mã như bạn muốn. Joel Spolsky đã viết một bài viết về lý do tại sao bạn có thể muốn dành một vài tuần chỉ đơn giản là Tái cấu trúc mã của bạn. Đọc nó ở đây và có nó là một chút cũ, nhưng tôi nghĩ rằng thông tin vẫn còn có liên quan.

Tôi hy vọng điều đó sẽ giúp

Tôi cảm thấy rằng tái cấu trúc / cải thiện mã cũ xác định chính lập trình viên. Muốn cải thiện mã mà bạn đã viết một năm trước chỉ cho thấy sự tiến bộ của bạn và nếu nó làm cho ứng dụng tốt hơn và bạn có khả năng, thời gian và phê duyệt để cải thiện nó, hãy làm điều đó.

Tốt hơn / cải thiện là một so sánh đa trục. Bạn có nghĩ rằng bạn có thể làm cho nó nhanh hơn, nhỏ hơn, tiết kiệm tài nguyên hơn, dễ đọc hơn, thông tin hữu ích hơn, kết quả chính xác hơn, linh hoạt hơn, tổng quát hơn, có thể chạy trên nhiều hệ thống hơn, loại bỏ sự phụ thuộc vào một sản phẩm riêng biệt?

Tại sao công ty của bạn phải trả tiền cho bạn để dành thời gian viết lại mã này, thay vì viết mã mới hoặc viết lại một số đoạn mã khác?

Bạn nên cải thiện khi có cơ hội, nhưng cơ hội có nghĩa là bạn đang làm việc với mã hoặc bạn đã xác định lý do kinh doanh để thực hiện thay đổi.

Đẩy một sự thay đổi vào sản xuất giới thiệu một cơ hội phá vỡ mọi thứ khác (thử nghiệm đơn vị và chức năng chỉ làm giảm cơ hội này, họ không loại bỏ nó) và chỉ nên được thực hiện khi lợi ích dự kiến ​​vượt xa rủi ro.

Đó là một điểm khác để xem xét - bạn có HỢP ĐỒNG để đẩy sự thay đổi này sang sản xuất, hay đơn giản là cho ngành phát triển? Thanh cho hai kịch bản là hoàn toàn khác nhau. Nếu nó chỉ đi vào nhánh phát triển và có thể không bao giờ được đưa vào sản xuất, thì về cơ bản, cơ hội có nghĩa là bạn đang xem mã vì một số lý do và không mất thời gian để làm. Nó có thể được xem xét theo quy định nếu một push bao giờ nên xảy ra, và bỏ qua nếu nó được coi là không có cơ sở tại mà thời gian. Mặt khác, nếu nó sẽ được sản xuất ngay bây giờ, như tôi đã nói ở trên, bạn cần xem xét liệu sự thay đổi này có xứng đáng với chi phí hay không: về thời gian thực hiện cú hích và lợi ích của việc sử dụng mã mới.

Một nguyên tắc nhỏ là nếu bạn mất thời gian để hiểu mã đang làm gì và nếu thời gian này có thể được giảm đi bởi một số phép tái cấu trúc được chọn tốt, thì bạn đang phục vụ nhu cầu của doanh nghiệp và nhóm của bạn thực hiện các bước này.

Nếu mã không được hưởng lợi từ phân tích của bạn, nếu tên trường không trở thành biểu hiện của mục đích mã và các phương thức không được chia thành các phần có thể đọc được, thì doanh nghiệp đã mất một thứ có giá trị: trạng thái hiểu của bạn. Với các công cụ như Visual Studio và ReSharper, các loại tái cấu trúc này là an toàn, trung tính logic và có giá trị lớn trong năng suất và sự tự tin của nhà phát triển trong tương lai.

Như chú Bob Martin nói, "Luôn luôn để khu cắm trại sạch hơn bạn tìm thấy."

Đây là một câu hỏi để hỏi quản lý trong công ty của bạn.

Bạn có thời gian và tài nguyên cần thiết để quay lại và thay đổi mã cũ không?

Bạn có đủ thời gian và nguồn lực để có một nhóm QA KIỂM TRA những gì bạn đã thay đổi để đảm bảo nó không bị hỏng không?

Tôi đã rơi vào cái bẫy này trước khi tôi ở trong một mô-đun sửa lỗi và thấy mã tôi hoặc người khác viết không hiệu quả hoặc không phù hợp, thay đổi nó và kết thúc với nhiều vấn đề cần xử lý hơn là tôi chỉ sửa lỗi tôi được giao nhiệm vụ sửa chữa.

Nó phụ thuộc.

Nếu mã được đề cập thực sự bị hỏng, do đó nó chứa các lỗi chắc chắn sẽ xuất hiện tại một điểm (ví dụ: một số bộ đếm tại một số điểm sẽ gây ra lỗi và gây ra các vấn đề khó chịu), thì việc sửa chúng có thể rất đáng để thử - nhưng nếu bạn làm, đặt tất cả các biện pháp bảo vệ có thể lên hàng đầu để tránh đưa ra các lỗi mới: đảm bảo bạn có các bài kiểm tra đơn vị có ý nghĩa bao gồm mọi thứ bạn chạm vào, kiểm tra tất cả các thay đổi của bạn bởi một người có thẩm quyền, khăng khăng kiểm tra kỹ, đảm bảo bạn có thể quay lại cũ phiên bản bất cứ lúc nào, sao lưu mọi dữ liệu trước khi đi vào sản xuất, triển khai đến môi trường chấp nhận trước và được người dùng thực tế kiểm tra, v.v. Bạn cũng sẽ muốn được chấp thuận trước khi tiếp tục: nếu lỗi thực sự là một quả bom hẹn giờ và người quản lý của bạn có phần có thẩm quyền,bạn sẽ có thể thuyết phục anh ấy / cô ấy cho phép bạn sửa nó (và nếu bạn không được chấp thuận, thì có lẽ đó là một dấu hiệu cho thấy bạn đã sai).

OTOH, nếu khiếu nại của bạn chỉ thiếu sự tao nhã của mã, thì bạn không dám chạm vào nó. Bây giờ, họ đã thực hiện dịch vụ trung thành trong sản xuất, thay đổi mã sẽ chỉ làm bạn hài lòng, nhưng không thêm bất kỳ giá trị nào, và giống như mọi thay đổi, có nguy cơ bạn phá vỡ thứ gì đó. Ngay cả khi bạn không, thời gian của bạn là có giá trị (theo nghĩa đen: bạn được trả tiền cho những gì bạn làm, vì vậy mỗi phút thời gian của bạn đều tốn tiền) và vì bạn không thêm bất kỳ giá trị thực tế nào, nên một sự thay đổi sẽ là một khoản lỗ ròng cho công ty và dự án.