Cẩm nang nghề lập trình & IT

Phan Anh Tú · ghi chép nghề

Chị ấy nhập vào ô “Số lượng” con số âm năm. Rồi một trăm nghìn. Rồi chữ “abc”. Rồi dán vào một đoạn văn bản dài ba trang. Ở lần thứ tư, trang giỏ hàng trắng xóa. Chị chụp màn hình, mở Jira, ghi tiêu đề ngắn gọn, kèm các bước tái hiện, môi trường thử, phiên bản trình duyệt, rồi gán cho cậu developer ngồi cách đó hai bàn. Cậu ấy thở dài rất khẽ, đủ để cả dãy nghe thấy.

Khi ai đó hỏi tôi tester QA QC là gì, tôi thường kể lại cảnh trên. Đó là người được trả lương để nghi ngờ phần mềm. Người viết code nghĩ về cách mọi thứ nên chạy, còn tester nghĩ về mọi cách nó có thể hỏng. Hai cái đầu đó cần nhau.

Người ngoài hay gộp QA với QC làm một

Trong tin tuyển dụng ở Việt Nam, chữ “tester”, “QA” và “QC” bị dùng lẫn lộn khá nhiều. Có công ty gọi người chạy test thủ công là QA, có nơi lại gọi là QC. Nhưng nếu hỏi người làm lâu, họ sẽ phân biệt khá rõ.

Ở công ty nhỏ, một người làm cả hai. Ở công ty lớn, thường có nhóm QC làm kiểm thử hằng ngày và một vài người QA lo phần quy trình. Dù được gọi bằng chữ nào, cái chung là họ đứng giữa sản phẩm và người dùng, chặn lỗi trước khi người dùng phải gặp.

Một tuần ở phòng kiểm thử

Tôi từng có dịp ngồi gần một nhóm kiểm thử phần mềm (software tester) trọn một sprint hai tuần. Ngày đầu, họ ít khi test gì. Họ đọc tài liệu yêu cầu, ngồi họp cùng BA và developer, hỏi những câu khiến cả bàn phải dừng lại suy nghĩ. “Nếu người dùng đổi địa chỉ giao hàng sau khi đã thanh toán thì sao?” Câu đó không có trong tài liệu. Cuối buổi, BA phải thêm một mục mới.

Tôi để ý là tester giỏi thường hiểu sản phẩm rộng hơn cả developer, vì họ phải đi qua mọi luồng chứ không chỉ phần mình được giao. Những gì họ cần biết về hệ thống, về cách code được viết và triển khai, trùng nhiều với kỹ năng cốt lõi của nghề lập trình mà tôi có kể ở một bài riêng.

Mấy ngày tiếp theo là viết test case. Mỗi ca kiểm thử ghi rõ điều kiện ban đầu, các bước làm, kết quả mong đợi. Họ chia ra kiểm thử chức năng, kiểm thử giao diện, kiểm thử với dữ liệu biên như số âm, chuỗi rỗng, ký tự tiếng Việt có dấu, emoji. Nhóm này dùng TestRail để quản lý test case và Jira để theo dõi lỗi, nhưng tôi cũng biết nơi chỉ dùng Google Sheets và vẫn làm tốt.

Khi bản build đầu tiên có trên môi trường thử, phòng bắt đầu ồn hơn. Bug được báo, developer sửa, tester kiểm tra lại, đôi khi mở lại vì sửa chỗ này hỏng chỗ khác. Gần ngày phát hành là đợt kiểm thử hồi quy (regression test), chạy lại những luồng chính để chắc rằng thay đổi mới không phá tính năng cũ. Đây là chỗ test tự động phát huy tác dụng nhất.

Có một chuyện ít ai kể là dữ liệu thử. Muốn test luồng hoàn tiền thì phải có đơn hàng đã thanh toán, muốn test tài khoản bị khóa thì phải có tài khoản bị khóa. Nhóm đó giữ một bảng tính riêng ghi các tài khoản thử, mật khẩu, trạng thái, ai đang dùng. Có lần hai người cùng dùng một tài khoản, người này đổi mật khẩu, người kia báo bug “không đăng nhập được”. Mất nửa buổi sáng mới hiểu ra.

