Tôi cần một lời giải thích thích đáng về Luật bao bọc phần mềm của Jamie Zawinski :
Mỗi chương trình cố gắng mở rộng cho đến khi nó có thể đọc thư. Những chương trình không thể mở rộng được thay thế bằng những chương trình có thể.
Tôi cần một lời giải thích thích đáng về Luật bao bọc phần mềm của Jamie Zawinski :
Mỗi chương trình cố gắng mở rộng cho đến khi nó có thể đọc thư. Những chương trình không thể mở rộng được thay thế bằng những chương trình có thể.
Câu trả lời:
Tất cả các câu trả lời (và bình luận) cho đến nay dường như tập trung hoàn toàn vào nửa đầu của tuyên bố, biến nó thành một nhận xét về "phình to", khi nửa quan trọng là nửa sau: Những chương trình không thể mở rộng được thay thế bằng những chương trình mà có thể.
Đây không phải là về sự phình to của phần mềm, mà là về thực tế của thị trường. Mọi người có thể nói rằng họ muốn một sản phẩm đơn giản, nhưng khi bạn nhìn vào cách sử dụng thực tế, những thứ được sử dụng là những thứ cho phép người dùng làm nhiều hơn và cuối cùng họ thay thế các công cụ có khả năng kém hơn.
Một phần của vấn đề là "đơn giản" là một từ khó hiểu. Giống như "cleave", nó có thể có nghĩa là hai điều gần như hoàn toàn trái ngược nhau. Những gì mọi người muốn là một cái gì đó đơn giản hóa các nhiệm vụ phức tạp. Đó là "đơn giản tốt", và nó đòi hỏi rất nhiều sự phức tạp để làm đúng. Tuy nhiên, điều mà một số người giải thích nó là mọi người muốn một cái gì đó đơn giản hoặc tối giản. Khái niệm này có thể có một số điểm hấp dẫn thích hợp, nhưng về tổng thể, đó là loại "đơn giản" sai để tập trung vào khi thiết kế một sản phẩm. Cho dù công việc của bạn tốt đến đâu, các yêu cầu tính năng mới vẫn tiếp tục xuất hiện.
Lấy một ví dụ, có chương trình tôi làm việc tại nơi làm việc. Có lẽ bạn chưa bao giờ nghe về nó, nhưng chúng tôi là công ty dẫn đầu thị trường trong một ngành công nghiệp chuyên ngành: kiểm soát phương tiện truyền thông. Chương trình của chúng tôi rất có thể chạy TV và / hoặc đài phát thanh yêu thích của bạn. Các khách hàng yêu nó, họ nói đó là rất tốt hơn nhiều so với bất cứ điều gì khác mà họ đã làm việc với.
Nó cũng rất lớn . EXE có kích thước hơn 65 MB, với khoảng 4 triệu dòng mã, được hỗ trợ bởi cơ sở dữ liệu với hơn 150 bảng, được xây dựng trong suốt hơn một thập kỷ làm việc. Tuy nhiên, dường như mỗi khi chúng tôi cố gắng cài đặt nó tại một số trạm hoặc mạng mới, có một hoặc hai điều thực sự cần thiết cho quy trình làm việc của họ, mà chúng tôi không có bất kỳ sự hỗ trợ nào. Vì vậy, chúng tôi cuối cùng đã thêm các tính năng mới bởi vì nếu không thì khách hàng sẽ không muốn chuyển đổi từ hệ thống mà họ đã quen. Và hãy để tôi nhắc lại, khách hàng thích nó.
Bạn phải hiểu rằng điều này đã xảy ra từ lâu và vào thời điểm đó, máy tính vẫn chưa thể chạy nhiều chương trình một lúc cho một người dùng nhất định. DOS cho máy tính cá nhân (và có thể là Windows 3 ở trên cùng) và các thiết bị đầu cuối dựa trên ký tự cho người dùng Unix (chỉ một số ít có X11).
Điều này có nghĩa là để kiểm tra xem bạn đã nhận được email chưa, bạn phải thoát khỏi những gì bạn đang làm, bắt đầu chương trình thư, đọc thư, thoát khỏi chương trình thư và khởi động lại chương trình cũ của bạn. Tôi đoán bạn có thể thấy rằng nếu chương trình hiện tại của bạn có thể cho phép bạn đọc email của mình, bạn có thể tránh tất cả điều đó.
Do đó, nếu chương trình hiện tại của bạn không thể đọc email của bạn, bạn có xu hướng làm cho nó làm như vậy (hãy nhớ rằng đây là sinh viên MIT) hoặc chuyển sang một chương trình khác có thể.
Những ngày đó là khó có thể tưởng tượng, nhưng bạn có thể nhận được một ý niệm mơ hồ của nó như thế nào là do giới hạn mình vào một đơn cửa sổ trình duyệt - không có tab, không có cửa sổ thêm - và có lẽ thậm chí không sử dụng dấu trang.
Như mọi người khác đã đề cập đến "luật" là một quan sát hài hước về sự phình to của phần mềm và điểm số leo thang , và nó rất giống với quy tắc thứ mười của Greensasta :
Bất kỳ chương trình C hoặc Fortran nào đủ phức tạp đều chứa một chương trình đặc biệt, được chỉ định không chính thức, có lỗi, triển khai chậm một nửa Common Lisp.
Luật này phản ánh công việc của Zawinski với trình duyệt Netscape và sau đó với Netscape Mail & News, như được mô tả ở đây bởi, chính anh ta:
Tiếp theo, tôi đã thiết kế, và Terry Weissman và tôi đã triển khai, ứng dụng khách Tin tức và Tin tức Netscape, phiên bản 2.0 đến 3.0. Đây là đóng góp của chúng tôi trong việc chứng minh Luật Bao bọc phần mềm :
"Mọi chương trình đều cố gắng mở rộng cho đến khi nó có thể đọc thư. Những chương trình không thể mở rộng này được thay thế bằng những chương trình có thể."
Trình duyệt Netscape, vào thời điểm trình duyệt phổ biến nhất, thường bị chỉ trích là có quá nhiều tính năng tốt, nếu tôi không nhầm lẫn thì đó là trình duyệt (phổ biến) hỗ trợ hai công cụ kết xuất là Gecko và Trident. Ví dụ: Ben Goodger xác định sự phình to của Netscape là một trong (nhiều) lý do dẫn đến việc tạo ra Firefox 1 :
Rối loạn giao diện người dùng của Mozilla
Do hầu hết thiết kế giao diện người dùng cho các sản phẩm Netscape được thực hiện bởi nhân viên Netscape làm việc theo yêu cầu của Netcenter, giao diện người dùng Mozilla phải chịu đựng. Thay vì là một lõi sạch mà Netscape có thể xây dựng một sản phẩm phù hợp với nhu cầu của mình, bộ Mozilla không bao giờ cảm thấy hoàn toàn đúng; nó đã được hoàn thiện với các cấu trúc UI khó xử chỉ tồn tại để được lấp đầy bởi các lớp phủ trong kho lưu trữ nguồn riêng của Netscape - cây thương mại của The.
Tổng hợp sự rối loạn chức năng này, tại thời điểm dự án đang được phát triển bởi hơn một trăm kỹ sư ở các bộ phận khác nhau, đôi khi kết nối kém trong CPD. Netscape đã phát triển nhanh chóng trong những năm trước, và với một kỹ sư thanh tuyển dụng không đồng đều với các khả năng cho thấy họ cần thêm sự trợ giúp từ những người khác đã có quá nhiều quyền tự chủ trong thiết kế và triển khai tính năng. Hỗ trợ trải nghiệm người dùng rất ít và do đó, ứng dụng nhanh chóng bị phình to.
1 Từ một phiên bản lưu trữ của blog hiện không còn tồn tại của Ben Goodger.
Đó không phải là một luật thực sự , đó là một nhận xét châm biếm về cách các dự án phần mềm (nếu không được quản lý đúng cách) có thể phát triển quá lớn và phức tạp, cuối cùng chúng bao gồm một trình đọc email (ngay cả khi nó không liên quan gì đến mục đích ban đầu của dự án) . Một người quản lý mà tôi đã từng thích một cụm từ tương tự "Bất kỳ hệ thống nào đủ phức tạp đều chứa một triển khai LISP nửa khẳng định trong đó".
Đó là một nhận xét về cách một số dự án phần mềm dường như tiếp tục mở rộng và thêm nhiều tính năng hơn.
Nhiều dự án dường như không thể chống lại việc thêm các tính năng, dù cần thiết hay không.
Một kết luận hợp lý là mọi phần mềm sẽ kết thúc việc gửi thư.
Cũng xem Phạm vi Creep .
Tôi thấy ít nhất ba cách để xem nó.
Một là bỏ qua việc đọc thư mỗi lần và xem nó như một tuyên bố rằng mọi người dường như thích các sản phẩm có tính linh hoạt được chuyển sang hầu hết mọi tác vụ, bất kể nó có liên quan đến mục đích ban đầu của công cụ đến mức nào. Nếu chúng ta nhìn theo cách này, một sản phẩm như Photoshop không hỗ trợ đọc thư không phải là bất thường bởi vì kiến trúc trình cắm của nó đủ linh hoạt để có thể hỗ trợ đọc thư, mặc dù (theo như tôi biết) không bổ trợ như vậy tồn tại. Quan điểm này có thể được tóm tắt rõ ràng hơn, nhưng ban đầu ít hơn, là "chuyên môn hóa nhịp đập linh hoạt".
Cách thứ hai để xem nó là Jamie Zawinski có trọng tâm hẹp đến mức anh ta đơn giản bỏ qua các sản phẩm như Photoshop, PowerPoint, hầu hết các trò chơi, v.v., đã tồn tại trong nhiều năm, không hỗ trợ đọc thư và không ' T dường như đang bị thay thế bởi bất cứ điều gì khác.
Thứ ba sẽ là một chút đối nghịch với thứ hai, nói rằng, về bản chất, sự tích hợp giữa các sản phẩm đã xảy ra ở mức độ mà việc đọc thư được tích hợp vào mọi thứ vì hầu hết mọi người hiện có một trình đọc thư chạy trong nền, tất cả thời gian và có thể chuyển sang nó một cách nhanh chóng / đủ dễ dàng, cắt và dán bất cứ thứ gì khác, v.v., rằng chi tiết nhỏ mà trình đọc thư được đóng gói dưới dạng một ứng dụng riêng biệt đã trở nên không liên quan.