Thiết kế thực dụng
White

Nghia Minh Le viết ngày 30/10/2016

Nhân đọc cuốn The Pragmatic Programmer - Lập trình viên thực dụng, note lại mấy dòng về tính thực dụng trong thiết kế.

Có một câu chuyện vui: có căn hộ đẹp đẽ, sang trọng, các đồ vật thật tinh tế, tấm thảm thật sang trọng, mọi thứ thật ngăn nắp. Một ngày kia, vô tình có hoả hoạn. Nhưng những người tới cứu hoả vì sợ làm hỏng các đồ vật, làm bẩn tấm thảm sang trọng, họ lúng túng, chậm chạp và cuối cùng cả căn hộ bị thiêu rụi.

Đôi khi một thiết kế đẹp, một thiết kế cẩn thận có thể rơi vào chính hoàn cảnh trên. Đó là khi một lập trình viên bước vào một project, nơi mà mọi thứ được làm quá đẹp đẽ, quá tinh tế. Và thật khó để anh ta nhanh chóng nắm bắt và hiểu hết tất cả ý đồ tinh tế mà người thiết kế ra project đó. Và một ngày kia “ngọn lửa deadline" bùng lên, lúc đó anh ta sẽ vô cùng lúng túng không biết sẽ phải làm sao cho không vỡ “món đồ”, “món đồ kia”... Rút cục thì plan bị “cháy rụi" vì không đảm bảo tiến độ và chất lượng.

Điều này đặt ra cho người làm architect một thách thức mới khi anh ta không chỉ có nhiệm vụ tạo ra một kiến trúc hoàn hảo, tuyệt mĩ, mà anh ta phải biết cân đối về mức độ phù hợp với hoàn cảnh của project. Nó vừa phải đảm bảo không quá lỏng lẻo, chẳng có quy củ chặt chẽ gì để nhanh chóng vỡ vụn, nhưng đồng thời vẫn đảm bảo khoảng để “sự bừa bãi" có thể khi cần.

Điều này nó cũng giống như quy hoạch một thành phố. Tại thời điểm bắt đầu, không ai có thể biết từng góc phố sẽ có các building hình hài ra sao, nhưng chắc chắn các đại lộ chính, quảng trường, các khu vực hành chính phải được quy hoạch và tuân thủ nghiêm ngặt. Nếu có một quy hoạch tốt như vậy, thì dù sự bữa bãi vẫn có thể chấp nhận trong các khoảng trống của từng khu vực. Và khi có điều kiện, nó sẽ được dọn dẹp mà không làm vỡ cấu trúc của cả thành phố, hay nói cách khác là chi phí nó đủ nhỏ để thực hiện.

Một thiết kế phần mềm cũng như vậy. Các cấu trúc layer, component, các quy định về việc bố trí mã nguồn, cấu trúc các model dữ liệu, xác thực, cách thức kết nối... phải rất chặt chẽ ngay từ đầu. Nhưng detail có thể để lại sau. Việc cố gắng phân tích quá chi tiết không những tốn kém resources, mà không chắc đã đáp ứng, hay sẽ rơi vào trạng thái ngôi nhà cháy ở trên.

Tìm ra điểm cân bằng là một thách thức với người thiết kế. Có lẽ vì vậy mà người ta gọi thiết kế phần mềm là một nghệ thuật.
Nhưng dù sao hãy luôn nhớ phải rất thực dụng trong mọi quyết định.

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Nghia Minh Le

10 bài viết.
115 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
29 0
1. Nguyên lý consistency của relational database – SQL Server. SQL Server nói riêng và các database quan hệ nói chung là dạng database có độ nhất...
Nghia Minh Le viết gần 2 năm trước
29 0
White
16 2
Mô hình Event Sourcing là một mô hình thiết kế hệ thống mà theo đó sẽ lưu giữ trạng thái thay đổi của một đối tượng là một chuỗi các thay đổi đã xả...
Nghia Minh Le viết gần 2 năm trước
16 2
White
9 1
Transaction và Distributed Transaction là các vấn đề phải đối mặt rất nhiều trong xây dựng các hệ thống lớn Enterprise Software. Nó ảnh hưởng rất l...
Nghia Minh Le viết gần 2 năm trước
9 1
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
10 bài viết.
115 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!