Là kỹ sư, tất cả chúng ta đều "thiết kế" các đồ tạo tác (tòa nhà, chương trình, mạch điện, phân tử ...). Đó là một hoạt động (design-the-verb) tạo ra một loại kết quả (design-the-noun).
Tôi nghĩ rằng tất cả chúng ta đều đồng ý rằng thiết kế-danh từ là một thực thể khác với chính tạo tác.
Một hoạt động chính trong kinh doanh phần mềm (thực sự, trong bất kỳ doanh nghiệp nào mà sản phẩm tạo ra sản phẩm kết quả cần phải được nâng cao) là để hiểu "thiết kế (danh từ)". Tuy nhiên, dường như chúng ta, với tư cách là một cộng đồng, đã thất bại khá nhiều trong việc ghi lại nó, bằng chứng là số lượng nỗ lực mà mọi người bỏ ra để khám phá lại sự thật về cơ sở mã của họ. Yêu cầu ai đó chỉ cho bạn thiết kế mã của họ và xem những gì bạn nhận được.
Tôi nghĩ về một thiết kế cho phần mềm là có:
- Một đặc điểm kỹ thuật rõ ràng cho những gì phần mềm được cho là phải làm và nó hoạt động tốt như thế nào
- Một phiên bản rõ ràng của mã (phần này rất dễ, mọi người đều có nó)
- Một lời giải thích về cách mỗi phần của mã phục vụ để đạt được đặc tả (ví dụ: mối quan hệ giữa các đoạn đặc tả và đoạn mã)
- Một lý do là tại sao mã là như vậy (ví dụ, tại sao một lựa chọn cụ thể chứ không phải là một lựa chọn khác)
Những gì KHÔNG phải là một thiết kế là một quan điểm cụ thể về mã. Ví dụ [không chọn cụ thể trên] sơ đồ UML không phải là thiết kế. Thay vào đó, chúng là các thuộc tính bạn có thể lấy từ mã, hoặc có thể nói là các thuộc tính bạn muốn bạn có thể lấy từ mã. Nhưng theo nguyên tắc chung, bạn không thể lấy được mã từ UML.
Tại sao sau hơn 50 năm xây dựng phần mềm, tại sao chúng ta không có cách thường xuyên để thể hiện điều này? (Vui lòng mâu thuẫn với tôi bằng các ví dụ rõ ràng!)
Ngay cả khi chúng tôi làm, hầu hết cộng đồng dường như rất tập trung vào việc lấy "mã" mà thiết kế danh từ bị mất đi. (IMHO, cho đến khi thiết kế trở thành mục đích của kỹ thuật, với tạo tác được trích ra từ thiết kế, chúng ta sẽ không giải quyết vấn đề này).
Những gì bạn đã xem là phương tiện để ghi lại các thiết kế (theo nghĩa tôi đã mô tả nó)? Tài liệu tham khảo rõ ràng để giấy tờ sẽ được tốt. Tại sao bạn nghĩ rằng cụ thể và chung có nghĩa là không thành công? Làm thế nào chúng ta có thể thay đổi được điều này?
[Tôi có ý tưởng riêng của mình đưa ra quan điểm gạch đầu dòng ở trên, nhưng tôi quan tâm đến câu trả lời của người khác ... và thật khó để thực hiện kế hoạch của tôi [[và có lẽ đó là vấn đề thực sự: -]]]
EDIT 2011/1/3: Một trong những chủ đề trả lời gợi ý rằng "tài liệu" (có lẽ là văn bản, đặc biệt là không chính thức) có thể là đầy đủ. Tôi đoán tôi nên làm rõ rằng tôi không tin điều này. Các công cụ CASE xuất hiện trên bối cảnh bắt đầu từ những năm 80, nhưng các công cụ ban đầu hầu như chỉ thu được các pixel cho sơ đồ của bất cứ thứ gì bạn vẽ; trong khi các công cụ được cho là thành công về mặt thương mại, chúng thực sự không hữu ích lắm. Một cái nhìn sâu sắc quan trọng là, nếu các tạo tác "thiết kế" bổ sung không thể giải thích chính thức, bạn không thể nhận được bất kỳ trợ giúp công cụ nghiêm túc nào. Tôi tin rằng cái nhìn sâu sắc tương tự áp dụng cho bất kỳ hình thức nắm bắt thiết kế hữu ích lâu dài nào: nếu nó không có cấu trúc chính thức, nó sẽ không được sử dụng thực sự. Tài liệu văn bản khá nhiều thất bại bài kiểm tra này.