Từ phòng kiểm thử: một bug report tử tế có tiêu đề nói rõ chuyện gì sai, các bước tái hiện đánh số, kết quả mong đợi và kết quả thực tế, kèm ảnh hoặc video ngắn. Chị tester trong nhóm đó bảo, nếu developer phải nhắn hỏi lại “chị làm thế nào để ra lỗi này?” thì bug report đó chưa đạt.

Từ bấm tay sang viết script

Nhiều người vào nghề bằng kiểm thử thủ công (manual testing), và đó là cửa vào hợp lý. Nó dạy bạn cách nghĩ như người dùng, cách nhìn ra chỗ lạ. Nhưng sau vài năm, phần lớn tester tôi biết đều học thêm tự động hóa, vì chạy tay một bộ hồi quy vài trăm ca mỗi lần phát hành thì không ai chịu nổi.

Công cụ thì có vài cái tên hay gặp. Selenium vẫn còn được dùng nhiều ở các dự án lâu năm, Playwright và Cypress được các đội mới chuộng hơn. Postman dùng để kiểm thử API, Appium cho ứng dụng di động, JMeter hoặc k6 khi cần kiểm thử hiệu năng. Viết script tự động thì cần biết lập trình ở mức cơ bản, thường là JavaScript, Python hoặc Java, tùy đội.

Tôi muốn nói rõ một điều vì hay nghe hiểu nhầm. Làm tester không phải là “lập trình viên hạng hai”. Một người kiểm thử giỏi phải hiểu nghiệp vụ, hiểu cấu trúc hệ thống, biết đọc log, biết gọi API, biết viết truy vấn SQL để kiểm tra dữ liệu dưới cơ sở dữ liệu. Nhóm kỹ năng đó trùng khá nhiều với những gì developer cần, chỉ khác góc nhìn.

Developer hỏi “nó có chạy không”. Mình hỏi “nó chạy cho ai, trong điều kiện nào, và khi nào thì không”.

Câu đó tôi ghi lại từ một cậu tester trẻ trong buổi chia sẻ nội bộ. Cậu ấy vào nghề từ ngành kinh tế, học qua một khóa ngắn hạn rồi xin vào làm manual tester. Ba năm sau cậu viết script Playwright cho cả đội và đang học thêm về kiểm thử bảo mật.

Về đường đi, có người lên trưởng nhóm kiểm thử (QA lead), có người đi sâu vào tự động hóa thành SDET, kỹ sư phát triển phần mềm trong kiểm thử. Một số chuyển sang BA hoặc quản lý sản phẩm vì đã quá quen với nghiệp vụ. Thu nhập thì chênh nhau khá rõ giữa manual và automation, và còn tùy vào công ty, dự án, ngoại ngữ, nên tôi không đưa con số.

Những gì người mới hay hỏi tôi

Hỏi: Có cần chứng chỉ ISTQB không?

Đáp: Không bắt buộc, nhưng chứng chỉ nền tảng ISTQB Foundation Level giúp bạn nói cùng một ngôn ngữ với người trong nghề, và một số công ty gia công cho khách nước ngoài có đánh giá cao. Nó không thay được kinh nghiệm thực tế.

Hỏi: Người trái ngành có vào được không?

Đáp: Được, và tôi gặp khá nhiều. Kiểm thử thủ công là cửa vào dễ hơn so với lập trình. Bạn nên tự test thử vài trang web hay ứng dụng thật, viết bug report cẩn thận rồi đưa vào hồ sơ, nhà tuyển dụng thường muốn thấy cách bạn nghĩ hơn là bằng cấp.

Hỏi: AI viết test case thay người thì nghề này còn không?

Đáp: Các công cụ AI đã giúp viết nháp test case và script khá nhanh, nhóm tôi kể ở trên cũng dùng. Nhưng việc quyết định nên test cái gì, rủi ro nằm ở đâu, lỗi nào đáng chặn phát hành thì vẫn cần người hiểu sản phẩm. Theo tôi, người chỉ biết bấm theo kịch bản có sẵn sẽ khó hơn, còn người hiểu nghiệp vụ và biết tự động hóa thì vẫn có chỗ.

Phan Anh Tú

Ở góc phòng của nhóm mobile có một cái ngăn kéo mà ai mới vào cũng tò mò. Bên trong là mười mấy chiếc điện thoại, đủ đời: một chiếc iPhone màn hình nhỏ đã sứt góc, vài máy Android tầm trung của ba bốn hãng, một chiếc máy tính bảng dán băng keo ghi “đừng cập nhật hệ điều hành”. Mỗi chiếc là một lý do khiến một bản phát hành từng bị trả về.

