Software Engineer: Từ Lính Mới Đến Cú Vấp Đầu Đời

Nếu anh em thấy hay thì ủng hộ mình 1 follow + 1 upvote + 1 bookmark + 1 comment cho bài viết này tại Mayfest 2025 nhé, cảm ơn anh em!

Xin chào anh em, lại là tôi - Jim đến từ Trà đá công nghệ đây!

Hôm nay, tôi muốn chia sẻ một câu chuyện cá nhân, một hành trình mà có lẽ nhiều người trong chúng ta cũng từng trải qua: những ngày đầu chuyển từ ngồi trên giảng đường Đại học sang làm quen với thế giới lập trình chuyên nghiệp. Đó là một chặng đường đầy những trải nghiệm mới về văn hóa công ty, những bài học thực tế và cả những khoảnh khắc giác ngộ khi khám phá ra những nguyên tắc của nghề. Đặc biệt, tôi muốn kể về việc mình đã từng được anh mentor góp ý như thế nào về clean code và cách sử dụng Git, những yếu tố mà khi còn đi học hay là trong quá trình cày lập trình thi đấu (Competitive programming), tôi chỉ nghĩ đơn giản là code chạy là được.

1. Những Ngày Đầu Nhập Cuộc

Bước vào công ty với tâm thế một người mới

Tôi nhớ rõ ngày đầu tiên đi làm tại một công ty phần mềm, hành trang không chỉ có chiếc laptop mà còn là kiến thức lý thuyết vừa học từ giảng đường, một chút tự tin ban đầu và nguồn năng lượng nhiệt huyết, tò mò về môi trường mới. Khung cảnh văn phòng hiện đại, những đồng nghiệp mới, tiếng gõ phím và những cuộc thảo luận sôi nổi – tất cả tạo nên một viễn cảnh đầy hứa hẹn về sự nghiệp. Tôi được bố trí một góc làm việc, bắt đầu làm quen với dự án và háo hức thể hiện những gì mình đã học. Tuy nhiên, thực tế không hoàn toàn như mong đợi. Sự tự tin ban đầu của một người mới nhanh chóng đối mặt với thử thách.

Thử thách thực tế: Những lần được anh mentor nhắc nhở về code và Git

Không lâu sau, những lời góp ý đầu tiên từ anh mentor bắt đầu xuất hiện...

Tình huống 1: "Code này... ai đọc?"

Lần đó, tôi vừa hoàn thành một tính năng nhỏ và gửi Merge request (MR). Anh mentor xem xong, gọi tôi ra hỏi. "Em xem lại MR này đi," anh mentor nói với giọng nghiêm túc, rồi chỉ vào màn hình. "Tên biến tempData này là gì? Hàm processData() này em xử lý những gì mà dài cả trăm dòng thế này? Anh đọc mà không hiểu logic của em là gì cả." Tôi lặng người. Rõ ràng code vẫn chạy đúng chức năng, nhưng cách anh mentor đặt vấn đề khiến tôi nhận ra, code chạy được và code tốt là hai khái niệm hoàn toàn khác nhau.

Tình huống 2: "Commit message thế này thì chưa đạt!"

Một lần khác, anh mentor đang xem lại lịch sử commit của dự án. Bất chợt, anh mentor dừng lại ở một commit của tôi với nội dung vỏn vẹn: "fix bug". Anh mentor quay sang hỏi: "Bug gì đây em? Em sửa ở file nào, logic thay đổi ra sao?". Tôi lại một lần nữa không thể giải thích rõ ràng, vì thực sự lúc đó tôi chỉ nghĩ commit cho xong việc. Chưa kể, có những lần tôi đặt tên nhánh rất chung chung như feature-abc hay update-xyz, khiến cả team khó hình dung mục đích của nhánh đó. Thậm chí, có lần tôi loay hoay cả buổi sáng vì một xung đột merge đơn giản, suýt nữa làm ảnh hưởng đến code của các anh đồng nghiệp.

