Ngồi cạnh một bạn thực tập mới, chúng tôi nghe câu hỏi quen thuộc: “Dev backend là ngồi gõ code cả ngày đúng không?” Câu trả lời làm bạn ấy bất ngờ.

Đây là nhật ký một ngày làm việc thực tế của dev backend, kể đúng quy trình mà đội ngũ chúng tôi trải qua mỗi ngày: có code, có debug, nhưng cũng có rất nhiều việc khác không tên, không tô vẽ thêm bớt.

Nhiều Người Hình Dung Sai Về Công Việc Thường Ngày Của Dev Backend

Hình dung phổ biến nhất về dev backend là ngồi một chỗ, gõ code từ sáng đến tối. Tai đeo tai nghe, không nói chuyện với ai. Hình ảnh đó không sai hẳn, nhưng thiếu quá nhiều mảnh ghép.

Trong một ngày làm việc thật, viết code chiếm khoảng nửa thời gian, có hôm còn ít hơn. Phần còn lại là đọc lại đoạn code cũ, họp ngắn với nhóm giao diện, trả lời câu hỏi của bên vận hành. Đôi khi là ngồi giải thích cho đồng nghiệp mới vì sao một API lại thiết kế theo cách đó.

Nhiều bạn mới ra trường bị hụt hẫng nhẹ ở giai đoạn này. Các bạn tưởng công việc chỉ là “tôi với máy tính”. Ai ngờ phần lớn thời gian lại là “tôi với người khác, thông qua máy tính”.

Một hệ thống backend không tồn tại một mình. Nó phải khớp với giao diện người dùng, khớp với hệ thống thanh toán. Nếu là dự án thương mại điện tử, nó còn phải khớp với cách vận hành kho hàng. Mỗi lần khớp là một lần trao đổi, chứ không phải một lần gõ phím.

Chúng tôi hay nói vui với người mới: kỹ năng gõ code giỏi giúp bạn qua vòng phỏng vấn. Kỹ năng phối hợp mới giữ bạn trụ lại được sau ba tháng thử việc.

Vì Sao Nên Hỏi Sớm Khi Bị Kẹt Trong Quy Trình Làm Việc

Một sai lầm khá phổ biến ở người mới: cố tự xử lý mọi thứ một mình để chứng minh năng lực. Nghe có vẻ chuyên nghiệp, nhưng thực ra lại làm chậm cả nhóm. Hỏi sớm một câu ngắn thường tiết kiệm thời gian hơn nhiều, so với việc tự mò mẫm nửa ngày rồi mới báo bị kẹt.

Chúng tôi thường khuyên người mới một cách đơn giản. Nếu bị kẹt quá ba mươi phút ở một vấn đề, hãy lên tiếng. Không ai đánh giá thấp việc hỏi đúng lúc. Người ta chỉ ngại những ai im lặng rồi trễ deadline.

Nhật Ký Quy Trình Thực Tế Trong Một Ngày Làm Việc Của Dev Backend

Ngày làm việc của chúng tôi thường mở đầu bằng mười lăm phút rà lại việc hôm qua. Cái gì xong, cái gì còn treo, cái gì cần báo sớm cho người khác biết. Sau đó là buổi họp ngắn với cả nhóm, thường không quá hai mươi phút. Mỗi người chỉ cần nói nhanh đang làm gì, có đang bị chặn ở đâu không.

Buổi Sáng: Rà Việc, Họp Ngắn Và Bắt Đầu Vào Việc

Qua giờ họp mới thật sự vào phần việc chính. Nhưng phần việc chính này hiếm khi là “ngồi viết code một mạch tới trưa”. Nó xen kẽ liên tục: viết một đoạn xử lý dữ liệu, chạy thử, thấy lỗi, dừng lại debug, xong quay lại viết tiếp. Có hôm một tính năng nhỏ mất nguyên buổi sáng. Chỉ vì một lỗi tưởng đơn giản, hoá ra lại nằm ở tầng kết nối cơ sở dữ liệu.

Xen giữa những đoạn code đó là tin nhắn từ bộ phận khác. Bên chăm sóc khách hàng báo đơn hàng bị treo. Bên marketing hỏi API lấy dữ liệu báo cáo chạy được chưa. Có lúc chúng tôi phải dừng hẳn việc đang làm để xử lý gấp.

Hệ thống đang chạy thật, không phải môi trường thử nghiệm. Nói dễ hiểu, môi trường thử nghiệm là một bản sao riêng để thử trước. Dân trong nghề hay gọi tắt là “staging”, lỡ có sai cũng không ảnh hưởng khách hàng đang dùng.

Không phải yêu cầu chen ngang nào cũng cần dừng việc đang làm ngay lập tức. Chúng tôi hay chia làm hai loại để quyết định nhanh hơn.

• Việc ảnh hưởng khách hàng đang dùng hệ thống thật thì xử lý ngay, dù đang viết dở phần nào.
• Việc hỏi để tham khảo, chưa gấp, thì ghi lại và trả lời vào cuối buổi hoặc đầu giờ chiều.

Cách phân loại đơn giản này giúp chúng tôi không bị cuốn theo mọi tin nhắn đến. Đồng thời cũng không bỏ sót việc thật sự khẩn cấp.

