Tái cấu trúc: Khi nào bạn biết đó là thời gian và khi nào bạn làm điều đó?

Question

Khi nào bạn biết đã đến lúc tái cấu trúc/xem lại một số đoạn mã? Và tốt hơn, khi nào bạn làm điều đó?

Có lẽ giống như những người khác, tôi thấy mình biết rằng một cái gì đó cần một refactor/xem xét nhưng thời hạn và quản lý để lại không có thời gian cho điều đó. Tôi cũng muốn nghe cách bạn bao gồm đánh giá mã trong quá trình phát triển chung.

Gần đây tôi đã tìm thấy chính mình làm việc đó trước khi làm việc trên các tính năng/mã mới. Ví dụ, nếu tôi phải phát triển một cái gì đó mới hoặc thay đổi một cái gì đó trong mô-đun X của một ứng dụng, tôi làm một đánh giá mã trên mô-đun đó. Tôi thấy nó cũng giúp tôi hiểu mô-đun tốt hơn để tôi có thể thực hiện các thay đổi dễ dàng hơn.

Vì vậy, khi nào bạn biết đó là thời gian và thời điểm bạn làm điều đó? Và hầu hết tất cả làm thế nào để bạn đưa nó vào trong kế hoạch của một dự án?

Answer 1

Tôi có xu hướng nhìn thấy 'mã mùi' như tôi lặp lại cùng một mã lặp đi lặp lại hoặc tôi thấy điều gì đó khiến tôi nghĩ, "Phải có cách tốt hơn để làm điều này và tôi sẽ tìm nó. " Đó là một phần của cách tôi viết mã và nghĩ rằng đó là một điều tốt để có mã tốt có thể mất nhiều thời gian hơn để hoàn thành nhưng điều đó dễ dàng mở rộng hơn, có thể duy trì hoặc có người khác mang nó và không phải chi tiêu ngày tìm ra những gì tôi đã làm trong mã.

Nếu bạn đang kế thừa mã, sau đó tôi có xu hướng nghĩ rằng có 2 trường phái tư tưởng phải làm gì với nó:

1) Giữ khoảng cách của bạn. Đây là nơi bạn thực hiện các thay đổi cần thiết để có được tính năng này và không thực hiện nữa. Nếu bạn biết mô-đun sẽ được thay thế sớm hoặc bạn chỉ làm việc này một lần hoặc hai lần một năm, sau đó tôi có thể thấy logic trong không muốn dành nhiều thời gian sửa chữa nó.

2) Đắm mình và sửa nó ngay bây giờ. Nếu những gì bạn làm là thay đổi khá rộng hoặc là một đoạn mã mà bạn sẽ làm việc thường xuyên, thì nó có thể được xem như là một phần của việc bảo trì để thực hiện một số phép tái cấu trúc hoặc tài liệu hoặc bạn muốn mô tả nơi mã xấu được biến thành mã không quá xấu vì điều này sẽ giúp bạn tiết kiệm thời gian sau này.

Answer 2

Cách TDD tiêu chuẩn là Red-Green-Refactor: thực hiện kiểm tra không thành công, viết mã để vượt qua bài kiểm tra, sau đó sửa lại mã hiện tại trong khi vẫn vượt qua các bài kiểm tra. Tái cấu trúc xảy ra sau khi kiểm tra vượt qua và khi bạn tìm thấy mã quá phức tạp hoặc sử dụng các mẫu xấu. Tái cấu trúc nên là một phần của quá trình phát triển hàng ngày, bình thường của bạn và không phải là một phần bổ sung vào cuối chu kỳ phát triển. Nó hoạt động tốt hơn, tôi nghĩ, để giữ cho các refactorings nhỏ. Làm nó như là một phần của hoạt động thường xuyên của bạn giữ cho mã nghèo phát triển quá lớn trước khi việc tái cấu trúc diễn ra - ít nhất là lý tưởng.

Answer 3

Tái cấu trúc không phải là điều tôi dành thời gian để làm riêng. Tôi liên tục làm điều đó khi tôi phát triển mã mới hoặc khi tôi duy trì mã cũ. Làm việc theo thói quen bình thường của bạn và luôn tìm kiếm những thứ bạn có thể cải thiện trong mã của mình.

Để trả lời trường hợp cụ thể mà bạn đã thêm vào câu trả lời của riêng mình cho câu hỏi này: Tôi nghĩ rằng tình huống của bạn là một ví dụ hoàn hảo khi bạn nên thay đổi lại tổng số thay vì viết lại toàn bộ. Đảm bảo bạn viết một nhóm các trường hợp thử nghiệm tốt cho mã được đề cập đến trước bạn thay đổi một dòng mã. Nếu mã không thành công, nó sẽ phục vụ ba mục đích. Đầu tiên, nó sẽ cung cấp cho bạn các khu vực cụ thể để tập trung nỗ lực của bạn vào. Thứ hai, nó sẽ cung cấp cho bạn một sự biện minh vững chắc (cho sếp của bạn) để làm việc trên mã. Thứ ba là mạng an toàn thử nghiệm đơn vị tiêu chuẩn mà bạn muốn có tại bất kỳ thời điểm nào bạn mã refactor.

