Thứ Tư, 22 tháng 2, 2017

Cách viết một tài liệu Detail Design hiệu quả

Càng ngày, các lập trình viên có thể làm được nhiều việc hơn trong thời gian ngắn hơn. Ngày nay, với nhiều ngôn ngữ lập trình cao cấp, môi trường làm việc, các công cụ hỗ trợ và tư tưởng phát triển phần mềm, cả LTV và nhà quản lý đều trở nên quen thuộc với việc cần phải tạo ra sản phẩm một cách cực kỳ nhanh chóng. Các lập trình viên có xu hướng bắt tay ngay vào bước coding vì sợ không kịp thời gian, chậm deadline, over-time...

Quá trình thiết kế trước khi coding đang trở thành lỗi thời. Tài liệu thiết kế đang hiếm dần. Nhiều LTV không bao giờ viết một tài liệu thiết kế, thậm chí không có ý định làm như vậy khi xây dựng phần mềm. Đến khi được yêu cầu, họ thường tạo ra rất nhiều sơ đồ tương tác và sơ đồ lớp mà thường không thể hiện quá trình suy nghĩ của họ trong giai đoạn thiết kế. Bài viết này sẽ thảo luận làm thế nào để viết một tài liệu thiết kế hiệu quả, chính xác. Đồng thời thảo luận về lý do tại sao một tài liệu thiết kế cũng là một trong những công cụ giá trị nhất khi thực hiện dự án.

Tại sao cần tài liệu thiết kế?

Tài liệu thiết kế là một cách để bạn giao tiếp với cộng sự về những giải pháp được chọn lựa, và trình bày lý do tại sao các giải pháp này là đúng đắn. Đừng lo lắng nếu như thiết kế của bạn không có đủ các sơ đồ, biểu đồ đúng chuẩn. Và cũng đừng lo lắng về các công cụ đặc biệt để tạo ra tài liệu. Yếu tố quyết định một tài liệu tốt là nó giải thích rõ ràng ý tưởng của bạn.
Việc diễn tả được ý tưởng là một vấn đề. Để truyền đạt được những giải pháp trong thiết kế, bạn phải xác định đến đối tượng người đọc. Đồng nghiệp của bạn có thể có cái nhìn khác so với quản lý của bạn, về kỹ thuật chuyên môn chẳng hạn. Vì vậy, thậm chí có hai tài liệu thiết kế riêng cho hai đối tượng này.

Điều gì tạo ra một thiết kế tốt?

Một thiết kế thường được coi là tốt nếu nó đáp ứng các yêu cầu một cách có ý nghĩa. Nếu bất kỳ khía cạnh nào của thiết kế không rõ ràng, nó có thể sẽ cần được đánh giá lại. Nhiều LTV cố gắng kết hợp các mẫu thiết kế thành công trước đây của họ và nhiều khi giờ đây nó trở nên phức tạp không cần thiết. Bạn nên liệt kê ít nhất một lý do thuyết phục để chứng minh cho giải pháp được lựa chọn. Nếu không tìm được lý do cho giải pháp mình lựa chọn thì nó chẳng có giá trị gì.
Các biểu đồ là công cụ tuyệt vời để diễn đạt thiết kế của bạn, nhưng nó không truyền tải nguyên nhân bạn chọn thiết kế ấy. Vì vậy nó quan trọng nhưng không phải là tất cả.
Các lợi ích khi chọn lựa giải pháp cần được trình bày. Tương tự các rủi ro liên quan cũng cần được nêu rõ. Bằng cách trình bày rõ ràng, đồng nghiệp có thể bàn bạc với nhau, tìm ra lỗ hổng, những rủi ro tiềm tàng, giúp giảm thiểu những vấn đề trong tương lai, trước khi bắt tay vào viết mã, tránh phải đập đi hàng ngàn dòng code do không lường trước được thay đổi.
Cuối cùng, thông qua tài liệu, mọi người sẽ sử dụng chung những thuật ngữ phổ biến của dự án. Tài liệu thiết kế cũng là một công cụ mạnh mẽ cho người quản lý nắm được tình hình dự án vì họ thường không tham gia quá sâu vào chuyên môn kỹ thuật.
Tài liệu dự án cũng đóng vai trò là một biên bản thống nhất giữa mọi người. Làm việc gì cũng tuân theo thiết kế và mọi người đều công nhận với nhau. Khi có điều gì thay đổi, cần được thống nhất lại và biên bản hóa nó.

Các nội dung của thiết kế

Mục đích dự án (Purpose): Trong đoạn này, viết một đoạn ngắn gọn mô tả những gì hệ thống thực hiện, vấn đề nó đang cố gắng để giải quyết là gì. Tại sao nó cần để tồn tại. Ai sẽ sử dụng nó. Bằng cách trả lời những câu hỏi này, bạn thiết lập phạm vi thiết kế của bạn. Nếu bạn cảm thấy khó khăn để viết đoạn này, bạn chưa hiểu đủ về domain. Sử dụng phần này như một công cụ để xác định phạm vi.

Xác định các thực thể ở mức high level (high level entities): Các đơn vị cấp cao là các đối tượng, các nhóm đối tượng tạo thành cấu trúc chính của thiết kế. Ví dụ các thực thể là một lớp truy cập dữ liệu, một đối tượng điều khiển, một tập các đối tượng nghiệp vụ. Ví dụ:

Trong phần này, mô tả ngắn gọn từng thực thể là gì, vai trò, lý do.

Xác định low level trong từng thực thể: Định nghĩa các đối tượng và các mối quan hệ của chúng:
+ Sử dụng (Usage): Mô tả một đoạn cách sử dụng thực thể, chức năng của nó trong hệ thống. Quan trọng nhất là bạn phải mô tả quá trình suy nghĩ đã xác định đối tượng. Liệt kê những lợi ích và rủi ro.
+ Cấu hình (Configuration): Nếu đối tượng cần cấu hình hoặc khởi tạo, hãy mô tả nó.
+ Mô hình (Model): Đừng lo lắng về độ hoàn hảo của sơ đồ, nhưng hãy chắc chắn mô tả những gì đang xảy ra trong sơ đồ.
+ Tương tác (Interaction): Một sơ đồ tương tác cho thấy làm thế nào một tập các đối tượng hoặc các thực thể giao tiếp với nhau để thực hiện một nhiệm vụ phức tạp. Ví dụ:

Lợi ích, giả định, rủi ro/vấn đề: Trong phần này, cung cấp một danh sách từ 5-6 lợi ích hàng đầu, một danh sách của tất cả các nguy cơ đã biết và một danh sách tất cả các giả định. Một số này có thể chỉ là xào xáo từ những phần trước của tài liệu, tập hợp lại vào một phần này cho rõ.
Đừng bao giờ loại bỏ bất cứ điều gì ở phần này. Bạn có thể nhìn vào phần này để biết ngay lập tức những rủi ro hiện tại trong thiết kế.


Kết luận

Khó nhất của việc viết tài liệu thiết kế là chẳng có gì để viết. Phần khó tiếp theo là đi qua các thiết kế logic trước khi bạn bắt tay vào coding. Một khi bạn có một cái nhìn về các đối tượng, thành phần, thực thể được sắp xếp lại với nhau, viết ra sẽ dễ hơn. Thêm nữa, nó không cần yêu cầu phải có các công cụ đặc biệt, word và paint là đủ.
"Nếu bạn không có kế hoạch, sau đó bạn có kế hoạch để thất bại - If you fail to plan, then you plan to fail".

1 nhận xét: