Là một tài liệu mô tả kiến ​​trúc có vi phạm Nguyên tắc DRY không?

Nguyên tắc DRY (Đừng lặp lại chính mình) nói rằng "mỗi phần kiến ​​thức phải có một đại diện duy nhất, rõ ràng, có thẩm quyền trong một hệ thống." Hầu hết thời gian này đề cập đến mã, nhưng nó cũng thường được mở rộng cho tài liệu.

Người ta nói rằng mọi hệ thống phần mềm đều có kiến ​​trúc cho dù bạn có chọn nó hay không. Nói cách khác, phần mềm bạn xây dựng có cấu trúc và cấu trúc "như được xây dựng" là kiến ​​trúc của phần mềm. Vì một hệ thống phần mềm được xây dựng đi kèm với một kiến ​​trúc, việc tạo ra một mô tả kiến ​​trúc của hệ thống đó có vi phạm Nguyên tắc DRY không? Rốt cuộc, nếu bạn cần biết kiến ​​trúc thì bạn luôn có thể nhìn vào mã ...

Việc sao chép suy nghĩ của bạn vào mã có vi phạm nguyên tắc DRY không?

Geez, nếu bạn chỉ có thể biết kiến ​​trúc bằng cách xem mã, sẽ không có những thứ như "tài liệu mô tả kiến ​​trúc" ở nơi đầu tiên. Đây không phải là một sự lặp lại, đó là một mức mô tả hệ thống khác , không thể suy diễn một cách tầm thường từ mã và ngược lại. Vì vậy, nó có toàn quyền tồn tại ngay cả khi bạn ôm DRY.

Đừng coi DRY là một quy tắc khó và nhanh. Đó là một điều tốt, nhưng bạn chỉ có thể ước chừng nó trong thực tế.

Ngoài ra tôi nghĩ rằng nó không được viết tốt. "Đừng lặp lại chính mình" dường như không đề cập đến trường hợp quan trọng không kém là để thực hiện thay đổi ngữ nghĩa hoặc chức năng, bạn sẽ phải chỉnh sửa văn bản nguồn ở nhiều nơi, nói những điều khác nhau nhưng được phối hợp.

Thay vì coi đó là một điều răn không được vi phạm, tốt hơn là nên hiểu tại sao đó là một ý tưởng tốt và đưa ra những lựa chọn hợp lý về nó. Lý do thật tệ khi phải chỉnh sửa phối hợp ở nhiều nơi là bạn, biên tập viên, mắc lỗi. Bạn không đáng tin cậy 100% để thực hiện các thay đổi mà không có lỗi. Nếu bạn phải thực hiện 10 thay đổi văn bản nguồn khác nhau và bạn chỉ nhận được 9 trong số đó là đúng, bạn đã gặp phải một lỗi . Đó là lý do tại sao sắp xếp văn bản nguồn để giảm thiểu số lượng thay đổi phối hợp là một điều tốt. Nó giảm thiểu lỗi.

Chúng tôi không thuộc về một tôn giáo trong đó DRY là một trong những điều răn. Nó chỉ là một cách tiện dụng, mặc dù hơi sai lệch, để gói gọn một số ý nghĩa thông thường.

Một kiến trúc mô tả, hoặc thiết kế phần mềm Mô tả không vi phạm DRY. Tuy nhiên, trong một tổ chức lớn, nơi các dự án vào năm ngoái, các nhà phát triển đến và đi, và hệ thống này quá lớn đối với bất kỳ ai để giữ tất cả các chi tiết trong đầu, đó là một tài liệu quan trọng. Lượng "lặp lại" cần thiết để giữ cho nó đồng bộ là hoàn toàn xứng đáng với công sức mà nó tiết kiệm được trong lần cập nhật hoặc bảo trì tiếp theo.

Một mô tả kiến ​​trúc không vi phạm nguyên tắc DRY.

Hệ thống phần mềm của bạn đi kèm với một kiến ​​trúc, chắc chắn. Và nó trải rộng trên nhiều tệp, trong nhiều lớp, với nhiều chi tiết không liên quan và không cần thiết cho tổng quan.

Tài liệu kiến ​​trúc của bạn nên giống như đoạn đầu tiên của một báo cáo tin tức: đó là một phác thảo, tóm tắt, lộ trình của dự án.

Nếu bạn hẹn hò với tài liệu, thì nó sẽ mô tả kiến ​​trúc tại thời điểm viết.

Trong khi đó mã đại diện cho kiến ​​trúc tại thời điểm hiện tại.

Hai điều riêng biệt - không phải cùng một kiến ​​thức.

Miễn là bạn nói rằng tài liệu đại diện cho kiến ​​trúc tại thời điểm viết, bạn không sao chép kiến ​​thức IMO bởi vì kiến ​​thức khác nhau nếu đó là về hệ thống tại một thời điểm khác.