Answer 4

Tái cấu trúc là thứ mà tôi liên tục phát triển thông qua phát triển chứ không phải thứ tôi định làm. Bất cứ khi nào mã đề xuất nó có thể được cấu trúc tốt hơn theo một cách nào đó, tôi thực hiện các thay đổi thích hợp.

Bạn không bao giờ có thể mong đợi thiết kế chính xác. Các sắc thái thực sự thể hiện bản thân trong quá trình thực hiện và bằng cách liên tục tái cấu trúc, bạn luôn cố gắng đạt được một mã được thiết kế và nhân cách tốt hơn.

Answer 5

Tôi thường không làm điều đó trừ khi tôi biết tôi sẽ sao chép mã. Vì vậy, khi viết một tính năng mới, nếu tôi thấy mình nói "hmm tôi đã làm một cái gì đó như thế này ở một nơi khác ..." Tôi cố gắng xem cách tôi có thể cấu trúc lại bản gốc để cho phép sử dụng lại nhiều mã nhất có thể.

Answer 6

Tôi refactor như tôi đi và tôi cố gắng giữ cho nó nhanh chóng và an toàn - tốt hơn khu vực của mã được kiểm tra, tôi càng có thể làm một cách nhanh chóng và an toàn. Ngoài ra, tôi đánh dấu các khu vực hoặc vấn đề kiến ​​trúc mà tôi nghĩ cần sửa chữa lớn hơn và cố gắng lên lịch các phiên lớn hơn một cách riêng biệt - thường là điều khiến chúng lớn hơn là thiếu kiểm tra, có nghĩa là tôi phải bỏ ra kiểm tra mà tôi cần.

Answer 7

Để tham gia vào một vấn đề cụ thể: Có một dự án có một số mã xấu được viết (ngay cả những người không còn trong công ty) trong một vài tháng nữa. Viết lại đầy đủ sẽ không khả thi và tôi không thể giải thích cho khách hàng hoặc quản lý.

Vì vậy, tôi đã tự hỏi nếu tái cấu trúc một mô-đun nhất định trước khi thực hiện thay đổi trên mô-đun đó sẽ được chấp nhận trong tình huống đó.

Tôi biết đó không phải là kịch bản tốt nhất nhưng ngữ cảnh là trường hợp đặc biệt (mã đã bị hỏng, không thể viết lại tất cả).

Answer 8

Tôi nghĩ câu trả lời đúng là: luôn là! Trong khi làm việc trên tính năng mới nếu tôi thấy một đoạn mã mà tôi có thể cấu trúc lại, tôi chỉ làm điều đó. Vì tôi sử dụng TDD, tôi không sợ rằng chức năng cũ sẽ ngừng hoạt động.

Answer 9

Khi mã của bạn smells

Answer 10

Tôi sẽ nói rằng tôi tìm kiếm mã mùi là tốt, nhưng tôi muốn cụ thể hơn. Tôi đang sử dụng một khuôn khổ thiết kế của tôi đang phát triển và phát triển với từng dự án. Tôi sẽ có khuynh hướng tái cấu trúc lại và thiết kế lại (kỷ luật bản thân mình để giữ riêng biệt những thứ mà tôi vẫn đang làm) trong một dự án và khi tôi đến gần thời hạn và gần hơn để giải quyết bất kỳ vấn đề hoặc mùi mã nào tôi sẽ giảm bớt và tập trung vào việc triển khai cụ thể của tôi. Khi tôi làm điều này, tôi thường sẽ tìm thấy (hoặc tạo ra) một vài điều nữa, trong khi chức năng, tôi không hoàn toàn hài lòng với. Tôi sẽ ghi lại những điều này và trong lần lặp lại tiếp theo của tôi thông qua dự án, tôi sẽ giải quyết những vấn đề này.

Khi tôi quay lại mã, đôi khi tôi sẽ thấy rằng có một cách thanh lịch hơn để xử lý tình huống và tự đá mình vì không nhìn thấy nó sớm hơn. Đôi khi, tôi sẽ tìm thấy có một cách tốt hơn, nhưng nó không phải là cách tôi đã hình dung ban đầu. Đôi khi tôi thấy rằng nó là tốt theo cách của nó và thay đổi nó sẽ được thiết kế quá mức. Lần khác tôi thấy rằng trong việc sửa chữa một cái gì đó khác, vấn đề ban đầu của tôi đã biến mất.

Answer 11

1. Khi tôi chuẩn bị để thực hiện một sự thay đổi chức năng mã (tính năng, sửa chữa lỗi, hiệu suất, bất cứ điều gì), lần đầu tiên tôi tự hỏi những gì nó sẽ như thế nào nếu mã được lý tưởng cấu trúc để thực hiện thay đổi đó.

