Giảm thiểu tác dụng phụ (lý tưởng là không có)
Một hàm gây ra 3 thay đổi cho các trạng thái bên ngoài phạm vi của chính nó rất khó để lý giải và duy trì hơn nhiều so với một hàm chỉ nhập một thứ gì đó và xuất ra một thứ khác. Bạn không thể biết chức năng này làm gì, bạn phải nhớ những gì nó đã làm và làm thế nào điều đó ảnh hưởng đến tất cả các chức năng có liên quan khác.
Đối với OOP giảm thiểu tác dụng phụ cũng có nghĩa là các lớp có ít thành viên hơn và đặc biệt là ít thành viên có thể sửa đổi trạng thái của lớp hơn, vì các hàm thành viên có thể sửa đổi các trạng thái ngoài chính chúng và có tác dụng phụ (ví dụ: chúng có thể điều khiển các phần bên trong của lớp). Điều đó cũng có nghĩa là các lớp có ít thành viên dữ liệu của riêng họ để có ít trạng thái hơn cho các phương thức đó để giả mạo và ít tác dụng phụ hơn mà chúng có thể gây ra.
Ví dụ đơn giản, hãy tưởng tượng bạn đang cố gắng thiết kế một cấu trúc dữ liệu ưa thích có thể duy trì sortedtrạng thái mà nó sử dụng để xác định xem thực hiện tìm kiếm nhị phân hay tuyến tính. Trong trường hợp như vậy, có thể hữu ích khi tách thiết kế thành hai lớp. Việc gọi sortedlớp chưa được sắp xếp có thể trả về cấu trúc dữ liệu của lớp khác luôn giữ nội dung của nó được sắp xếp. Bây giờ bạn có ít tác dụng phụ hơn (do đó ít bị lỗi và dễ hiểu mã hơn) cũng như mã áp dụng rộng rãi hơn (thiết kế trước đây sẽ lãng phí cả về xử lý và hiệu quả trí tuệ của con người đối với các mảng nhỏ không cần phải sắp xếp).
Tránh phụ thuộc bên ngoài
Bạn có thể thực hiện mã ngắn gọn nhất có thể tưởng tượng được với việc sử dụng lại mã tối đa bằng cách sử dụng 13 thư viện khác nhau để thực hiện một nhiệm vụ tương đối đơn giản. Tuy nhiên, điều đó chuyển giao chi phí trí tuệ cho độc giả của bạn bằng cách sau đó phải làm cho họ hiểu ít nhất một phần của 13 thư viện khác nhau. Sự phức tạp vốn có này cần được đánh giá ngay lập tức bởi bất kỳ ai cố gắng xây dựng và hiểu một thư viện bên thứ ba cần kéo vào và xây dựng hàng tá thư viện khác để hoạt động.
Đây có lẽ là một quan điểm rất gây tranh cãi nhưng tôi thích một số sao chép mã khiêm tốn đến cực đoan ngược lại với điều kiện kết quả cuối cùng được kiểm tra tốt (không có gì tệ hơn so với mã bị lỗi chưa được sao chép nhiều lần). Nếu lựa chọn nằm giữa 3 dòng mã trùng lặp để tính toán một sản phẩm chéo vector hoặc kéo vào thư viện toán sử thi chỉ để loại bỏ 3 dòng mã, tôi sẽ đề xuất trước đây trừ khi toàn bộ nhóm của bạn có mặt trên thư viện toán học này , tại thời điểm đó, bạn vẫn có thể xem xét chỉ viết 3 dòng mã thay vì 1 nếu nó đủ tầm thường để đổi lấy lợi ích tách rời.
Tái sử dụng mã là một hành động cân bằng. Tái sử dụng quá nhiều và bạn chuyển sự phức tạp về trí tuệ theo cách một-nhiều, vì trong 3 dòng mã đơn giản mà bạn đã lưu ở trên phải trả giá bằng cách yêu cầu người đọc và người bảo trì hiểu nhiều thông tin hơn 3 dòng mã . Nó cũng làm cho mã của bạn kém ổn định hơn, vì nếu thư viện toán học thay đổi, thì mã của bạn cũng vậy. Tái sử dụng quá ít và bạn cũng nhân lên chi phí trí tuệ và mã của bạn không được hưởng lợi từ các cải tiến trung tâm, vì vậy đó là một hành động cân bằng, nhưng ý tưởng rằng đó là một hành động cân bằng đáng được đề cập vì cố gắng dập tắt mọi hình thức sao chép khiêm tốn có thể dẫn đến kết quả là khó duy trì, nếu không muốn nói là nhiều hơn so với thái cực ngược lại.
Kiểm tra tào lao ra khỏi nó
Đây là một điều được đưa ra nhưng nếu mã của bạn không xử lý tất cả các trường hợp đầu vào và bỏ lỡ một số trường hợp cạnh, thì làm sao bạn có thể mong đợi người khác duy trì mã mà bạn đã viết mà bạn thậm chí không nhận được ngay trước khi nó được chuyển sang mắt và tay của họ? Điều đó đủ khó để thực hiện các thay đổi đối với mã hoạt động hoàn hảo chứ đừng nói đến mã không bao giờ hoàn toàn đúng ngay từ đầu.
Trên hết, mã vượt qua các bài kiểm tra kỹ lưỡng thường sẽ tìm thấy ít lý do hơn để thay đổi. Điều đó liên quan đến sự ổn định thậm chí còn hơn cả một chén thánh để đạt được hơn là khả năng bảo trì, vì mã ổn định không bao giờ cần phải thay đổi sẽ không mất chi phí bảo trì.
Tài liệu giao diện
Ưu tiên "những việc cần làm" hơn "cách mọi thứ thực hiện" nếu bạn không thể dành thời gian bình đẳng cho việc ghi chép cả hai. Một giao diện rõ ràng rõ ràng trong ý định của nó về những gì nó sẽ làm (hoặc ít nhất, những gì nó phải làm) trong tất cả các trường hợp đầu vào có thể sẽ mang lại sự rõ ràng về bối cảnh để thực hiện chính nó sẽ hướng dẫn cách hiểu không chỉ về cách thức để sử dụng mã, nhưng cũng làm thế nào nó hoạt động.
Trong khi đó, mã thiếu những phẩm chất này, nơi mọi người thậm chí không biết những gì nó phải làm là SOL cho dù chi tiết thực hiện của nó được ghi chép tốt như thế nào. Hướng dẫn gồm 20 trang về cách triển khai mã nguồn là vô ích đối với những người thậm chí không thể hiểu chính xác cách sử dụng nó ở nơi đầu tiên và thậm chí nó phải làm gì trong tất cả các tình huống có thể xảy ra.
Đối với phía thực hiện, ưu tiên ghi lại những gì bạn làm khác với mọi người. Ví dụ, Intel có một hệ thống phân cấp âm lượng giới hạn cho các hạt nhân raytracing của họ. Vì tôi làm việc trong lĩnh vực này, tôi có thể nhận ra phần lớn những gì mã của họ đang làm trong nháy mắt mà không cần lọc qua tài liệu. Tuy nhiên, họ làm một cái gì đó độc đáo, đó là ý tưởng đi ngang qua BVH và thực hiện các giao điểm song song bằng cách sử dụng các gói tia . Đó là nơi tôi muốn họ ưu tiên tài liệu của họ vì những phần đó của mã là kỳ lạ và khác thường so với hầu hết các triển khai BVH lịch sử.
Dễ đọc
Phần này rất chủ quan. Tôi không thực sự quan tâm nhiều đến khả năng đọc của một loại gần với quá trình suy nghĩ của con người. Mã tài liệu tốt nhất mô tả mọi thứ ở mức cao nhất vẫn khó theo dõi nếu tác giả sử dụng các quá trình suy nghĩ kỳ quái và phức tạp để giải quyết vấn đề. Trong khi đó, mã terse sử dụng tên 2 hoặc 3 ký tự thường có thể dễ hiểu hơn đối với tôi nếu logic rất đơn giản. Tôi đoán bạn có thể đánh giá ngang hàng và xem những gì người khác thích.
Tôi chủ yếu quan tâm đến khả năng bảo trì và quan trọng hơn là sự ổn định. Mã không tìm thấy lý do để thay đổi là mã không có chi phí bảo trì.