Có phải lỗi đang giết chết động lực của bạn?

Lỗi phần mềm là một sự xuất hiện phổ biến trong thế giới công nghệ. Nếu bạn đã từng viết hơn mười dòng mã, rất có thể bạn đã vô tình gây ra một dòng.

Bây giờ, tôi muốn bạn nghĩ về lần cuối cùng bạn nhận được tin nhắn từ một khách hàng hoặc đồng nghiệp lo lắng về một lỗi. Nó đã kết thúc như thế nào? Lỗi có khẩn cấp đến mức bạn phải dừng công việc đang làm không?

Trong bài viết này, chúng ta sẽ cố gắng thách thức suy nghĩ thông thường về lỗi và tìm hiểu xem mỗi lỗi khiến bạn và nhóm của bạn phải trả giá bao nhiêu.

Về tôi

Xin chào 👋, tên tôi là Krste và tôi là một nhà phát triển toàn diện đã làm việc trong các công ty khởi nghiệp hơn bảy năm. Gần đây, tôi đã đồng sáng lập Bugpilot , một nền tảng theo dõi lỗi giúp cảnh báo cho các nhóm phần mềm về các lỗi nghiêm trọng mà người dùng gặp phải.

Tôi viết bài này với mục tiêu thách thức suy nghĩ thông thường về lỗi và "chúng ta cần sửa nó càng sớm càng tốt!" tư duy, đặt câu hỏi về sự cần thiết phải khám phá chi phí thực sự của từng vấn đề.

Phần mềm không có lỗi 100%. Huyền thoại hay Thực tế?

Mục tiêu đạt được phần mềm không có lỗi 100% luôn là một mục tiêu khó khăn. Ý tưởng tạo một ứng dụng ít lỗi nghe có vẻ lý tưởng, nhưng liệu nó có thực sự khả thi?

Sự thật là lỗi phần mềm là không thể tránh khỏi do logic nghiệp vụ phức tạp, lỗi của con người và cập nhật liên tục của công nghệ. Ngay cả khi đã thử nghiệm và kiểm tra chất lượng cẩn thận, rất khó để loại bỏ chúng hoàn toàn.

Tuy nhiên, nhờ các công cụ dành cho nhà phát triển mới và các quy trình được cải tiến, các nhóm hiện đang cung cấp các tính năng mới với tốc độ cực nhanh để có thể duy trì tính phù hợp và tính cạnh tranh.

Và, với bất kỳ thay đổi nào đối với cơ sở mã, luôn có thể xảy ra sự cố. (Việc phải hỗ trợ nhiều thiết bị và nhiều trình duyệt không giúp ích gì cả.)

Tất nhiên, có những trường hợp bug phải gần bằng không. Một số ngành, chẳng hạn như ngân hàng, y tế và hàng không vũ trụ, phải đảm bảo hạn chế tối đa sai sót, vì chúng có thể phải trả giá bằng mạng sống .

Điều đó giải thích tại sao hầu hết phần mềm trong các ngành này được viết bằng công nghệ từ nhiều thập kỷ trước và tại sao mọi người hiện nay ngần ngại chạm vào nó.

Nhưng cuối cùng, chúng ta phải tự hỏi: "Có đáng không? " Đối với hầu hết chúng ta khi xây dựng các công cụ tiếp thị và CRM, tôi tin rằng sửa lỗi thường tốn kém hơn là để chúng ở đó. Tôi sẽ cố gắng giải thích lý do.

Không phải tất cả các lỗi đều bình đẳng

Hãy tưởng tượng bạn đang làm việc trên một trang web thương mại điện tử và một lỗi đã phá vỡ quy trình thanh toán, khiến khách hàng không thể hoàn tất việc mua hàng của họ.

Rõ ràng là lỗi này cần được chú ý ngay lập tức vì nó ảnh hưởng trực tiếp đến chức năng cốt lõi và có khả năng dẫn đến mất doanh thu và khách hàng không hài lòng.

Tương tự, chúng tôi không thể coi lỗi trong trang Đăng ký ngăn người dùng mới tham gia ứng dụng đi chung xe mới của chúng tôi giống như sự cố liên quan đến việc cập nhật ảnh hồ sơ .

Những ví dụ đen trắng này cho thấy rằng chúng ta không chỉ cần phát hiện mà còn cần một cách để hiểu tác động của lỗi. Tuy nhiên, trên thực tế, mọi thứ không trắng đen rõ ràng. Hầu hết các tình huống nằm trong khu vực màu xám. Sau đó, câu hỏi trở thành: làm thế nào để chúng ta biết phải khắc phục điều gì?