Người làm mobile developer, lập trình di động, sống với cái ngăn kéo đó. Họ viết ứng dụng chạy trên điện thoại, thứ bạn tải về từ App Store hay Google Play, và họ phải lo cho nó chạy được trên những thiết bị mà chính họ không bao giờ chọn mua.

Viết cho một cái máy nằm trong túi người khác

Khác với web, ứng dụng di động chạy trên máy của người dùng, với pin của họ, bộ nhớ của họ, mạng 4G chập chờn trong thang máy của họ. Một lập trình viên di động (mobile developer) phải nghĩ đến những chuyện mà người làm web ít khi gặp. App bị hệ điều hành tắt ngầm khi chạy nền thì dữ liệu đang nhập có mất không. Người dùng từ chối quyền truy cập vị trí thì màn hình bản đồ hiện gì. Thông báo đẩy có đến đúng lúc không, hay đến muộn sau khi khuyến mãi đã hết giờ.

Có hai cách làm chính. Cách thứ nhất là viết riêng cho từng nền tảng: Swift và SwiftUI với Xcode cho iOS, Kotlin và Jetpack Compose với Android Studio cho Android. Cách này cho hiệu năng và cảm giác sử dụng sát với hệ điều hành nhất, nhưng tốn hai đội hoặc một người phải giỏi cả hai. Cách thứ hai là đa nền tảng, phổ biến nhất ở các văn phòng tôi biết là Flutter (viết bằng Dart) và React Native (viết bằng JavaScript hoặc TypeScript), một bộ code chạy được cả hai bên.

Không cách nào thắng tuyệt đối. Tôi thấy các startup và công ty gia công hay chọn Flutter hoặc React Native vì ra sản phẩm nhanh. Các ứng dụng ngân hàng lớn, ứng dụng cần đụng sâu vào camera, Bluetooth hay xử lý ảnh thì thường vẫn có đội native riêng. Nếu bạn muốn xem nhánh mobile nằm ở đâu giữa các vị trí khác trong một đội phần mềm, tôi có ghi lại phần kiến thức nền của nghề ở một bài riêng, đọc trước sẽ dễ hình dung hơn.

“Trên web lỡ lỗi thì sửa trong mười phút. Trên app, bản lỗi nằm trong máy người ta cả tuần.”

Đó là điều làm nghề mobile căng hơn hẳn ở khâu phát hành. Mỗi bản cập nhật phải qua vòng duyệt của Apple hoặc Google, thời gian không cố định, có lúc trôi chảy có lúc bị trả về vì một dòng mô tả quyền riêng tư chưa rõ. Và kể cả khi đã duyệt, người dùng không cập nhật ngay. Có người giữ bản cũ hàng năm trời. Vì vậy backend phải tiếp tục phục vụ cả những phiên bản app cũ, và người làm mobile phải nghĩ kỹ trước khi đổi bất cứ thứ gì liên quan đến dữ liệu.

Một tuần trước ngày phát hành

Tôi từng ngồi cạnh một nhóm mobile vào tuần cuối trước khi đưa một bản lớn lên chợ ứng dụng. Thứ Hai họ đóng băng tính năng, chỉ sửa lỗi. Thứ Ba bản thử nghiệm được đẩy qua TestFlight cho iOS và kênh thử nghiệm nội bộ trên Google Play Console cho Android, cả công ty được mời cài thử. Thứ Tư là ngày ngăn kéo điện thoại được mở ra, tester và developer chia nhau cầm từng máy, bấm qua từng luồng.

Ở bàn thử máy: lỗi khó chịu nhất tuần đó nằm trên một chiếc Android tầm trung, bàn phím ảo che mất nút “Xác nhận” ở màn hình nhập mã OTP. Trên máy giả lập thì không thấy. Phải cầm máy thật mới phát hiện được.

Thứ Năm nộp bản lên duyệt. Thứ Sáu cả nhóm ngồi chờ, mở Firebase Crashlytics liên tục để xem tỷ lệ crash của bản thử. Phát hành thì thường làm theo kiểu tung dần, ban đầu chỉ một phần nhỏ người dùng nhận bản mới, thấy ổn mới mở rộng.

