Context-Blind Change
Failure Pattern của Context Erosion và Unverifiable Correctness
Summary
Context-Blind Change là Failure Pattern trong đó,
ngay cả khi các thay đổi được thực hiện liên tục,
các giả định, lý do cho các quyết định, và ràng buộc của chúng
bị mất mà không được chia sẻ.
Trong Pattern này, thực hiện các thay đổi nhanh chóng không bị phủ nhận bản thân.
Đúng hơn, trong các tình huống mà sự không chắc chắn cao và tần suất thay đổi được yêu cầu,
tiến hành mà không ghi lại các giả định trở thành lựa chọn hợp lý nhất,
và Pattern này đề cập đến cấu trúc trong đó "correctness" trở nên không thể xác minh kết quả.
Context
Trong software đang vận hành,
các thay đổi lớn nhỏ khác nhau xảy ra liên tục,
như specification changes, feature additions, refactoring, và bug fixes.
Trong nhiều trường hợp, các thay đổi cá nhân là hợp lý cục bộ,
và reviews và tests pass.
Tuy nhiên, trên những giả định hoặc ràng buộc nào mà thay đổi đã dựa trên
thường không thể đọc từ code hoặc tickets.
Khi trạng thái này tiếp tục,
không ai có thể giải thích
hành vi hoặc điều kiện ràng buộc của software như một tổng thể.
Forces
Các động lực chính tạo ra Pattern này như sau:
-
Pressure for speed of change
Dừng bản thân change được coi là một rủi ro,
và các quyết định để tiến hành triển khai dễ dàng được ưu tiên hơn xác nhận các giả định. -
Assumptions becoming implicit
Sự hiểu biết được cho là được chia sẻ trong team không được ghi lại,
và lý do cho các quyết định vẫn nằm ngoài code hoặc diffs. -
Chain of local optimization
Mỗi thay đổi trông đúng cá nhân,
vì vậy khó nhận thấy rằng tính nhất quán tổng thể đang bị mất. -
Supplemental effect of support tools
AI và automation tools hỗ trợ công việc thay đổi,
vì vậy các thay đổi có thể thành lập ngay cả mà không làm rõ ràng các giả định.
Failure Mode
Bởi vì các giả định không được chia sẻ,
tính hợp pháp của các thay đổi không thể được xác minh sau thực tế.
Kết quả là, các dạng hỏng sau đây tiến hành đồng thời:
-
"Source of Truth" phân tán vào các đoạn code
Specifications và rules được nhúng vào các đoạn triển khai,
và trở nên không thể đánh giá cái nào là tiêu chuẩn. -
Lý do cho state transitions không thể theo dõi
Tại sao transitions xảy ra đến state đó không thể xác định,
và các inconsistencies giữa display và internal state trở nên khó phát hiện. -
Lý do cho change không thể theo dõi
Thay đổi đó để bảo vệ cái gì bị mất,
và các thay đổi tiếp theo được thực hiện dựa trên suy đoán.
Consequences
-
Mỗi fix có xu hướng hỏng ở nơi khác
(Part I: What Breaks — State / Boundary) -
Phạm vi tác động change không thể giải thích, và các quyết định bị trì hoãn
(Part I: What Breaks — Responsibility / Boundary) -
Specification confirmation được thay thế bằng code reading
(Part I: What Breaks — Data / Boundary) -
AI và new members không thể hỗ trợ hiệu quả
Bởi vì các giả định và ràng buộc không được làm rõ ràng,
sử dụng như decision support bị giới hạn.
(Part II: Why It Breaks — Context Erosion)
Countermeasures
Sau đây không phải là danh sách các giải pháp,
mà là các counter-patterns để thay đổi động lực với can thiệp tối thiểu chống lại Failure Mode.
- Thay vì change content,
trước tiên diễn đạt các giả định và ràng buộc đang được bảo vệ - Không ghi lại mọi thứ,
nhưng để lại minimal context cần thiết cho change decisions - Để lại dưới dạng có thể xác minh sau
liệu change có đúng hay không
Resulting Context
Các thay đổi vẫn xảy ra thường xuyên,
và không phải tất cả các quyết định được xác định trước.
Tuy nhiên, bằng cách làm cho các giả định hiển thị,
tính thích hợp của các thay đổi có thể được xác minh sau thực tế.
Kết quả là, các thay đổi được coi
không phải là mere diffs,
mà là một lịch sử của các quyết định có thể học được.
See also
-
Specification-by-Absence
Một derived pattern trong đó các thay đổi tích lũy mà không làm rõ ràng các giả định, và các vấn đề không xác định trở nên cố định như các de facto specifications. -
Test-Passing Illusion
Một cấu trúc trong đó, trong các môi trường mà các giả định không được chia sẻ, thành công hạn chế có xu hướng được coi như một chỉ số proxy của correctness.
Appendix: Conceptual References
- Requirements & Knowledge
Background của các cấu trúc trong đó các thay đổi tiến hành mà không làm rõ ràng kiến thức tiên quyết cần thiết cho các quyết định. - Information Hiding & Boundaries
Background của failure structures trong đó các giả định và ràng buộc rò rỉ vào các đoạn code. - Feedback, Measurement & Learning
Background của các động lực trong đó các thay đổi mà không có các giả định không dẫn đến learning hoặc verification.
Appendix: References
- Pamela Zave, Michael Jackson, Four Dark Corners of Requirements Engineering, 1997.
- David L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, 1972.
- Barry W. Boehm, Software Engineering Economics, 1981.
- Gojko Adzic, Specification by Example: How Successful Teams Deliver the Right Software, 2011.