“CHÚNG TÔI PHẢI KHẮC PHỤC NGAY BÂY GIỜ HOẶC KHÁCH HÀNG SẼ RỜI”

Tôi nhận thấy rằng chúng tôi có xu hướng thêm cảm giác khẩn cấp "thêm" vào các lỗi mà khách hàng của chúng tôi tìm thấy.

Bạn có thể đã từng ở trong tình huống tương tự khi một trong những khách hàng lớn của bạn gặp sự cố nhỏ và toàn bộ nhóm của bạn nhận được rất nhiều thông báo như thể cả thế giới đang bốc cháy 🔥

” Giovanni phàn nàn rằng họ không thể căn chỉnh văn bản 11 1 Họ là một khách hàng quan trọng. Chúng ta phải sửa lỗi NGAY BÂY GIỜ!”

- sếp của bạn

Dựa trên kinh nghiệm của tôi, các vai trò đối mặt với khách hàng như sự thành công của khách hàng, hỗ trợ và bán hàng có xu hướng ưu tiên các vấn đề tùy thuộc vào cách khách hàng phản ứng và cách nó ảnh hưởng đến danh tiếng của họ. Đây là lý do tại sao mọi thứ dường như là một vấn đề lớn đối với họ, điều này có thể hiểu được.

Không ai muốn tạo ấn tượng xấu hoặc mang tiếng xấu, và đó chính xác là những gì lỗi có thể gây ra.

Càng nhiều người dùng bị ảnh hưởng bởi một lỗi, điều quan trọng hơn (có lẽ) là sửa nó

Đôi khi, các vấn đề sản xuất được xử lý khi chúng xảy ra. Đặc biệt là các nhà phát triển của chúng tôi sẽ xử lý ngay bất kỳ lỗi hoặc lỗi mã hóa nào lọt vào hộp thư đến của họ.

Bạn hoặc nhóm của bạn có thể đang sử dụng một công cụ như Sentry hoặc Bugsnag để theo dõi và nhận thông báo khi xảy ra lỗi. Khi tìm thấy bất kỳ lỗi nào, lỗi đó sẽ nhanh chóng được giao cho nhà phát triển trong khi mọi người đều sốt ruột chờ đợi bản cập nhật trong Slack.

Thông thường, các công cụ này ưu tiên các lỗi dựa trên tần suất chúng xảy ra và số lượng người dùng bị ảnh hưởng.

Human.prioritizeBugs()

Tuy nhiên, mức độ ưu tiên của hầu hết các lỗi trong hầu hết các nhóm có thể được xác định bởi chủ sở hữu sản phẩm hoặc nhà phát triển chính. Những vai trò này thường có hiểu biết về logic kinh doanh, công nghệ cơ bản, khối lượng công việc hiện tại và các ưu tiên sắp tới cũng như lập kế hoạch phù hợp.

Tiêu chí ưu tiên của họ có thể giống như thế này:

Nó có quan trọng hay không? Câu hỏi đầu tiên, nhưng nó đã trở nên hơi phức tạp rồi. Điều gì quan trọng? Quan trọng không có một định nghĩa rõ ràng. Nếu một chức năng cốt lõi không sử dụng được, thì rõ ràng là chúng ta phải sửa nó. Tuy nhiên, như bạn đã thấy trong ví dụ trên, nếu một khách hàng quan trọng bị ảnh hưởng thì sao?

Nó ảnh hưởng đến bao nhiêu khách hàng? Chỉ một? Mọi người? Chúng ta thậm chí có biết không? Khi một số lượng đáng kể người dùng bị ảnh hưởng, bạn có thể muốn giải quyết vấn đề, ngay cả khi vấn đề đó liên quan đến một chức năng nhỏ.

Mất bao nhiêu thời gian để sửa nó? Tiếp theo, chủ sở hữu quy trình “Xử lý lỗi” sẽ hỏi cần bao nhiêu thời gian để khắc phục sự cố. Nếu chỉ mất vài giờ, họ sẽ tìm cách dồn nó vào công việc của tuần này.

“Khắc phục (càng sớm càng tốt) hay không khắc phục, đó là câu hỏi.”