Người ở góc phòng đó là ai

Những người làm mobile mà tôi quen thường có tính tỉ mỉ đến mức hơi khó chịu. Họ để ý khi một hiệu ứng chuyển màn hình bị giật nửa nhịp. Họ biết chuyện pin hao nhanh khi app gọi định vị liên tục. Họ đọc kỹ hướng dẫn thiết kế của Apple (Human Interface Guidelines) và Material Design của Google, không phải để chép, mà để biết người dùng mỗi bên quen thao tác thế nào.

Họ cũng phải học liên tục. Mỗi năm Apple và Google đều ra phiên bản hệ điều hành mới, kèm thay đổi về quyền riêng tư, về chạy nền, về thông báo. Có năm cả nhóm mất vài tuần chỉ để sửa app cho khớp với một chính sách mới.

Đường đi sau vài năm khá mở. Có người đi sâu thành chuyên gia iOS hoặc Android, có người học thêm backend để làm fullstack, có người lên trưởng nhóm mobile. Với ai thích tự làm, mảng này còn một lối riêng là tự phát hành ứng dụng của mình lên chợ, dù sống được bằng nó thì không dễ chút nào.

Còn cái ngăn kéo, đến giờ tôi nghe nói nó vẫn ở đó, thêm vài chiếc máy mới, bớt vài chiếc đã chết pin hẳn. Chiếc máy tính bảng dán băng keo thì vẫn chưa ai dám cập nhật.

Phan Anh Tú · người từng trực đêm

Hai giờ mười bảy phút sáng, điện thoại của cậu kỹ sư trực rung lên ba lần liền. Kênh cảnh báo báo thời gian phản hồi của API đặt hàng vọt từ hai trăm mili giây lên tám giây. Cậu mở laptop ngay trên giường, vào Grafana, thấy biểu đồ kết nối tới cơ sở dữ liệu dựng đứng như vách núi. Phía người dùng, ai đang đặt đồ ăn khuya chỉ thấy vòng xoay chờ mãi không dừng.

Tôi kể cảnh đó trước vì nó trả lời câu hỏi backend developer là gì rõ hơn mọi định nghĩa. Họ là những người chịu trách nhiệm cho phần bạn không nhìn thấy: máy chủ nhận yêu cầu, kiểm tra quyền, tính toán, ghi dữ liệu, trả kết quả về. Khi phần đó chạy ổn, không ai nhắc đến họ. Khi nó trục trặc, điện thoại reo lúc hai giờ sáng.

Thứ họ xây là đường ống, không phải mặt tiền

Nếu ví một ứng dụng như một nhà hàng thì frontend là phòng ăn, còn backend là bếp, kho, sổ sách và đường ống nước. Khách gọi món qua giao diện, yêu cầu đi xuống backend dưới dạng một lời gọi API. Backend kiểm tra món còn không, khách có đủ tiền trong ví không, tính phí giao hàng, ghi đơn vào cơ sở dữ liệu, rồi báo cho bếp và tài xế.

Một ngày làm việc của lập trình viên backend (backend engineer) thường xoay quanh vài loại việc. Thiết kế và viết API, thường theo kiểu REST, đôi khi là GraphQL hoặc gRPC khi các dịch vụ nội bộ gọi nhau. Thiết kế bảng dữ liệu, đặt chỉ mục (index) sao cho truy vấn không chậm khi bảng lên vài chục triệu dòng. Viết các tác vụ chạy nền như gửi email xác nhận, xuất báo cáo cuối ngày, đồng bộ dữ liệu với hệ thống của đối tác.

Phần còn lại, và phần này nhiều hơn người ta tưởng, là đọc log, đọc biểu đồ và đọc code cũ. Hệ thống backend sống lâu. Có những dịch vụ tôi từng sửa được viết từ thời người viết nó còn là sinh viên thực tập, giờ người đó đã làm giám đốc kỹ thuật ở công ty khác.

Ngôn ngữ nào cũng được, miễn hiểu thứ bên dưới

Câu hỏi tôi nghe nhiều nhất từ người mới là nên học ngôn ngữ nào. Thành thật thì ở Việt Nam, các văn phòng tôi biết dùng khá phân tán, tùy loại công ty và loại dự án.

Ngôn ngữ chỉ là lớp ngoài. Thứ phân biệt người làm backend lâu năm với người mới là họ hiểu những gì nằm dưới. Cơ sở dữ liệu quan hệ như PostgreSQL hay MySQL, giao dịch (transaction) và khóa dòng hoạt động thế nào. Bộ nhớ đệm như Redis giúp gì và gây rắc rối gì khi dữ liệu cũ không được xóa đúng lúc. Hàng đợi tin nhắn như RabbitMQ hay Kafka dùng khi nào. Docker để đóng gói, và với hệ thống lớn hơn thì Kubernetes để chạy hàng chục bản sao cùng lúc.

Tôi từng phỏng vấn một bạn viết Java rất nhanh nhưng không giải thích được vì sao truy vấn của mình chậm khi bảng lớn lên. Bạn ấy không sai khi chọn Java. Bạn ấy chỉ chưa từng nhìn vào kế hoạch thực thi (execution plan) của câu SQL mình viết.

Ai muốn thấy backend nằm ở đâu so với frontend, mobile, kiểm thử và phân tích nghiệp vụ thì có thể đọc thêm bài tôi viết về các vị trí trong nghề lập trình, ở đó tôi kể về từng chỗ ngồi trong một văn phòng phần mềm.

Đêm hôm đó kết thúc thế nào

Quay lại cậu kỹ sư trực đêm. Sau hai mươi phút dò log, cậu tìm ra nguyên nhân: một tác vụ xuất báo cáo được ai đó đổi lịch chạy từ bốn giờ sáng sang hai giờ, và nó khóa đúng bảng mà API đặt hàng cần ghi vào. Cậu tạm dừng tác vụ, kết nối thông trở lại, biểu đồ hạ xuống. Sáng hôm sau cả nhóm ngồi viết báo cáo sự cố (postmortem), không đổ lỗi cho ai, chỉ ghi lại chuyện gì xảy ra, vì sao không phát hiện sớm, và sẽ thêm cảnh báo gì.

Lúc đó em chỉ nghĩ, may mà mình đã đọc log từ trên xuống chứ không đoán bừa rồi khởi động lại máy chủ.

Cậu ấy kể vậy trong buổi họp sáng, giọng vẫn còn ngái ngủ. Tôi nghĩ đó là bài học quý hơn mọi khóa học. Backend không chỉ là viết code đúng. Nó là viết code mà khi sai thì để lại đủ dấu vết cho người khác lần ra, là thêm log ở đúng chỗ, là đặt cảnh báo trước khi người dùng phải gọi tổng đài.

Thói quen của người làm lâu thường rất cụ thể. Họ viết test cho phần tính tiền trước khi viết code. Họ hỏi “nếu dịch vụ bên kia không trả lời thì sao” trong mọi buổi thiết kế. Họ không tin dữ liệu từ phía người dùng gửi lên, kể cả khi frontend đã kiểm tra rồi. Và họ ghét nhất là những thay đổi được đẩy lên lúc năm giờ chiều thứ Sáu.

Bảo mật cũng nằm trên vai backend nhiều hơn người ta nghĩ. Mật khẩu phải được băm, không lưu dạng thô. Truy vấn phải tham số hóa để tránh SQL injection. Token đăng nhập phải có hạn dùng. Danh sách OWASP Top 10 là thứ tôi hay khuyên người mới đọc ít nhất một lần, vì phần lớn lỗi bảo mật tôi gặp trong đời đi làm đều nằm trong đó.

Đường đi của người làm phía sau

Lộ trình thường bắt đầu bằng việc sửa lỗi nhỏ và viết API đơn giản dưới sự kèm cặp của người đi trước. Vài năm sau, bạn được giao thiết kế cả một dịch vụ, tự quyết định bảng dữ liệu và cách các thành phần nói chuyện với nhau. Lên senior, bạn bắt đầu nghĩ về cả hệ thống: chỗ nào là điểm nghẽn, chỗ nào hỏng thì kéo sập mọi thứ, chi phí máy chủ hàng tháng là bao nhiêu và có đáng không.

Từ đó, có người đi tiếp lên kiến trúc sư phần mềm, có người rẽ sang DevOps hoặc SRE (site reliability engineer) vì thích lo chuyện vận hành, có người sang kỹ sư dữ liệu (data engineer) vì đã quen với cơ sở dữ liệu và các luồng xử lý. Một số làm quản lý. Tôi thấy backend là chỗ xuất phát khá rộng cửa cho nhiều hướng đi sau này.

