Nếu bạn mới bước vào nghề làm web, gần như chắc chắn sẽ đụng phải vài lỗi quen thuộc. Code rối như tơ vò, form bị kẻ xấu dòm ngó, trang tải chậm đến mức khách bỏ đi trước khi kịp thấy nội dung. Đội ngũ chúng tôi đã gặp đi gặp lại những lỗi này qua nhiều dự án khác nhau, từ website công ty nhỏ đến hệ thống đào tạo trực tuyến. Bài viết này gom chúng thành ba nhóm chính, kèm cách tránh để bạn áp dụng ngay khi viết dòng code tiếp theo.
Vì sao dev web mới hay mắc cùng một loại lỗi
Lý do khá đơn giản. Người mới thường dồn toàn bộ sức lực vào việc làm sao cho chương trình chạy được đã. Chuyện cấu trúc, bảo mật hay vận hành thì họ nghĩ sẽ tính sau. Nhưng chữ “sau” ấy thường không bao giờ đến, và lỗi cứ thế chồng lên nhau như một quả cầu tuyết lăn xuống dốc.
Khi chọn 10 mục trong bài này, chúng tôi dựa trên ba tiêu chí. Thứ nhất là tần suất xuất hiện trong dự án thực tế. Thứ hai là mức độ ảnh hưởng nếu mắc phải. Thứ ba là việc người mới dễ bỏ qua nhất. Bài viết phù hợp với sinh viên, dev junior và bất kỳ ai đang tự học làm web, kể cả bạn đang cân nhắc giữa các hướng đi trong nghề.
Sai lầm 1 đến 3: khi mã nguồn bắt đầu rối
Sai lầm đầu tiên là không dùng Git, hoặc có dùng nhưng mỗi lần commit lại là một khối thay đổi khổng lồ. Bạn có thể hình dung commit giống như chụp một tấm ảnh lưu lại trạng thái dự án. Nếu tấm ảnh quá lớn, lúc cần quay lại đúng một chi tiết nhỏ, bạn sẽ phải lục tìm rất vất vả. Nên commit từng thay đổi nhỏ và ghi chú rõ ràng, để sau này ai đọc lịch sử cũng hiểu chuyện gì đã xảy ra.
Sai lầm thứ hai là trộn lẫn giao diện, xử lý nghiệp vụ và truy vấn dữ liệu trong cùng một file. Lúc dự án mới có vài trang thì chưa thấy vấn đề gì. Đến khi thêm chức năng, bạn sẽ không dám sửa bất cứ thứ gì vì sợ làm hỏng chỗ khác. Hãy tách riêng phần hiển thị, phần logic và phần làm việc với cơ sở dữ liệu. Mỗi hàm chỉ nên làm một việc chính. Nếu thấy hàm nào dài hơn một màn hình, đó là dấu hiệu bạn nên cắt nhỏ nó ra.
Sai lầm thứ ba nghe thì nhỏ nhưng lại gây khổ nhiều nhất là đặt tên không đồng nhất. Hôm nay bạn gọi là getUser, mai gọi thành fetch_user, ngày kia lại thành loadUserInfo. Dự án càng lớn, chính bạn cũng phải đọc lại lâu hơn mỗi lần mở code. Hãy chọn một quy ước, ví dụ camelCase cho hàm và PascalCase cho lớp, rồi giữ nó đến cùng. Công cụ như ESLint có thể nhắc bạn khi lệch chuẩn.
Bảo mật: đừng để lỗ hổng tự tìm đến bạn
Đây là nhóm lỗi nguy hiểm nhất. Hậu quả thường xuất hiện sau khi website đã lên mạng, lúc việc sửa chữa trở nên tốn kém và căng thẳng hơn nhiều. Sai lầm thứ tư là không kiểm tra và làm sạch dữ liệu người dùng nhập vào. Nếu bạn ghép trực tiếp chuỗi nhập vào câu lệnh SQL, kẻ xấu có thể chèn lệnh của riêng chúng, gọi là SQL injection. Tương tự, nếu in nội dung người dùng ra trang mà không lọc, mã độc có thể chạy ngay trên trình duyệt của người khác, gọi là XSS.
Cách phòng tránh khá rõ ràng: dùng truy vấn có tham số hoặc ORM thay vì nối chuỗi, và luôn mã hóa nội dung trước khi hiển thị. Nếu dự án của bạn dùng WordPress, các hàm như esc_html và sanitize_text_field đã sẵn có, bạn chỉ cần nhớ gọi đúng lúc.
Sai lầm thứ năm là lưu mật khẩu dưới dạng văn bản thuần, hoặc băm bằng thuật toán yếu như MD5. Bạn nên dùng bcrypt hay argon2, vì chúng được thiết kế để làm chậm việc dò mật khẩu. Chi tiết này có vẻ nhỏ, nhưng nếu cơ sở dữ liệu bị lộ thì cái giá phải trả rất lớn, cả về uy tín lẫn pháp lý.
Sai lầm thứ sáu là để khóa API hoặc mật khẩu kết nối database nằm thẳng trong mã nguồn rồi đẩy lên GitHub công khai. Bot quét mã nguồn hoạt động rất nhanh. Chúng tôi từng chứng kiến thông tin bị lấy đi chỉ vài phút sau khi commit. Hãy đặt những thông tin nhạy cảm vào biến môi trường, thêm file cấu hình cục bộ vào .gitignore, và nếu lỡ đẩy lên rồi thì đổi khóa ngay lập tức.
Tốc độ trang: người dùng không đợi bạn
Sai lầm thứ bảy là tải quá nhiều ảnh nặng cùng những đoạn script không cần thiết. Một trang có ảnh năm megabyte, kèm thêm năm thư viện JavaScript chẳng dùng tới, có thể khiến người dùng trên mạng di động chờ vài giây mới thấy nội dung. Google đo điều này qua các chỉ số Core Web Vitals, và trang chậm sẽ bị xếp hạng thấp hơn. Quan trọng hơn, người dùng thường rời đi trước khi bạn kịp làm gì.
Cách xử lý đơn giản hơn bạn nghĩ. Nén ảnh và dùng định dạng WebP, tải script theo nhu cầu thay vì tải hết một lần, và gỡ bỏ những thư viện không còn dùng. Đội ngũ chúng tôi từng nhận một dự án landing page tải gần bốn giây trên điện thoại. Chỉ sau một buổi chiều nén ảnh và bỏ hai thư viện thừa, thời gian đó đã xuống còn dưới một giây rưỡi.
Sai lầm thứ tám là truy vấn database nằm trong vòng lặp, hay còn gọi là lỗi N+1. Ví dụ bạn lấy 100 bài viết, rồi trong vòng lặp lại gọi thêm 100 lần để lấy tên tác giả. Khi test với 10 dòng dữ liệu thì mọi thứ vẫn ổn. Lên môi trường thật với vài nghìn dòng, trang đứng hẳn. Cách xử lý là lấy toàn bộ dữ liệu liên quan trong một truy vấn có JOIN, đồng thời thêm chỉ mục cho các cột hay được tìm kiếm. Nếu bạn muốn hiểu cơ chế ánh xạ dữ liệu trong các framework, hãy đọc thêm ORM là gì? Tổng quan kiến thức về ORM Framework trong lập trình.
Kiểm thử và triển khai: đừng để khách hàng là người test
Sai lầm thứ chín là bỏ qua kiểm thử, viết xong là đẩy thẳng lên hệ thống thật. Bạn không cần viết kiểm thử tự động cho mọi thứ ngay từ đầu. Chỉ cần kiểm tra lại các luồng quan trọng như đăng nhập, thanh toán và gửi form là đã giảm đáng kể rủi ro. Có lần đội ngũ chúng tôi thấy một lỗi nhỏ ở bước thanh toán làm mất đơn hàng suốt cả buổi chiều, chỉ vì không ai thử lại trước khi phát hành.
Sai lầm thứ mười là triển khai thủ công, không có môi trường staging và không có kế hoạch sao lưu. Staging là bản sao gần giống hệ thống thật để thử nghiệm trước khi đưa cho người dùng. Việc sao lưu nên làm định kỳ, và quan trọng hơn là thử khôi phục ít nhất một lần cho chắc. Nhiều người chỉ phát hiện bản sao lưu bị hỏng khi thực sự cần dùng đến, lúc đó thì đã muộn.
Cách chọn công cụ giúp bạn tránh các lỗi trên
Có nhiều công cụ giúp bạn tự động hóa phần lớn việc kiểm tra. Chúng tôi đánh giá chúng dựa trên chi phí, độ khó khi học và mức độ cộng đồng hỗ trợ tiếng Việt. Đây chỉ là nhận định tương đối trong điều kiện làm việc của đội ngũ, nên bạn hãy tự thử trước khi quyết định.
Nhóm linter như ESLint và Prettier bắt lỗi cú pháp và giữ định dạng code đồng nhất giữa các thành viên, đặc biệt hữu ích khi nhóm có nhiều người cùng sửa một dự án. Nhóm kiểm thử như Jest hay PHPUnit cần thêm thời gian làm quen, nhưng về lâu dài sẽ tiết kiệm rất nhiều công kiểm tra thủ công. Với CI/CD, GitHub Actions cho phép tự động chạy kiểm thử và triển khai mỗi khi bạn đẩy code. Tuy nhiên gói miễn phí có giới hạn số lần build, nên hãy xem bảng giá hiện hành trước khi dựa vào nó cho dự án lớn.
Một lưu ý quan trọng: các con số hiệu năng trên trang quảng cáo công cụ thường đo trong điều kiện lý tưởng. Hãy tự đo trên dự án thật của bạn trước khi tin hoàn toàn. Nếu cần một điểm khởi đầu gọn gàng không tốn chi phí, bạn có thể xem Top 10 lập trình web và mobile app miễn phí đáng dùng để so sánh các lựa chọn phù hợp với quy mô của mình.
Nhìn lại quy trình của team nhỏ
Với team từ hai đến năm người, bạn chưa cần một quy trình phức tạp. Tuy vậy, vài thói quen nhỏ lại rất đáng giá. Code review, dù chỉ là một người đọc lại trước khi merge, giúp bắt được nhiều lỗi bảo mật và lỗi logic mà người viết thường bỏ sót vì quá quen với đoạn code của chính mình. Một checklist bảo mật ngắn cho mỗi lần phát hành cũng hữu ích, vì nó buộc bạn dừng lại kiểm tra những việc hay bị quên như xóa thông tin debug, rà soát quyền truy cập và đổi khóa tạm.
Tài liệu nội bộ cũng không cần đồ sộ. Chỉ cần ghi lại vì sao chọn một thư viện, vì sao thư mục được tổ chức theo cách đó, hay cách chạy dự án trên máy mới. Sáu tháng sau, chính bạn sẽ cảm ơn bản ghi chú ấy, và thành viên mới cũng đỡ mất thời gian hơn. Nếu bạn đang phân vân giữa các hướng đi, hãy đọc thêm Chọn học lập trình Front-end hay Back-end để hiểu vai trò và yêu cầu của từng mảng trước khi quyết định.
Câu hỏi thường gặp
Người mới nên sửa sai lầm nào trước tiên?
Bạn nên bắt đầu từ Git và việc kiểm tra dữ liệu đầu vào. Hai việc này tốn ít thời gian để làm quen nhưng giúp tránh phần lớn rủi ro nghiêm trọng. Sau đó mới tính đến tổ chức code và tối ưu tốc độ.
Có cần học bảo mật web ngay từ đầu không?
Bạn không cần đi sâu ngay, nhưng nên biết các lỗi phổ biến như SQL injection và XSS, cùng cách phòng tránh cơ bản. Đây là kiến thức nền mà bất kỳ dev web nào cũng nên nắm, vì lỗi bảo mật thường không báo trước.
Dự án nhỏ có cần CI/CD không?
Không bắt buộc. Nếu bạn triển khai vài lần mỗi tháng, một script đơn giản là đủ. Khi tần suất tăng lên, CI/CD sẽ tiết kiệm nhiều thời gian và giảm lỗi do thao tác tay.
Làm sao biết code web đã đủ tốt để đưa lên môi trường thật?
Hãy tự hỏi: các luồng chính đã được thử chưa, có bản sao lưu không, thông tin nhạy cảm đã được bảo vệ chưa. Nếu trả lời được cả ba câu, bạn có thể yên tâm hơn khi đưa sản phẩm lên mạng.