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"?

Những mẩu tin ngắn hàng ngày dành cho bạn
  • Tin tức sáng sớm, mọi người còn nhớ vụ kiện của Ryan Dahl - hay nói đúng hơn là của nhóm Deno với Oracle về cái tên JavaScript không?

    Oracle đã phản hồi rằng họ không từ bỏ cái tên JavaScript đâu 🫣

    https://x.com/deno_land/status/1876728474666217739

    » Xem thêm
  • Mọi người nghỉ tết sớm rồi hay sao á? Nhiên cái nguyên tuần nay traffic giảm hẳn luôn 😳. Một mình tuôi nói kể cũng buồn, ai đi ngang qua đọc được thì thả một "còm men" cho vui cửa vui nhà nha. Nói gì cũng được vì ẩn danh cả mà 😇🔥

    » Xem thêm
  • Có người hỏi mình là cập nhật tin tức ở đâu mà nhanh thế, hay là kiếm ra được mấy cái tools, mấy cái projects... ở đâu mà nhiều thế? Thì có một nguồn xa tận chân trời mà gần ngay trước mắt đó chính là trang Github Trending này đây.

    Trang này thống kê lại các kho lưu trữ đang có lượt "star" nhiều nhất theo ngày/tuần/tháng. Nó còn xem theo được ngôn ngữ cơ, mà mỗi ngôn ngữ lại kiểu như một chủ đề á. Ví dụ Python thì hót rần rần về AI, LLMs..., Rust thì bao tools siêu mạnh, còn Go thì... đồ chơi liên tục 😁. Trong khi JavaScript 🫣😑

    » 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

Bí mật ngăn xếp của Blog

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào 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ùng11 tháng 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ống11 tháng 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
Bấm hoặc cuộn mạnh để sang bài mới