Mặc định có thể nhấn chìm bạn  Tóm lại: Hãy coi những phản hồi không xác định là trái phép, không phải là hợp lệ.  Vấn đề  Rủi ro bảo mật  Bỏ qua các trường hợp chưa biết  Lỗi giải thích sai  Mặc định là trạng thái hợp lệ  Quyền không khớp  Không ghi lại được sự kiện  Tiềm năng khai thác  Giải pháp  Xác thực tất cả phản hồi dựa trên một tập hợp đóng các mã đã biết.  Mặc định (và không xác định) là không được phép hoặc   . Xóa mặc định  Ghi lại mọi trường hợp không khớp hoặc bất ngờ để phân tích.  Kiểm tra với các tình huống ngoại biên.  Đồng bộ hóa nhóm phản hồi với bộ xử lý thường xuyên để tránh mã lỗi thời.  Tập trung vào vấn đề bảo mật, biến nó thành một quá trình chuyển dịch sang trái.  Thiết kế hệ thống có khả năng phục hồi khi thay đổi để xử lý các tình huống phát sinh.  Bối cảnh  Hôm nay là   và mọi lập trình viên cần phải thừa nhận trách nhiệm của mình. ngày an ninh máy tính  Hãy tưởng tượng một ứng dụng xử lý bán hàng dựa vào nhóm phản hồi từ bộ xử lý thẻ tín dụng để xử lý các giao dịch.  Mỗi bộ xử lý thẻ tín dụng đều cung cấp mã phản hồi được xác định trước cho nhiều tình huống khác nhau, chẳng hạn như số dư không đủ hoặc thẻ hết hạn.  Sự cố bắt đầu khi bộ xử lý thêm mã phản hồi mới cho các giao dịch bị từ chối nhưng không thông báo cho nền tảng.  Ứng dụng không nhận dạng được mã mới, mặc định coi mã là "không tìm thấy" và cho phép mua hàng.  Người dùng nhận thấy lỗi này và lợi dụng nó để thực hiện các giao dịch mua trái phép.  Doanh thu của nền tảng giảm mạnh, dẫn đến phá sản.  Mã mẫu  Sai   String response = paymentProcessor.authorize(cardDetails); switch (response) { case "DECLINED_INSUFFICIENT_FUNDS": // Handle insufficient funds break; case "DECLINED_EXPIRED_CARD": // Handle expired card break; default: // Authorize purchase break; }  Phải   String response = paymentProcessor.authorize(cardDetails); switch (response) { case "APPROVED": // Authorize purchase break; case "DECLINED_INSUFFICIENT_FUNDS": // Handle insufficient funds break; case "DECLINED_EXPIRED_CARD": // Handle expired card break; case "DECLINED_NEW_REASON": // Handle new declined reason break; default: // Reject purchase (default case for unknown responses) break; }  Phát hiện    Hướng dẫn sử dụng [x]  Bạn có thể phát hiện ra lỗi này bằng cách xem xét logic xử lý lỗi.  Kiểm tra xem hệ thống có ghi lại và từ chối những trường hợp không được nhận dạng hay không.  Các bài kiểm tra tự động có thể giúp xác định xem các đầu vào mới hoặc bất ngờ có mặc định là hành động hợp lệ hay không.  Các công cụ phân tích tĩnh có thể giúp đánh dấu việc xử lý lỗi có khả năng chưa hoàn thiện.  Thẻ  Bảo vệ  Mức độ    Trung cấp [x]  Tại sao song ánh lại quan trọng  Điều quan trọng là phải duy trì sự tương ứng một-một giữa biểu diễn nội bộ của ứng dụng về phản hồi của bộ xử lý thanh toán và mã thực tế do bộ xử lý trả về.  Khi bạn phá vỡ   , bạn sẽ tạo ra sự không phù hợp. Song ánh xạ  Ứng dụng giải thích sai các mã không xác định, dẫn đến hành vi không mong muốn, lỗ hổng bảo mật và hậu quả kinh doanh có thể thảm khốc.  Thế hệ AI  Các công cụ AI có thể tạo ra mùi này nếu bạn không chỉ định cách xử lý các trường hợp chưa biết.  Ví dụ, việc xử lý lỗi chung có thể mặc định là kết quả lành tính như "không tìm thấy" hoặc "thành công".  Phát hiện AI  Máy phát AI có thể khắc phục tình trạng này khi bạn hướng dẫn chúng xử lý các trường hợp chưa biết là trái phép và nhấn mạnh vào việc ghi nhật ký và thử nghiệm các tình huống bất ngờ.  Hãy thử chúng!   Hãy nhớ: Trợ lý AI mắc rất nhiều lỗi  Không có hướng dẫn đúng đắn  Với hướng dẫn cụ thể   Trò chuyệnGPT   Trò chuyệnGPT   Claude   Claude   Sự bối rối   Sự bối rối   Phi công phụ   Phi công phụ   Song Tử   Song Tử  Phần kết luận  Luôn xử lý những trường hợp chưa biết một cách thận trọng.  Các giá trị mặc định như "không tìm thấy" có thể dẫn đến các vấn đề bảo mật nghiêm trọng và tổn thất tài chính.  Hãy biến việc ghi nhật ký và từ chối các phản hồi không xác định thành một phần trong hoạt động phát triển của bạn.  Đưa ra quyết định dịch chuyển sang trái liên quan đến bảo mật trong khi lập trình.  Quan hệ   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-viii-8mn3352  Tuyên bố miễn trừ trách nhiệm  Code Smells là   của tôi. ý kiến  Tín dụng  Ảnh của   trên  Nathana Rebouças Bapt   https://www.youtube.com/watch?v=J2QOejhA6ek  Giả định là mẹ của mọi thất bại.   Ouissal nói   Trích dẫn tuyệt vời về Kỹ thuật phần mềm  Bài viết này là một phần của Series CodeSmell.   Làm thế nào để tìm ra những phần có mùi hôi thối trong mã của bạn

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Software Engineer and Book Author

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Make resilience your competitive advantage

Mùi mã 282 - Mặc định xấu và cách khắc phục

Mùi mã 282 - Mặc định xấu và cách khắc phục

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

189 Stories To Learn About Reading Books

184 Stories To Learn About Psychology

61 Stories To Learn About Polotical Philosophy

72 Stories To Learn About Adam Smith

189 Stories To Learn About Reading Books

184 Stories To Learn About Psychology

61 Stories To Learn About Polotical Philosophy

72 Stories To Learn About Adam Smith

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps