Commodore 64 đã tải phần mềm từ máy cassette.
Bạn đã bao giờ tự hỏi tại sao những người thông minh như các nhà phát triển phần mềm lại thường xuyên làm khó nó như vậy? Có những người đã làm. Trong bài viết này, chúng tôi đánh giá một số luật bất thành văn mô tả hành vi của các chuyên gia của máy tính.
Máy tính đầu tiên của tôi là Commodore 64. Gần 30 kb RAM là dành cho hệ thống, còn lại 32 kb để xử lý văn bản, chơi game, kế toán doanh nghiệp gia đình và tất cả mọi thứ tôi làm với chiếc máy tính 6 gb mà tôi sở hữu bây giờ. Điều đó bỏ ngỏ câu hỏi Thiết bị ngày nay có đáp ứng được nhu cầu của phần mềm hay phần mềm sử dụng nhiều tài nguyên phần cứng hơn vì chúng có sẵn?
Công bằng mà nói, game không giống nhau, chất lượng đồ họa cũng không giống nhau, và không thể xem phim và nghe nhạc được. Tuy nhiên, người ta không thể không nghĩ rằng có những chương trình phát hành phiên bản và ngày càng tiêu tốn nhiều tài nguyên hơn mà không thực sự đóng góp gì mới.
Đây là những nguyên nhân.
Định luật Zawinsky
Nhà phát triển Jamie Zawinsky của Netscape lập luận rằng Mọi chương trình đều kết hợp các tính năng cho đến khi nó có thể đọc được email. Nếu anh ta không thành công, anh ta sẽ được thay thế bởi một người khác có khả năng làm điều đó.
Khi anh ta nói điều đó, trò đùa là anh ta đang đề cập đến các chương trình không được dự định ban đầu là ứng dụng email. Thật buồn cười khi phát hiện ra rằng nhiều ứng dụng trên Google Play đang yêu cầu quyền truy cập vào các thành phần điện thoại và dữ liệu người dùng mà họ không cần thực hiện công việc của mình.
Một số giải thích đây là một phần của nỗ lực theo dõi người dùng. Nhưng có lẽ bản chất của con người là làm điều gì đó đơn giản vì nó có thể làm được.
Nguyên tắc của Peter áp dụng cho phần mềm
Lawrence Peter trở nên nổi tiếng khi nói rằng trong hệ thống phân cấp, một người vươn lên vị trí mà anh ta hoàn toàn không đủ năng lực. Nhưng anh ấy cũng có thời gian để nói điều gì đó về các dự án phức tạp:
"Một dự án phức tạp sẽ trở nên quá phức tạp để có thể hiểu được ngay cả bởi các nhà phát triển của chính nó."
Nguyên tắc ít gây ngạc nhiên nhất
Được xuất bản trên Tạp chí Hệ thống của IBM vào năm 1984, nguyên tắc này nói rằng:
"Nếu một tính năng bắt buộc gây ra bất ngờ lớn, thì tính năng đó có thể cần được thiết kế lại."
Nói cách khác, nếu một phần hoặc tất cả phần mềm rất khác so với những gì người dùng đã từng sử dụng, thì tốt nhất là thiết kế lại. Lý tưởng nhất là phấn đấu để đạt được những cải tiến gia tăng đủ lớn để gây ấn tượng, nhưng đủ nhỏ để vẫn quen thuộc cho người dùng.
Thật tệ là Shuttleworth đã không tính đến điều đó khi tung ra Unity.
Luật côn trùng học điều khiển từ
Lỗi đầu tiên trong lịch sử máy tính là có thật. Một con bướm đêm đã bay vào một trong các rơ le trên máy tính MARK II gây ra sự cố.
Tiếp tục với phép ẩn dụ, quy luật côn trùng học điều khiển học cho rằng sẽ luôn có một lỗi nữa.
Đó là điều mà tất cả những người sử dụng máy tính đều biết. Bất kể hệ điều hành được kiểm tra đến đâu, luôn có một lỗi được phát hiện khi đã quá muộn.
Định luật Kernighan
Linux Adictos đã cài đặt một plugin để đảm bảo rằng tác giả của chúng tôi viết theo cách thân thiện với công cụ tìm kiếm. Tôi ghét nó từ ngày đầu tiên. Bất kỳ nỗ lực viết nào mang tính chất văn học một chút sẽ ngay lập tức bị tố cáo bằng một vòng tròn màu đỏ. Thời gian trôi qua tôi đã quen dần và hiếm khi phải chỉnh sửa lại.
Điều tương tự cũng xảy ra với các lập trình viên, nhiều khi họ quan tâm đến việc thể hiện khả năng viết mã của mình hơn là viết một đoạn mã đơn giản dễ hiểu và dễ bảo trì hơn.
Trong hơn một thập kỷ, đĩa mềm là phương tiện chính để phân phối phần mềm.
Do đó định luật Kernighan cho rằng:
Gỡ lỗi khó gấp đôi so với viết mã ngay từ đầu. Vì vậy, nếu bạn viết mã một cách thông minh nhất có thể, theo định nghĩa, bạn không đủ thông minh để gỡ lỗi nó. '
Quy tắc 90/90
Bất cứ ai đã bắt đầu một dự án vì lợi nhuận trong đời thực đều biết rằng mỗi dự án sẽ mất gấp đôi thời gian và chi phí gấp đôi ngân sách, để tạo ra một nửa lợi nhuận dự kiến.
Thế giới máy tính có những biến thể của luật này. Ví dụ, một Tom Cargill đã nói:
“90 phần trăm đầu tiên của mã đại diện cho 90 phần trăm đầu tiên của thời gian phát triển. 10 phần trăm còn lại của mã đại diện cho 90 phần trăm còn lại của thời gian phát triển. "
Nó không rõ ràng? Có lẽ định luật Hofstadter sẽ giúp:
"Nó luôn mất nhiều thời gian hơn bạn mong đợi, ngay cả với định luật Hofstadter."
Tôi đoán các nhà phát triển Ubuntu và Fedora phải biết. Hoặc ít nhất hãy nhớ nó 6 tháng một lần.
Luật Brook
Các dự án phần mềm nguồn mở thường có hai vấn đề; tài chính và thiếu cộng tác viên. Trừ khi thứ hai không phải là vấn đề. Theo Brook:
"Việc thêm lao động vào một dự án phần mềm bị chậm tiến độ sẽ khiến nó thêm chậm trễ."
Nói một cách dễ hiểu, bạn không chỉ phải cập nhật các bộ mã hóa mới. Sẽ phải ghi chép nhiều hơn nữa, sẽ cần nhiều quan liêu hơn để giữ cho mọi người đồng bộ, và có thể sẽ có những cuộc chiến.
Và tất nhiên chúng ta không thể quên về người bạn Parkinson và tuyên bố của anh ấy rằng Không quan trọng bạn bắt đầu với bao nhiêu không gian trống. Bạn sẽ luôn cần nhiều hơn. Anh ấy đang đề cập đến không gian văn phòng, nhưng RAM và dung lượng đĩa cũng vậy.
Văn bản xuất sắc. Dễ hiểu, triết học và văn học. Một trong những điều hay nhất mà tôi đã đọc từ máy chủ Linux. Tôi chúc mừng bạn.
Rất cảm ơn bạn vì sự góp ý
Tất cả đều rất thực tế, nhiều năm trước tôi là một lập trình viên và đã sống trong nhiều tình huống như vậy. Xin chúc mừng. Từ Chicago, tôi theo bạn.
Cảm ơn bạn rất nhiều
Các nguyên tắc áp dụng cho hầu hết mọi công việc