Những lời nhận xét đó, dù ban đầu khiến tôi cảm thấy đôi chút hoang mang và xấu hổ, nhưng ngẫm lại, đó chính là những lời nhắc nhở quý giá. Sự thiếu kinh nghiệm thực tế, cộng với suy nghĩ chủ quan rằng chỉ cần code chạy đúng logic thuật toán là đủ, đã khiến tôi chưa nhận thức được tầm quan trọng của các tiêu chuẩn nghề nghiệp. Những lời góp ý thẳng thắn từ mentor, dù có phần nghiêm khắc, lại chính là động lực để tôi nghiêm túc nhìn nhận lại bản thân và bắt đầu hành trình học hỏi thực sự. Đó không chỉ đơn thuần là về kỹ thuật viết code hay dùng Git, mà còn là bài học về cách tiếp nhận phản hồi và ý thức trách nhiệm khi làm việc trong một tập thể.

2. Hành Trình Cải Thiện: Clean Code và Git Không Còn Là Trở Ngại

Sau những trải nghiệm ban đầu, tôi quyết tâm tìm hiểu xem mình đã sai ở đâu và làm thế nào để cải thiện. Quá trình tìm hiểu những góp ý của anh mentor đã mở ra cho tôi hai khái niệm quan trọng: Clean Code và Git Best Practices.

2.1. Clean Code - Tinh Chỉnh Tư Duy Lập Trình

Tôi bắt đầu nhìn lại những đoạn code chưa tốt của mình trước đây. Phải thừa nhận là chúng có nhiều vấn đề:

