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

Trả lời thẳng: Ở môn 7COM1025, code chạy được vẫn có thể bị điểm thấp vì người chấm Level 7 không chấm chương trình mà chấm phán đoán kỹ thuật đứng sau nó, tức bạn đã chọn gì, đã loại bỏ gì và bằng chứng nào cho thấy lựa chọn đó hợp lý. Code chạy đúng chỉ là vạch xuất phát, nên báo cáo lẫn code của bạn đều phải bảo vệ được lựa chọn kỹ thuật.

Khoảnh khắc gây hoang mang nhất của môn này là lúc một bài nộp biên dịch trơn tru, chạy đúng và qua hết test mà điểm trả về chỉ nằm ở nhóm giữa. Người từng đi làm lập trình thấy khó chịu nhất, vì tiêu chuẩn họ mang theo là code chạy được, trong khi môn này coi đó là vạch xuất phát chứ không phải vạch đích.

Bài viết giúp bạn chuyển trọng tâm từ viết code sang bảo vệ lựa chọn kỹ thuật, để phần báo cáo và phần code của bạn cùng ghi điểm ở đúng những tiêu chí người chấm Level 7 đang tìm. Bạn sẽ thấy người chấm đọc bài theo cách nào, nên chia dung lượng báo cáo ra sao, và những chỗ du học sinh Việt hay mất điểm không đáng có.

Tác giả: Ban Biên tập MAAS
Cập nhật lần cuối: 2026-08-10
Chuyên mục: it-data

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

Trả lời trực tiếp: 7COM1025 Programming for Software Engineers là môn Level 7 tại University of Hertfordshire, giá trị 30 tín chỉ, giảng ở Semester B. Môn này bắt buộc trong MSc Software Engineering và là môn tự chọn trong MSc Advanced Computer Science. Với 30 tín chỉ, môn chiếm một phần tư năm học phần giảng dạy, và con số đó cho thấy khối lượng làm việc độc lập mà trường trông đợi sau mỗi sản phẩm bạn nộp.

Các dữ kiện này lấy từ programme specification, tức bản mô tả chương trình mà trường công bố công khai kèm trang giới thiệu khoá học, nơi từng môn được lập bảng 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 bắt buộc hay tự chọn có ý nghĩa thực tế. Nếu học MSc Software Engineering, bạn không thể né môn này, và nó nằm cùng năm với hai môn Measures and Models for Software Engineering và Software Engineering Practice and Experience, ba môn được thiết kế để bổ trợ lẫn nhau.

Ở buổi trao đổi đầu tiên, một sinh viên tin rằng mình đang tụt lại, vì các bạn cùng lớp bàn về đo lường và chỉ số (metrics) mà bạn ấy chưa học tới. Thật ra sinh viên đó không hề tụt lại, mà chỉ 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ỳ chính là để thuật ngữ của môn này xuất hiện trong bài đánh giá của môn kia. Sommerville (2016) cũng coi đo lường và đánh giá là một hoạt động kỹ thuật liền mạch chứ không phải hai việc tách rời.

Có một vấn đề về nguồn mà bạn nên biết trước khi bắt đầu tra cứu. University of Hertfordshire để Definitive Module Document, tức tài liệu mô tả môn chính thức, sau lớp đăng nhập của sinh viên, nên phần lớn tài liệu đang lưu hành công khai dưới mã môn này do các trang bán bài đăng lại, và thường là tài liệu của một 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 trực tiếp: Vì 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 qua chính chương trình đó. Người chấm Level 7 đọc code như một bản ghi các quyết định, và điểm số bám theo mức độ những quyết định ấy được biện giải, kiểm thử và đánh giá, chứ không bám theo tốc độ phần mềm đạt tới trạng thái chạy được.

Cách nhìn này khớp với định nghĩa của Sommerville (2016), khi ông coi kỹ thuật phần mềm là một ngành đặt quy trình lên trên sản phẩm cuối cùng.

Chuẩn đầu ra của chương trình mà môn này được gắn vào nói rõ sự chuyển dịch đó. Trong đó 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, á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à đá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 hiện nay. Mọi động từ vừa nêu, gồm mô hình hoá, đo lường và đánh giá, đều nằm cao hơn cài đặt. Quality Assurance Agency for Higher Education (QAA), cơ quan bảo đảm chất lượng giáo dục đại học của Anh, mô tả trình độ thạc sĩ theo cù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).

