Bạn có thể cố ý tạo ra một lỗi không?

Chúng tôi, những nhà phát triển, thường xuyên gặp lỗi , đó chỉ là một phần công việc của chúng tôi. Vì vậy, ngay từ cái nhìn đầu tiên, câu hỏi “Bạn có thể cố ý tạo ra lỗi không?” có vẻ tầm thường - “Vâng, tất nhiên, tôi có thể viết một lỗi.” Tuy nhiên, nếu bạn nghĩ về nó, mọi thứ dường như không còn rõ ràng nữa.

Thực tế là lỗi không giống như mã bị hỏng . Một lỗi là một lỗi, một lỗ hổng nói chung

chương trình làm việc.

Vấn đề là gì?

Thế giới được biết đến là được mô tả rõ ràng bằng các công thức toán học. Và các công thức thực sự là các thuật toán. Do đó, nếu chúng ta có thể mô tả một hiện tượng nào đó bằng toán học, thì việc sửa công thức tính được để đôi khi nó chỉ cho kết quả sai là một nhiệm vụ không hề nhỏ. Tuy nhiên, đây không phải là lúc để tuyệt vọng. Điều kiện biên có thể đến để giúp chúng ta ở đây. Tất cả chúng ta đều đã thấy những điều này if index == 0 {…} else if index == n-1 {…} . Luôn có điều gì đó không ổn ở ranh giới 🤷‍♀️. Vì vậy, hãy lưu ý ý tưởng đầu tiên để tạo lỗi - bỏ qua các trường hợp khó khăn .

Nói chung, việc lặp qua các mảng là một kho chứa các lỗi tiềm ẩn. Và phổ biến nhất trong số đó là chỉ số ngoài giới hạn . Nếu bạn chưa bao giờ gặp phải điều như vậy thì bạn chưa bao giờ viết mã. Thật không may, lỗi này phổ biến đến mức mọi người bắt đầu viết các trình bao bọc an toàn cho mảng, đại loại như array[safe: index] . Vì vậy, ngày nay, đồng nghiệp của bạn sẽ khó phê duyệt bất kỳ mã nào nếu không có thứ này. Bạn có thể thử, nhưng điều đó là không thể…

Các lỗi phổ biến bao gồm lỗi tràn ngăn xếp . Thuật toán đệ quy có thể lặp lại vô hạn khi không có điều kiện thoát. Ở đây, đệ quy dường như là tùy chọn - viết while true và bạn đã hoàn tất. Tuy nhiên, một lần nữa, sự phổ biến của lỗi này lại đang chống lại chúng ta. Các nhà phát triển nhận thức rõ các vấn đề tiềm ẩn của các vòng lặp vô tận và chắc chắn họ sẽ chú ý đến những điều như thế này trong buổi đánh giá mã 👮

Để vẫn đưa kế hoạch ngấm ngầm của bạn vào sản xuất, hãy thử sử dụng biến toàn cục cho các điều kiện thoát và lặng lẽ thay đổi nó từ bên ngoài .

 var coditionCounter = 0; class A { func foo() { while coditionCounter < 10 { coditionCounter++; B.boo(); } } } class B { func boo() { coditionCounter--; } }

Lời khuyên chung

Thật buồn cười là ngay cả ChatGPT cũng từ chối giúp đỡ khi viết lỗi. Có lẽ tôi chỉ cần một gói đăng ký trả phí… 🤔

Về mặt tích cực, AI cung cấp một bộ quy tắc chung góp phần viết mã không có lỗi: mã hóa theo các Phần tăng nhỏ, tuân theo các tiêu chuẩn mã hóa, viết bài kiểm tra đơn vị và bla-bla-bla. Chúng ta có thể thử làm điều ngược lại - viết mã spaghetti và quên đi SOLID. Tuy nhiên, theo cách này, chúng tôi mất quyền kiểm soát tất cả mã chúng tôi viết. Thay vì một vũ khí chính xác tao nhã, chúng ta gặp phải sự hỗn loạn không thể kiểm soát được, thứ sẽ chinh phục chương trình của chúng ta.

Khi giải quyết vấn đề tạo ra lỗi, cần xác định các nhiệm vụ phụ. Đầu tiên, chúng ta cần đưa ra một số trường hợp hiếm gặp. Thứ hai, chúng ta cần ngụy trang lỗi thành mã thông thường để nó vượt qua quá trình xem xét mã. Thứ ba, chúng ta phải thu hút sự chú ý của bộ phận QA. Thứ tư, đừng để bị bắt ngay. Nhưng điều này đã là tùy chọn.

Lời khuyên chung của tôi như sau (và bạn hãy chia sẻ lời khuyên của mình trong phần bình luận):

• Thao tác cấp độ truy cập . Để nhân đôi trở lại, hãy thay đổi giá trị của các tham số quan trọng từ những nơi không mong đợi nhất. Thực hiện việc này thông qua một số lớp như thể bạn là một VPN.

• Thực hiện một số logic bất ngờ trong lớp con. Tóm lại là phá vỡ nguyên tắc L trong SOLID .

   class A { func decrease() { x--; } } class B: A { override func decrease() { x++; } }

• Ẩn những thay đổi ngấm ngầm của bạn trong các chức năng lớn hơn. Càng nhiều hàng thì càng tốt - lạc vào đám đông.

• Sử dụng nguyên tắc tương tự trong các yêu cầu kéo. Trong một PR nhỏ, xác suất được chú ý sẽ cao hơn.

• Cố gắng chia lỗi thành nhiều phần và đặt chúng vào các yêu cầu kéo khác nhau . Nếu có thể thì cũng hãy để những người đánh giá khác nhau.

• Tìm điểm yếu của QA của bạn và chiếm được lòng tin của anh ấy. Hoặc đánh lạc hướng họ bằng những cuộc trò chuyện trong quá trình kiểm tra.

Nhân tiện, bạn đã nghe nói về Heisenbug chưa? Đây là một lỗi biến mất hoặc thay đổi hành vi của nó trong quá trình nghiên cứu/ gỡ lỗi . Giống như con mèo của Schrodinger. Hoàn hảo nếu vấn đề khắc phục sẽ không được giao cho bạn.

Bạn có thể

Hãy tin vào chính mình! Lịch sử biết những ví dụ về thời điểm một lỗi được đưa vào sản xuất ở các công ty rất nghiêm trọng.

Chuyến bay Ariane 5 501: Một trong những lỗi phần mềm đắt giá nhất xảy ra vào năm 1996 khi tên lửa Ariane 5 mang sứ mệnh Cluster phát nổ chỉ 40 giây sau khi cất cánh. Sự cố được bắt nguồn từ lỗi phần mềm trong hệ thống dẫn đường của tên lửa.

Tàu quỹ đạo khí hậu sao Hỏa của NASA: Năm 1999, NASA đã mất Tàu quỹ đạo khí hậu sao Hỏa do lỗi phần mềm. Phần mềm sử dụng đơn vị đo lường Anh ( pound-giây) thay vì đơn vị mét (newton-giây), khiến tàu vũ trụ bốc cháy trong bầu khí quyển sao Hỏa.

Hơn nữa, một số lỗi có thể trở thành tính năng, chẳng hạn như hành vi nhảy tường trong Mario hoặc Mahatma Gandh trong Civilization …có lẽ vậy.

Phát triển một lỗi là khả năng suy nghĩ thấu đáo về thuật toán của bạn và dự đoán kỹ lưỡng các vấn đề có thể xảy ra. Vì vậy, ngay cả khi bạn không có lý do gì để để lại lỗi trong mã, thì điều đó vẫn đáng để xem xét.