Các nhà phát triển thường phải đối mặt với tình thế tiến thoái lưỡng nan khi xử lý một lỗi "khẩn cấp". Họ có thể gấp rút hoàn thành nhiệm vụ hiện tại của mình và sửa lỗi, có thể đưa ra các lỗi mới trong quá trình này; họ thường bỏ qua chi phí chuyển đổi ngữ cảnh , vì họ có thể đột ngột chuyển sự chú ý sang lỗi, từ bỏ hoàn toàn nhiệm vụ hiện tại của họ.

Có ba vấn đề quan trọng với các tình huống này:

1. Nhóm ưu tiên không chính xác, dẫn đến có thể lãng phí thời gian và sửa các lỗi ít liên quan hơn.

   
   

2. Thêm tính cấp bách không cần thiết vào các lỗi không nghiêm trọng sẽ khiến nhóm chuyển trọng tâm một cách không cần thiết.

   
   

3. Trước khi giải quyết một lỗi, điều quan trọng là phải xem xét chi phí của nó. Vì vậy, một lỗi thực sự gây thiệt hại cho đội là bao nhiêu? Là sửa chữa nó một chi phí hợp lý?

Làm thế nào tốn kém để sửa lỗi?

Bạn đã bao giờ nghe câu "Không có bữa trưa nào là miễn phí" chưa?

Khi chúng ta nói về chi phí, điều đầu tiên chúng ta nghĩ đến với tư cách là nhà phát triển là chi phí cơ sở hạ tầng, chi phí của máy chủ, Hàm Lambda, Cụm MongoDB, v.v. Tuy nhiên, khi nói đến lỗi, tôi đang nói về chi phí liên quan đến con người: sự chú ý .

Chuyển ngữ cảnh

Nếu bạn học kỹ thuật máy tính hoặc bạn đã từng đọc về cách thức hoạt động của hệ điều hành, có lẽ bạn đã nghe nói về chuyển đổi ngữ cảnh.

Trong điện toán, chuyển đổi ngữ cảnh là quá trình lưu trữ trạng thái của một quy trình hoặc luồng, để nó có thể được khôi phục và tiếp tục thực thi sau đó, sau đó khôi phục trạng thái khác, đã lưu trước đó.

