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
  • Hẳn là nhiều người ở đây đã nghe đến kiểu tấn công bảo mật Clickjacking rồi nhỉ. Kẻ tấn công thường nhúng một website (thường là mục tiêu) vào trong một iframe trên website của chúng, sau đó làm mờ hoặc ẩn nó đi rồi đặt vào vị trí các nút bấm trên web, ví dụ "Bấm vào để nhận quà". Đâu ai ngờ rằng phía trên nút bấm đó là một nút bấm khác trong iframe. Khá nguy hiểm!

    Nhưng trình duyệt đã có cách ngăn chặn kiểu tấn công này bằng các quy tắc như tiêu đề X-Frame-Options, frame-ancestors của CSP và SameSite: Lax/Strict của Cookies...

    Mới đây, đã xuất hiện thêm kiểu tấn công mới - "DoubleClickjacking" 😨. Đại ý là "hắn" lợi dụng hành động double click để lừa người dùng bấm vào một nút mà hắn muốn. Chi tiết hơn trong bài viết này: DoubleClickjacking: A New Era of UI Redressing.

    » Xem thêm
  • Mọi người đã nghe nói đến Jujutsu - jj - một dạng quản lý phiên bản cho mã nguồn (version control system) chưa? Có vẻ như nó đang nhận được nhiều sự quan tâm.

    Chờ xíu! Chẳng phải git đã quá tốt rồi sao? Thế thì chế ra thằng jj để làm gì nữa? Cũng hơi khó trả lời nhỉ? Mỗi công cụ sinh ra chắc chắn phải cải thiện hoặc khắc phục được nhược điểm của cái trước. Cho nên jj ắt hẳn phải làm được điều gì đó mà git chưa làm được nên mới nổi lên như vậy.

    Thật ra mình đã nghe nói đến jj từ vài tháng trước rồi, nhưng vào đọc thì toàn kiến thức cao siêu. Hoặc là đang mang nặng cái lối suy nghĩ của git vào trong đầu rồi nên chưa lĩnh hội ra được điều gì cả.

    Mình hay có kiểu cái gì đọc lần 1 mà không hiểu thì đọc tiếp lần 2, lần 2 không hiểu thì đọc tiếp lần 3... đến lần thứ n mà vẫn không hiểu thì bỏ. Cơ mà không phải là từ bỏ mà một thời gian sau đó quay lại đọc tiếp. Đến một lúc nào đó khả năng mình sẽ hiểu ra một ít vấn đề, thế mới tài 😆.

    Thì cái jj này có vẻ như nó đang mở ra được tính linh hoạt trong việc "cam kết" mã. Tưởng tượng bạn đang làm việc trên một dự án, đang ở nhánh này, muốn sang nhánh khác để sửa, nhưng mà lại đang viết dở ở nhánh này, thế là phải stash, rồi checkout, rồi commit, rồi merge hoặc rebase lại vào nhánh cũ... nhìn chung quá trình làm việc với git nghiêm ngặt đến mức cứng nhắc, cần nhiều thao tác để giải quyết một vấn đề, chưa kể cái cây commit (commit-tree) nữa thì ôi thôi, khỏi xem cho đỡ nhức mắt. Thế nên ông jj này đang làm cách nào đó để bạn khỏi cần phải quan tâm đến các nhánh luôn, sửa trực tiếp vào commit. Nghe ảo nhỉ 😂.

    Đấy mới lĩnh hội được đến đấy, hy vọng sau n lần đọc lại nữa mình sẽ viết được một bài chi tiết hơn về công cụ này.

    » Xem thêm
  • Gòi gòi tới công chiện gòi 🤤🤤🤤

    » 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
Bấm hoặc cuộn mạnh để sang bài mới