Viết mã mạnh mẽ so với áp đảo

Làm thế nào để các bạn biết rằng bạn đang viết mã mạnh mẽ nhất có thể mà không cần áp đảo?

Tôi thấy mình suy nghĩ quá nhiều về mọi con đường có thể mà mã của tôi có thể đi và đôi khi cảm thấy lãng phí thời gian. Tôi đoán nó phụ thuộc vào loại chương trình bạn đang viết, nhưng tôi không muốn sử dụng quá nhiều thời gian để tính đến những tình huống sẽ không bao giờ xảy ra.

Làm thế nào để các bạn biết rằng bạn đang viết mã mạnh mẽ nhất có thể mà không cần áp đảo?

Bạn nghĩ gì về mã mạnh mẽ? Mã đã là bằng chứng trong tương lai và mạnh mẽ đến mức nó có thể đối phó với mọi tình huống? Sai, không ai có thể dự đoán được tương lai! Và sai một lần nữa, bởi vì nó sẽ là một mớ hỗn độn phức tạp, không thể nhầm lẫn.

Tôi tuân theo các nguyên tắc khác nhau: Đầu tiên và quan trọng nhất là YAGNI (chưa) và KISS , vì vậy tôi không viết mã không cần thiết. Điều đó cũng có hiệu quả ngăn chặn quá mức. Tôi cấu trúc lại ứng dụng khi cần mở rộng. Các công cụ tái cấu trúc hiện đại cho phép bạn khá dễ dàng tạo giao diện và trao đổi triển khai sau đó khi bạn cần chúng.

Sau đó, tôi cố gắng làm cho mã tôi viết mạnh mẽ nhất có thể, bao gồm loại bỏ càng nhiều đường dẫn mà chương trình có thể đi (và cả trạng thái) càng tốt và một chút lập trình Spartan . Một trợ giúp tuyệt vời là các chức năng / phương pháp "nguyên tử" không dựa vào các trạng thái bên ngoài hoặc ít nhất là không để chương trình ở trạng thái không nhất quán khi chúng thất bại. Nếu bạn làm tốt điều đó, rất có thể bạn sẽ không bao giờ kết thúc với mã spaghetti và đó cũng là một phước lành cho khả năng duy trì. Ngoài ra, trong thiết kế hướng đối tượng, các nguyên tắc RẮN là một hướng dẫn tuyệt vời cho mã mạnh mẽ.

Tôi thực sự phát hiện ra rằng thường thì bạn có thể giảm độ phức tạp, ví dụ như sự bùng nổ kết hợp của các đường dẫn hoặc trạng thái chương trình, bằng cách suy nghĩ sâu sắc về cách bạn có thể thiết kế nó như là con đường thẳng nhất có thể. Cố gắng giữ các kết hợp có thể ở mức tối thiểu bằng cách chọn thứ tự tốt nhất của chương trình con của bạn và thiết kế chúng cho mục đích này.

Mã mạnh mẽ luôn luôn là mã đơn giản và sạch sẽ, nhưng đơn giản là một đặc điểm không phải lúc nào cũng dễ dàng đạt được. Tuy nhiên, bạn nên phấn đấu cho nó. Luôn luôn chỉ viết mã đơn giản nhất có thể và chỉ thêm độ phức tạp khi bạn không có lựa chọn nào khác.

Đơn giản là mạnh mẽ, phức tạp là mong manh.

Sự phức tạp giết chết.

Tôi cố gắng giữ thăng bằng, tập trung vào

• xử lý tất cả các đường dẫn thực thi có thể có trong các trường hợp sử dụng hiện có (đây là phần "mạnh mẽ"),
• cho phép các tính năng / yêu cầu Tôi khá chắc chắn rằng sẽ đến trong tương lai gần và
• những điều tôi biết từ kinh nghiệm sẽ cần cho khả năng duy trì lâu dài của cơ sở mã (tức là giữ cho mã sạch và có thể kiểm tra được).

Đó là một khu vực biên giới mờ - đôi khi tôi quản lý để làm một số công việc không cần thiết, đôi khi tôi không làm được điều gì đó là cần thiết sau này. Nếu bỏ lỡ không lớn, tôi ổn. Bằng mọi giá, tôi cố gắng học hỏi từ những sai lầm của mình.