Thu nhập thì như mọi nhánh khác, khác nhau rất nhiều theo công ty, mảng nghiệp vụ, ngôn ngữ và khả năng tiếng Anh. Tôi không đưa con số ở đây vì nó dễ gây hiểu lầm hơn là giúp ích.

Mấy câu tôi hay bị hỏi

Hỏi: Không giỏi Toán có làm backend được không?

Đáp: Được, với phần lớn công việc thường ngày. Bạn cần tư duy logic, hiểu độ phức tạp thuật toán ở mức cơ bản và biết vì sao một vòng lặp lồng nhau trên dữ liệu lớn lại chậm. Toán sâu chỉ cần khi làm các mảng như mật mã, tối ưu hóa định tuyến hay học máy.

Hỏi: Nên học SQL hay NoSQL trước?

Đáp: Theo tôi là SQL. Phần lớn hệ thống nghiệp vụ vẫn dựa trên cơ sở dữ liệu quan hệ, và hiểu được join, index, transaction rồi thì chuyển sang MongoDB hay các loại khác dễ hơn nhiều so với chiều ngược lại.

Hỏi: Có phải làm backend thì phải trực đêm?

Đáp: Không phải nơi nào cũng vậy. Công ty làm sản phẩm chạy 24/7 như thanh toán, giao đồ ăn, sàn thương mại thường có lịch trực xoay vòng. Công ty gia công theo dự án hoặc làm phần mềm nội bộ thì ít hơn hẳn. Nên hỏi thẳng chuyện này khi phỏng vấn.

Phan Anh Tú · ghi chép nghề

Cô ấy phóng to màn hình lên 400%, rồi lấy thước đo của Figma đặt cạnh cái nút “Thanh toán”. Lệch bốn pixel so với bản thiết kế. Không ai trong phòng để ý, trừ cô và cậu designer ngồi đối diện, người vừa nhắn tin hỏi “chỗ này em làm theo bản cũ à?”. Đó là một buổi chiều rất bình thường của một frontend developer.

Tôi hay được hỏi frontend developer là gì, thường bởi người thân hoặc sinh viên năm nhất. Câu trả lời ngắn là người dựng phần mà bạn nhìn thấy và chạm vào trên một trang web: nút bấm, ô nhập liệu, menu, ảnh, hiệu ứng khi kéo trang. Câu trả lời dài hơn thì thú vị hơn nhiều, và nó nằm ở những gì diễn ra phía sau cái nút lệch bốn pixel kia.

Họ là người dịch bản vẽ thành thứ bấm được

Một bản thiết kế trong Figma chỉ là hình ảnh. Nó không biết khi người dùng nhập sai email thì phải hiện chữ đỏ ở đâu, không biết khi mạng chậm thì nút có xoay vòng chờ không, cũng không biết màn hình điện thoại năm inch thì cột bên phải sẽ đi đâu. Người làm frontend (lập trình viên giao diện) phải trả lời hết những câu đó bằng code.

Công việc trong một tuần

Đầu tuần thường là nhận ticket. Một màn hình mới, một form đăng ký, hoặc sửa lỗi “trên Safari bị vỡ khung”. Họ mở bản thiết kế, chia nó thành các thành phần nhỏ (component) như thẻ sản phẩm, thanh tìm kiếm, hộp thoại xác nhận. Một component viết tốt có thể dùng lại ở hai chục chỗ.

Giữa tuần là nối giao diện với dữ liệu thật. Lúc này frontend phải ngồi cùng người làm backend, thống nhất API trả về trường nào, tên gì, khi lỗi thì mã lỗi ra sao. Tôi đã thấy không ít cuộc tranh cãi chỉ vì một bên đặt tên userName, bên kia mong username. Nghe buồn cười nhưng sửa ở giai đoạn muộn thì tốn công thật.

Cuối tuần, nếu may mắn, là kiểm thử trên nhiều trình duyệt và thiết bị. Chrome, Safari, Firefox, một chiếc iPhone cũ, một chiếc Android giá rẻ của phòng QA. Cái điện thoại Android cũ đó là nỗi ám ảnh của nhiều người, vì trang chạy mượt trên MacBook có thể giật từng nhịp trên nó.

Bộ đồ nghề

