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
  • Cuối tuần đang ngồi làm cái Cửa hàng cho thư giãn mọi người ạ. Trước mình đã làm một lần rồi cơ mà làm cho có, bán được hẳn 1 cuốn sách 😆

    Giờ làm lại, sẽ đa dạng sản phẩm hơn. Dự là đăng mấy sản phẩm đã mua và dùng rồi kèm theo vài dòng nhận xét cho mọi người tham khảo 🤓

    » Xem thêm
  • Một bài viết thú vị về cách làm thế nào để viết blog cho lập trình viên đọc.

    How to Write Blog Posts that Developers Read

    Tóm tắt lại là đi thẳng vào vấn đề và hình dung ra đối tượng độc giả mà bạn đang nhắm đến. Một điều nữa là tác giả đã có hơn 9 năm kinh nghiệm viết, thời gian đầu không ai đọc nhưng sự kiên trì đã giúp anh đạt được mốc 300K - 500K độc giả mỗi năm. Quả là con số ấn tượng phải không ạ 🔥

    » Xem thêm
  • Bây giờ hiện đại quá cái gì người ta cũng có thể nghĩ ra được. ferretdb.com là một dự án mã nguồn mở, biến cơ sở dữ liệu PostgreSQL thành... MongoDB. Đúng vậy bạn không nghe nhầm đâu. Nếu vẫn muốn dùng Postgres mà thích cú pháp truy vấn của Mongo thì ferretdb là dành cho bạn.

    À ngoài PostgreSQL ra thì còn có thể cắm vào SQLite nữa. Xịn!!! 🙏

    » 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ù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