: Bài viết này được viết chỉ nhằm mục đích giải trí. Đừng cố gắng lặp lại nó ở nơi làm việc. Tuy nhiên, hãy làm bất cứ điều gì bạn muốn ở nhà. Tuyên bố miễn trừ trách nhiệm Chúng tôi, những nhà phát triển, thường xuyên gặp , đó 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. lỗi Thực tế là . Một lỗi là một lỗi, một lỗ hổng nói chung lỗi không giống như mã bị hỏng chương trình làm việc. Thuật ngữ "lỗi" trong bối cảnh các vấn đề về phần mềm bắt nguồn từ năm 1947 khi một con sâu bướm gây ra trục trặc trong máy tính Harvard Mark II. Theo đúng nghĩa đen, các kỹ sư đã tìm thấy một con bướm đêm bị mắc kẹt trong một trong các rơle và họ gọi đó là “trường hợp lỗi thực tế đầu tiên được tìm thấy”. 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 để 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. có thể đến để giúp chúng ta ở đây. Tất cả chúng ta đều đã thấy những điều này . 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 - . đôi khi nó chỉ Điều kiện biên if index == 0 {…} else if index == n-1 {…} 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à . 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ư . 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ể… chỉ số ngoài giới hạn array[safe: index] Các lỗi phổ biến bao gồm . 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 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ã 👮 lỗi tràn ngăn xếp while true Để 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, 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 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. AI chúng tôi mất quyền kiểm soát tất cả mã 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): . Để 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. Thao tác cấp độ truy cập 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. - lạc vào đám đông. Càng nhiều hàng thì càng tốt 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 . Nếu có thể thì cũng hãy để những người đánh giá khác nhau. các yêu cầu kéo 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/ . 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. gỡ lỗi Một ví dụ phổ biến về heisenbug là lỗi xuất hiện khi chương trình được biên dịch bằng trình biên dịch tối ưu hóa, nhưng không xuất hiện khi cùng một chương trình được biên dịch mà không tối ưu hóa (như thường được thực hiện nhằm mục đích kiểm tra nó bằng trình gỡ lỗi). Trong khi gỡ lỗi, các giá trị mà một chương trình được tối ưu hóa thường giữ trong các thanh ghi thường được đẩy vào bộ nhớ chính. 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. 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. Chuyến bay Ariane 5 501: 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. Tàu quỹ đạo khí hậu sao Hỏa của NASA: 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 hoặc Mahatma Gandh trong …có lẽ vậy. Mario Civilization 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.
