Helpex - Trao đổi & giúp đỡ Đăng nhập

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

mười năm trước, tôi đã lãnh đạo một nhóm cho một khách hàng ngân hàng để trẻ hóa nền tảng giao dịch fx của họ. một khía cạnh của nhiệm vụ đó là cắt bỏ giải pháp đơn độc hiện có để tạo ra một đơn vị sạch hơn và dễ kiểm tra hơn. Tôi đã viết nghiên cứu điển hình cho dự án phân rã có phương pháp (và có thể tạm dừng ) này qua một vài bài báo trước:

từ bài báo năm 2008 - bài báo đã giới thiệu thành phần phụ thuộc nhiều nhất và ít phụ thuộc nhất như một chiến lược - một nỗ lực để tìm một phép ẩn dụ trực quan cho sự vướng víu / rối loạn:

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

Tuy nhiên, ngày nay, một bản trình chiếu từ trước đó đã được sử dụng để thuyết phục khách hàng bắt đầu công việc trẻ hóa.

lưu ý: vì mục đích của bài viết này 'singleton' là nhóm gồm bốn mẫu , không phải là thành ngữ spring / guice.

mười một trang trình bày hiển thị lần tái cấu trúc đầu tiên

kiến trúc như được mô tả bởi khách hàng:

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

điểm khởi đầu là cấp kinh doanh hợp lý:

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

hóa ra, nó không bị phân hủy như hy vọng:

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

tạo khoảng trống trong sơ đồ cho nhiều ô hơn:

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

giới thiệu công cụ định vị dịch vụ và một nơi cho các thành phần được tái cấu trúc:

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

xác định thành phần ** phụ thuộc nhiều nhất và ít phụ thuộc nhất **,:

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

di chuyển nó sang cơ sở mã mới (đảm bảo rằng các thử nghiệm đơn vị của nó cũng xuất hiện và làm trẻ hóa chúng):

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

trong cơ sở mã cũ, hai thành phần phụ thuộc hiện tìm kiếm thành phần mới thông qua bộ định vị dịch vụ. một phần mới và một phần cũ, ứng dụng / dịch vụ sẽ hoạt động tại thời điểm này:

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

xác định một thành phần khác để di chuyển (phụ thuộc nhiều nhất và phụ thuộc ít nhất):

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

di chuyển nó như trước đây. lần này với sự phụ thuộc tồn tại từ trước (thông qua bộ định vị dịch vụ):

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

trong cơ sở mã cũ, hãy thêm một lần tra cứu nữa cho thành phần mới (thông qua bộ định vị dịch vụ). lặp lại ba bước cuối cùng cho đến khi không còn singleleton:

Java Legacy Hairball: Nghiên cứu điển hình về cấu trúc lại

một bản chất có phương pháp cho điều này

nỗ lực tái cấu trúc có thể tạm dừng ở bất kỳ giai đoạn nào (vì có các ưu tiên cao hơn cho nhóm phát triển) hoặc tiếp tục một cách có phương pháp với các ưu tiên kinh doanh khác. thực sự, ứng dụng / dịch vụ hoạt động theo một nhịp nhất định có lẽ phải là một phần chức năng mới và một phần tái cấu trúc. để đạt được điều đó, bạn thực sự muốn phát triển dựa trên thân cây và thậm chí có thể là phân phối liên tục. nếu công việc này được thực hiện trên một chi nhánh riêng biệt, với lời hứa sẽ hợp nhất trở lại sau đó (và hoạt động), thì nguy cơ doanh nghiệp ngừng sáng kiến ​​ngày càng tăng, có lẽ không thể thu hồi với những hậu quả ảnh hưởng đến sự nghiệp.

dự án trở lại năm 2006?

chúng tôi đã đồng thời di chuyển từ phân nhánh nhiều nhánh sang lực lượng thân đơn. các thành phần được định hình đầu tiên trong chữ in rõ ràng, và bị loại bỏ khi chúng được đặt trong thân cây lực lượng trong cây nguồn phân cấp và xây dựng (kiểu maven, nhưng theo kiểu kiến). những thứ từ bản rõ ràng vốn cần các thành phần bây giờ trong perforce đã tìm thấy chúng trong 'nhị phân repo' (sau đó là webdav, nhưng giống như mối quan hệ của sonatype hoặc kiểu nghệ thuật). dần dần, các thành phần (và các thử nghiệm của chúng) đã di chuyển ra khỏi chữ cái rõ ràng và vào thân cây lực lượng với một bản dựng phân cấp. cruisecontrol (tiền thân của jenkins, v.v.) có một bản dựng sẽ tạo ra các tạo tác nhị phân trong repo, cũng như sử dụng chúng trong các bản dựng. đường ống ci đó sẽ được kích hoạt bằng các cam kết đối với một trong hai scms và cũng như các tệp nhị phân được thay thế trong kho nhị phân.

trong khi đó, các nhóm không tập trung lặp lại quá trình di chuyển sẽ tiếp tục với chức năng kinh doanh. tổng chức năng kinh doanh và tái cấu trúc được đưa vào cùng một bản phát hành, trên một nhịp không thay đổi (hoặc tốt hơn). doanh nghiệp không bao giờ biết việc tái cấu trúc đang diễn ra hoặc phạm vi kiểm tra đang tăng lên.

nguyên tắc chỉ đạo là chỉ tấn công "thành phần phụ thuộc nhiều nhất và ít phụ thuộc nhất ". mỗi lần đạt được điều đó, sẽ có một ứng cử viên mới cho điều đó trong quả cầu tóc.

một vài năm sau, tại google, tôi đã làm việc với thực tập sinh của nhà sáng tạo góc cạnh misko hevery (david rubel) trên máy dò google singleton . điều này giúp dễ dàng xác định trực quan thành phần phụ thuộc và ít phụ thuộc nhất cho các sáng kiến ​​trong tương lai. đã giúp, có lẽ, nó có thể không hoạt động với java 8/9 nữa.

sau khi tất cả các single đã biến mất, điều gì tiếp theo?

tất nhiên là đi tiêm phụ thuộc. bạn sẽ thực hiện việc này trong một loạt lần tái cấu trúc thứ hai và dừng lại khi không còn gì sử dụng bộ định vị dịch vụ nữa. cái sau phải đi yên, vì nó tạo điều kiện cho trạng thái có thể thay đổi tĩnh không mong muốn.

danilo sato chỉ cho bạn cách với ý tưởng intellij, trong video siêu ấn tượng này:

ref: thử nghiệm tái cấu trúc trên vimeo.


danilo thực hiện tái cấu trúc tại một thời điểm đẩy các tra cứu của bộ định vị dịch vụ lên đến phương thức khởi tạo, sau đó đến các tham số của phương thức khởi tạo và cuối cùng là hướng tới lớp khởi động tạo ra giải pháp.

Mục nhập blog của danilo đi kèm với video: chiến lược tái cấu trúc: một thử nghiệm hướng dẫn .

20 hữu ích 0 bình luận 13k xem chia sẻ

Có thể bạn quan tâm

loading