2. Sau đó, tôi refactor theo hướng đó

3. bây giờ tôi thực hiện thay đổi chức năng.

4. Cuối cùng, tôi tái cấu trúc lại để làm sạch sự xấu xí được giới thiệu bởi thay đổi của tôi.

Tôi luôn muốn cân bằng công việc tái cấu trúc với các yếu tố khác (thời hạn, tầm quan trọng của mã này, chất lượng phạm vi kiểm tra, v.v.).

Answer 12

Nếu bạn không cần phải thay đổi mã đó (nó hoạt động, không cần phải mở rộng nó), không làm điều đó. Để cho nó được. Nói cách khác, nếu nó cần thay đổi trong nó, hãy viết một số kiểm thử một trình cấu trúc lại nó và bao gồm các thay đổi của bạn.

Answer 13

Tôi tự coi mình là lập trình viên mới (tôi đã lập trình để kiếm sống chỉ trong 6 tháng tại thời điểm này) và tôi đã nhận thấy rằng chỉ bằng cách xem mã bạn sẽ có cảm giác nếu cần tái cấu trúc hoặc không phải.

Theo tôi hiểu, một số tham chiếu đến điều này là "mã ngửi" nhưng tôi muốn nói rằng đó là cảm giác bất công khi bạn chưa thực hiện tốt nhất với mã bạn đang nhắm đến. Bạn có thể không chắc chắn phải làm gì hoặc làm thế nào để cải thiện mã nhưng nếu bạn có ngay cả những nghi ngờ nhỏ nhất của rằng mã không hoàn hảo thì nó rất có thể là không.

Answer 14

Bạn có thể thường phạm vi thậm chí nhỏ hơn mô-đun. Đôi khi một chức năng đơn lẻ sẽ là một ứng cử viên rõ ràng để tái cấu trúc trong sự cô lập, ngay cả khi nó chỉ đổi tên các biến địa phương, loại bỏ nhu cầu nhận xét bằng cách làm cho mã giải thích chính nó, những thứ như thế.

Nếu bạn có thể xác định một khu vực cần được thay đổi, hãy dọn sạch khu vực đó trước và trong khi thực hiện thay đổi. Thường thì tôi thấy tôi cần thực hiện một số phép tái cấu trúc để có đủ hiểu biết về mã để thực hiện thay đổi.

Tôi muốn thêm giọng nói của mình vào những người khác nói để nhận được một số loại thử nghiệm được bao bọc xung quanh mã. Cố gắng ít nhất bao gồm một tập hợp các trường hợp "bình thường" hợp lý và nhận được một số tự động tại chỗ (có sẵn các khuôn khổ cho mọi ngôn ngữ) để dễ dàng và nhanh chóng chạy thử nghiệm của bạn sau mỗi thay đổi nhỏ. Tôi muốn tôi nghĩ về/được biết về các khuôn khổ thử nghiệm khi tôi bắt đầu các hoạt động dọn dẹp mã của mình ...

Answer 15

Nếu tôi tiếp tục truy cập lại mã đó khi sửa lỗi, tôi xác định thời gian để cấu trúc lại nó. Nếu tôi đã tham gia một dự án mới hoặc chịu trách nhiệm về mã mới, tôi cũng ngồi xuống và bắt đầu tái cấu trúc. Nếu tôi đang mở rộng một cái gì đó, thì trước khi có bất kỳ thay đổi lớn nào tôi đã cấu trúc lại tất cả các vấn đề cũ trước (trước khi chúng trở nên quá ăn sâu).

Bạn đã hoàn tất việc tái cấu trúc khi bạn đã đạt đến một số cấp được nhắm mục tiêu là normalization. Nếu nó chỉ làm sạch chung: 1,2 hoặc 3 là đủ tốt. Nếu bạn đang mở rộng mã, thì 4 hoặc 5 là tốt hơn. Nếu bạn thực sự cố gắng tận dụng công việc hiện tại trong một thời gian dài, thì 6 là cách để đi.

Paul.

Answer 16

Để chỉ trả lời một phần câu hỏi của bạn: tôi sẽ nhắc lại một số điểm của những người khác ở đây - nói chung, nếu bạn không có một bộ thử nghiệm lặp lại mà bạn có thể chạy để đảm bảo rằng bạn thay đổi đã không phá vỡ mã - sau đó bạn có lẽ không nên refactor ở tất cả.

Bạn đã nói mã đã bị hỏng.Bạn có thể bị cám dỗ để đi với ban đầu làm cho ít, thay đổi nhỏ để nó càng tốt, để có được nó "làm việc". Rắc rối là, nếu không có một thử nghiệm, làm thế nào bạn có thể nói nó thực sự là "làm việc"?

Chúc bạn may mắn!