Bàn về vấn đề "Có nên sửa lỗi của người khác"?

Bàn về vấn đề "Có nên sửa lỗi của người khác"?

Tin ngắn hàng ngày dành cho bạn
  • Manus đã chính thức mở cửa cho tất cả người dùng rồi đấy mọi người. Cho những ai chưa biết thì đây là một công cụ viết báo cáo (làm mưa làm gió) giống như Deep Research của OpenAI á. Mỗi ngày được miễn phí 300 Credits để nghiên cứu. Mỗi lượt nghiên cứu tiêu tốn tuỳ thuộc vào độ phức tạp của yêu cầu. À với cả họ đang có chương trình tặng miễn phí Credits hay sao á. Như mình thì vào thấy được hẳn 2000.

    Mình dùng thử, so sánh với cùng một lệnh giống như đợt trước dùng bên Deep Research thì nội dung khác biệt nhau hoàn toàn. Manus báo cáo như kiểu viết văn hơn so với OpenAI là các gạch đầu dòng và bảng biểu.

    À lúc đăng ký xong có bắt nhập số điện thoại để xác minh, nếu lỗi thì các bạn đợi qua ngày thử lại xem có được không nhé.

    » Xem thêm
  • Mọi người chắc nghe nhiều về xu hướng tìm kiếm thông tin bằng AI chứ không cần công cụ tìm kiếm như Google nữa rồi đúng không? Không đâu xa ánh xạ vào bản thân thì thấy đúng thật, thi thoảng mới tìm kiếm thôi chứ còn đâu toàn hỏi tụi AI.

    Ngay từ đầu viết blog, thứ mà mình hướng đến là chia sẻ kinh nghiệm chứ không phải là những bài mang nặng tính kỹ thuật, máy móc, hướng dẫn từ đầu... Vì thời điểm đó đã có quá nhiều người làm nội dung này rồi và họ làm rất tốt, tại sao mình phải cố phát minh lại bánh xe? Một điều nữa là tin tưởng độc giả của mình có khả năng tìm hiểu vấn đề. Nếu bạn đọc đủ nhiều các bài viết trên blog thì thấy mình luôn cố gắng chèn thêm các liên kết tham khảo ngoài bài viết, nêu ra vấn đề mở và rất ít khi kết luận chắc chắn một điều gì đó.

    Mình đã cố gắng rèn luyện kỹ năng viết, kỹ năng trình bày và cả cách tương tác với độc giả để mang lại giá trị cho họ. Nhiều lúc ngồi lật lại các con số thống kê thấy lượng đọc bài viết tăng lên lại cảm thấy vui. Nhưng khi nguồn truy cập đến từ Google thì lại thấy buồn, vì điều đó chứng tỏ họ biết đến mình chỉ khi đang cố đi tìm giải pháp, có thể họ chỉ đọc chớp nhoáng, may ra tìm được cách giải quyết và thế là đóng cửa sổ trình duyệt rồi đi như một cơn gió.

    Chừng vài tháng đổ lại đây, một điều khiến mình rất vui đó là lượng người truy cập thẳng vào trang chủ mà không thông qua công cụ tìm kiếm đang tăng dần lên, có nhiều hôm lượng truy cập tự nhiên còn cao hơn cả đến từ Google. Điều đó chứng tỏ độc giả đã có thói quen quay lại trang của mình nhiều hơn và họ tìm thấy được giá trị từ blog mang lại. Vui mừng khôn xiết 🤩

    Bên cạnh đó thì lượng truy cập vào chuyên mục Threads - tức là mục mình đang viết bài này đang cao hơn bao giờ hết. Điều đó chứng tỏ xu hướng đi theo tin nhanh là đúng đắn. Mình có thể ngồi cả ngày để viết tin ngắn cho bạn đọc vì nó rất nhanh mà tiện, không tốn công đi tìm tài liệu để viết, không tốn cả thời gian viết nữa, còn mình thì có rất nhiều thứ để chia sẻ 😅. Nhưng không vì thế mà bỏ bê các bài viết dài, vì dài thì có nhiều thông tin để chia sẻ hơn.

    Vài lời tâm sự thế thôi chứ hơn một tháng nay mình chưa viết bài viết mới nào vì công việc bận quá. Xong lâu dần cứ trì hoãn lại thành lười. À với cả tháng 5 này rất thích hợp để đọc các cuốn sách về cách mạng á. Có hôm đọc đến 2 giờ sáng mới đi ngủ 🥱

    » Xem thêm
  • Mình mới nhìn thấy một trang web khá thú vị nói về các cột mốc đáng nhớ trong lịch sử phát triển Internet toàn cầu: Internet Artifacts

    Chỉ từ 1977 - khi Internet còn nằm trong hộp thí nghiệm thì nhìn xem - giờ đây Internet đã khiến mọi thứ phát triển đến mức nào 🫣

    » Xem thêm