Nền móng vẫn là ba thứ cũ: HTML để dựng khung, CSS để trang trí và sắp xếp, JavaScript để xử lý tương tác. Bây giờ hầu hết các đội dùng thêm TypeScript để bắt lỗi kiểu dữ liệu sớm hơn. Trên nền đó là framework, phổ biến nhất ở các công ty tôi biết là React, sau đó là Vue và Angular. Next.js hay Nuxt được dùng khi cần trang tải nhanh và thân thiện với công cụ tìm kiếm.

Nếu muốn thấy frontend đứng ở đâu giữa các nhánh còn lại như backend, mobile hay kiểm thử, tôi có viết một bài tổng quan nghề lập trình kể kỹ hơn về từng chỗ ngồi trong một văn phòng phần mềm.

Bốn pixel không phải chuyện nhỏ

Người ngoài nghe chuyện cãi nhau vì bốn pixel hay cười. Nhưng trong một trang thanh toán, nút lệch có thể khiến người dùng bấm nhầm vào nút “Quay lại”. Nhiều lần như vậy, đơn hàng rơi rớt mà không ai hiểu vì sao.

“Người dùng không bao giờ khen giao diện đẹp. Họ chỉ bỏ đi khi nó khó dùng.”

Một trưởng nhóm frontend tôi quen hay nói vậy với người mới. Anh ấy bắt cả đội tự mở trang bằng chế độ mạng 3G giả lập trong DevTools mỗi khi xong một tính năng. Ai làm trang nặng quá, ảnh không nén, gói JavaScript phình lên vài megabyte, sẽ tự thấy xấu hổ khi nhìn thanh tải chạy mãi không xong.

Có một mảng mà ở Việt Nam ít người để ý là khả năng truy cập (accessibility). Nút có nhãn để trình đọc màn hình đọc được không, màu chữ có đủ tương phản cho người mắt kém không, dùng bàn phím có đi hết được form không. Các dự án làm cho khách hàng Nhật, Úc hay châu Âu thường kiểm phần này khá kỹ, và người frontend biết làm thì có thêm một điểm cộng rõ ràng.

Ở bàn code: người mới hay học framework trước khi hiểu JavaScript thuần. Đến lúc gặp lỗi liên quan đến bất đồng bộ, từ khóa this, hoặc vòng đời của component, họ không biết lỗi nằm ở React hay ở chính ngôn ngữ. Tôi thấy ai chịu ngồi vài tuần với JavaScript gốc thì về sau đỡ khổ hơn nhiều.

Ai hợp với chỗ ngồi này

Tôi để ý những người làm frontend lâu năm thường có một điểm chung: họ khó chịu khi thấy thứ gì đó xấu hoặc khó dùng. Không nhất thiết phải biết vẽ. Nhưng nhìn một trang web mà chữ dính sát lề, nút bé xíu trên điện thoại, họ thấy ngứa mắt và muốn sửa.

Họ cũng phải chịu được việc bị góp ý liên tục. Designer góp ý về khoảng cách, product manager góp ý về luồng, tester gửi lỗi kèm ảnh chụp màn hình, khách hàng gửi email “chữ to lên chút được không”. Frontend là chỗ mọi người đều nhìn thấy, nên cũng là chỗ ai cũng có ý kiến.

Về đường đi, sau vài năm người làm frontend có thể đi sâu vào hiệu năng và kiến trúc phía giao diện, học thêm backend để thành fullstack, hoặc chuyển sang mobile với React Native vì cùng gốc JavaScript. Một số người tôi biết rẽ sang thiết kế sản phẩm vì nhận ra mình thích nghĩ về trải nghiệm người dùng hơn là viết code. Không hướng nào sai cả.

Thu nhập thì tôi không nêu con số. Nó lệ thuộc nhiều vào việc bạn làm cho công ty nào, dự án trong nước hay nước ngoài, có thạo TypeScript và một framework lớn không, và tiếng Anh tới đâu. Chênh lệch giữa hai người cùng ba năm kinh nghiệm có thể rất lớn.

Chiều hôm đó, cô frontend sửa xong bốn pixel, đẩy code lên, rồi nhắn cho cậu designer một chữ “xong”. Cậu gửi lại một sticker con mèo giơ ngón cái. Ở nghề này, đôi khi đó là lời khen đáng giá nhất trong ngày.