Kiến trúc tiến hóa và thiết kế nổi dần: Tái cấu trúc mã nguồn hướng theo thiết kế pdf

Kiến trúc tiến hóa và thiết kế nổi dần: Tái cấu trúc mã nguồn hướng theo

thiết kế

Tìm và thu thập thiết kế ẩn trong mã của bạn

Neal Ford, Kiến trúc phần mềm, ThoughtWorks

Tóm tắt: Các bài viết trước đây của loạt bài viết này thảo luận về việc kiểm thử

đơn vị giúp bạn có một thiết kế tốt hơn như thế nào. Nhưng nếu bạn đã có rất

nhiều mã, thì làm thế nào bạn có thể khám phá các yếu tố thiết kế ẩn bên trong các

mã đó? Bài viết trước đã bàn về xây dựng các đích cấu trúc cho mã của bạn. Trong

bài viết này, tác giả Neal Ford của của loạt bài viết mở rộng các ý tưởng đó và nói

về các kỹ thuật sử dụng tái cấu trúc mã nguồn để cho phép thiết kế nổi dần lên.

Trong hai bài viết "Thiết kế hướng kiểm thử, phần 1" và "Thiết kế hướng kiểm

thử, phần 2," tôi đã nói về cách mà việc kiểm thử có thể dẫn đến thiết kế tốt hơn

cho các dự án mới. Trong phần "Phương thức hợp thành và SLAP," (N.D: SLAP

là viết tắt “single level of abstraction principle” - nguyên tắc chỉ một mức trừu

tượng) tôi có nói về hai mẫu trọng yếu — phương thức hợp thành và nguyên tắc

chỉ một mức trừu tượng — hai mẫu này mang lại cho bạn một cái đích tổng thể

cho cấu trúc mã của bạn. Hãy ghi nhớ các mẫu này. Khi bạn có một dự án phần

mềm đang tồn tại rồi, thì tuyến đường để phát hiện và thu thập các yếu tố thiết kế

nằm trong việc cấu trúc lại mã nguồn. Trong cuốn sách kinh điển Tái cấu trúc mã

nguồn, của mình, Martin Fowler đã định nghĩa tái cấu trúc mã nguồn "là một kỹ

thuật có quy tắc để cấu trúc lại phần chính yếu hiện tại của mã, thay đổi cấu trúc

bên trong của nó mà không thay đổi hành vi bên ngoài của nó" (xem phần Tài

nguyên). Cấu trúc lại mã nguồn là một phép chuyển đổi cấu trúc có mục đích. Có

một cơ sở mã dễ cấu trúc lại là một mục tiêu đáng khen ngợi của bất kỳ dự án nào.

Trong bài viết này, tôi nói về cách sử dụng việc tái cấu trúc mã nguồn như thế nào

để tìm ra một thiết kế chưa được sử dụng đúng mức còn ẩn giấu trong mã của bạn.

Về loạt bài viết này

Loạt bài viết này nhằm cung cấp một phối cảnh tươi mới về các khái niệm thường

được thảo luận nhưng khó nắm bắt về kiến trúc và thiết kế phần mềm. Thông qua

các ví dụ cụ thể, Neal Ford mang đến cho bạn một nền tảng vững chắc cho cách

làm thực tế lanh lẹn của kiến trúc tiến hóa và thiết kế nổi dần. Bằng cách trì hoãn

các quyết định quan trọng về thiết kế và kiến trúc cho đến thời điểm quyết định

cuối cùng, bạn có thể ngăn ngừa được những phức tạp không cần thiết không để

chúng ngầm phá hoại các dự án phần mềm của bạn

Các kiểm thử đơn vị là cái lưới an toàn chính cho phép bạn tuỳ ý cải tiến cơ sở mã

của mình. Nếu bạn có mức bao quát kiểm thử là 100 phần trăm mã của dự án của

mình, thì bạn có thể cấu trúc lại mã của mình mà không gặp rắc rối nào. Nếu bạn

không theo đuổi mức kiểm thử đó, thì việc quá hăng hái cấu trúc lại mã nguồn sẽ

nguy hiểm hơn. Các thay đổi được khoanh vùng rất dễ áp dụng và bạn có thể thấy

tác dụng ngay lập tức của chúng, nhưng các rạn vỡ do tác dụng phụ lâu dài về sau

này sẽ làm cho bạn điêu đứng. Phần mềm sẽ dẫn đến những điểm kết dính không

mong muốn, và một thay đổi nhỏ đối với một phần của mã có thể lan truyền qua

cơ sở mã, gây ra lỗi cho hàng trăm dòng mã từ việc thay đổi đó. Sự tự tin để sửa

đổi mã và tìm ra những lỗi lan xa này là một dấu hiệu nổi bật của kiểm thử đơn vị

bao quát mọi nơi. Một dự án kéo dài trong 2 năm của công ty tư vấn

ThoughtWorks đã được người phụ trách kỹ thuật tiến hành 53 lần cấu trúc lại mã

nguồn khác nhau cho đến tận ngày trước khi dự án đi vào hoạt động. Ông đã làm

điều này với sự tự tin thanh thản vì dự án bao trùm toàn bộ mã.

Làm thế nào để đưa cơ sở mã của bạn tới chỗ có thể thực hiện được những đợt tái

cấu trúc mã nguồn rộng lớn? Một lựa chọn là từ chối viết thêm mã khác cho đến

khi bạn có thời gian để thêm các phép kiểm thử cho toàn bộ dự án. Ngay khi bạn

đề xuất việc này thì bạn sẽ bị đuổi việc và bạn có thể đi làm việc cho một công ty

coi trọng việc kiểm thử đơn vị hơn. Cách tiếp cận này có thể là không tối ưu. Lựa