(từ [Wikipedia](https://Context switch https://en.wikipedia.org › wiki › Context_switch))

Một trường hợp chuyển đổi bối cảnh hệ điều hành có thể là Đa nhiệm: Chuyển đổi ngữ cảnh là đặc điểm của đa nhiệm cho phép chuyển đổi quy trình từ CPU để có thể chạy một quy trình khác.

Tôi đã nghe những từ này ở đâu trước đây 🤔? - À, vâng:

“Tôi là bậc thầy về đa nhiệm.”

Đa nhiệm có thể diễn ra khi ai đó cố gắng thực hiện đồng thời hai nhiệm vụ, chuyển từ nhiệm vụ này sang nhiệm vụ khác hoặc thực hiện hai hoặc nhiều nhiệm vụ liên tiếp nhanh chóng.

Vừa giặt đồ vừa nói chuyện với một người bạn có lẽ sẽ ổn thôi. Phần khó xảy ra khi chúng ta làm những công việc phức tạp về mặt trí óc, chẳng hạn như viết mã.

Các nhà tâm lý học đã tiến hành nhiều thí nghiệm về chuyển đổi nhiệm vụ để xác định chi phí của nó. Họ đo thời gian cần thiết để mọi người hoàn thành nhiệm vụ và chi phí thời gian chuyển đổi giữa các nhiệm vụ. Kết quả như sau:

“ Mặc dù chi phí chuyển đổi có thể tương đối nhỏ, đôi khi chỉ bằng vài phần mười giây cho mỗi lần chuyển đổi, nhưng chúng có thể cộng lại thành số tiền lớn khi mọi người chuyển đổi qua lại liên tục giữa các tác vụ. … chuyển đổi giữa các nhiệm vụ có thể tiêu tốn tới 40 phần trăm thời gian làm việc hiệu quả của ai đó.”

“Bạn có thời gian rảnh không?”

Hãy tưởng tượng điều này: bạn đang bị khóa, đắm chìm hoàn toàn và không gì có thể ngăn bạn hoàn thành tính năng mới, sáng bóng này. Thế giới bên ngoài thậm chí không tồn tại - chỉ có bạn và mã của bạn. Nhưng sau đó, bạn đột nhiên nghe thấy một hồi chuông... một thông báo mới trên điện thoại của bạn.

Đó là bạn của bạn rủ bạn đi uống nước vào cuối tuần này. Và cứ như thế, gặp sự cố , 20 phút tiếp theo của cuộc đời bạn sẽ biến mất.

Hoặc có thể bạn vừa nhận được một tin nhắn Slack từ đồng nghiệp hỏi liệu bạn có thời gian để trợ giúp về một vấn đề cụ thể hay không.

Tình huống thứ hai có dễ chấp nhận hơn tình huống thứ nhất không?

Vâng, cuối cùng, nó không quan trọng. Dựa trên phân tích 10.000 phiên lập trình được ghi lại từ 86 lập trình viên sử dụng Eclipse và Visual Studio và khảo sát 414 lập trình viên ( Parnin:10 ) cho thấy:

• Một lập trình viên mất 10-15 phút để viết thêm mã sau khi tiếp tục công việc sau khi bị gián đoạn.

• Khi bị gián đoạn trong quá trình chỉnh sửa một phương thức, chỉ 10% số lần lập trình viên tiếp tục công việc trong vòng chưa đầy một phút.

• Một lập trình viên có thể chỉ nhận được một phiên 2 giờ không bị gián đoạn trong một ngày.

Các nhà phát triển có xu hướng tránh ( và ghét ) chuyển đổi ngữ cảnh khi nói về các cuộc họp vô ích. Tuy nhiên, tôi tin rằng chúng ta có thể bị mù bằng cách nào đó khi chuyển ngữ cảnh giữa “các nhiệm vụ của nhà phát triển” và hoàn toàn bỏ qua tác động tiêu cực của nó.

Suy nghĩ cuối cùng

Trong thế giới thực, chúng ta luôn phải đối mặt với những nguồn lực hạn chế, cho dù đó là tiền bạc, thời gian hay sự chú ý .

Sửa lỗi có giá.

“Không” là không đối với một điều. “Có” là không đối với rất nhiều thứ. – Jason Chiên

Nói “có” để sửa một lỗi có nghĩa là nói “không” với một tính năng. Nhìn bề ngoài, đa nhiệm có vẻ hiệu quả, nhưng việc chuyển đổi giữa các tác vụ sẽ mất nhiều thời gian hơn và cuối cùng sẽ gây ra nhiều lỗi hơn.

Hiểu được chi phí tiềm ẩn của việc chuyển ngữ cảnh giúp bạn đưa ra lựa chọn tốt hơn về lỗi nào đáng để loại bỏ mọi thứ và lỗi nào không (hầu hết là không).

Chúng ta có nên ngừng quan tâm đến lỗi không?

Ồ không. Tuy nhiên, ít nhất chúng ta nên nhận thức được chi phí sửa lỗi và tự hỏi: "Có đáng để sửa không?" Việc ngồi bình tĩnh và chấp nhận lỗi có thể là một thách thức. Tất cả chúng ta đều có mong muốn bên trong là tạo ra sản phẩm chất lượng cao và xây dựng thứ gì đó mà chúng ta có thể tự hào.

Thật không may, những con bọ phiền phức đó thường cản trở bạn.

Như Tom De Marco đã viết trong cuốn sách "Peopleware" của mình, điều này có thể giải thích tại sao thật khó để ngừng quan tâm đến chất lượng:

Tất cả chúng ta đều có xu hướng gắn chặt lòng tự trọng của mình với chất lượng sản phẩm chúng ta sản xuất—không phải số lượng sản phẩm, mà là chất lượng. (Vì một số lý do, có rất ít sự hài lòng khi tạo ra một lượng lớn những thứ tầm thường, mặc dù đó có thể chỉ là những gì cần thiết cho một tình huống nhất định.)

– Phần mềm nhân dân

Chúng ta có nên nỗ lực nhiều hơn vào việc ngăn chặn lỗi không?

Như tôi đã đề cập trước đó, bạn không có sự lựa chọn trong nhiều ngành công nghiệp. Ở đó, bạn phải thực hiện tất cả các bước cần thiết để ngăn ngừa sai lầm xảy ra và sửa chúng nhanh nhất có thể.

Tuy nhiên, đối với hầu hết các ứng dụng, nỗ lực thêm đó có đáng không?

PS Vào cuối ngày, ngay cả khi chúng tôi có cây đũa thần sửa tất cả các lỗi, người dùng của chúng tôi vẫn sẽ tìm cách lạm dụng ứng dụng của chúng tôi 😅