Theo: http://www.robweir.com/blog/2006/10/chernobyl-design-pattern.html
Bài được đưa lên Internet ngày 26/10/2006
Năm 1994, chip Pentium của Intel được tìm thấy có một lỗi trong đó. Trong một số trường hợp, nó đưa ra câu trả lời sai đối với việc chia điểm tràn. Những trường hợp như vậy là rất hãn hữu xảy ra, chỉ 1 trong số 9 triệu phép chia, và thường chỉ xảy ra trong các lỗi qua 8 con số thập phân.
Intel đã làm gì lúc đó? Vâng, đầu tiên là phủ nhận, và sau đó giải tán vấn đề như thứ tầm thường và không quan trọng. Nhưng cuối cùng họ đã sáng suốt và đưa ra một chính sách thay thế không cần hỏi cho các bộ vi xử lý có khiếm khuyết. Không nghi ngờ gì việc này là đắt giá đối với Intel, nhưng điều này đã khôi phục tên tuổi và danh tiếng tốt của họ.
In 1994, the Intel Pentium chip was found to have a bug in it. In certain cases, it gave the wrong answer for floating-point division. These cases were rare, only 1 in 9 billion divisions, and typically only resulted in errors past the 8th decimal place.
What did Intel do about this? Well, there was denial at first, and then dismissal of the problem as being trivial and unimportant. But eventually they saw the light and offered a no-questions-asked replacement policy for defective processors. No doubt this was expensive for Intel, but this restored their good name and reputation.
Có thể có cách khác. Ví dụ, họ có thể đơn giản giữ lại lỗi đó. Họ có thể để dành lỗi đó trong các phiên bản tiếp sau của Pentium đối với việc tương hợp ngược, tranh cãi rằng một vài phần mềm có thể đã chạy quanh lỗi gốc và để họ sửa lỗi đó ngay bây giờ có thể chỉ làm ngắt việc khắc phục. Lỗi gì không chạy được bởi lý lẽ này?
It could have been different. For example, they could have simply kept the bug. They could have preserved that bug in future versions of the Pentium for backwards compatibility, arguing that some software may have worked around the original defect, and for them to fix the bug now would only break the workaround. What bug can't be excused by that argument?
Intel có thể đã quyết định xa hơn để biển lỗi của họ thành một tiêu chuẩn, và thần thánh hoá nó bởi tổ chức phát triển các tiêu chuẩn và có thể ngay cả ISO. “Nó không phải là lỗi, nó là một tiêu chuẩn”.
Nhưng Intel không phải Microsoft, vì thế họ không có sự trơ tráo để biến một lỗi thành một tiêu chuẩn, mà nó là những gì Microsoft đang mong muốn làm khi công bố trong Office Open XML (OOXML) rằng năm 1900 phải được coi là một năm nhuận, đối nghịch với lịch Gregorian mà nó đã được sử dụng gần 500 năm nay. (Các năm chia hết cho 100 chỉ là năm nhuận nếu chúng cũng chia hết cho 400).
Intel could have further decided to turn their bug into a standard, and get it blessed by a standards development organization and maybe even ISO. “It's not a bug, it's a standard”.
But Intel is not Microsoft, so they don't have quite the audacity to turn a bug into a standard, which is what Microsoft is attempting to do by declaring in Office Open XML (OOXML) that the the year 1900 should be treated as a leap year, in contradiction of the Gregorian Calendar which has been in use almost 500 years. (Years divisible by 100 are leap years only if they are also divisible by 400)
Bằng việc bắt vĩnh viễn có lỗi này, chúng ta đang thấy lo lắng. Các thư viện ngày tháng trong các ngôn ngữ lập trình hiện đại như C, C++, Java, Python, Ruby sẽ tính tất cả các ngày một cách chính xác theo lịch Gregorian. Vì thế mọi biên dịch ngày tháng trong các tệp OOXML trong các ngôn ngữ này sẽ bị mất một ngày trừ phi tác giả của phần mềm tự khắc phục chúng đối với mã của họ để giải thích cho lỗi của Excel. Nhất định một số người sẽ chỉnh “đúng” một cách chính xác với các phí tổn của riêng họ. Những còn nhiều người sẽ không làm được, có thể vì họ không thấy nó sâu bên trong 6000 trang giấy đặc tả kỹ thuật.
By mandating the perpetuation of this bug, we are asking for trouble. Date libraries in modern programming languages like C, C++, Java, Python, Ruby will all calculate dates correctly according to the Gregorian Calendar. So any interpretation of dates in OOXML files in these languages will be off by one day unless the author of the software adds their own workaround to their code to account for Excel's bug. Certainly some will make the “correction” properly, at their own expense. But many will not, perhaps because they did not see it deep within the 6,000 page specification.
Có cái gì đó ta gọi là “Mô hình thiết kế kiểu Chernobyl”, nơi mà bạn giữ lỗi tồi tệ nhất của mình, phần xấu xa nhất trong mã nguồn của mình, phần mà quá tồi, quá có nhiều phóng xạ mà không ai có thể chạm vào nó mà không bị chết, và bạn làm cho nó thành thứ riêng tư không thể truy cập được, và làm một giao diện mới xung quanh nó, về cơ bản chôn nó xuống mồ một cách tỉ mỉ sao cho không một ai có thể tới gần nó được. Nói một cách khác, nếu bạn không thể sửa được nó, ít nhất có thiệt hại.
There is something I call the “Chernobyl Design Pattern”, where you take your worst bug, the ugliest part of your code, the part that is so bad, so radioactive that no one can touch it without getting killed, and you make it private and inaccessible, and put a new interface around it, essentially entomb it in concrete so that no one can get close to it. In other words, if you can't fix it, at least contain the damage.
Microsoft đã thực hiện một tiếp cận khác ở đây. Thay vì ngăn chặn, họ đang tuyên truyền lỗi đó ngay cả là xa hơn. Chúng ta cần nghĩ xa hơn Excel và cũng nghĩ tới các ứng dụng khác mà chúng làm việc với các dữ liệu của OOXML, và các ứng dụng khác mà chúng làm việc với các ứng dụng này và cứ như thế, toàn bộ mạng các phụ thuộc dữ liệu. Sự tồn tại đơn thuần của lỗi này trong một tiêu chuẩn sẽ dẫn tới những triển khai có lỗi, tính tương hợp kém và sự hỗn loạn chung về ngày tháng. Sự nhiễm độc của lỗi này phải được cho vào trong mã nguồn của Excel. Để nó rò rỉ ra ngoài, vào trong một đặc tả kỹ thuật, sau đó một tiêu chuẩn và sau đó trong các triển khai khác, mâu thuẫn cả với lịch dân sự và từng công cụ khác mà chúng làm việc với ngày tháng, sẽ gây ô nhiễm toàn bộ thệ thống ecosystem.
Microsoft has taken another approach here. Instead of containment, they are propagating the bug even further. We need to think beyond Excel and think as well of other applications that work with OOXML data, and other applications that work with those apps and so on, the entire network of data dependencies. The mere existence of this bug in a standard will lead to buggy implementations, poor interoperability, and general chaos around dates. The contamination of this bug should have been contained within the source code of Excel. For this fall-out to leak out, into a specification, then a standard and then into other implementations, contradicting both the civil calendar and every other tool that deals with dates, will pollute the entire ecosystem.
Dịch tài liệu: Lê Trung Nghĩa
Công ty Cổ phần phần mềm – Thương mại điện tử Nhất Vinh
No comments:
Post a Comment