Đừng để mã kiểm tra lọt vào sản xuất

Tóm lại: Tránh thêm isTesting hoặc các cờ tương tự.

Vấn đề 😔

• Trừu tượng rò rỉ
• Ô nhiễm mã phi kinh doanh
• Mã dễ vỡ
• Hành vi không nhất quán
• Phụ thuộc ẩn
• Gỡ lỗi khó khăn
• Cờ Boolean
• Các bài kiểm tra không đáng tin cậy
• Mã phụ thuộc vào sản xuất

Giải pháp 😃

1. Xóa bỏ hành vi Nếu
2. Sử dụng tiêm phụ thuộc
3. Mô hình hóa các dịch vụ bên ngoài (Đừng chế giễu chúng)
4. Cấu hình riêng biệt
5. Logic kiểm tra cô lập
6. Duy trì ranh giới hành vi sạch sẽ

Tái cấu trúc ⚙️

Bối cảnh 💬

Khi bạn thêm các cờ như isTesting , bạn sẽ kết hợp mã thử nghiệm và mã sản xuất.

Điều này tạo ra các đường dẫn ẩn chỉ hoạt động trong các bài kiểm tra.

Ngoài ra, bạn không đề cập đến mã sản xuất thực tế.

Bạn có nguy cơ áp dụng hành vi thử nghiệm vào sản xuất, dẫn đến lỗi và hành vi không thể đoán trước.

Mã mẫu 📖

Sai ❌

 struct PaymentService { is_testing: bool, } impl PaymentService { fn process_payment(&self, amount: f64) { if self.is_testing { println!("Testing mode: Skipping real payment"); return; } println!("Processing payment of ${}", amount); } }

Đúng 👉

 trait PaymentProcessor { fn process(&self, amount: f64); } struct RealPaymentProcessor; impl PaymentProcessor for RealPaymentProcessor { fn process(&self, amount: f64) { println!("Processing payment of ${}", amount); } } struct TestingPaymentProcessor; impl PaymentProcessor for TestingPaymentProcessor { // Notice this is not a mock fn process(&self, _: f64) { println!("No payment: Skipping real transaction"); } } struct PaymentService<T: PaymentProcessor> { processor: T, } impl<T: PaymentProcessor> PaymentService<T> { fn process_payment(&self, amount: f64) { self.processor.process(amount); } }

Phát hiện 🔍

• [x] Bán tự động

Bạn có thể phát hiện ra dấu hiệu này bằng cách tìm kiếm các cờ có điều kiện như isTesting , environment == 'test' , DEBUG_MODE và các thành ngữ tương tự như thế này.

Điều này chỉ ra rằng hành vi thử nghiệm đang bị rò rỉ vào mã sản xuất.

Thẻ 🏷️

• Kiểm tra

Cấp độ 🔋

• [x] Trung cấp

Tại sao song ánh lại quan trọng 🗺️

Bạn cần phân tách rõ ràng giữa mã thử nghiệm và mã sản xuất.

Khi bạn kết hợp chúng, bạn phá vỡ sự song ánh một-một giữa hành vi trong thế giới thực và chương trình.

Vì môi trường là các thực thể trong thế giới thực nên bạn cần mô hình hóa chúng một cách rõ ràng trong MAPPER .

Thế hệ AI 🤖

Mã do AI tạo ra thường phát hiện ra mùi này khi bạn sử dụng các thủ thuật hack nhanh để thử nghiệm.

Một số công cụ gợi ý các cờ như isTesting vì chúng ưu tiên sự dễ sử dụng hơn là thiết kế phù hợp.

Phát hiện AI 🥃

Các công cụ AI có thể phát hiện ra điều này nếu bạn cấu hình chúng để đánh dấu logic có điều kiện dựa trên trạng thái thử nghiệm.

Hãy thử chúng! 🛠

Hãy nhớ: Trợ lý AI mắc rất nhiều lỗi

Gợi ý: Xóa phương thức IsTesting và thay thế bằng cách mô hình hóa môi trường

Kết luận 🏁

Tránh sử dụng cờ isTesting .

Sử dụng tính năng tiêm phụ thuộc và mô hình hóa môi trường để tách biệt logic thử nghiệm và logic sản xuất.

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-xiii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vi-cmj31om

Tuyên bố miễn trừ trách nhiệm 📘

Code Smells là ý kiến của tôi.

Tín dụng 🙏

Ảnh của Christian Gertenbach trên Unsplash

Khi bạn thêm cờ kiểm tra, bạn sẽ làm giảm sự tin tưởng vào quá trình sản xuất.

Phường Cunningham

Bài viết này là một phần của Series CodeSmell.