56 luật phần mềm, Việt hóa để dễ đọc lại

Nếu một hành vi của hệ thống có thể quan sát được, sớm muộn cũng sẽ có người phụ thuộc vào nó.

Hệ thống phức tạp hoạt động tốt thường tiến hóa từ một hệ thống đơn giản đã chạy ổn trước đó.

Mọi abstraction đủ phức tạp đều sẽ để lộ chi tiết bên dưới vào lúc bạn ít mong muốn nhất.

Độ phức tạp cốt lõi không tự biến mất; bạn chỉ đang chuyển nó từ người dùng sang code hoặc ngược lại.

Trong hệ phân tán có phân vùng mạng, bạn không thể đồng thời tối đa cả nhất quán lẫn sẵn sàng.

Phiên bản tiếp theo của một sản phẩm thành công rất dễ bị nhồi quá nhiều ý tưởng và trở nên cồng kềnh.

Nhiều giả định tưởng hiển nhiên như mạng luôn ổn định, độ trễ bằng không hay topology không đổi đều sai.

Mỗi thay đổi trong hệ thống phức tạp đều có thể tạo ra tác động phụ ở nơi bạn chưa nghĩ tới.

Phần mềm có xu hướng phình to phạm vi cho đến khi cố làm nhiều việc hơn mức nó nên làm.

Cấu trúc hệ thống thường phản chiếu cách các nhóm giao tiếp và chia trách nhiệm với nhau.

Thêm người vào một dự án đã trễ hạn thường làm nó trễ hơn vì chi phí phối hợp và truyền đạt tăng lên.

Con người chỉ duy trì hiệu quả một số lượng hữu hạn quan hệ ổn định, nên quy mô đội ngũ có giới hạn tự nhiên.

Khi nhóm lớn lên, hiệu suất của từng cá nhân thường giảm nếu trách nhiệm và mục tiêu không đủ rõ.

Trong nhiều nhóm, một phần nhỏ thành viên tạo ra tỷ lệ đóng góp rất lớn cho kết quả chung.

Khoảng cách giữa người quản lý và người làm kỹ thuật dễ tạo ra quyết định thiếu ăn khớp với thực tế công nghệ.

Trong tổ chức phân cấp, con người dễ được thăng tiến tới mức vai trò mà họ không còn làm tốt nữa.

Nếu quá ít người nắm kiến thức sống còn, dự án sẽ cực kỳ mong manh khi họ rời đi hoặc không còn sẵn sàng hỗ trợ.

Tổ chức yếu có thể đẩy người kém phù hợp khỏi công việc tạo giá trị trực tiếp và vô tình đưa họ lên quản lý.

Tối ưu khi chưa có dữ liệu thực tế thường làm hệ thống phức tạp hơn trước khi mang lại giá trị rõ ràng.

Công việc có xu hướng nở ra để chiếm trọn khoảng thời gian được cấp cho nó.

Những phần cuối cùng của dự án thường ngốn thời gian nhiều hơn tưởng tượng và phá vỡ kế hoạch ban đầu.

Mọi việc thường mất lâu hơn dự tính, kể cả khi bạn đã nhớ rằng nó thường mất lâu hơn dự tính.

Khi một chỉ số trở thành mục tiêu, con người sẽ tối ưu theo chỉ số đó thay vì theo giá trị thật.

Ngay cả khi chưa đo hoàn hảo, việc đo một cách hữu ích vẫn tốt hơn là hoàn toàn không đo.

Mỗi lần chạm vào code, hãy để nó sạch hơn, rõ hơn hoặc an toàn hơn một chút so với trước đó.

Nếu có cách để sự cố xảy ra, hãy giả định nó sẽ xảy ra và chuẩn bị cho trường hợp đó.

Khi phát dữ liệu hãy chặt chẽ, khi nhận dữ liệu hãy chịu lỗi hợp lý để tăng khả năng tương thích.