Sự khác biệt giữa mạnh mẽ và áp đảo là sự khác biệt giữa xử lý duyên dáng tất cả các trường hợp sử dụng có thể, ngay cả các trường hợp sử dụng kỳ quái và rìa mà KHÔNG NÊN xảy ra. Khi tôi nói một cách duyên dáng, ý tôi là, người dùng gặp trường hợp ngoại lệ kỳ quái hoặc gặp phải tình huống gọi một tính năng không được hỗ trợ hoặc không xác định không được xác định và mã thoát ra một cách duyên dáng mà không gặp sự cố hoặc thông báo cho người dùng về chức năng không được hỗ trợ.

Mặt khác, việc áp đảo có thể rơi vào cảnh thực hiện đầy đủ các tính năng không cần thiết hoặc được yêu cầu (một số tính năng khách hàng CẦN nhưng không bao giờ được yêu cầu!) HOẶC có thể được xác định bằng cách tạo ra một thiết kế quá phức tạp hoặc quá phức tạp mã để xử lý một vấn đề tương đối đơn giản.

1) Nhận yêu cầu.

2) Viết mã tối thiểu để đáp ứng yêu cầu. Nếu một cái gì đó mơ hồ, hãy đoán. Nếu nó siêu mơ hồ, quay lại 1.

3) Gửi để kiểm tra.

4) Nếu người kiểm tra nói rằng nó tốt, tài liệu phê duyệt. Nếu một cái gì đó tắt, quay trở lại 1.

Tập trung vào việc vượt qua các bài kiểm tra, không dự đoán các bài kiểm tra. Nếu bạn không có người kiểm tra ... hãy lấy người kiểm tra! Chúng rất cần thiết không chỉ để xác minh tính chính xác của mã, mà cho toàn bộ quá trình phát triển.

Ở nơi đầu tiên, giữ cho dữ liệu được chuẩn hóa (không dư thừa) càng nhiều càng tốt. Nếu dữ liệu được chuẩn hóa hoàn toàn, không một bản cập nhật nào cho dữ liệu có thể làm cho nó không nhất quán.

Bạn không thể luôn giữ dữ liệu được chuẩn hóa, nói cách khác, bạn có thể không thể loại bỏ sự dư thừa, trong trường hợp đó, nó có thể có các trạng thái không nhất quán. Điều cần làm sau đó là chịu đựng sự không nhất quán và sửa chữa nó định kỳ với một loại chương trình quét qua nó và vá nó lại.

Có một xu hướng mạnh mẽ là cố gắng quản lý dự phòng chặt chẽ bằng các thông báo. Những điều này không chỉ khó để chắc chắn rằng chúng đúng, mà còn có thể dẫn đến sự thiếu hiệu quả rất lớn . (Một phần của sự cám dỗ để viết thông báo phát sinh vì trong OOP chúng thực sự được khuyến khích.)

Nói chung, bất cứ điều gì phụ thuộc vào chuỗi thời gian của các sự kiện, tin nhắn, v.v., sẽ dễ bị tổn thương và đòi hỏi hàng tấn mã hóa phòng thủ. Sự kiện và thông điệp là đặc trưng của dữ liệu với sự dư thừa, bởi vì chúng đang truyền đạt các thay đổi từ phần này sang phần khác, cố gắng ngăn chặn sự không nhất quán.

Như tôi đã nói, nếu bạn phải có dự phòng (và cơ hội là khá tốt bạn phải có), tốt nhất là có thể a) chịu đựng, và b) sửa chữa nó. Nếu bạn cố gắng ngăn chặn sự không nhất quán chỉ bằng các thông điệp, thông báo, kích hoạt, v.v., bạn sẽ rất khó để làm cho nó mạnh mẽ.

• viết để sử dụng lại.
• viết bài kiểm tra. tầm thường, không tầm thường, một số phức tạp vô lý để xem cách nó xử lý trong các điều kiện như vậy. kiểm tra cũng sẽ giúp bạn xác định hình thức của giao diện.
• viết chương trình để thất bại khó khăn (ví dụ khẳng định). mã của tôi có rất nhiều lần sử dụng lại và tôi kiểm tra hàng tấn trường hợp - có nhiều kiểm tra / xử lý lỗi hơn so với thực hiện thực tế (dựa trên số lượng dòng).
• tái sử dụng.
• ngay lập tức sửa chữa những thứ đi sai.
• học hỏi và xây dựng từ kinh nghiệm

