Các Nguyên Tắc Phát Triển Phần Mềm Cơ Bản
Thiết kế kiến trúc phần mềm đóng vai trò quan trọng trong việc giúp mã nguồn dễ hiểu, khả chuyển và dễ bảo trì. Vấn đề là có rất ít người hiểu về các bộ nguyên tắc này, từ các lập trình viên mới vào nghề đến các tay to nhiều năm kinh nghiệm (lặp đi lặp lại), hệ quả là đầu tư lãng phí vào các phần mềm / hệ thống có tuổi đời rất ngắn do không đáp ứng được nhu cầu thực tế .
Dưới đây là một số nguyên tắc phải biết đối với một lập trình viên để phát triển phần mềm
KISS (Keep It Simple, Stupid!)
Được viết trong bộ nguyên tắc của thùy quân Mỹ những năm 1960, phát biểu như sau:
“Most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design, and that unnecessary complexity should be avoided”
DRY (Don’t Repeat Yourself)
Được viết bởi Andy Hunt and Dave Thomas trong quyển The Pragmatic Programmer, phát biểu như sau:
“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”
Bạn vi phạm nguyên tắc này khi copy một đoạn code từ chỗ này sang chỗ khác, lặp đi lặp lại một việc có thể xử lý đơn giản và tự động ngày này sang ngày khác.
Để tối ưu công việc hãy:
- Dựa vào IDE để phát hiện các đoạn code lặp lại nhiều lần, review code trước khi push lên
- Dựa vào kho thư viện common, util hoặc các trình gen code để tránh viết lại những hàm xử lý căn bản
- Dựa vào công cụ deploy để tránh nhiều bước deploy dịch vụ tốn thời gian
SOLID
SOLID là từ viết tắt của năm nguyên tắc phát triển phần mềm hướng đối tượng được viết trong bài viết “Design Principles and Design Patterns” được phát hành năm 2000 Robert Cecil Martin (Thường được biết với tên Uncle Bob).
Single responsibility principle
“Một module hay class được viết ra chỉ nên có một nhiệm vụ duy nhất đối với một phần chức năng của phần mềm”
Ví dụ khác: Với một yêu cầu api đổi paswword của người dùng trong hệ thống thì cần tách riêng các lớp tương tác dữ liệu (truy vấn vào database), xử lý nghiệp vụ (kiểm tra username cũ đúng, password cũ đúng, password mới hợp lệ), trả dữ liệu (qua api) thành ba class độc lập để khi có bất kì sửa đổi căn bản gì chỉ cần tương tác với một tầng class duy nhất.
Open/closed principle
“Thiết kế class dễ dàng mở rộng và mang tính khép kín khi có yêu cầu sửa đổi”
Liskov substitution principle
“Một đối tượng trong phần mềm có thể được thay đổi bẳng một subtype của nó mà không làm mất tính chính xác của phần mềm”
Interface segregation principle
“Nhiều interface chi tiết sẽ tốt hơn một interface quá tổng quát”
Dependency inversion principle
“Bao gồm hai phát biểu:
- Module cấp cao không nên phụ thuộc vào module cấp thấp, tất cả chỉ nên phụ thuộc vào lớp trừu tượng
- Các lớp cụ thể nên phụ thuộc vào lớp trừu tượng”
CHÚ Ý: Một phần mềm có thể chọn áp dụng một tập nguyên tắc phù hợp với nhu cầu và giai đoạn phát triển của mình. Cố gắng áp dụng toàn bộ trên một sản phẩm nhỏ, cần phát triển nhanh với các lập trình viên ít kinh nghiệm dẫn sẽ đến trễ deadline cùng đầu ra là một sản phẩm tồi!
Cách Áp Dụng
- Đọc các tựa sách gối đầu trong phát triển phần mềm như: Software Craftmanship, Clean Code.
- Đặt giả thiết mình vào vị trí của một lập trình viên mới tham gia, thiết kế hiện tại bây giờ có dễ hiểu không?
- Đặt giả thiết dự án có gấp đôi lượng lập trình viên đang có, thiết kế phần mềm hiện tại có khả năng hỗ trợ nhiều người cùng lập trình các module / task độc lập không? Có còn dễ dàng để áp dụng các quy trình đảm bảo chất lượng như review code vào không?