Vấn đề

Xin chào độc giả của 2coffee.dev, hôm nay chúng ta hãy dành một ít thời gian để cùng nhau tâm sự, bài viết hôm nay là về chủ đề "Có nên sửa lỗi của người khác?". Hmm, Câu hỏi này cũng đơn giản mà, tất nhiên là đã làm việc trong cùng một Công ty, trong cùng một Team, cùng một sản phẩm thì tất cả mọi người cùng nhau phát triển và cùng nhau sửa lỗi là một điều hết sức bình thường thế sao lại còn phải hỏi!?

Đó có thể là suy nghĩ của nhiều người khi nói về việc "có nên sửa lỗi" của người khác. Nhưng tôi tin rằng, bên cạnh đó vẫn có những người, kể cả như tôi cách đây vài năm trước thôi, cảm thấy đây là một điều gì đó "khó mà chấp nhận được".

Trong suốt thời gian đi làm, tất cả công ty tôi tham gia đều làm về một sản phẩm nào đó, hay còn gọi là công ty "Products". Việc mình phụ trách một vị trí trong một dự án, ví dụ như lập trình viên Backend hay Frontend đồng nghĩa với việc đảm bảo phát triển các tính năng ở từng mảng chuyên môn.

Thông thường khi đưa ra quyết định phát triển một tính năng mới, sau bảy bảy bốn mươi chín bước để đến tay được đội "dev", công việc tiếp theo là lập kế hoạch và phân chia nhiệm vụ cho từng thành viên trong Team. Ví dụ tính năng sau khi phân tích ra gồm có 4 công việc chính cần hoàn thành, tôi nhận 2 phần việc, còn lại người khác 2 phần việc. Trong quá trình làm, tôi phải phụ trách từ đầu đến cuối cho đến khi tính năng đó hoàn thành và phát hành đến cho người dùng. Nghĩa là nếu có lỗi, QC sẽ gán lỗi đó cho tôi và cần phải sửa.

Cho đến khi vào một team khác, quy trình phát triển có phần thay đổi, đặc biệt nhất là lỗi không được gán cho chính người làm tính năng đó, nó được gán ngẫu nhiên cho những người tương đương hoặc theo chỉ định của người quản lý.

Lúc này nhiều vấn đề bắt đầu xảy đến, việc cố gắng sửa lỗi của người khác giống như là phải hiểu được tường tận mã của họ trước khi đặt tay vào những dòng mã. Tôi mất nhiều thời gian hơn để hiểu người khác nghĩ gì, mất nhiều thời gian hơn để trao đổi và cả những khi lỗi tôi tạo ra còn nhiều hơn là sửa lỗi của họ. Đó quả thật là một điều tồi tệ và tôi cảm thấy bất hợp lý trong một thời gian dài.