lỗi sẽ xuất hiện trên đường đi, nhưng may mắn thay, chúng sẽ được bản địa hóa và chúng (trong hầu hết các trường hợp) sẽ xuất hiện rất sớm trong thử nghiệm. lợi ích khác của việc tái sử dụng là máy khách / người gọi có thể lưu hầu hết các kiểm tra lỗi / giàn giáo bằng cách sử dụng do việc cấy ghép mang lại.

các bài kiểm tra của bạn sau đó sẽ xác định các khả năng của chương trình và mức độ mạnh mẽ của chúng - tiếp tục thêm các bài kiểm tra cho đến khi bạn hài lòng với tỷ lệ thành công và đầu vào; cải thiện, mở rộng và củng cố khi cần thiết.

Tôi tạo ra sự khác biệt này bằng cách viết mã với định nghĩa rõ ràng, nhưng không nhất thiết là hành vi tối ưu cho các lần thực thi rất khó xảy ra. Ví dụ, khi tôi khá chắc chắn (đã được chứng minh, nhưng chưa được kiểm tra) rằng một ma trận sẽ có giá trị dương, tôi chèn một xác nhận hoặc ngoại lệ vào chương trình để kiểm tra trạng thái, nhưng không viết đường dẫn mã riêng cho nó. Qua đó, hành vi được xác định, nhưng không tối ưu.

Tính mạnh mẽ: Mức độ mà một hệ thống tiếp tục hoạt động với sự có mặt của các yếu tố đầu vào không hợp lệ hoặc các điều kiện môi trường căng thẳng. (Mã hoàn thành 2, tr464)

Câu hỏi quan trọng ở đây là hỏi mức độ mạnh mẽ quan trọng đối với bạn như thế nào. Nếu bạn là Facebook, điều thực sự quan trọng là trang web của bạn tiếp tục hoạt động khi ai đó đưa các ký tự đặc biệt vào đầu vào và máy chủ của bạn sẽ duy trì khi 100 triệu người dùng đăng nhập cùng lúc. Nếu bạn đang viết một kịch bản để thực hiện một thao tác chung mà chỉ có bạn làm, bạn không quan tâm nhiều. Ở giữa có rất nhiều cấp độ. Đưa ra đánh giá về mức độ mạnh mẽ mà bạn cần là một trong những kỹ năng quan trọng mà nhà phát triển nên học hỏi.

Nguyên tắc của YAGNI áp dụng để thêm các tính năng mà chương trình có thể cần. Nhưng nguyên tắc đó không áp dụng cho sự mạnh mẽ. Các lập trình viên có xu hướng đánh giá quá cao khả năng sẽ cần một phần mở rộng trong tương lai nhất định (đặc biệt nếu đó là một phần mở rộng) nhưng họ đánh giá thấp khả năng xảy ra sự cố. Ngoài ra, nếu nó phát hiện ra rằng một tính năng bị bỏ qua là cần thiết sau đó, lập trình viên có thể viết nó sau. Nếu nó chỉ ra một kiểm tra lỗi bị bỏ qua là cần thiết, thiệt hại có thể được thực hiện.

Do đó, tốt hơn hết là bạn nên kiểm tra các điều kiện lỗi bất thường. Nhưng có một sự cân bằng. Một số điều cần xem xét trong số dư này:

• Làm thế nào thường xuyên có thể xảy ra lỗi này?
• Chi phí để có lỗi này xảy ra là gì?
• Đây là để sử dụng nội bộ hay bên ngoài?

Đừng quên rằng mọi người có thể - và sẽ - cố gắng sử dụng chương trình của bạn theo những cách không ngờ tới. Sẽ tốt hơn nếu có điều gì đó có thể dự đoán được khi họ làm.

Là một tuyến phòng thủ cuối cùng, sử dụng khẳng định hoặc tắt máy. Nếu có điều gì đó xảy ra mà bạn không thể tìm ra cách giải quyết, hãy tắt chương trình. Điều đó thường tốt hơn là cho phép chương trình tiếp tục và làm một cái gì đó không thể đoán trước.