7COM1025: vì sao code chạy được vẫn bị điểm thấp?

Khoảnh khắc gây hoang mang nhất ở môn 7COM1025 là lúc một bài nộp biên dịch trơn tru, chạy đúng, qua hết test, mà điểm trả về chỉ nằm ở nhóm giữa. Những bạn từng đi làm lập trình thấy khó chịu nhất, bởi tiêu chuẩn mà các bạn mang theo, tức là code chạy được, chính là vạch xuất phát của môn này chứ không phải vạch đích. Programming for Software Engineers là môn Level 7, mà Level 7 thì chấm phán đoán kỹ thuật: bạn đã chọn gì, đã loại bỏ gì, và bạn đưa ra được bằng chứng nào cho thấy lựa chọn đó là hợp lý. Dưới đây là những điều mentor MAAS phải giải thích nhiều nhất với sinh viên Việt Nam học môn này ở Hertfordshire.

Tác giả: Ban biên tập MAAS · Hiệu đính bởi mentor cao cấp mảng Công nghệ thông tin (Tiến sĩ, Software Engineering)
Cập nhật: 10/08/2026
Chuyên mục: writing-tips

Môn 7COM1025 là gì và nằm ở đâu trong chương trình?

Trả lời ngắn: 7COM1025 Programming for Software Engineers là môn Level 7 tại University of Hertfordshire, giá trị 30 tín chỉ, giảng trong kỳ B. Đây là môn bắt buộc của chương trình MSc Software Engineering, và là môn tự chọn trong MSc Advanced Computer Science. Con số 30 tín chỉ tương đương một phần tư năm học phần giảng dạy, và đó là tín hiệu khá rõ về khối lượng làm việc độc lập mà trường trông đợi phía sau mỗi sản phẩm bạn nộp.

Bằng chứng: Các dữ kiện này lấy từ programme specification mà trường công bố công khai kèm trang giới thiệu chương trình, nơi lập bảng từng môn theo mã, tên, số tín chỉ, học kỳ và trạng thái bắt buộc hay tự chọn. Sự phân biệt này có ý nghĩa thực tế. Nếu bạn học MSc Software Engineering thì không thể né môn này, và nó nằm cùng năm với Measures and Models for Software Engineering cùng Software Engineering Practice and Experience, ba môn được thiết kế để bổ trợ lẫn nhau.

Ví dụ: Ở buổi trao đổi đầu tiên, có bạn tới với tâm thế mình đang bị tụt lại, vì các bạn cùng lớp bàn về đo lường và chỉ số mà bạn chưa học tới. Thật ra bạn không hề tụt lại. Bạn đã mặc định các môn chạy độc lập với nhau, trong khi cấu trúc chương trình xếp chúng vào cùng một kỳ đúng để thuật ngữ của môn này xuất hiện trong bài đánh giá của môn kia.

Có một vấn đề về nguồn mà bạn nên biết trước khi bắt đầu tra cứu. Hertfordshire để Definitive Module Document sau lớp đăng nhập của sinh viên, nên phần lớn thứ đang lưu hành công khai dưới mã môn này đều do các trang bán bài đăng lại, thường là của năm học đã qua. Handbook của chính môn bạn trên Canvas mới là căn cứ duy nhất về đề bài, trọng số và số từ của năm nay.

Vì sao lập trình bậc thạc sĩ được chấm theo cách khác?

Trả lời ngắn: Bởi thứ được chấm không phải chương trình, mà là lập luận của bạn về chương trình đó, thể hiện thông qua chính chương trình. Người chấm ở Level 7 đọc code của bạn như một bản ghi các quyết định, và điểm số bám theo mức độ bạn biện giải, kiểm thử và đánh giá các quyết định ấy, chứ không bám theo tốc độ bạn đưa phần mềm về trạng thái chạy được.