Những vấn đề trên chỉ xảy ra khi can thiệp vào logic chuyên sâu chứ không nói đến một số lỗi đơn giản như lỗi cú pháp, lỗi thiếu điều kiện lọc... Nếu là lỗi đơn giản, bất kì ai cũng có thể nhận ra và nhanh chóng sửa chữa, nhưng điều tôi muốn nói đến là lỗi phức tạp hơn liên quan đến logic của nghiệp vụ. Vâng, nghe đến đây thôi cũng đã thấy đau đầu rồi.

Vì thế câu hỏi mà tôi đặt ra lúc đó là: Tại sao tôi phải đi sửa lỗi của người khác chứ? Chẳng phải hơn ai hết, họ hiểu biết mã họ viết ra và họ phải có trách nhiệm sửa chữa sai lầm họ gây ra chứ?

Tại sao nên sửa lỗi của chính mình?

Tạm gác lại câu hỏi đầy bức xúc bên trên, chúng ta thử phân tích lợi ích của việc tự sửa lỗi của chính mình gây ra.

Thứ nhất, mình là người tạo ra lỗi thế cho nên cần có trách nhiệm với điều đó. Việc phải chịu trách nhiệm trước lỗi lầm mà mình gây ra sẽ làm cho bản thân có suy nghĩ thấu đáo hơn khi đặt những dòng mã, bởi vì mình biết đó là lỗi lầm bản thân gây ra và phải tự chịu "hình phạt" là sửa lại. Thử nghĩ nếu một lập trình viên vì lý do nào đó, tạo ra lỗi liên tục và bạn là người phải gánh chịu thì bạn có vui vẻ tiếp nhận hay là không?

Hơn ai hết, họ là những người tạo ra logic và hiểu được logic mà họ viết ra. Nếu có lỗi, họ nhanh chóng suy đoán ra được lỗi nằm ở đâu hay biết cách tìm ra lỗi nhanh nhất thay vì đi phỏng đoán và tốn nhiều thời gian hơn để debug.

Một phần nữa là do văn hóa của Công ty hoặc trong Team. Phụ thuộc vào cách làm việc từ xưa đến nay, mỗi người quản lý có cách quản lý khác nhau, họ quan niệm rằng lỗi ai tạo ra thì người đó nên sửa để tiết kiệm thời gian. The quy trình, QC cũng tự động gán lỗi cho người làm tính năng đó. Làm như vậy quy trình sẽ thống nhất và tiết kiệm được thời gian đáng kể.

Tại sao nên sửa lỗi của người khác?

Vậy, sửa lỗi của người khác có thực sự là một điều "tồi tệ" như trước kia tôi nghĩ?

Thứ nhất, phải xác định được một điều: Phần mã nguồn của tất cả mọi người là thuộc về công ty, tổ chức. Vì thế tất cả mọi người đều có trách nhiệm, hay nói cách khác ai cũng có thể phải chịu trách nhiệm cho phần mã nãy trong dự án, ai cũng cần phải sẵn sàng sửa bất kì lỗi nào phát sinh. Điều này đánh vào trách nhiệm bản thân và tinh thần làm việc nhóm.

Tuy mất nhiều thời gian để đọc hiểu logic trước khi sửa lỗi, bù lại là bạn có thể nắm bắt được phần công việc của người khác. Nếu chẳng may tác giả của đoạn mã kia nghỉ ốm, hay thậm chí là nghỉ việc, những thành viên khác có thể thay thế và tiếp tục công việc mà không bị ngắt đoạn. Sau này có người mới vào, quy trình sẽ lặp lại, họ sẽ nhanh chóng nắm bắt được văn hóa làm việc và từ đó dễ thích nghi hơn.

