[Series Phỏng Vấn Backend] #5: Trả Lời Câu Hỏi Tech Lead - Làm Sao Để Tự Động Hóa Việc Bắt Lỗi Code Của Team?

Chào mừng anh em quay trở lại với series Giải Mã Phỏng Vấn Backend.

Ở kỳ trước, chúng ta đã bóc trần nguyên nhân gốc rễ của việc sập server do dùng hàm env() ngoài thư mục config. Lỗi thì đã hiểu, cách fix cũng đã có. Nhưng nếu bạn đang ứng tuyển vào vị trí Tech Lead, người phỏng vấn sẽ không tha cho bạn dễ dàng như vậy. Họ sẽ ném ra một câu hỏi mang tính "thử lửa":

"Giả sử em là Tech Lead của một team 10 người. Em không thể ngày nào cũng đi theo đít từng ông dev để nhắc 'Đừng xài env() lung tung nhé'. Vậy em sẽ làm gì để cả team không bao giờ dính lại lỗi này — tức là biến bài học cá nhân thành một cơ chế tự động chặn ở cấp dự án? Kể anh nghe vài cách cụ thể."

Để ăn trọn điểm câu này, bạn hãy bắt đầu bằng câu thần chú của mọi Tech Lead: "Đừng tin vào con người, hãy tin vào hệ thống".

Chúng ta không dùng lời nói để quản lý, chúng ta dùng CI/CD và Tooling. Dưới đây là 3 cấp độ phòng ngự mà một Tech Lead có thể thiết lập để "diệt cỏ tận gốc" con bug này.

Cấp Độ 1: Phòng Ngự Tại Máy Dev (Shift-Left Testing)

Nguyên tắc tối thượng là: Lỗi phát hiện càng sớm, chi phí sửa càng rẻ. Không nên đợi code được push lên server rồi mới chửi nhau, hãy chặn nó ngay từ lúc dev gõ lệnh git commit.

Giải pháp: Sử dụng Git Hooks (Pre-commit Hook)

Bạn có thể thiết lập một công cụ quản lý Git Hook (ví dụ như CaptainHook cho PHP hoặc Husky nếu team quen dùng hệ sinh thái Node.js) vào dự án.

Mỗi khi bất kỳ ai trong team gõ git commit, một script sẽ tự động quét qua những file đang được thay đổi (staged files).

• Script sẽ tìm kiếm chuỗi env(.
• Nếu phát hiện hàm env() được sử dụng ở bất cứ thư mục nào ngoại trừ thư mục config/, tiến trình commit sẽ bị hủy bỏ ngay lập tức (Abort) kèm theo một dòng chửi thân thiện trên terminal: "Lỗi: Không được dùng env() ngoài thư mục config. Hãy khai báo trong config và dùng hàm config()!".
• Dev buộc phải sửa lại code mới có thể commit được.

Cấp Độ 2: Bức Tường Thép Tại CI/CD Pipeline

Dù có Git Hooks, một số dev "lươn lẹo" vẫn có thể dùng cờ --no-verify để bypass. Do đó, chốt chặn cuối cùng và quyền lực nhất phải nằm ở CI/CD (GitLab CI, GitHub Actions...).

Khi dev tạo Merge Request / Pull Request (MR/PR), pipeline sẽ chạy. Nếu không pass, nút "Merge" sẽ bị vô hiệu hóa, Tech Lead thậm chí không cần tốn công review. Có 2 cách để triển khai trên CI:

Cách A: Dùng Static Code Analysis (Hệ chính quy)

Đã làm Laravel thì Tech Lead phải biết đưa PHPStan (hoặc Larastan) vào dự án. Đây là công cụ phân tích tĩnh mã nguồn cực mạnh.

• Bạn chỉ cần cấu hình một rule tùy chỉnh (Custom Rule) hoặc cài các package có sẵn (như ergebnis/phpstan-rules) để cấm (ban) hoàn toàn việc gọi hàm env().
• Khi CI chạy php artisan code:analyse, công cụ sẽ đọc hiểu AST (Abstract Syntax Tree) của code. Nếu thấy env(), nó sẽ báo failed pipeline ngay lập tức. Cách này vô cùng chuẩn chỉ và chuyên nghiệp.

Cách B: Script "Nhà Nghèo Mà Võ Công Cao" (Bash/Grep)

Nếu dự án chưa kịp setup Larastan phức tạp, Tech Lead có thể dùng một thủ thuật cực kỳ nhanh - gọn - lẹ bằng một dòng lệnh Bash duy nhất nhét vào file .gitlab-ci.yml hoặc Github Actions:

# Quét thư mục app/ và văng lỗi (exit 1) nếu tìm thấy chuỗi env(
if grep -rnw 'app/' -e 'env('; then
  echo "🔥 ERROR: Đã phát hiện hàm env() trong thư mục app/. Vui lòng dùng config() thay thế!"
  exit 1
fi

Lệnh grep này chạy tốn chưa tới 1 giây. Bất kỳ ai cố tình nhét env() vào thư mục app/ (chứa Controller, Service, Model) sẽ làm đỏ quạch pipeline ngay lập tức. Không giải thích lằng nhằng!

Cấp Độ 3: Tự Động Hóa Code Review (Linter Auto-Fix)

Ở một đẳng cấp tinh tế hơn, thay vì chỉ "báo lỗi", hệ thống có thể tự động "đập vào mặt" dev lúc review.

Bằng cách sử dụng PHP_CodeSniffer hoặc công cụ mới của Laravel là Laravel Pint. Bạn tạo ra một rule định nghĩa chuẩn Coding Standard cho team. Khi CI chạy, nếu phát hiện vi phạm, hệ thống có thể cấu hình một con bot tự động comment trực tiếp vào dòng code sai trên Pull Request: "Chỗ này sai Convention rồi người anh em, sửa lại thành config() nhé".

Điều này giúp giảm thiểu việc Tech Lead phải đi làm "cảnh sát chính tả" và tiết kiệm hàng giờ đồng hồ mỗi tuần.

Tổng Kết

Một Tech Lead giỏi không đo bằng việc anh ta fix bug nhanh như thế nào, mà đo bằng việc anh ta xây dựng "đường ray" vững chắc ra sao để cả team dù có nhắm mắt cũng không thể trật bánh.

Biến bài học cá nhân thành bộ Rule của Linter, chặn nó bằng Git Hooks, và hành quyết nó ở CI Pipeline — đó chính là tư duy Engineering thực thụ!