Tại một thời điểm nào đó trong sự nghiệp Rails, bạn sẽ gặp phải một bộ điều khiển khiến bạn muốn từ bỏ lập trình mãi mãi. Nó có thể chứa mọi dòng mã cho toàn bộ tính năng. Nó có thể có 15 before_filters rằng tất cả đều giao tiếp thông qua các biến thể hiện và phải được gọi theo một thứ tự cụ thể hoặc mọi thứ sẽ nổ tung. Và, chắc chắn, các bài kiểm tra của nó sẽ như thế này:
test "index" do
get :index
assert_response :success
end
Đáng kinh ngạc. 100% phạm vi kiểm tra, phải không?
Tuyệt vời như bạn chỉ cần nhắm mắt lại và giả như nó không tồn tại, một ngày nào đó bạn sẽ phải sửa lỗi ở một trong những bộ điều khiển này. Và, là một nhà phát triển phần mềm giỏi, bạn muốn để lại mã tốt hơn những gì bạn tìm thấy.
Nhưng làm thế nào bạn có thể cấu trúc lại, đặc biệt là không có các thử nghiệm tốt để dựa vào?
Kiểm tra nó (bằng cách nào đó)
Bạn cần có các bài kiểm tra tốt để cảm thấy an toàn trong khi cấu trúc lại, nhưng bạn không thể viết các bài kiểm tra tốt đối với mã này cho đến khi bạn tái cấu trúc. Vậy bạn có thể làm gì?
Chà, cho dù bộ điều khiển của bạn được viết tệ đến mức nào, bạn vẫn có thể viết các bài kiểm tra tích hợp gửi một số dữ liệu đến bộ điều khiển và mong đợi một số phản hồi từ nó. Hiện tại, bạn nên viết các bài kiểm tra để đảm bảo rằng bộ điều khiển hiện có hành vi không thay đổi khi bạn tái cấu trúc.
Các bài kiểm tra này sẽ không tập trung như các bài kiểm tra đơn vị. Nhưng những bài kiểm tra cấp cao này có thể khiến bạn cảm thấy thoải mái rằng việc tái cấu trúc mà bạn sắp thực hiện sẽ không phá vỡ mọi thứ. Và quá trình viết chúng sẽ giúp bạn hiểu mã của mình tốt hơn, điều này sẽ giúp bạn quyết định cách cấu trúc lại mã.
Phá vỡ sự phụ thuộc của bạn
Điều gì làm cho mã bộ điều khiển xấu trở nên tồi tệ? Hầu hết thời gian, đó là sự phụ thuộc ngầm định giữa before_filters , phương thức trợ giúp hoặc các phần khác nhau của hàm 200 dòng. Nó cũng có thể là một trường hợp tái cấu trúc quá sớm. Để làm cho mã tốt hơn, bạn cần phải phá vỡ các phụ thuộc này.
Đối với bộ điều khiển Rails, có một cách dễ dàng để phá vỡ các phần phụ thuộc. Chỉ cần sao chép mã từ before_filters của bạn , phương thức trợ giúp, lớp cha và bất kỳ nơi nào khác có thể ẩn mã controller-ish. Sau đó, thay thế các lệnh gọi đến các phương thức đó bằng mã bạn đã sao chép.
Bạn đang tạm thời bỏ KHÔ mã của mình, vì vậy bạn có thể cấu trúc lại mã theo cách dễ hiểu hơn sau này. Thật là xấu, nhưng bây giờ tất cả mã của bạn đang ở trạng thái mở. Bạn sẽ có thể thấy những phần nào tương tác và mọi thứ trôi chảy như thế nào.
(Trong quá trình này, bạn nên chạy thử nghiệm của mình sau mỗi lần thay đổi để đảm bảo rằng nội tuyến của bạn không vi phạm bất kỳ điều gì.)
Refactor hướng tới mã có thể kiểm tra
Bây giờ, bạn đã sẵn sàng để cấu trúc lại mã của mình. Có thể bạn sẽ tuân theo phương pháp trích xuất cơ bản , trích xuất đối tượng , phương pháp kéo lên - loại tái cấu trúc. Hãy thử cấu trúc lại mã của bạn theo một vài cách khác nhau và xem cách nào phù hợp nhất.
Trong vài lần vượt qua đầu tiên, bạn có thể dựa vào các thử nghiệm tích hợp cấp cao của mình như một mạng lưới an toàn. Nhưng chẳng bao lâu nữa, bạn sẽ muốn thứ gì đó tốt hơn.
Khi bạn cấu trúc lại, hãy tìm cơ hội để làm cho mã của bạn dễ kiểm tra hơn. Điều này thường có nghĩa là tạo ra các vị trí để tăng gấp đôi thử nghiệm, giảm sự phụ thuộc giữa các đối tượng của bạn và làm cho bộ điều khiển của bạn dựa vào các đối tượng có thể dễ dàng tạo và kiểm tra đơn vị. Bằng cách chuyển mã vào các đối tượng có thể kiểm tra, bộ điều khiển của bạn sẽ nhỏ hơn, dễ hiểu hơn và dễ tự kiểm tra hơn.
Tôi có thể lấy nó ở dạng danh sách được đánh số không?
Một lần nữa, đây là các bước cần thực hiện để phá vỡ bộ điều khiển lớn:
- Nhận các bài kiểm tra tích hợp cấp cao chạy trên bộ điều khiển.
- Chạy các bài kiểm tra, đảm bảo chúng vượt qua.
- Inline
before_filters, các phương thức siêu lớp và các phần tóm tắt khác ẩn mã. - Chạy các bài kiểm tra, đảm bảo rằng chúng vẫn vượt qua.
- Thực hiện tái cấu trúc ( phương pháp trích xuất , trích xuất đối tượng dịch vụ , thay thế biến phiên bản bằng local , vân vân.). Xem mã có cảm thấy tốt hơn không.
- Chạy các bài kiểm tra, đảm bảo rằng chúng vẫn vượt qua.
- Nếu bạn vừa trích xuất mã, hãy viết một số bài kiểm tra đơn vị dựa trên đối tượng hoặc phương pháp bạn đã trích xuất.
- Chạy các bài kiểm tra, đảm bảo rằng chúng vẫn vượt qua.
- Nếu bộ điều khiển vẫn cần hoạt động, hãy quay lại bước 5.
Tiếp theo là gì?
Nếu bạn muốn tìm hiểu thêm, Làm việc hiệu quả với Mã kế thừa là kinh thánh về việc lấy mã không thể xác minh được mà không cần kiểm tra và biến nó thành thứ bạn có thể làm việc. Tôi thực sự khuyên bạn nên sử dụng nó , nếu bạn thấy mình thường xuyên phải đối mặt với các bộ điều khiển nguyên khối khổng lồ (và nếu việc tái cấu trúc cũng thú vị với bạn như đối với tôi).
Vậy bây giờ, hãy nghe những câu chuyện kinh dị của bạn! Mã bộ điều khiển tồi tệ nhất mà bạn từng làm việc trông như thế nào?