Bằng chứng: Bảng chuẩn đầu ra của chương trình, nơi môn này được xếp vào, nói thẳng điều đó. Trong đó có việc dựng mô hình cho quy trình và sản phẩm phần mềm bằng kỹ thuật mô hình hoá phù hợp, việc áp dụng các phép đo lên quy trình và sản phẩm rồi dùng dữ liệu thu được để đánh giá công việc, và việc đánh giá phản biện các vấn đề nghề nghiệp, xã hội, pháp lý, đạo đức trong thực hành đương đại. Mọi động từ vừa nêu, mô hình hoá, đo lường, đánh giá, đều nằm cao hơn cài đặt. Cơ quan Bảo đảm Chất lượng Giáo dục Đại học Anh mô tả trình độ thạc sĩ theo đúng hướng đó, khi trông đợi tính nguyên bản trong vận dụng tri thức và ý thức phản biện về những vấn đề đang ở tuyến đầu của ngành (QAA, 2024).

Ví dụ: Hai bạn nộp hai lời giải giống nhau về mặt chức năng. Bạn thứ nhất trình bày code kèm một ghi chú ngắn nói rằng nó đáp ứng yêu cầu. Bạn thứ hai kèm một phần biện giải thiết kế ngắn gọn: hai phương án cấu trúc đã cân nhắc, đánh đổi giữa chúng phát biểu bằng ngôn ngữ coupling và khả năng kiểm thử, phương án được chọn cùng lý do, và một đoạn thừa nhận lựa chọn ấy sẽ lỗi thời ở đâu nếu yêu cầu thay đổi theo một hướng có thể lường trước. Khoảng cách điểm giữa hai bạn không phải khoảng cách về kỹ năng lập trình.

Người chấm tìm gì mà sinh viên hay bỏ sót?

Trả lời ngắn: Có bốn thứ, và chúng biến mất theo một trật tự khá dễ đoán. Biện giải lựa chọn thiết kế rơi rụng đầu tiên, đánh giá dựa trên bằng chứng thứ hai, kiểm thử với tư cách một lập luận thứ ba, và phần bàn về giới hạn thì mất sau cùng.

Bằng chứng: Đây không phải sở thích chấm bài của riêng một trường. Parnas (1972) đặt ra tiêu chí rằng module nên được phân rã quanh những quyết định thiết kế cần che giấu, chứ không phải quanh các bước xử lý, và đó là lý do câu "em tách nó ra thành các hàm" yếu hơn hẳn câu "em cô lập những quyết định dễ thay đổi nhất". Martin (2017) diễn đạt lại chính nguyên lý ấy cho thực hành hiện nay qua hướng phụ thuộc và ranh giới. Ở phía kiểm thử, nhiều nghiên cứu thực chứng đã cho thấy độ phủ tự thân nó là chỉ báo kém về khả năng phát hiện lỗi (Inozemtseva & Holmes, 2014), nên báo một con số phần trăm độ phủ mà không diễn giải thì gần như không được tính điểm.

Ví dụ: Một bạn ghi trong tài liệu rằng độ phủ test đạt chín mươi tư phần trăm và tin rằng con số đó tự nói lên chất lượng. Khi được hỏi test nào sẽ hỏng nếu đảo một điều kiện biên duy nhất, bạn phát hiện không test nào hỏng cả. Con số thì chính xác còn lập luận đứng sau nó thì rỗng. Viết lại sáu test để nhắm vào biên khiến độ phủ giảm nhẹ nhưng bài nộp mạnh lên rõ rệt.

Nên bố cục phần báo cáo viết thế nào?

Trả lời ngắn: Hãy coi báo cáo là một lập luận kỹ thuật mà code đóng vai bằng chứng, và chia dung lượng theo đúng chỗ có điểm. Một bố cục đứng vững ở Level 7: đặt vấn đề và diễn giải yêu cầu khoảng 15% số từ, biện giải thiết kế kèm phương án thay thế và đánh đổi khoảng 30%, ghi chú cài đặt chỉ nói những gì code không tự nói được khoảng 15%, phần kiểm chứng gồm chiến lược test và số liệu đo kèm diễn giải khoảng 25%, và đánh giá phản biện kèm giới hạn cùng hướng phát triển khoảng 15%.

Phần lớn bài nộp làm ngược lại. Phần cài đặt phình lên chiếm nửa tài liệu vì đó là phần dễ viết nhất, còn biện giải thiết kế và đánh giá bị nén lại mỗi phần một trang. Hai phần bị nén ấy lại đúng là nơi có các tiêu chí trọng số cao nhất.

