Thứ Bảy, 31 tháng 3, 2018

Đây là chương 10 trong cuốn DDD của Eric Evans nói về thế nào là 1 thiết kế tốt, và khi refactoring ta nên làm gì để có một thiết kế tốt.



Tại sao phải chú ý đến việc tạo ra một thiết kế tốt?
Một phần mềm được viết ra với mục đích phục vụ người dùng, nhưng trước hết những người lập trình viên là người sử dụng nó đầu tiên, điều này được thể hiện rất rõ trong quá trình Refactoring code. Trong quá trình phát triển phần mềm, người lập trình viên phải quay lại, thay đổi, viết thêm rất nhiều dòng code. Cứ thử tưởng tượng, sau 1 vài nằm làm trên cùng 1 sản phẩm, bạn quay lại để thêm các tính năng mới, hay bảo trì hệ thống cũ bạn sẽ thấy gì?

Với một thiết kế không tốt bạn sẽ gặp phải các vấn đề như:

Rất khó để refactor hay kết hợp các phần code cũ với nhau, nhiều duplication code xuất hiện, và bạn không thể tự tin để thay đổi 1 tính năng vì không biết nó sẽ ảnh hưởng những gì tới các thành phần cũ.
Duplication Code bị ép buộc một cách tự nhiên, khi bạn viết chương trình theo dạng nguyên khối (Monolithic). Điều này có thể giảm bớt bằng các tách nhỏ thành nhiều Class hay các method dùng chung, nhưng với cách này, hệ thống của bạn ngày càng kết thành 1 khối lớn hơn, các phần ràng buộc với nhau bởi các sợi chỉ mỏng nhỏ (các method dùng chung), sửa 1 chỗ ảnh hưởng tới rất nhiều chỗ, nó khíến bạn sợ hãi khi quay lại làm, bạn sợ refactoring, hệ thống của bạn sẽ dần dần mất kiểm soát.
Thế nào là 1 thiết kế tốt?
The design must serve the developer working to change it. To be open to change, a design must be easy to understand, revealing that same underlying model that the client developer is drawing on. It must follow the contours of a deep model of the domain, so most changes bend the design at flexible points. The effects of its code must be transparently obvious, so the consequences of a change will be easy to anticipate. see DDD by Eric Evans page 155.

Một thiết kế được gọi là tốt khi nó dễ thay đổi, dễ hiểu, các “side effects” phải minh bạch rõ ràng, giúp người lập trình viên nhanh chóng nhìn ra các ảnh hưởng khi thay đổi.

Supple Design là cái gì?
Supple design is the complement to deep modeling. Once you've dug out implicit concepts and made them explicit, you have the raw material. Through the iterative cycle, you hammer that material into a useful shape, cultivating a model that simply and clearly captures the key concerns, and shaping a design that allows a client developer to really put that model to work. Development of the design and code leads to insight that refines model concepts. Round and round—we're back to the iterative cycle and refactoring toward deeper insight. see DDD by Eric Evans page 155.



Lập trình viên được chia làm 2 loại: 

Developer: Người trực tiếp viết ra đoạn code, hay interface
Client: Người dùng lại Interface mà Developer viết ra để

Reactions: