QUY ƯỚC CODE

V. Quy ước đặt tên 

 9. Biến 

 

 Sử dụng camelCase 

 Tên phải có ý nghĩa 

 Không viết tắt khó hiểu 

 

 Không sử dụng tên như: a, data1, temp, test nếu không có ý nghĩa rõ ràng. 

 

 10. Class và Interface 

 

 Sử dụng PascalCase 

 Tên phản ánh đúng chức năng 

 

 Ví dụ: 

 

 UserSyncService 

 AuthController 

 DataMappingRepository 

 

 Không đặt tên chung chung như: Service1, TestClass. 

 

 11. Tên file 

 

 Tên file trùng với class chính 

 Không đặt tên file không rõ nghĩa 

 

 Không sử dụng các tên như: utils2, newfile, test. 

 

 VI. Cấu trúc và tổ chức code 

 12. Phân tầng rõ ràng 

 

 Controller không chứa business logic phức tạp 

 Service không truy cập database trực tiếp nếu đã có repository layer 

 Không viết toàn bộ logic trong một file duy nhất 

 

 Phải tuân thủ đúng kiến trúc đã thống nhất của dự án. 

 

 13. Hàm và logic 

 

 Một function chỉ nên thực hiện một nhiệm vụ 

 Không viết function quá dài và khó theo dõi 

 Logic phức tạp phải được tách nhỏ 

 

 Nếu một function vượt quá mức hợp lý và khó đọc, reviewer có quyền yêu cầu refactor. 

 

 14. Logging 

 

 Log phải có mục đích rõ ràng 

 Không log dữ liệu nhạy cảm 

 Không để log debug dư thừa trước khi merge 

 

 

 15. Xử lý lỗi 

 

 Không catch lỗi mà bỏ qua 

 Không throw lỗi chung chung 

 Message lỗi phải rõ ràng, có ngữ cảnh 

 

 Không để các khối catch rỗng hoặc bỏ qua exception. 

 

 16. Format và kiểm tra tự động 

 

 Bắt buộc sử dụng ESLint / Prettier theo cấu hình dự án 

 Không merge nếu format sai 

 Không thay đổi format toàn bộ file nếu không liên quan đến task 

 

 

 VII. Trách nhiệm kỹ thuật 

 

 Code trước khi tạo PR phải: 

 

 Chạy được 

 Không lỗi compile 

 Không làm hỏng chức năng cũ 

 

 Người thực hiện task chịu trách nhiệm: 

 

 Test lại trước khi merge 

 Theo dõi lỗi phát sinh sau khi merge 

 

 Không đổ lỗi cho quá trình merge nếu chưa kiểm tra kỹ trước đó. 

 

 

 VIII. Xử lý vi phạm 

 17. Vi phạm mức độ 1 – Yêu cầu chỉnh sửa 

 Áp dụng khi: 

 

 Sai format 

 Sai naming 

 Commit message không đúng quy ước 

 PR thiếu mô tả 

 

 Hình thức xử lý: 

 

 Yêu cầu chỉnh sửa trước khi approve 

 

 

 18. Vi phạm mức độ 2 – Từ chối merge 

 Áp dụng khi: 

 

 Không tuân thủ workflow 

 Tự ý commit vào nhánh chính 

 Không xử lý conflict 

 Không test trước khi tạo PR 

 

 Hình thức xử lý: 

 

 Từ chối merge 

 Yêu cầu làm lại theo đúng quy trình 

 

 

 19. Vi phạm mức độ 3 – Đánh giá năng lực kỹ thuật 

 Áp dụng khi: 

 

 Lặp lại vi phạm nhiều lần 

 Không tuân thủ quy ước dù đã được nhắc 

 Gây ảnh hưởng nghiêm trọng đến hệ thống 

 

 Hình thức xử lý: 

 

 Trao đổi trực tiếp 

 Đánh giá lại mức độ phù hợp trong dự án 

 

 

 IX. Hiệu lực 

 Quy định này có hiệu lực kể từ ngày ban hành và áp dụng cho toàn bộ thành viên tham gia phát triển dự án. 

 Mọi thay đổi về workflow hoặc quy ước kỹ thuật phải được thống nhất trước khi áp dụng.