4 thói quen khiến bạn trở thành một Developer kém hiệu quả
Bạn không phải là một Developer kém cỏi, bạn chỉ có một số thói quen xấu cần bỏ đi mà thôi!
Tất cả chúng ta đều có những thói quen xấu, không có bất kì một người nào trên trái đất này là hoàn hảo cả!
Có những thói quen xấu có thể làm tổn hại nghiêm trọng đến hiệu quả làm việc của một Developer. Thậm chí chúng cũng có thể tác động đến những người xung quanh.
Jack Canfield nói: “Các thói quen của bạn sẽ quyết định tương lai của bạn”. Nếu bạn muốn phát triển, bạn phải phá bỏ những thói quen xấu của mình. Nếu bạn có thể làm điều đó, hiệu quả làm việc của bạn sẽ tăng lên đáng kể.
Hãy vượt qua những thói quen xấu mà bạn có thể chấm dứt càng sớm càng tốt.
Nói “Có” với mọi thứ
Việc “nói có với mọi thứ” thực tế là một điều rất khiêm tốn và không có gì ích kỷ. Điều đó có nghĩa là bạn rất sẵn lòng giúp đỡ người khác trong khả năng của bạn.
Nhưng “nói có với mọi thứ” là một kẻ giết người. Vào cuối ngày, bạn có thể phải tự mình đối mặt với một khối lượng công việc khổng lồ.
Không ai nói rằng bạn không nên giúp đỡ các Developer khác. Nhưng đừng nên hủy hoại năng suất của bản thân. Một số Developer có xu hướng đặt rất nhiều câu hỏi cho mọi điều nhỏ nhặt và tìm đến sự giúp đỡ của bạn.
Paulo Coelho đã từng nói “When you say “yes” to others, make sure you are not saying “no” to yourself.”
Nếu bạn thấy mình gặp khó khăn khi nói không, hãy chỉ cho phép mọi người yêu cầu giúp đỡ vào một số thời điểm nhất định - dành cho mình khoảng thời gian tập trung cao độ để có thể hoàn thành công việc.
Điều này cũng buộc người khác bắt đầu tự tìm kiếm giải pháp, trước khi họ mù quáng nhờ cậy đến bạn. Nếu họ thực sự không thể đưa ra giải pháp, họ có thể ghi ra những câu hỏi và vấn đề của bản thân. Sau đó, họ có thể đưa cho bạn danh sách những thắc mắc của họ. Điều này giúp bạn tiết kiệm rất nhiều thời gian vì bạn sẽ chỉ bị gián đoạn một lần thay vì bị ngắt quãng bởi từng câu hỏi một.
Định nghĩa của bạn về từ “Xong!” có lẽ không thực sự là “Xong!”
Lý do mà định nghĩa của từ “Xong!” đối với Developer khác những người khác có lẽ là do Developer thường sẽ có 10.000 việc khác để làm. Khi làm việc trong một team năng suất cao, các Developer luôn muốn chạy nước rút để hoàn thành công việc vì họ cảm thấy không có thời gian để lãng phí bởi quỹ thời gian quá hạn hẹp.
Mặc dù định nghĩa của từ “Xong!” khác nhau, nhưng nó có thể bao gồm nhiều hơn là chỉ viết một đoạn code cho một tính năng ưa thích. Bất cứ khi nào bạn nghĩ rằng bạn đã hoàn thành, ít nhất bạn nên xem xét những điều sau đây.
Bạn đã cấu trúc lại code của bạn? Và nếu bạn có một cái nhìn quan trọng về code của mình, bạn có nghĩ rằng các Developer khác hiểu nó không? Nếu câu trả lời cho một trong những câu hỏi trên là “không” - hãy sửa nó!
Documentation thì sao? Có cần thiết cho tính năng này? Bạn đã cho Tester biết làm thế nào để kiểm tra tính năng này chưa? Có bất kỳ điều kiện tiên quyết nào mà Tester cần phải biết hay không?
Cho Tester biết tính năng này nên được kiểm tra thế nào giúp tiết kiệm rất nhiều thời gian cho cả hai bạn.
Bạn có biết theo Gloria Mark, người nghiên cứu phân tâm kỹ thuật số tại Đại học California, mất trung bình 23 phút để trở lại nhiệm vụ ban đầu của bạn sau khi bị gián đoạn?
Cuối cùng, nhưng không kém phần quan trọng: bạn đã kiểm tra công việc của mình bằng cách thử nghiệm nó chưa. Nói về thử nghiệm, điều đó đưa chúng ta đến thói quen xấu tiếp theo.
Không test code riêng của bạn
Phần yêu thích của việc trở thành một Developer chắc chắn không phải là testing. Hầu hết các nhà phát triển hơi lười biếng khi test code của riêng họ.
Thói quen xấu này sẽ dẫn đến rất nhiều thời gian dành cho việc cung cấp tính năng phù hợp. Nếu bạn không kiểm tra mã của mình, Tester có thể sẽ tìm thấy một lỗi trong vòng một phút, điều bạn có thể dễ dàng làm nếu bạn tự kiểm tra mã của mình.
Khi Tester báo cáo lỗi, bạn phải xem lại cùng một code. Sau đó, Tester cần kiểm tra lại tính năng một lần nữa khi bạn đã sửa lỗi. Đây là điều rất mất thời gian.
“Nhưng testing làm tăng thời gian lập trình.”
Không! Đây là một quan niệm sai lầm rất phổ biến. Testing chỉ làm tăng thời gian lập trình ban đầu, khi bạn chỉ mới bắt đầu học cách test. Bạn nên gắn bó với nó và biến nó thành một phần của quá trình lập trình để nó trở thành một thói quen tốt. Testing sẽ giúp bạn tiết kiệm rất nhiều thời gian trong tương lai.
Thực hiện các commit quá lớn
Một thói quen rất kém hiệu quả là làm cho các commit của bạn quá lớn. Commit lớn dẫn đến không thể nhìn thấy “rừng” cho “cây”. Bởi vì rất nhiều điều đã thay đổi trong commit, và bạn sẽ không rõ những gì đã thực sự thay đổi.
Bên cạnh đó, bạn sẽ cảm thấy thế nào khi phải xem lại một commit có hơn một trăm file đã thay đổi? Bạn có thể sẽ thấy kinh khủng và không có động lực để xem xét kỹ lưỡng commit đó.
Commit nhỏ là bạn của bạn. Chúng giúp cho Developer có thể đưa ra một thông điệp mô tả commit. “Đã khắc phục một số vấn đề” - đây không phải là một mô tả commit đúng đắn.
Những đánh giá code sẽ dễ dàng hơn với các commit nhỏ. Reviewer sẽ dễ dàng để xem lại từng thay đổi cùng một lúc và hiểu được toàn bộ quá trình lập trình
Làm cho các commit nhỏ hơn giúp code của bạn cũng dễ dàng debug hơn. Bạn sẽ dễ dàng quay trở lại một commit nhất định để kiểm tra xem có lỗi gì tồn tại ở đó. Một khi bạn đã tìm thấy lỗi được mô tả, chắc chắn rằng sẽ không có quá nhiều code mô tả lỗi đó nếu những commit của bạn không lớn.
Điều này sẽ giúp bạn làm việc hiệu quả hơn mà không tốn quá nhiều công sức.
Via: Medium