Có hai sinh viên nộp hai lời giải giống hệt nhau về chức năng. Sinh viên thứ nhất trình bày code kèm một ghi chú ngắn rằng nó đáp ứng yêu cầu. Sinh viên thứ hai kèm một phần biện giải thiết kế ngắn, nêu hai phương án cấu trúc đã cân nhắc, phát biểu đánh đổi giữa chúng bằng ngôn ngữ coupling (mức phụ thuộc giữa các thành phần) và khả năng kiểm thử, chọn một phương án kèm lý do, rồi thêm một đoạn thừa nhận lựa chọn đó sẽ kém đ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 người không nằm ở kỹ năng lập trình mà ở kiểu lập luận quanh các quyết định thiết kế cần che giấu, đúng điều Parnas (1972) cho rằng phải dẫn dắt việc chia hệ thống thành module ngay từ đầu.

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

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

Việc biện giải và đánh giá được đặt cao hơn bản thân code chạy được không phải sở thích chấm bài của riêng một trường. Parnas (1972) nêu thẳng mục đích bài báo của mình: "This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time" (p. 1053). Từ mục đích đó, ông đặt ra tiêu chí rằng module nên được chia 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 nguyên lý này cho thực hành hiện nay qua hướng phụ thuộc và ranh giới giữa các thành phần, còn Sommerville (2016) coi chính phần biện giải ấy, chứ không riêng code chạy được, là sản phẩm mà một quy trình kỹ thuật phần mềm phải tạo ra. Ở phía kiểm thử, Inozemtseva và Holmes (2014) cho thấy độ phủ (coverage) tự nó là một chỉ báo kém về khả năng phát hiện lỗi, 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.

Một sinh viê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ố ấy 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 ấy 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. Sau khi viết lại sáu test để nhắm vào giá trị biên, độ phủ giảm nhẹ nhưng bài nộp mạnh lên rõ rệt, đúng khoảng cách giữa con số độ phủ và khả năng phát hiện lỗi mà Inozemtseva và Holmes (2014) đã đo được.

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

Trả lời trực tiếp: 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, đúng tinh thần Sommerville (2016), và chia dung lượng theo chỗ có điểm. Một bố cục đứng vững ở Level 7 dành khoảng 15% số từ cho đặt vấn đề, khoảng 30% cho biện giải thiết kế, khoảng 15% cho ghi chú cài đặt, khoảng 25% cho kiểm chứng và khoảng 15% cho đánh giá phản biện.

Nói cụ thể hơn, phần đặt vấn đề chiếm 15% là nơi bạn diễn giải yêu cầu của đề. Phần biện giải thiết kế chiếm 30% nêu các phương án thay thế và đánh đổi giữa chúng. Phần ghi chú cài đặt chỉ nói những gì code không tự nói được. Phần kiểm chứng chiếm 25% gồm chiến lược kiểm thử và số liệu đo, kèm diễn giải kết quả. Phần cuối nêu giới hạn của thiết kế và hướng làm tiếp.

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 chỉ còn một trang. Hai phần bị nén ấy lại là nơi có các tiêu chí giá trị cao nhất, tức phần biện giải thiết kế mà Parnas (1972) bàn tới và phần kiểm thử như một lập luận mà Inozemtseva và Holmes (2014) mô tả, mỗi nguồn nhìn từ một góc.

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 các bài tập trong kỳ và qua project, và 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 phần lớn ý nghĩa. Mô tả code của bạn làm gì chưa phải vận dụng tri thức, còn bảo vệ lý do nó làm theo cách ấy thì đúng là vận dụng, và đó cũng là chuẩn vận dụng tri thức mà QAA (2024) đặt ra cho trình độ thạc sĩ.

Một bản nháp dài mười bốn trang có tám trang đi qua code từng lớp một, vì người viết mặc định rằng sự tỉ mỉ là thứ đang được kiểm tra. Khi sinh viên đó cắt tám trang ấy xuống còn hai, rồi dùng chỗ trống thu về để giải thích vì sao tầng lưu trữ (persistence layer) được tách riêng và điều gì sẽ vỡ nếu không tách, bản báo cáo ngắn hơn mà tốt hơn hẳn. Đó cũng là kiểu lập luận về ranh giới và hướng phụ thuộc mà Martin (2017) coi là mục đích của một kiến trúc được thiết kế tốt.

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

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

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 hiện nay, nên câu hỏi về cách dùng công cụ nằm bên trong nội dung môn học chứ không chỉ nằm cạnh nó. Perry và cộng sự (2023) ghi nhận rằng code do trợ lý AI sinh ra có 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. Đó chính 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 trong bài.