Nâng cao quy trình làm việc. Hãy nhớ lại những ưu điểm của việc tự sửa lỗi của chính, đó có thể phản ánh một "sự thật nhức nhối" về quy trình làm việc bất ổn. Hãy thử đặt câu hỏi: Tại sao anh A có cùng cấp với anh B mà lại không thể sửa được lỗi của B gây ra? Giả sử A nói rằng B viết mã khó đọc, khó hiểu thì vấn đề của người xem xét mã (review code) ở đâu? Tại sao lại để cho B viết mã khó hiểu mà vẫn duyệt (merge)? Phải chăng trong Team không có quy tắc chung cho việc viết?... Tương tự, phải chăng mọi người đã không chịu trao đổi về logic trước khi bắt đầu bắt tay vào làm? Chỉ cho đến khi người chịu trách nhiệm chính của phần logic đó nghỉ thì không ai hiểu được phần mà người đó viết nữa...

Vậy có nên sửa lỗi của người khác?

Theo quan điểm của tôi vẫn là nên, nhưng không phải là bắt buộc.

Như đã nói, điều này phụ thuộc nhiều vào văn hóa của team, của công ty từ trước. Nếu team bạn đang để ai tự sửa lỗi của người đó và cảm thấy mọi thứ dễ dàng và nhanh chóng hơn thì không có lý do gì để thay đổi. Ngược lại, một Team đã có văn hóa "chia sẻ" lỗi cho những người cùng chức vụ thì mọi người sẽ đi vào một quy trình chuyển giao công việc liên tục hơn.

Tổng kết

Như tôi đã chia sẻ câu chuyện của mình, rằng trước đó chưa hề có suy nghĩ về vấn đề sửa lỗi của người khác. Thời gian đầu cảm thấy thật phi lý và khó chịu vì phải tốn nhiều thời gian đi đọc lại logic của người khác, nhiều đoạn còn không hiểu hoặc không dám sửa vì sợ gây ra nhiều lỗi khác. Nhưng dần dần, khó khăn sẽ qua đi và mình thì hiểu được dự án hơn. Còn bạn? Bạn suy nghĩ sao về vấn đề này, hãy để lại bình luận nhé!

Cao cấp
Hello

Tôi & khao khát "chơi chữ"

Bạn đã thử viết? Và rồi thất bại hoặc chưa ưng ý? Tại 2coffee.dev chúng tôi đã có quãng thời gian chật vật với công việc viết. Đừng nản chí, vì giờ đây chúng tôi đã có cách giúp bạn. Hãy bấm vào để trở thành hội viên ngay!

Bạn đã thử viết? Và rồi thất bại hoặc chưa ưng ý? Tại 2coffee.dev chúng tôi đã có quãng thời gian chật vật với công việc viết. Đừng nản chí, vì giờ đây chúng tôi đã có cách giúp bạn. Hãy bấm vào để trở thành hội viên ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (2)

Nội dung bình luận...
Avatar
Huy Tùng1 năm trước
Blog của bạn rất thú vị nhưng mình tìm mãi ko có chỗ subcribe để nhận & noti bài viết mới :(
Trả lời
Avatar
Xuân Hoài Tống1 năm trước
Xin lỗi bạn vì sự bất tiện này, thực ra là blog có phần nhận thông báo tuy nhiên nó hơi "ẩn" một chút xíu. Nếu muốn nhận notification cho bài viết mới bạn có thể thao tác: Ngay lần truy cập đầu tiên, góc phải phía dưới màn hình có một thông báo sử dụng Cookie, bạn bấm vào đồng ý, sau đó tải lại trang hoặc đọc một bài viết khác thì một thông báo khác hiện ra nhắc nhở bạn bật thông báo bài viết mới. Sở dĩ mình làm thế vì những người quay lại lần 2 hoặc đọc nhiều bài viết sẽ có nhu cầu theo dõi cao hơn so với người chỉ đọc một lần. Tuy nhiên thì với gợi ý của bạn, mình sẽ xem xét bổ sung thêm tính năng nhận thông báo rõ ràng hơn trong tương lai 😄.
Avatar
Thành Đỗ1 năm trước
Tóm lại là nên kết hợp cả 2, vừa sửa lỗi mình, vừa sửa lỗi người khác :))
Trả lời