6 thói quen cần có nếu bạn muốn “thoát kiếp” Junior

Code thế nào mới gọi là code tốt?

Khi thấy code dở, ta sẽ biết ngay. Nhưng code tốt lại khó xác định hơn, nhiều khi bạn cho ra những đoạn code rất chất lượng, nhưng chả ai nhìn ra cả (nhiều khi chính ta còn không biết cũng không chừng).

Theo kinh nghiệm của tôi, hai câu hỏi sau có thể phần nào chỉ ra chất lượng của code:

• Khi làm việc với team, các thành viên khác có thể hiểu được code của bạn không?
• Khi cần thay đổi thứ gì đó, công việc có nhanh chóng và đơn giản hay không?

Nếu bạn gặp khó khăn khi giải thích code với các thành viên khác, hay code break đủ chỗ khi bạn thực hiện thay đổi; có lẽ code của bạn không được tốt cho lắm. Để xử lý vấn đề, ta cần phân tích môi trường và tìm ra các giải pháp phù hợp nhất: liệu ta dùng sai pattern, hay đã quên phần unit test?

Cùng tham gia cuộc chiến nào

Như đã đề cập, việc fix code hiển nhiên là cần thiết, nhưng nguyên nhân dẫn đến vấn đề cũng không kém phần quan trọng. Và qua nhiều năm không ngừng làm việc và cải thiện bản thân, tôi nhận thấy, nguyên nhân sâu xa đều bắt nguồn từ những thói quen chủ quan vô cùng “mãn tính”.

Khi đã tập cho mình một tác phong làm việc đúng cách, và bỏ đi những thói quen vô bổ “lợi bất cập hại”, đường đến senior sẽ không còn quá xa xôi.

Đừng quá vội tối ưu code

Hồi mới bắt đầu vào nghề lập trình, cứ mỗi lần “tém” được vài dòng code thành một dòng duy nhất, tôi lại ngồi ngây ngô tự trầm trồ mình “bá đạo” ra sao. Tôi sẽ xóa bay hết tất cả khoảng trống và comment đã viết trước đó; nest một đống function call lại với nhau để thay cho các biến đã đánh dấu rõ ràng, và đủ thứ trò “màu nhiệm” khác. Cứ viết được đoạn nào, tôi sẽ tìm mọi cách tối ưu đoạn đó, lớn hay nhỏ mặc kệ.

Giống như việc chế tạo một bộ máy vậy, mải mê tinh chỉnh thu gọn code chỉ mạng lại cho bạn cảm giác “thiên tài thoáng qua” mà thôi, nhưng hiệu năng thực tế lại chả tăng là bao. (Hình ảnh từ Flickr user Andrew Taylor.)

Viết ‘code cho rõ ràng’ còn quan trọng hơn là ‘code khôn (vặt)’. Đây là bài học đắng lòng tôi rút ra được khi phải quay lại project cũ bị bỏ ngõ trong 6 tháng trời. Lúc ấy, trước khi bắt tay vào thực hiện thay đổi, tôi phải ngồi mòn mông, đọc đi đọc lại xem thử hồi đó mình viết cái quái gì. Bỗng nhiên, tôi chả thấy hồi đó mình “bá đạo” ở chỗ nào cả.

Không bao giờ hack framework

Là lập trình viên, ai cũng bị ám ảnh bởi deadline liên tục bám dai như đỉa (chuẩn bị phiên bản chốt cho project, hay chuẩn bị public demo thì stress khỏi phải nói). Deadline ngày càng sát, và còn biết bao nhiêu code để làm; và bạn bắt đầu tìm đường tắt. Đôi khi, tình thế bắt buộc, và ta chắn chắn có thể refactor ngay sau đó, miễn là refactor cho “đúng cách”.

Tuy nhiên, hack các framework như Bootstrap hay jQuery chưa bao giờ là “lối tắt” cả. Hiển nhiên, cách làm này có thể giúp bạn chạy deadline rất nhanh, nhưng khi bạn muốn fix thì lại là một câu chuyện hoàn toàn khác. Hãy tính đến tình hình tệ nhất đi, nếu bạn đã nhận lời của khách hàng thêm một tính năng mà không cách nào có được từ việc viết thêm code mới, mà chỉ khi thay đổi files framework mới có thể, Lúc này bạn chỉ còn nước kêu trời.

Thường xuyên refactor

Tiếp tục nói về “đường tắt”, Tập hợp tất cả các hack lại một chỗ bằng file shame.css cũng là một ý hay. (Bạn hoàn toàn có thể áp dụng ý tưởng này cho các non-web projects.) Khi đã tạm đối phó được với deadline đầy áp lực, bạn hoàn toàn có thể xóa hết “nỗi nhục” và viết lại code cho đúng. Ngay cả khi tôi không tạo quick hack, tôi vẫn dành chút thời gian để xem lại, đối chiếu, và refactor. Ví dụ, khi bạn đọc lại một số đoạn code đầu tiên đã viết, code vẫn còn dễ hiểu chứ? Khi project dần phình to, thói quen này lại càng quan trọng.

Bạn nên refactor vào sáng sớm, hoặc vào đầu tuần. Lúc này, bạn sẽ có cách nhìn mới hơn, đồng thời cũng đây cũng là bước lấy đà trước khi tiếp tục nhảy trở lại vào workflow.

Hãy nhớ dùng revision control

Nếu bạn vẫn chưa dùng qua revision control (quản lý phiên bản), hãy bắt đầu ngay luôn đi. Github có cung cấp công cụ miễn phí, hoặc thu phí rất hợp lý (nếu nhu cầu của bạn gia tăng). Viết code không có revision control cũng như lái xe mà không thắt dây an toàn vậy. Sau một đoạn thời gian, mọi thứ vẫn ổn, nhưng khi trục trặc bắt đầu xuất hiện, hậu quả sẽ vô cùng nghiêm trọng.

Tôi đã từng thấy nhiều project với lối code “một người một ngựa” vô cùng bất cẩn, nếu họ có dùng đến revision control, có lẽ công việc đã nhanh hơn nhiều.

Dành thời gian học hỏi

Khi bạn phải gồng mình chạy từ deadline này đến hết deadline khác, thời gian dành cho học tập quả thật xa xỷ. Tuy nhiên, lập trình viên nếu không học tập, thì bị tụt hậu là không thể tránh khỏi. Kiến thức càng nhiều, ta càng có thể làm việc hiệu quả và năng suât hơn, phạm ít sai lầm hơn. Khi làm việc nhanh hơn, ta lại có thêm nhiều thời gian cho cuộc sống và phát triển sự nghiệp.

Thực ra, học tập thực sự lại tiếp kiệm thời gian chứ không phải phí thời gian như mọi người nghĩ.

Luôn luôn tham khảo code review

Khi hoàn thành tác phẩm của mình, đừng ngần ngại đi hỏi ý kiến “dạo” xem thử phản ứng của mọi người ra sao. Dù đó là đồng nghiệp, thầy cô, cấp trên, hay bạn bè (hiển nhiên phải biết code); ý kiến của họ đều có giá trị vô cùng to lớn. Với những góc nhìn và quan điểm khác nhau, bạn sẽ vô cùng ngạc nhiên trước những giải pháp “kỳ lạ” mà bạn chưa nghĩ đến trước đây.

Cùng tham gia cuộc chiến nào

Nếu bạn còn có lời khuyên hữu ích nào khác nào khác, hãy chia sẻ trong phần comment nhé!