Khi được hỏi vì sao lời giải của mình dùng một primitive đồng thời (công cụ đồng bộ hoá khi nhiều luồng chạy cùng lúc) cụ thể, một sinh viên không trả lời được. Bạn ấy không chọn nó mà công cụ AI chọn, và vì code chạy được nên sinh viên đó đi tiếp. Việc dựng lại lập luận mất của bạn ấy một buổi chiều và làm thay đổi phần cài đặt, vì 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. Đây là cùng một mẫu hình chấp nhận mà không hiểu mà Perry và cộng sự (2023) tìm thấy trên một mẫu lớn lập trình viên dùng trợ lý AI.

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

Trả lời trực tiếp: Chủ yếu ở phần lập luận viết chứ không phải ở phần lập trình. Du học sinh đ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 bị chấm trên một thể loại chưa ai dạy họ, là báo cáo kỹ thuật có rào đón, có bằng chứng và tự phản biện mà khung QAA (2024) trông đợi ở trình độ thạc sĩ.

Nhóm chuẩn đầu ra về kỹ năng chuyển đổi (transferable skills) của chương trình bao gồm khả năng diễn đạt mạch lạc bằng văn viết 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ả mức chi tiết lẫn trong bối cảnh rộng hơn. Đây là những kỹ năng được chấm điểm riêng, không phải phần đánh bóng thêm vào lúc cuối, và QAA (2024) cũng xếp năng lực giải thích và bảo vệ công việc vào phần cốt lõi của trình độ thạc sĩ.

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, sinh viên đó sửa lại thành một câu khác hẳn. Câu mới nói rằng thiết kế này tốt hơn trong phạm vi các ràng buộc đã nêu, sẽ 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 thao tác 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. Đó là tính nguyên bản trong vận dụng tri thức mà QAA (2024) dùng để mô tả trình độ thạc sĩ.

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 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ức mô tả. Bạn tự viết và tự nộp code cũng như báo cáo của mình, MAAS không viết code thay bạn. 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 điều 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 cấu trúc toàn bộ báo cáo với bảng tiêu chí đặt bên cạnh. Các câu hỏi về trích dẫn và liêm chính học thuật được xử lý ngay trong lượt đọc ấy, 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 cho thấy môn này học ở Semester B, bắt buộc với MSc Software Engineering, còn với MSc Advanced Computer Science thì chỉ là một lựa chọn. Hãy xác nhận lại trạng thái của môn theo chương trình và năm học của chính bạn, vì danh mục môn tự chọn có thay đổi, và hãy dùng handbook hiện hành thay vì một trang chia sẻ tài liệu, vì Definitive Module Document của Hertfordshire nằm sau lớp đăng nhập của sinh viên.

Môn này bao nhiêu tín chỉ?
30 tín chỉ ở Level 7, tương đương một phần tư năm học phần giảng dạy trong cấu trúc 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. 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ữ, đúng với lối lập luận thiết kế không phụ thuộc ngôn ngữ mà cả Parnas (1972) lẫn Martin (2017) đều bàn tới.

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 nhưng 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. Đó cũng là bước chuyển từ viết code sang làm kỹ thuật một quy trình mà Sommerville (2016) mô tả. 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 hữu ích hơn con số phần trăm. Ở 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 bằng chứng ra mà thiếu lập luận là bài đang tự bỏ lỡ điểm, giống khoảng trống giữa độ phủ và diễn giải mà Inozemtseva và Holmes (2014) ghi nhận riêng cho kiểm thử.

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ế như information hiding (che giấu thông tin) của Parnas (1972), hay một nghiên cứu thực chứng về độ phủ như của Inozemtseva và Holmes (2014), để biện minh cho một 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ợ dự á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. https://www.qaa.ac.uk/docs/qaa/quality-code/the-frameworks-for-higher-education-qualifications-of-uk-degree-awarding-bodies-2024.pdf

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