• Đặt tên biến, hàm chưa rõ ràng: Tôi thường dùng những cái tên viết tắt, mơ hồ như x, y, val, temp, hay những hàm process() mà không rõ nó xử lý cụ thể điều gì vì trong lập trình thi đấu, chỉ cần thế là đủ, làm sao để giải được bài toán càng nhanh càng tốt. Ví dụ, một biến lưu trữ ngày tháng có thể được tôi đặt là d, hay một hàm kiểm tra quyền người dùng chỉ đơn giản là check().
• Viết chú thích chưa hiệu quả: Những dòng chú thích của tôi hoặc là giải thích những điều quá hiển nhiên (ví dụ: ++i; // tăng i lên 1), hoặc tệ hơn là không được cập nhật khi code thay đổi, dẫn đến chú thích không còn phù hợp với logic thực tế.
• Hàm quá dài và đa nhiệm: Tôi có thói quen viết những hàm làm quá nhiều việc, từ kiểm tra đầu vào, xử lý logic, lưu vào cơ sở dữ liệu, cho đến gửi email thông báo, tất cả gói gọn trong một hàm dài hàng trăm dòng, rất khó đọc, khó gỡ lỗi và gần như không thể tái sử dụng.
• Sử dụng "Magic Numbers" và chuỗi cố định (hard-coded strings) nhiều nơi: Việc sử dụng trực tiếp các con số hay chuỗi ký tự trong code mà không có giải thích về ý nghĩa của chúng là chuyện thường thấy. Ví dụ, if (status == 2) mà không rõ số 2 đó đại diện cho trạng thái gì.

May mắn thay, mentor và các anh chị đồng nghiệp đã giới thiệu cho tôi cuốn sách "Clean Code" của Robert C. Martin, cùng với nhiều bài viết và hướng dẫn hữu ích khác. Dần dần, tôi học được nhiều nguyên tắc giá trị:

• Nguyên tắc đặt tên có ý nghĩa: Tên biến, hàm, lớp phải rõ ràng, dễ hiểu và thể hiện đúng mục đích của chúng. Một cái tên tốt sẽ giúp người đọc (kể cả chính anh em trong tương lai) hiểu được code đang làm gì mà không cần phải đọc quá sâu vào logic bên trong.
• Viết hàm ngắn, đơn nhiệm (Single Responsibility Principle): Mỗi hàm chỉ nên thực hiện một công việc duy nhất và làm tốt công việc đó. Điều này giúp hàm dễ đọc, dễ kiểm thử và dễ tái sử dụng hơn.
• Chú thích để giải thích "Tại sao" (WHY), không phải "Cái gì" (WHAT): Code nên tự nó giải thích những gì đang diễn ra. Chú thích nên tập trung vào việc giải thích lý do tồn tại của đoạn code đó, những quyết định thiết kế đằng sau, hoặc những logic nghiệp vụ phức tạp mà bản thân code không thể hiện hết được.
• Loại bỏ "Magic Numbers" và chuỗi cố định: Thay thế chúng bằng các hằng số có tên gọi ý nghĩa. Điều này không chỉ giúp code dễ hiểu hơn mà còn dễ dàng thay đổi khi cần.
• Tránh lặp code (DRY - Don't Repeat Yourself): Nếu anh em thấy mình viết đi viết lại cùng một đoạn code ở nhiều nơi, đó là dấu hiệu anh em cần tách nó ra thành một hàm riêng để tái sử dụng.

Để anh em dễ hình dung hơn, hãy cùng xem qua bảng so sánh "trước và sau" khi tôi áp dụng các nguyên tắc Clean Code:

Việc viết code chưa tốt không chỉ gây khó khăn cho người khác khi đọc và bảo trì, mà còn trực tiếp làm tăng thời gian gỡ lỗi, phát triển tính năng mới cho chính bản thân người viết. Hãy tưởng tượng code của anh em như một căn phòng. Nếu nó bừa bộn, việc tìm kiếm một món đồ (gỡ lỗi) hay sắp xếp lại (bảo trì) sẽ vô cùng vất vả. Khi nhiều người cùng làm việc trong không gian đó, sự thiếu trật tự càng gia tăng, dẫn đến xung đột và chậm trễ tiến độ. Clean code, vì thế, không chỉ là một kỹ thuật, mà còn là một thái độ và một kỹ năng cần được rèn luyện không ngừng. Nó phản ánh sự chuyên nghiệp, sự tôn trọng dành cho đồng nghiệp và cho chính sản phẩm mà anh em đang xây dựng.

2.2. Git - Quản Lý Phiên Bản Code Hiệu Quả

Song song với Clean Code, Git cũng là một lĩnh vực mà tôi đã từng gặp không ít khó khăn vì trên giảng đường tôi không được học về Git.

Những vấn đề với Git thời mới vào nghề:

• Commit message không rõ ràng: Những nội dung commit như "fix bug", "update", "done", "abc", "xyz" là điều tôi thường làm. Khi anh mentor hỏi "sửa lỗi gì?", "cập nhật cái gì?" thì tôi không giải thích được.
• Đặt tên nhánh thiếu quy tắc: Những cái tên như new-feature, test_branch, my_work_final, fix_something xuất hiện thường xuyên trong repository.
• E ngại khi gặp xung đột merge (merge conflict): Mỗi khi Git báo conflict, tôi thường lo lắng, không biết phải giải quyết thế nào, đôi khi sao chép code một cách thiếu cân nhắc và hy vọng nó chạy, hoặc tệ hơn là làm mất code của mình hoặc của người khác.
• Commit nhầm nhánh: Chuyện commit code vào nhầm nhánh rồi tìm cách khắc phục cũng không phải là hiếm.
• Chỉ biết merge, chưa dùng rebase: Kết quả là lịch sử commit của nhánh develop trở nên phức tạp, với vô số merge commit không cần thiết.

Qua những lần thực hành và sự hướng dẫn của các đồng nghiệp đi trước, tôi dần làm quen với các phương pháp làm việc tốt hơn với Git:

7 quy tắc cho commit message chất lượng:

1. Tách biệt tiêu đề (subject) và nội dung (body) bằng một dòng trắng.
2. Tiêu đề ngắn gọn, súc tích (tối đa 50 ký tự).
3. Viết hoa chữ cái đầu tiên của tiêu đề.
4. Không kết thúc tiêu đề bằng dấu chấm (.).
5. Sử dụng giọng mệnh lệnh (imperative mood) ở tiêu đề (ví dụ: Add login feature thay vì Added login feature hay Adding login feature).
6. Nội dung (body) giới hạn khoảng 72 ký tự mỗi dòng.
7. Nội dung giải thích "Cái gì" (WHAT) và "Tại sao" (WHY) thay đổi, chứ không phải "Như thế nào" (HOW) (phần HOW đã có trong code).

Quy ước đặt tên nhánh chuyên nghiệp:

• Sử dụng các tiền tố (prefix) rõ ràng: feature/ (cho tính năng mới), bugfix/ (sửa lỗi), hotfix/ (vá lỗi khẩn cấp trên production), docs/ (cập nhật tài liệu), refactor/ (tái cấu trúc code).
• Tên nhánh nên mô tả ngắn gọn nội dung công việc, sử dụng dấu gạch ngang (-) để nối các từ (ví dụ: feature/user-authentication).
• Có thể thêm ID của tác vụ từ các công cụ quản lý dự án (Jira, Trello) vào tên nhánh (ví dụ: feature/JIRA-123-new-payment-gateway).

Học cách xử lý merge conflict một cách bình tĩnh: Hiểu rằng conflict là chuyện bình thường khi làm việc nhóm. Sử dụng các công cụ hỗ trợ của IDE (như VSCode, IntelliJ IDEA) hoặc các lệnh Git cơ bản (git status, git diff) để xem xét kỹ lưỡng các thay đổi và quyết định giữ lại phần code nào.

Tìm hiểu về các quy trình làm việc (Git workflow) phổ biến như Gitflow hoặc Trunk-based development, và quan trọng nhất là hiểu rõ quy trình mà nhóm của anh em đang áp dụng.

Dưới đây là bảng so sánh một số thói quen sử dụng Git chưa tốt và cách làm đúng:

Việc sử dụng Git một cách tùy tiện, không theo quy chuẩn không chỉ tạo ra một lịch sử commit khó theo dõi mà còn gây khó khăn lớn cho việc review code, tìm lỗi khi sự cố xảy ra, và đặc biệt là làm giảm hiệu quả phối hợp trong nhóm. Git không đơn thuần là một công cụ để lưu trữ code, nó là nền tảng của quy trình phát triển phần mềm hiện đại.

Thật thú vị khi nhận ra rằng, tư duy mạch lạc trong việc viết code và trong việc sử dụng Git có một sự tương đồng đáng kể. Cả hai đều hướng đến sự rõ ràng, dễ hiểu, và khả năng bảo trì tốt cho những người sẽ đọc và làm việc với chúng sau này. Một người cẩn thận với clean code thường cũng sẽ có xu hướng cẩn thận hơn với các thao tác Git của mình, và ngược lại. Việc chủ động học và áp dụng các phương pháp tốt nhất về Git ngay từ những ngày đầu sự nghiệp sẽ giúp một lập trình viên mới hòa nhập nhanh hơn vào quy trình làm việc của nhóm, giảm thiểu sai sót không đáng có và từng bước xây dựng uy tín cá nhân. Đây thực sự là một kỹ năng nền tảng quan trọng, không kém cạnh kỹ năng lập trình thuần túy.

3. Bài Học Kinh Nghiệm và Lời Khuyên Cho Anh Em Đi Sau

Nhìn lại quãng thời gian đầu đầy thử thách đó, tôi nhận ra rằng những va vấp đã dạy cho mình những bài học giá trị.

Những bài học rút ra từ kinh nghiệm thực tế:

• Không có code nào là hoàn hảo ngay từ đầu: Ai trong chúng ta cũng từng viết những dòng code chưa tối ưu. Điều quan trọng là nhìn nhận sai lầm và không ngừng nỗ lực để cải thiện.
• Mentor và đồng nghiệp đang giúp anh em tốt hơn: Ban đầu, tôi cũng có chút tự ái khi code của mình được nhận xét và phải sửa đi sửa lại rất nhiều lần. Nhưng rồi tôi hiểu ra rằng, những lời góp ý đó, dù thẳng thắn, đều xuất phát từ mong muốn giúp tôi tiến bộ và giúp dự án tốt hơn. Hãy thay đổi thái độ từ phòng thủ sang biết ơn những phản hồi đó.
• Clean code và Git chuẩn mực là sự đầu tư xứng đáng: Có thể ban đầu anh em sẽ cảm thấy hơi mất thời gian để viết code chỉn chu hơn, để viết commit message cẩn thận hơn. Nhưng tin tôi đi, về lâu dài, nó sẽ tiết kiệm cho anh em và cả nhóm rất nhiều công sức trong việc đọc hiểu, bảo trì và gỡ lỗi.
• Đừng ngại hỏi, nhưng hãy tìm hiểu kỹ trước khi hỏi: Khi gặp vấn đề, việc đầu tiên nên làm là tự mình tìm tòi, nghiên cứu. Nếu đã cố gắng hết sức mà vẫn chưa giải quyết được, đừng ngần ngại hỏi xin sự giúp đỡ từ đồng nghiệp hoặc mentor. Tuy nhiên, hãy trình bày rõ vấn đề anh em gặp phải và những gì anh em đã thử. Điều này thể hiện sự tôn trọng thời gian của người khác và cho thấy anh em đã có nỗ lực tự giải quyết.

Một số gợi ý cho người mới:

Về Clean Code:

• Hãy tìm đọc cuốn sách "Clean Code" của Robert C. Martin hoặc các tài liệu, blog uy tín về chủ đề này.
• Luôn tự đặt câu hỏi khi viết code: "Code này có dễ đọc không? Liệu 6 tháng nữa, hoặc một người khác đọc lại, họ có hiểu được không?".
• Tập thói quen xem lại code của chính mình một cách cẩn thận trước khi tạo Merge Request hoặc nhờ người khác xem xét.
• Học hỏi cách viết code từ các lập trình viên có kinh nghiệm trong nhóm hoặc từ các dự án mã nguồn mở chất lượng.

Về Git:

• Nắm vững các lệnh Git cơ bản và hiểu rõ ý nghĩa của chúng, không chỉ dùng theo thói quen.
• Thống nhất và tuân thủ quy ước viết commit message cũng như đặt tên nhánh với cả nhóm.
• Nếu nhóm cho phép và anh em đã hiểu rõ, hãy tập làm quen với git rebase để giữ cho lịch sử commit được gọn gàng.
• Sử dụng các công cụ hỗ trợ Git có giao diện đồ họa (GUI clients như Sourcetree, GitKraken) hoặc các tiện ích tích hợp trong IDE (VSCode, IntelliJ IDEA) để trực quan hóa các thao tác và dễ dàng xử lý hơn, đặc biệt là khi gặp xung đột merge.
• Thực hành Git thường xuyên trên các dự án cá nhân để làm quen và thành thạo các thao tác.

Về Kỹ năng mềm:

• Chủ động giao tiếp với trưởng nhóm hoặc quản lý về tiến độ công việc, những khó khăn đang gặp phải. Đừng im lặng cho đến khi quá muộn.
• Luôn giữ thái độ cầu tiến, ham học hỏi và sẵn sàng tiếp thu những điều mới.

Việc chia sẻ những sai lầm và quá trình học hỏi một cách chân thực không chỉ giúp bài viết này trở nên gần gũi hơn, mà tôi hy vọng nó còn góp phần làm cho những khó khăn ban đầu mà bất kỳ lập trình viên nào cũng có thể gặp phải trở nên bình thường hơn. Điều này đặc biệt quan trọng để khích lệ tinh thần cho các anh em mới vào nghề, giúp các anh em thấy rằng mình không đơn độc và việc mắc lỗi là một phần tự nhiên của quá trình trưởng thành trong nghề. Hãy nhớ rằng, đầu tư thời gian để học và áp dụng clean code cũng như các quy chuẩn Git ngay từ đầu sự nghiệp là một chiến lược thông minh. Nó không chỉ giúp anh em phát triển kỹ năng cá nhân nhanh hơn mà còn đóng góp vào sự thành công chung của dự án và xây dựng một môi trường làm việc chuyên nghiệp, hiệu quả.

4. Kết Luận: Nền Móng Vững Chắc Cho Chặng Đường Dài

Nhìn lại chặng đường đã qua, từ một người mới còn nhiều bỡ ngỡ, phải làm quen với những khái niệm cơ bản, đến nay tôi đã tự tin hơn rất nhiều trong việc áp dụng những quy tắc chung của ngành lập trình. Dĩ nhiên, hành trình học hỏi là vô tận, công nghệ luôn thay đổi và luôn có những điều mới mẻ để khám phá. Nhưng những bài học đầu đời về tầm quan trọng của Clean Code và việc sử dụng Git một cách chuyên nghiệp chính là những viên gạch nền tảng quan trọng, giúp tôi vững bước hơn trên con đường sự nghiệp của mình.

Câu chuyện của tôi, từ những ngày đầu đi làm còn nhiều bỡ ngỡ, được anh mentor góp ý vì code chưa tốt, Git chưa chuẩn, đến quá trình tự học hỏi, sửa sai và dần hoàn thiện bản thân, hy vọng đã mang lại cho các anh em, đặc biệt là những người mới, một góc nhìn thực tế và những lời khuyên hữu ích.

Anh em có kỷ niệm nào với clean code hay Git trong những ngày đầu đi làm không? Hay có kinh nghiệm nào muốn chia sẻ với các anh em mới khác không? Hãy để lại bình luận bên dưới nhé! Chúng ta cùng nhau học hỏi và phát triển nhé.

Hẹn gặp lại anh em trong các bài tiếp theo tại Trà đá công nghệ!