Bằng chứng: Chiến lược đánh giá công bố cho chương trình nêu rằng kỹ năng trí tuệ và kỹ năng thực hành được chấm qua bài tập trong kỳ và qua đồ án, và rằng tri thức phải được thể hiện là đã vận dụng trong bối cảnh một khối lượng công việc độc lập đáng kể. Chữ "vận dụng" trong câu đó gánh toàn bộ ý nghĩa. Mô tả code của bạn làm gì thì không phải vận dụng tri thức, còn bảo vệ lý do nó làm theo cách ấy thì có.

Ví dụ: Một bản nháp dài mười bốn trang, trong đó tám trang đi qua từng lớp một của code. Người viết đã mặc định rằng sự tỉ mỉ là đức tính đang được kiểm tra. Cắt tám trang đó còn hai, rồi dùng chỗ trống thu về để nói vì sao tầng lưu trữ được tách riêng và điều gì sẽ vỡ nếu không tách, cho ra một báo cáo ngắn hơn và tốt hơn nhiều.

Còn công cụ AI hỗ trợ viết code thì sao?

Trả lời ngắn: Hãy theo đúng quy định chương trình bạn học và handbook của môn, đồng thời hiểu rằng rủi ro ở môn này là rủi ro học thuật trước khi là rủi ro kỷ luật. Code sinh ra mà bạn không hiểu thì bạn không bảo vệ được, mà môn này chấm chính khả năng bảo vệ.

Bằng chứng: Môn này đóng góp vào một chuẩn đầu ra về đánh giá phản biện các vấn đề nghề nghiệp, xã hội, pháp lý và đạo đức trong thực hành máy tính đương đại, nên câu chuyện dùng công cụ nằm bên trong nội dung môn học chứ không phải chỉ nằm cạnh nó. Nghiên cứu thực chứng về code do trợ lý AI sinh ra ghi nhận tỷ lệ đáng kể kết quả kém an toàn hoặc sai mà lập trình viên vẫn chấp nhận (Perry và cộng sự, 2023), và đó đúng là kiểu hỏng mà người chấm Level 7 dò tới khi họ hỏi vì sao một cấu trúc cụ thể lại có mặt ở đó.

Ví dụ: Được hỏi vì sao lời giải của mình dùng một primitive đồng thời cụ thể, có bạn không trả lời được. Bạn không chọn nó, công cụ chọn, và nó chạy được nên bạn đi tiếp. Dựng lại lập luận mất của bạn một buổi chiều và làm thay đổi phần cài đặt, bởi primitive đó bảo vệ được cho một trong hai tình huống sử dụng và sai với tình huống còn lại.

Sinh viên quốc tế hay mất điểm oan ở đâu?

Trả lời ngắn: Ở phần lập luận viết chứ không phải ở phần lập trình. Các bạn đi lên từ chương trình cử nhân công nghệ thông tin ở Việt Nam thường cài đặt rất chắc tay, rồi lần đầu tiên bị chấm trên một thể loại viết kỹ thuật chưa ai dạy: báo cáo kỹ thuật có rào đón, có bằng chứng, và tự phản biện chính mình.

Bằng chứng: Nhóm chuẩn đầu ra về kỹ năng chuyển đổi của chương trình bao gồm khả năng diễn đạt mạch lạc bằng cả văn bản lẫn lời nói, và khả năng giải thích, biện minh, bảo vệ công việc của mình ở cả chi tiết cụ thể lẫn bối cảnh rộng hơn. Đó là những kỹ năng được chấm chứ không phải phần đánh bóng thêm vào lúc cuối.

Ví dụ: Trong một bài nộp, phần kết luận viết rằng thiết kế "là lời giải tốt nhất cho bài toán này". Khi được hỏi cần bằng chứng nào để chống đỡ một khẳng định mạnh tới vậy, bạn sửa lại thành: thiết kế này ưu việt hơn trong phạm vi các ràng buộc đã nêu, yếu đi nếu khối lượng dữ liệu tăng lên một bậc độ lớn, và chưa được kiểm thử với ghi đồng thời. Bản thứ hai khiêm tốn hơn mà điểm cao hơn, vì người chấm nhìn thấy được đường biên của khẳng định.

Mentor MAAS thật sự làm gì ở môn này?

