Một môn lập trình đầu tiên như INFO1110 trông như thể nó nói về cú pháp, và trong vài tuần đầu thì đúng là như vậy. Rồi phần mô tả môn gọi tên một thứ chẳng phải cú pháp chút nào: mô hình bộ nhớ có địa chỉ. Chính ý niệm đó giúp bạn hiểu vì sao đoạn mã lại hành xử như thế, thay vì chỉ thuộc lòng một mớ khuôn mẫu, và những bạn chưa hình dung được nó vẫn qua được các bài tập đầu rồi tới một tuần nào đó thì thấy chẳng còn gì vào đầu nữa. Dưới đây là cách chuyên gia MAAS phân tích một môn có cấu trúc như vậy.
Tác giả: Ban biên tập MAAS · Hiệu đính bởi mentor chuyên môn của MAAS
Cập nhật: 19/08/2026
Chuyên mục: it-data
Trước tiên, hãy xác nhận bạn đang học INFO1110 của trường nào
Trả lời trực tiếp: Bài viết này mô tả môn INFO1110 Introduction to Programming của University of Sydney, 6 tín chỉ, ở cấp 7 trong Australian Qualifications Framework, do School of Computer Science thuộc Faculty of Engineering giảng dạy, mở ở cả học kỳ 1 lẫn học kỳ 2 năm 2026 tại cơ sở Camperdown và Darlington.
Bằng chứng: Môn không có điều kiện tiên quyết, không có môn song hành và không đòi kiến thức nền, nhưng nó mang một danh sách môn cấm học chồng khá dài: INFO1910, INFO1103, INFO1903, INFO1105, INFO1905 và ENGG1810. Danh sách ấy mới là chi tiết dễ ảnh hưởng tới bạn nhất, bởi vài môn trong đó là môn sinh viên có thể đang định học song song.
Ví dụ: Một bạn đã học xong ENGG1810 tại Faculty of Engineering dự định lấy INFO1110 để ôn lại trước khi vào các môn máy tính năm hai. Kế hoạch đổ ở khâu đăng ký chứ không đổ vì năng lực, và nó khiến bạn ấy mất một học kỳ trong lộ trình.
"Không đòi kiến thức nền" thật ra nghĩa là gì với bạn?
Trả lời trực tiếp: "Không đòi kiến thức nền" nghĩa là INFO1110 bắt đầu từ số không, chứ không có nghĩa cả lớp cũng bắt đầu từ số không. Một môn không tiên quyết sẽ gom chung những bạn đã viết mã từ hồi phổ thông, quen cả IDE (Integrated Development Environment) lẫn CLI (command-line interface), với những bạn chưa từng mở cửa sổ dòng lệnh, và hai nhóm ấy gặp khó theo hai kiểu khác nhau.
Bằng chứng: Nhóm đã có kinh nghiệm thường tới lớp với thói quen thành thục của một ngôn ngữ nào đó và chậm đổi sang quy ước của môn, mà quy ước viết mã ở đây là một chuẩn đầu ra của CS1 được chấm chứ không phải chuyện sở thích. Nhóm chưa có kinh nghiệm thì hay mất thời gian vào chuyện chạy được chương trình, một thứ không xuất hiện trong đề cương nhưng ngốn rất nhiều công trong 2 tuần đầu.
Ví dụ: Một bạn từng làm website thấy mấy tuần đầu quá dễ nên bỏ buổi thực hành, rồi đâm vào phần đệ quy khi chưa có thói quen hỏi và cũng chưa quen ai trong nhóm trợ giảng. Một bạn cùng lớp không có nền thì đi đủ, hỏi liên tục, và về đích trước. Lợi thế ấy có thật ở tuần thứ hai và biến mất vào tuần thứ tám.
Vì sao giữa môn lại khó lên đột ngột?
Trả lời trực tiếp: Vì các khái niệm lập trình phụ thuộc vào nhau chặt chẽ một cách bất thường, nên một lỗ hổng sẽ không nằm yên tại chỗ. Bỏ lỡ chuyện hàm nhận giá trị theo cách nào thì bạn sẽ không thật sự hiểu đệ quy, mà đệ quy lại không phải chủ đề bạn bỏ qua rồi quay lại sau được.
Bằng chứng: Chuyện khó lên đột ngột này là một mô thức đã được ghi nhận chứ không phải khiếm khuyết của riêng ai. Robins (2010), trên tạp chí Computer Science Education, mô tả hiệu ứng quán tính ở rìa vùng học trong các môn CS1 để giải thích vì sao môn lập trình nhập môn cho ra một phân bố điểm bất thường với cả số trượt lẫn số điểm cao đều nhiều hơn phần lớn các môn khác: nắm được một khái niệm sẽ làm những khái niệm liên quan gần trở nên dễ hơn, còn không nắm được thì làm chúng khó hơn, nên những chênh lệch nhỏ ban đầu cứ thế cộng dồn. Ông cũng rà lại nhiều thập niên nghiên cứu và thấy rất ít căn cứ cho ý niệm cũ rằng con người đơn giản là chia thành nhóm hợp lập trình và nhóm không hợp.
Ví dụ: Một bạn không giải thích được điều gì xảy ra với một danh sách khi nó được truyền vào hàm thì 3 tuần sau không gỡ nổi lỗi trong một hàm đệ quy, đúng kiểu thiếu mô hình về cỗ máy mà du Boulay (1986) mô tả. Đệ quy không phải chỗ hỏng. Chỗ hỏng là cái giả định chưa bao giờ được soi lại về việc một hàm nhận được cái gì, và nó đã nằm im ở đó từ tuần thứ tư.
Nên làm gì với chuyện này. Hãy coi mọi điểm mù là việc khẩn cấp chứ không phải thứ để dành bù sau. Ở phần lớn các môn, 1 tuần lơ mơ chỉ khiến bạn mất điểm của tuần đó, còn ở môn này nó lấy đi cả những tuần dựng lên trên nó.
Mô hình bộ nhớ có địa chỉ
Trả lời trực tiếp: Phần mô tả môn xếp nó đứng cạnh kiểu dữ liệu, luồng điều khiển, vòng lặp, hàm và đệ quy, tức là đặt một mô hình tư duy về RAM, về CPU, ngang hàng với các tính năng của ngôn ngữ. Đó là lời đáp cho câu hỏi vì sao đoạn mã lại chạy ra kết quả như vậy, chứ không phải cho câu hỏi phải gõ gì.
Bằng chứng: du Boulay (1986), trên Journal of Educational Computing Research, trình bày những khó khăn mà người mới gặp khi học lập trình, và một khó khăn trung tâm là thiếu một mô hình dùng được về cỗ máy mà chương trình chạy trên đó, viết rằng "the main emphasis is on the notional machine both at the general level of understanding (and misunderstanding) the relationship of the terminal to the computer as such" (du Boulay, 1986, p. 57). Giới nghiên cứu giáo dục lập trình sau này gọi mô hình đó là notional machine, và Sorva (2013) hệ thống hóa lại vai trò của nó trong việc dạy CS1. Không có nó, người học CS1 đang ghi nhớ hành vi của từng cấu trúc theo từng trường hợp, cách này còn hiệu quả cho tới khi số trường hợp nhân lên. Có nó, hành vi trở thành thứ bạn dự đoán được thay vì thứ bạn phải nhớ lại.
Ví dụ: Khi được hỏi vì sao sửa một danh sách bên trong hàm lại ảnh hưởng tới danh sách ở nơi gọi trong bộ nhớ RAM, trong khi gán lại một con số thì không, một bạn trả lời rằng danh sách là kiểu đặc biệt. Đó là một trường hợp đã thuộc. Câu trả lời mạnh hơn nói về việc cái tên đang trỏ tới đâu và thứ gì thật sự được truyền đi, và cách lý giải ấy vừa giải thích được hành vi đó vừa dự đoán được vài hành vi khác mà bạn ấy chưa gặp.
| Môn học chấm gì | Nó trông ra sao khi làm đúng | Chỗ sinh viên làm chưa tới |
|---|---|---|
| Quy ước viết mã | Đoạn mã mà người chấm đọc không mệt | Coi quy ước là chuyện trang trí |
| Thiết kế thuật toán | Có một kế hoạch trước khi có dòng mã nào | Gõ trước rồi thiết kế bằng cách thử |
| Dựng chương trình và dùng kiểu dữ liệu | Chọn đúng cấu trúc cho đúng việc | Dùng danh sách cho mọi thứ |
| Đệ quy | Tin vào lời gọi đệ quy | Cố lần từng tầng trong đầu |
| Kiểm thử và gỡ lỗi | Tự tìm ra lỗi của mình một cách có hệ thống | Sửa từng dòng cho tới khi kết quả trông đúng |
Vì sao quy ước viết mã lại bị đem ra chấm?
Trả lời trực tiếp: Vì danh sách chuẩn đầu ra, gần với khung chương trình mà Association for Computing Machinery (ACM), cùng với Institute of Electrical and Electronics Engineers (IEEE), đề xuất cho CS1, liệt kê quy ước viết mã như một năng lực riêng, đứng cạnh thiết kế thuật toán và những năng lực còn lại. Ở một môn đông như thế này, người chấm đọc lập luận của bạn thông qua đoạn mã, mà mã khó đọc thì che mất chuyện lập luận có chắc hay không.
Bằng chứng: Quy ước ở đây nghĩa là những chuẩn mà môn học dạy chứ không phải sở thích cá nhân: tên gọi nói rõ thứ đó là gì, hàm làm đúng một việc, cấu trúc khớp với bài toán. Các bạn đi lên từ con đường tự học thường mang theo thói quen vốn ổn khi làm một mình nhưng hỏng ngay khi có người khác phải đọc theo.
Ví dụ: Hai bài nộp cùng giải đúng một đề. Một bài đặt tên biến bằng chữ cái đơn từ đầu tới cuối và gói tất cả vào một hàm dài bốn mươi dòng. Người chấm xác nhận được kết quả nhưng không xác nhận được phần thiết kế, và điểm phản ánh đúng chuyện đó. Bạn còn lại giải không hề tinh tế hơn nhưng làm cho phần thiết kế đọc được, mà đây là một kỹ năng khác với kỹ năng làm cho nó chạy và được chấm riêng.
Cách tự kiểm. Hãy đọc lại mã của chính bạn sau 1 tuần mà không chạy nó. Nếu bạn không theo nổi thì người chấm cũng không, và chính bạn cũng sẽ không theo nổi trong phòng thi khi bị yêu cầu sửa nó dưới áp lực thời gian.
Thiết kế thuật toán đi trước việc gõ
Trả lời trực tiếp: Danh sách chuẩn đầu ra tách việc thiết kế thuật toán khỏi việc dựng chương trình, và sự tách bạch ấy là một chỉ dẫn thực hành. Bước thiết kế diễn ra ở chỗ rời bàn phím, bằng lời, bằng giả mã, hoặc bằng một sơ đồ khối kiểu UML (Unified Modeling Language) trên giấy, và đó mới là nơi phần lớn cái khó của một đề bài thật sự nằm.
Bằng chứng: Nghiên cứu đa quốc gia của McCracken và cộng sự (2001) cho sinh viên năm nhất ở nhiều trường cùng làm một đề, và phần lớn không tự thiết kế được lời giải dù viết mã ổn, đúng khoảng cách mà bước tách bạch này của môn đang cố thu hẹp. Phần mô tả môn đặt kỹ năng này là chuyển các bài toán thực tế thành lời giải tính toán được. Chữ chuyển hàm ý hai cách biểu diễn: bài toán như đề nêu, và bài toán như một thứ cỗ máy thực thi được. Những bạn gõ ngay lập tức là đang làm cả phần chuyển đổi lẫn phần dựng cùng lúc, nên đoạn mã của họ cứ trôi dần khỏi đích.
Ví dụ: Với một đề về xử lý bản ghi, một bạn gõ mã suốt 20 phút, xoá đi, rồi gõ một đoạn khác. Một bạn cùng lớp dành 5 phút viết bốn bước bằng câu văn thường rồi cài đặt trong 15 phút. Bạn thứ hai không gõ nhanh hơn. Bạn ấy đã tách ra hai bài toán mà bạn thứ nhất đang giải cùng một lúc.
Kiểm thử và gỡ lỗi là nội dung, không phải việc vặt
Trả lời trực tiếp: Phần mô tả môn nêu rõ năng lực về các thực hành phát triển phần mềm, trong đó có kiểm thử và gỡ lỗi, là một phần của thứ môn học rèn ra. Đây là những kỹ năng được dạy và có phương pháp, chứ không phải phần đuôi hành chính của việc viết mã.
Bằng chứng: Gỡ lỗi bằng cách thu hẹp có hệ thống nghĩa là đặt một giả thuyết về chỗ chứa lỗi, thiết kế phép quan sát nhỏ nhất đủ để xác nhận hoặc loại bỏ giả thuyết ấy, rồi lặp lại. Gỡ lỗi bằng cách sửa tới khi kết quả trông đúng là một hoạt động khác hẳn mà tình cờ mang chung một cái tên, và nó cho ra đoạn mã qua được ví dụ mẫu rồi trượt bộ kiểm thử của người chấm.
Ví dụ: Một bạn có hàm chạy sai với đầu vào rỗng đã sửa ba dòng và làm ví dụ mẫu chạy được. Bạn ấy không bao giờ biết trong ba dòng đó dòng nào mới là dòng có ý nghĩa, nên đúng lỗi ấy quay lại ở bài sau dưới một lớp vỏ khác.
Hãy viết bài kiểm thử trước khi sửa lỗi, đúng tinh thần TDD (test-driven development) mà Beck (2002) hệ thống hóa thành một phương pháp làm việc. Một bài kiểm thử trượt vì một lý do bạn đã biết rồi sau đó chạy qua sẽ cho bạn biết mình vừa thay đổi điều gì, còn một kết quả trông đỡ hơn thì gần như không nói lên điều gì cả.
Cùng một kỷ luật ấy đi tiếp sang các môn dữ liệu về sau, nơi một câu truy vấn chạy trơn tru vẫn có thể trả lời sai câu hỏi. Bài hướng dẫn INFO20003 Database Systems đi qua kiểu hỏng đó cùng nghiên cứu đã phân tích hơn 33.000 câu truy vấn SQL của sinh viên.
Sáu việc đáng làm ở môn này
- Kiểm danh sách môn cấm học chồng trước khi đăng ký, nhất là nếu bạn đã học ENGG1810 hoặc bất kỳ môn INFO19xx nào.
- Đi buổi thực hành trong 3 tuần đầu kể cả khi thấy dễ, vì đó là lúc việc hỏi còn rẻ.
- Đẩy mọi chỗ chưa hiểu lên ngay trong tuần nó xuất hiện. Khái niệm ở đây cộng dồn, nên việc để chậm không hề trung tính.
- Với mỗi cấu trúc, hãy hỏi trong bộ nhớ đang có gì thay vì hỏi kết quả in ra là gì. Câu hỏi ấy là xương sống của cả môn.
- Tập giải thích đoạn mã thành lời mà không chạy nó. Nếu bạn không dự đoán được hành vi thì bạn đang nhớ lại chứ chưa mô hình hoá.
- Học lấy một phương pháp gỡ lỗi có hệ thống rồi dùng nó ngay cả khi đoán mò thì nhanh hơn. Chính thói quen ấy mới là thứ đi theo bạn về sau.
Câu hỏi thường gặp
Học INFO1110 có cần biết lập trình trước không?
Không. Trang môn học của University of Sydney, cấp 7 trong AQF, ghi không có điều kiện tiên quyết và không đòi kiến thức nền. Hãy chuẩn bị tinh thần là lớp sẽ rất chênh lệch, và cũng hãy chuẩn bị tinh thần rằng kinh nghiệm sẵn có ít quan trọng hơn vẻ ngoài của nó sau 1 tháng đầu.
Những môn nào bị cấm học chồng với INFO1110?
Danh sách công bố tại University of Sydney, School of Computer Science, ghi rõ gồm INFO1910, INFO1103, INFO1903, INFO1105, INFO1905 và ENGG1810. Hãy đối chiếu với lộ trình đăng ký của bạn trước khi lên kế hoạch, vì quy định cấm chặn ở khâu đăng ký bất kể bạn dự định thế nào.
Vì sao bài này không nêu tỷ lệ chấm điểm?
Trang môn học của University of Sydney không công bố chúng, và chúng được ấn định trong đề cương của từng học kỳ. Một tỷ lệ trích từ kỳ khác sẽ trông đáng tin trong khi lại sai với bạn, và vì điểm môn này góp thẳng vào WAM (Weighted Average Mark) của bạn, nên hãy lấy tỷ lệ từ đề cương của chính mình.
Tôi dùng trợ lý AI để viết mã được không?
Bất kể từng bài đánh giá của INFO1110, môn cấp 7 trong AQF, cho phép tới đâu, môn học đang kiểm tra xem bạn có thiết kế, dự đoán và gỡ lỗi được hay không, mà đoạn mã do một LLM (large language model) viết ra nhưng bạn không tự lập luận lại thì không rèn được những thứ đó. Hãy đọc đề cương của chính bạn để biết điều gì được phép, và hãy coi bất cứ đoạn nào bạn không giải thích được từng dòng là đoạn chưa thuộc về mình.
Đệ quy có thật sự khó tới thế không?
Nó khó khi phần nền bên dưới còn lung lay, đúng như hiệu ứng quán tính ở rìa vùng học mà Robins (2010) mô tả, mà đó thường là chuyện đã xảy ra. Nếu đệ quy mãi không vào, hãy kiểm xem bạn đã nói được chính xác một hàm nhận cái gì và trả về cái gì hay chưa.
MAAS đứng ở đâu trong việc này
Chuyên gia MAAS làm việc cùng sinh viên ở những môn như INFO1110 tại University of Sydney, chứ không làm thay. Với môn lập trình đầu tiên, việc hữu ích nhất mà người đồng hành làm được là từ chối nhìn vào kết quả trước: hỏi bạn đã trông đợi điều gì xảy ra và vì sao, cho tới khi khoảng cách giữa mô hình trong đầu bạn với hành vi thật của máy hiện ra. Chính khoảng cách ấy là thứ cả môn học nói về. Bài làm vẫn là của bạn. Nếu điều đó hữu ích, dịch vụ gia sư và dịch vụ dự án dữ liệu và lập trình của MAAS là hai chỗ để bắt đầu.
References
Beck, K. (2002). Test-driven development: By example. Addison-Wesley.
du Boulay, B. (1986). Some difficulties of learning to program. Journal of Educational Computing Research, 2(1), 57–73. https://doi.org/10.2190/3LFX-9RRF-67T8-UVK9
McCracken, M., Almstrum, V., Diaz, D., Guzdial, M., Hagan, D., Kolikant, Y. B.-D., Laxer, C., Thomas, L., Utting, I., & Wilusz, T. (2001). A multi-national, multi-institutional study of assessment of programming skills of first-year CS students. ACM SIGCSE Bulletin, 33(4), 125–140. https://doi.org/10.1145/572139.572181
Robins, A. (2010). Learning edge momentum: A new account of outcomes in CS1. Computer Science Education, 20(1), 37–71. https://doi.org/10.1080/08993401003612167
Sorva, J. (2013). Notional machines and introductory programming education. ACM Transactions on Computing Education, 13(2), Article 8. https://doi.org/10.1145/2483710.2483713
Tools & resources
The University of Sydney. (2026). INFO1110: Introduction to Programming. https://www.sydney.edu.au/units/INFO1110