Những chỗ xấu nhỏ bị bỏ mặc trong codebase thường kéo theo thêm nhiều chỗ xấu và tiêu chuẩn thấp hơn.

Mọi quyết định làm nhanh hôm nay nhưng làm chậm việc thay đổi ngày mai đều đang tạo thêm nợ kỹ thuật.

Khi đủ nhiều người xem xét đúng chỗ, lỗi khó cũng dễ bị phát hiện hơn.

Code càng khôn lỏi và khó hiểu, việc debug nó sau này càng tốn sức gấp nhiều lần.

Hệ kiểm thử bền vững thường có nhiều test nhanh ở lớp thấp và ít test giao diện chậm ở lớp cao.

Chạy mãi cùng một bộ test sẽ dần kém hiệu quả vì lỗi mới tìm cách lẩn qua các mẫu cũ.

Phần mềm gắn với thế giới thực phải tiếp tục thay đổi; nếu không, nó sẽ dần mất giá trị và khó bảo trì.

Phần lớn sản phẩm và ý tưởng ngoài kia chỉ ở mức trung bình hoặc tệ, nên đừng lấy số đông làm chuẩn chất lượng.

Tốc độ tăng nhờ song song hóa bị giới hạn bởi phần việc vẫn bắt buộc phải chạy tuần tự.

Khi bài toán đủ lớn, thêm tài nguyên song song vẫn có thể mang lại lợi ích đáng kể.

Giá trị của mạng lưới thường tăng rất nhanh khi số người hoặc điểm kết nối tăng lên.

Đừng thêm tính năng, abstraction hay cấu hình khi nhu cầu thực tế vẫn chưa xuất hiện.

Mỗi mẩu tri thức quan trọng nên có một nơi thể hiện đáng tin cậy thay vì bị sao chép rải rác.

Thiết kế càng đơn giản và dễ hiểu thì càng dễ thay đổi, kiểm thử và vận hành lâu dài.

Đây là bộ nguyên tắc giúp code dễ mở rộng, dễ thay đổi và giảm phụ thuộc chặt giữa các thành phần.

Một đối tượng nên nói chuyện với các thành phần gần nó, không nên luồn sâu qua nhiều tầng để lấy dữ liệu.

API và giao diện nên cư xử theo cách người dùng hoặc đồng đội dễ đoán nhất.

Người biết ít về một chủ đề thường dễ tự tin quá mức vì chưa thấy hết độ khó thật sự.

Đừng vội quy mọi lỗi thành ác ý khi thiếu hiểu biết, sơ suất hoặc hệ thống tồi cũng có thể giải thích được.

Khi nhiều giả thuyết cùng giải thích được vấn đề, hãy ưu tiên phương án đơn giản nhất trước.

Thời gian hay tiền đã bỏ ra trong quá khứ không nên ép bạn tiếp tục một hướng đi đang sai.

Mô hình, dashboard, sơ đồ hay tài liệu chỉ là đại diện cho thực tế, không phải chính thực tế.

Con người có xu hướng chọn dữ kiện ủng hộ niềm tin sẵn có và bỏ qua tín hiệu trái chiều.

Ta thường kỳ vọng quá cao vào tác động ngắn hạn của công nghệ mới nhưng lại đánh giá thấp ảnh hưởng dài hạn.

Thứ gì tồn tại hữu ích lâu trong thời gian dài thường có xác suất tiếp tục tồn tại thêm nữa.

Hãy bóc vấn đề về các giả định nền tảng nhất rồi xây lại lời giải từ các sự thật cơ bản đó.

Thay vì chỉ hỏi làm sao để thành công, hãy hỏi điều gì chắc chắn dẫn tới thất bại rồi tránh nó.

Một phần nhỏ nguyên nhân thường tạo ra phần lớn kết quả, nên cần ưu tiên đúng điểm đòn bẩy.

Trên Internet, câu trả lời đúng thường xuất hiện nhanh hơn khi ai đó nhìn thấy một câu trả lời sai.