MAAS làm việc với vai trò cố vấn học thuật. Mentor đọc bản nháp và phần biện giải thiết kế của bạn đối chiếu với chuẩn đầu ra của môn, đặt đúng những câu hỏi mà người chấm sẽ đặt về một quyết định bạn đang coi là hiển nhiên, và chỉ ra chỗ lập luận mới dừng ở mô tả. Bạn tự viết và tự nộp code cùng báo cáo của mình. Với một môn như thế này, trình tự thường đi từ làm rõ đề bài thật ra đang chấm cái gì, sang rà phần biện giải thiết kế trước khi bạn xây quá xa trên nền đó, rồi tới một lượt đọc toàn bộ báo cáo theo cấu trúc với bảng tiêu chí đặt bên cạnh. Chuyện trích dẫn và liêm chính học thuật được xử lý ngay trong lượt đọc ấy chứ không tách thành một dịch vụ riêng.

Câu hỏi thường gặp

Môn 7COM1025 có bắt buộc không?
Còn tuỳ chương trình bạn học. Programme specification công bố công khai xếp môn này là môn bắt buộc kỳ B của MSc Software Engineering và là môn tự chọn trong MSc Advanced Computer Science. Hãy xác nhận lại theo chương trình và năm học của chính bạn, vì danh mục tự chọn có thay đổi.

Môn này bao nhiêu tín chỉ?
Ba mươi tín chỉ ở Level 7, tương đương một phần tư năm học phần giảng dạy của một chương trình thạc sĩ toàn thời gian tiêu chuẩn.

Môn học dùng ngôn ngữ lập trình nào?
Handbook của môn là căn cứ, và ngôn ngữ có thể khác nhau giữa các khoá. Hãy coi mọi ngôn ngữ mà một trang bên thứ ba nêu ra là thông tin chưa kiểm chứng, đồng thời nhớ rằng các kỹ năng được chấm gồm biện giải thiết kế, chiến lược kiểm thử và đánh giá phản biện đều chuyển được qua mọi ngôn ngữ.

Không có kinh nghiệm đi làm thì có học tốt được không?
Được. Người đã đi làm thường vượt lên ở phần cài đặt và tụt lại ở phần biện giải, vì môi trường công việc thưởng cho việc ra được sản phẩm còn môn này thưởng cho việc bảo vệ được lựa chọn. Cuối cùng cả hai nhóm gặp nhau ở cùng một khoảng trống.

Code chiếm bao nhiêu phần trăm điểm?
Trọng số nằm trong handbook của bạn, nhưng cách đặt câu hỏi còn hữu ích hơn con số: ở gần như mọi bài của môn này, code đóng vai bằng chứng cho một lập luận, nên bài nộp đưa ra bằng chứng mà thiếu lập luận là bài đang tự đánh mất điểm.

Bài lập trình có cần trích dẫn tài liệu học thuật không?
Có, ở đúng chỗ tài liệu chi phối một quyết định. Trích một nguyên lý thiết kế hay một nghiên cứu thực chứng để biện minh cho lựa chọn cấu trúc chính là điều tách một báo cáo Level 7 khỏi một bài bậc cử nhân.

Bài liên quan

• Cách viết báo cáo đại học
• Tư duy phản biện trong bài luận đại học
• Hỗ trợ đồ án dữ liệu và lập trình cùng MAAS

Trao đổi với mentor MAAS về môn học của bạn

References

Inozemtseva, L., & Holmes, R. (2014). Coverage is not strongly correlated with test suite effectiveness. In Proceedings of the 36th International Conference on Software Engineering (pp. 435–445). ACM. https://doi.org/10.1145/2568225.2568271

Martin, R. C. (2017). Clean architecture: A craftsman's guide to software structure and design. Prentice Hall.

Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058. https://doi.org/10.1145/361598.361623

Perry, N., Srivastava, M., Kumar, D., & Boneh, D. (2023). Do users write more insecure code with AI assistants? In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (pp. 2785–2799). ACM. https://doi.org/10.1145/3576915.3623157

Quality Assurance Agency for Higher Education. (2024). The frameworks for higher education qualifications of UK degree-awarding bodies. QAA.

Sommerville, I. (2016). Software engineering (10th ed.). Pearson.