Assignment lớn của COSC2081 không phải là bài kiểm tra xem bạn thuộc bao nhiêu cú pháp Java, mà là bài kiểm tra bạn có biến được một đề bài dài mấy trang thành một hệ thống class chạy được, rồi đứng trước camera giải thích vì sao mình thiết kế như vậy. Nếu bạn đang nhìn đề mà chưa biết bắt đầu từ class nào thì bạn không hề đơn độc, gần như cả lớp đang ở đúng chỗ đó. Bài này dẫn bạn đi từ cấu trúc đề tới ngày nộp, dựa trên chính các bản spec mà những kỳ trước để lại.
Cấu trúc đề: 3 phần, các kỳ trước nặng khoảng 40%
Theo course guide các kỳ trước, assignment lớn của môn chiếm khoảng 40% tổng điểm và được chấm trên 3 phần tách bạch:
- Thiết kế và triển khai OOP: hệ thống class có kế thừa, đóng gói, đa hình dùng đúng chỗ, thay vì một file Main khổng lồ chứa mọi thứ.
- Problem solving: chương trình giải đúng bài toán trong đề, đọc dữ liệu, xử lý các thao tác nghiệp vụ và trả kết quả chính xác.
- Video demo dưới 10 phút: bạn trình bày phần phân tích và thiết kế của mình, sau đó chạy demo chương trình hoạt động thật.
Trọng số và cấu hình assessment có thể đổi theo kỳ, nên mở course guide trên Canvas của đúng kỳ bạn học để đối chiếu trước khi phân bổ thời gian.
Điều đáng chú ý nằm ở tỷ lệ ngầm: code chạy đúng chỉ là một trong ba phần. Hai phần còn lại (thiết kế OOP và video giải thích) chấm cách bạn tư duy, và đó mới là chỗ tách band điểm giữa các bài cùng chạy được.
- Nên: đọc mục chấm điểm của cả 3 phần trước khi viết dòng code đầu tiên, rồi lên lịch ngược từ deadline: chốt thiết kế, chốt code, chốt video.
- Không nên: dồn hết thời gian cho code rồi quay video vào đêm cuối. Video dưới 10 phút phải gói cả phân tích, thiết kế lẫn demo, nghĩa là cần kịch bản viết sẵn chứ không ứng khẩu được.
Kịch bản đổi mỗi kỳ, bộ xương thì không
Đề môn này xoay kịch bản theo kỳ, nên nhiều bạn kết luận vội rằng kinh nghiệm và bài mẫu kỳ trước vô dụng. Nhìn hai đề có thật sẽ thấy điều ngược lại:
- Kỳ 2021B: xây tool phân tích dữ liệu COVID-19 dạng text chạy trên console, đọc file CSV của WHO. Spec yêu cầu đúng 3 nhóm hierarchy: Data objects quản lý khu vực địa lý và khoảng thời gian, Summary objects lo việc nhóm dữ liệu và tính toán chỉ số, và Display objects hiển thị kết quả dạng bảng cùng biểu đồ vẽ bằng dấu sao trong khung 24x80 ký tự.
- Kỳ 2023B: assignment nhóm 4 người, xây Container Port Management System: quản lý cảng (tên, vị trí, sức chứa), phương tiện (mã, loại, trọng tải chở), container (mã, cân nặng, mức tiêu thụ nhiên liệu), tất cả thao tác qua giao diện dòng lệnh.
Hai bối cảnh nghe chẳng liên quan gì nhau, nhưng bộ xương giống nhau tới mức gọi tên được: một nhóm entity cần thêm, sửa, xóa, xem + một hệ thống hierarchy OOP + video demo + contribution log. Đề kỳ bạn học gần như chắc chắn là một biến thể mới của đúng bộ xương này, chỉ thay bối cảnh. Vì vậy:
- Làm đúng: học cái khung từ các repo công khai kỳ trước (cách tách class, tổ chức package, dựng menu console) rồi tự áp vào kịch bản của kỳ mình.
- Làm sai: đi tìm code trùng kịch bản để sửa lại cho nhanh. Thứ nhất, kịch bản xoay vòng nên hiếm khi trùng. Thứ hai, code bị so trùng theo cấu trúc, đổi tên biến không thoát được.
Ràng buộc kỹ thuật: đọc spec như đọc hợp đồng
Spec kỳ 2021B liệt kê một loạt ràng buộc mà kỳ nào cũng có bạn mất điểm oan vì bỏ qua, dù chúng in ngay trong đề:
- Không dùng thư viện ngoài. Chỉ Java chuẩn (kỳ đó là Java 16). Kéo một thư viện đọc CSV về cho tiện là tự nộp bằng chứng phạm quy.
- Code theo Google Java Style, làm trên IntelliJ, chương trình khởi chạy từ đúng một file Main.java.
- README phải kèm link GitHub repo và link YouTube của video demo.
- Bảng phân bổ đóng góp (contribution allocation) phải cân về 0: mỗi thành viên ghi mức cộng trừ so với chia đều, tổng cả nhóm phải bằng 0. Muốn ghi nhận một bạn gánh nhiều hơn thì phải có bạn nhận phần trừ tương ứng, và cả nhóm cùng ký vào một câu chuyện thống nhất.
- Nộp đúng một file zip duy nhất.
Chi tiết ràng buộc có thể đổi theo kỳ, nhưng tinh thần rất bền: người chấm muốn mở được bài của bạn theo một quy trình duy nhất và chấm ngay, không phải dò tìm file hay đoán cách chạy.
- Nên: biến từng gạch đầu dòng trong spec thành checklist nộp bài, và tick xong toàn bộ trước deadline 2 ngày.
- Không nên: để việc quay video, viết README và họp chốt contribution sang ngày cuối, vì cả ba việc này cần đủ mặt cả nhóm, mà ngày cuối luôn là ngày khó gom quân nhất.
Thiết kế OOP ăn điểm: từ danh từ trong đề tới hierarchy
Phần thiết kế là nơi người chấm phân biệt bài hiểu OOP với bài chỉ chạy được. Quy trình tụi mình hay hướng dẫn:
- Gạch chân danh từ lặp lại trong đề. Ở đề 2023B, các danh từ cảng, phương tiện, container lặp đi lặp lại: đó chính là các class gốc của hệ thống.
- Nhóm danh từ có chung thuộc tính để tìm lớp cha. Nhiều loại phương tiện cùng có mã, loại và trọng tải thì lớp phương tiện xứng đáng là lớp cha, các loại cụ thể là lớp con với hành vi riêng.
- Chạy được một lát mỏng trước. Menu console hiện ra, thêm và xem được một entity là cột mốc đầu tiên, sau đó mới mở rộng từng chức năng. Đừng viết 500 dòng rồi mới bấm Run lần đầu.
- Commit đều tay nếu làm việc trên Git. Lịch sử commit đều đặn vừa là bằng chứng tiến độ, vừa là bằng chứng bạn tự làm nếu có tranh chấp đóng góp về sau.
Khi viết README hoặc kịch bản video, mỗi quyết định thiết kế nên phát biểu theo mẫu: quyết định, lý do, lợi ích. Một câu mẫu bạn có thể chỉnh lại cho bài mình:
Tụi mình tách lớp phương tiện thành lớp cha trừu tượng với các lớp con cụ thể, vì các loại phương tiện dùng chung dữ liệu định danh và trọng tải nhưng khác nhau ở cách tính toán, nhờ vậy thêm một loại phương tiện mới không phải sửa code cũ.
- Viết đúng: giải thích vì sao chọn kế thừa ở chỗ này, interface ở chỗ kia, gắn trực tiếp với yêu cầu cụ thể trong đề.
- Viết sai: liệt kê định nghĩa lý thuyết (kế thừa là gì, đa hình là gì) mà không chỉ vào một dòng code nào của chính mình.
Video demo dưới 10 phút: kịch bản 3 màn
Giới hạn dưới 10 phút cho cả phân tích, thiết kế lẫn demo nghĩa là mỗi phút đều phải có việc. Một khung chia thời gian hợp lý:
- Màn 1, khoảng 2 phút: bài toán là gì và kiến trúc tổng thể: các nhóm class chính cùng quan hệ giữa chúng, trình bày trên đúng một sơ đồ.
- Màn 2, khoảng 3 phút: hai tới ba quyết định thiết kế quan trọng nhất, nói theo mẫu quyết định, lý do, lợi ích ở trên.
- Màn 3, khoảng 4 phút: demo chạy thật các chức năng chính theo một kịch bản người dùng, kèm một trường hợp nhập sai để cho thấy chương trình xử lý được input lỗi.
Câu mở video bạn có thể dùng làm đà: 'Chương trình của tụi mình giải bài toán X bằng ba nhóm class chính; trước khi demo, mình xin đi qua sơ đồ thiết kế trong một phút.'
- Làm đúng: quay màn hình chương trình chạy thật, nói theo kịch bản đã viết, bấm giờ chạy thử trước ít nhất một lần.
- Làm sai: đọc slide lý thuyết 8 phút rồi demo vội 1 phút cuối, hoặc quay đúng một lần duy nhất vào đêm nộp rồi phát hiện vượt giới hạn thời gian.
Academic integrity với code
Code cũng qua máy so trùng như essay, và các vụ bị đưa ra hội đồng ở môn này đa số không phải vì chép toàn bộ, mà vì mượn một đoạn của bạn cùng lớp rồi đổi tên biến. Máy so cấu trúc, không so tên. Ranh giới an toàn: thảo luận hướng giải thì được, nhìn code của nhau thì không; dùng đoạn code từ tài liệu môn học thì ghi nguồn trong comment. Ngưỡng an toàn về trùng lặp tụi mình đã viết kỹ trong bài Turnitin bao nhiêu phần trăm là đạt, tinh thần áp dụng cho code y hệt.
Nếu bạn đã tự viết được chương trình nhưng không chắc thiết kế OOP đủ chuẩn (tách class hợp lý chưa, kế thừa đúng chỗ chưa, kịch bản video đã thuyết phục chưa), tụi mình nhận review và góp ý bài trước khi nộp. Chi tiết ở bảng báo giá của 7 Writing Service nhé.
Câu hỏi thường gặp
Đề kỳ mình khác hẳn các ví dụ trong bài, hướng dẫn này còn dùng được không?
Dùng được, vì môn xoay kịch bản chứ không xoay khung. Từ tool phân tích COVID kỳ 2021B tới hệ thống quản lý cảng container kỳ 2023B, bộ xương vẫn là một nhóm entity cần quản lý, một hierarchy OOP, một video demo và một contribution log. Học cái khung, rồi áp bối cảnh mới của kỳ mình vào.
Nhóm có bạn không làm gì thì contribution allocation ghi sao?
Cơ chế cân về 0 tồn tại đúng cho tình huống này: bạn gánh nhiều nhận mức cộng, bạn làm ít nhận mức trừ, tổng bằng 0 và cả nhóm cùng xác nhận. Đừng đợi tới ngày nộp mới đàm phán; chốt nguyên tắc chia từ tuần đầu, giao việc có tên người nhận, và giữ lịch sử commit làm bằng chứng khách quan nếu cần đối chiếu.
Chương trình còn lỗi, có nên nộp không?
Nên. Bài được chấm trên cả thiết kế OOP, problem solving lẫn video demo, nên một chương trình chạy được phần lớn chức năng kèm thiết kế sạch vẫn có điểm đáng kể, còn không nộp là mất tất cả. Nộp bản tốt nhất đang có, demo phần chạy được, và nói thẳng trong video phần nào chưa hoàn thiện cùng hướng bạn định sửa.
Cần hỗ trợ 1-1 cho môn này? Xem bảng giá và quy trình nhận hỗ trợ của 7 Writing Service.