Một phần việc lặp lại khá nhiều là viết đi viết lại những đoạn xử lý na ná nhau. Kiểm tra dữ liệu đầu vào, ghi log, xử lý lỗi — cứ thế lặp đi lặp lại mỗi ngày. Nhiều đội giờ tìm cách giảm bớt phần lặp này bằng công cụ hỗ trợ. Cách làm khá giống cách một số cửa hàng nhỏ giảm việc lặp lại mỗi ngày bằng giải pháp tự động. Chỉ khác là áp dụng cho code, không phải cho việc vận hành cửa hàng. Chúng tôi không tự động hoá hết được, nhưng phần nào giảm được cũng đáng làm.

Buổi Chiều: Review Code Và Trao Đổi Liên Phòng Ban

Buổi chiều thường nhẹ hơn về code, nặng hơn về trao đổi. Review code cho đồng nghiệp, trả lời câu hỏi kỹ thuật. Chúng tôi hay dùng một bảng công việc chung, kiểu Jira hoặc Trello, để ghi việc ai đang làm, xong tới đâu. Nói đơn giản, đó là một tấm bảng liệt kê việc cho cả nhóm cùng nhìn vào.

Đôi khi ngồi cùng bên vận hành để xử lý một yêu cầu nội bộ phát sinh gấp. Có công ty còn để hẳn một trợ lý tự động xử lý bớt các yêu cầu nội bộ lặp đi lặp lại. Nhờ vậy đội kỹ thuật đỡ bị ngắt quãng liên tục.

Những Điều Bất Ngờ So Với Hình Dung Ban Đầu

Điều làm nhiều bạn mới bất ngờ nhất là thời gian đọc code cũ. Trước khi thêm được một tính năng mới, phải hiểu hệ thống hiện tại đang chạy ra sao. Phần nào không được đụng vào, phần nào an toàn để sửa. Có khi đọc mất một ngày, sửa chỉ mất một giờ.

Backend càng chạy lâu, đoạn code cũ càng nhiều lớp. Đôi khi lớp cũ đó do người đã nghỉ việc viết, không còn ai giải thích được ý đồ ban đầu. Việc dev backend giỏi không chỉ nằm ở viết code sạch, mà còn ở khả năng đọc hiểu code không sạch của người khác, và vẫn sửa được mà không làm hỏng phần đang chạy tốt.

Có lần một bạn trong nhóm sửa nhanh một đoạn code cũ, mà không đọc hết phần liên quan phía trên. Tính năng mới chạy đúng, nhưng lại vô tình làm sai một luồng thanh toán cũ đang chạy ổn. Chúng tôi mất nguyên buổi tối hôm đó để tìm nguyên nhân và sửa lại. Từ đó, quy tắc trong nhóm là: sửa code cũ, dù chỉ vài dòng, cũng phải đọc rộng ra xung quanh trước.

Giao Tiếp Quan Trọng Ngang Kỹ Thuật Trong Quy Trình Làm Việc

Bất ngờ thứ hai, ít ai kể trước khi vào nghề: giao tiếp quan trọng ngang kỹ thuật. Một API viết đúng logic nhưng đặt tên khó hiểu sẽ khiến bên giao diện hỏi lại liên tục, tốn thời gian cả hai bên. Một lỗi phát sinh mà báo chậm cho bên vận hành nửa tiếng có thể khiến khách hàng chờ lâu hơn mức cần thiết.

Có giai đoạn hệ thống, chúng tôi phải quyết định một việc: việc nào nên để máy làm tự động, việc nào vẫn cần người ngồi kiểm tra tay. Cách chúng tôi cân nhắc khá giống nguyên tắc chọn lúc nào nên để AI làm và lúc nào cần người quyết. Việc lặp lại, ít rủi ro thì tự động hoá. Việc ảnh hưởng trực tiếp đến khách hàng thì vẫn cần người xem lại trước khi chạy.

Nhiều lần khác, hệ thống backend phải phối hợp chặt với phần giao diện bán hàng phía trước. Nếu công ty chưa có đội kỹ thuật mạnh, nên thuê một đơn vị thiết kế website bán hàng chuyên nghiệp ngay từ đầu. Backend và giao diện nhờ vậy ăn khớp nhau hơn, đỡ phải sửa đi sửa lại về sau.

Sau Một Ngày Như Vậy, Chúng Tôi Rút Ra Điều Gì

Có một điều chúng tôi muốn bạn thực tập kia mang theo sau buổi nói chuyện. Đừng chọn nghề dev backend chỉ vì nghĩ được ngồi yên một mình với máy tính. Ngồi yên có, nhưng ít hơn tưởng tượng nhiều.

Phần lớn giá trị của một dev backend giỏi nằm ở ba điều: viết code chắc tay, hiểu được người dùng đang cần gì, và phối hợp tốt với đồng đội.

Nếu bạn đang cân nhắc theo nghề này, hãy thử quan sát một ngày làm việc thật của một dev backend đang đi làm, giống như một dạng nhật ký thực tế thay vì mô tả công việc trên tin tuyển dụng. Nhìn cách người ta rà việc buổi sáng, xử lý một lỗi phát sinh giữa giờ, rồi ngồi giải thích lại cho đồng nghiệp mới — nhìn vậy sẽ thấy công việc thật hơn nhiều.

Chúng tôi vẫn hay chia sẻ thêm nhiều câu chuyện nghề nghiệp và quy trình làm việc thực tế trong ngành công nghệ. Hy vọng những ai đang cân nhắc con đường này sẽ có thêm góc nhìn trước khi quyết định.