Thử thách JPA 5 tuần tự mình tái hiện, từ N+1 đến Persistence Context
Đây là thử thách 5 tuần nhằm trực tiếp tái hiện bối cảnh persistence (영속성 컨텍스트), quan hệ (연관관계), kiểu giá trị (값 타입), QueryDSL và vấn đề N+1 trong cùng một điều kiện, đồng thời kiểm tra log SQL để giải thích căn cứ cho việc lựa chọn mapping và truy vấn.
🚀 Từng làm việc tại Toss, tốt nghiệp POSTECH | Nhà phát triển Backend hiện tại (+9 năm) 🎥 YouTuber 20.000 sub | Sáng tạo nội dung lập trình 📚 Giảng viên Inflearn | Tổng số học viên 18.000+ 👥 Đang vận hành cộng đồng tuyển dụng lập trình viên (8.000+) 🧩 Contributor cho nhiều dự án mã nguồn mở (Gradle, Spring AI, v.v.) 📝 Kinh nghiệm vượt qua 38 vòng hồ sơ và hơn 100 lần chỉnh sửa CV trên Kmong (Đánh giá 5.0 sao)
Truyền tải những thông tin thực tế sống động từ ngành công nghiệp một cách dễ hiểu và có tính diễn dịch.
Thử thách JPA 5 tuần · Miễn phí · 100 người đăng ký sớm nhất
DINGCO CHALLENGE · 5 TUẦN
JPA mà bạn vẫn luôn tin dùng, hãy tự mình kiểm chứng trong vòng 5 tuần.
Tái hiện ngữ cảnh lưu trữ (Persistence Context) và vấn đề N+1 trong cùng một điều kiện để so sánh qua nhật ký SQL, sau đó lưu lại dưới dạng một PR mỗi tuần. Sau 5 tuần, bạn sẽ có trong tay hồ sơ thực nghiệm được giải thích bằng số lượng truy vấn và tài liệu ADR về mapping.
Miễn phí · 100 người đầu tiên
Được tạo bởi DingcoDingco, người có tổng cộng hơn 18.000+ học viên trên Inflearn · mức độ hài lòng trung bình 4.9 · kinh nghiệm giúp học viên trúng tuyển vào 38 doanh nghiệp.
Thử thách này không cung cấp bài giảng hay giáo trình. Đây là một lộ trình thực thi nhằm chứng minh những nội dung bạn đã biết hoặc tự học thông qua các bài toán thực tế và GitHub PR. Chuẩn bị trước khi bắt đầu · Cần có kinh nghiệm sử dụng Entity và Repository trong dự án Spring Boot.
Đây là lộ trình thực thi trong 5 tuần nhằm chứng minh các khái niệm đã học thông qua mã nguồn, thực nghiệm và giải thích.
SẢN PHẨM BẠN SẼ HOÀN THÀNH
Những gì còn lại sau khi hoàn thành
Bộ sưu tập các bài kiểm tra xác thực vòng đời và ngữ cảnh bền vững (persistence context)
Số lượng SQL trước và sau khi cải thiện N+1 và API truy vấn động
20 câu trả lời phỏng vấn JPA kết nối giữa ADR mapping và log thực tế
BEFORE
Ngay cả khi truy vấn khác với dự kiến, họ vẫn bỏ qua và cho đó là đặc tính của framework.
AFTER
Cố định trạng thái persistence và số lượng SQL bằng các bài kiểm tra, đồng thời giải thích chi phí của các chiến lược mapping và truy vấn.
QUY TRÌNH LÀM VIỆC THỰC TẾ
Từ đăng ký đến đánh giá, theo đúng trình tự màn hình thực tế
Bạn không cần sao chép và gửi địa chỉ GitHub. Trang chủ Dingco sẽ hỗ trợ bạn từ việc chuẩn bị kho lưu trữ cá nhân, tạo nhánh nhiệm vụ và PR, cho đến việc kiểm tra đánh giá chi tiết.
1GitHub trước, Discord sau cùngSau khi hoàn tất đăng nhập Kakao và chẩn đoán sơ bộ, bạn sẽ chuẩn bị kho lưu trữ cá nhân (private), còn vai trò Discord và kênh theo khóa học sẽ được kết nối sau cùng.2Thực hiện nhiệm vụ trong kho lưu trữ riêng tư (private) của tôiTrang chủ sẽ kết nối việc tạo nhánh (branch) và PR cho 'Thí nghiệm 4 chức năng chính của Persistence Context và câu trả lời dựa trên căn cứ'. Không sao chép và dán địa chỉ PR.3Xác nhận 91 điểm và căn cứ cụ thểKiểm tra những điểm làm tốt và điểm cần cải thiện của việc kiểm tra tự động và đánh giá AI trong phần đánh giá chi tiết của Dingco và bình luận trên GitHub PR, sau đó chỉnh sửa trên cùng một PR đó.4Kênh vận hành JPA Challenge khóa 1Các bài đánh giá chi tiết cho từng cá nhân sẽ không được đăng lên Discord, chỉ chia sẻ bản tóm tắt hàng tuần và thông báo vận hành.
Màn hình trên là ví dụ được tạo dựa trên giao diện vận hành thực tế và quy tắc của kho lưu trữ·kênh. Tên kho lưu trữ, số thứ tự khóa học và điểm đánh giá sẽ thay đổi tùy theo người tham gia và khóa học.
5-WEEK ROUTE
Nhiệm vụ hàng tuần giúp chuyển đổi những nội dung đã biết thành thành quả thực tế
Mỗi tuần, bạn sẽ nộp các nội dung bao gồm: thực hiện/thử nghiệm, kiểm tra/log, căn cứ lựa chọn và câu trả lời cho các câu hỏi vào trong cùng một PR. Các câu hỏi không phải là bài tập về nhà để trả lời theo kiểu học thuộc lòng, mà phải được trả lời dựa trên mã nguồn và bằng chứng mà bạn vừa tạo ra.
W1
Nỗi đau của JDBC và Ngữ cảnh bền vững (Persistence Context)
So sánh JDBC và JPA, đồng thời kiểm chứng 1st-level cache (bộ nhớ đệm cấp 1), tính đồng nhất, thay đổi nhận dạng (dirty checking) và trì hoãn ghi (write-behind) thông qua log.
PR tổng hợp hàng tuầnThí nghiệm về 4 chức năng chính của ngữ cảnh lưu trữ và câu trả lời dựa trên bằng chứng
Tái hiện lần lượt các tính năng: bộ nhớ đệm cấp 1 (1st level cache), tính đồng nhất (identity), phát hiện thay đổi (dirty checking) và trì hoãn ghi (write-behind) trong cùng một transaction.
Ghi lại SQL dự kiến, SQL thực tế và thời điểm phát sinh trong mỗi lần thử nghiệm.
So sánh với việc quản lý trạng thái mà bạn phải trực tiếp chịu trách nhiệm khi xử lý cùng một yêu cầu đó bằng JDBC.
Bằng chứng nộp bài · Kiểm tra xác minh theo từng tính năng · Nhật ký SQL hiển thị thứ tự thực thi · Giải thích so với JDBC · Câu trả lời cho các câu hỏi dựa trên căn cứ từ 1~4
함께 답할 근거형 질문 4개
Tại sao bộ nhớ đệm cấp 1 (1st level cache) không phải là bộ nhớ đệm toàn cục của ứng dụng?
Tính đồng nhất của các thực thể có cùng mã định danh được đảm bảo trong phạm vi nào và bạn đã xác nhận điều đó như thế nào?
Cơ chế phát hiện thay đổi (Dirty Checking) so sánh thông tin gì vào thời điểm nào để tạo ra câu lệnh UPDATE?
Bạn đã chứng minh bằng log như thế nào về thời điểm mà việc trì hoãn ghi (write-behind) thay đổi thứ tự thực thi SQL thực tế?
W2
Mapping thực thể và vòng đời
Thực nghiệm về chiến lược tạo khóa, flush, trạng thái detached và cạm bẫy của save/merge.
PR tổng hợp hàng tuầnTái hiện cạm bẫy của save và định danh cùng câu trả lời dựa trên bằng chứng
Lưu trữ thực thể mới và thực thể ở trạng thái tách rời (detached), sau đó so sánh lộ trình giữa persist và merge.
Ghi lại các trường hợp thời điểm phát sinh INSERT thay đổi tùy theo chiến lược định danh hoặc việc có tự gán ID trực tiếp hay không.
Viết bài kiểm tra hồi quy về những vấn đề phát sinh khi nhầm lẫn giữa đối tượng trả về và đối tượng truyền vào của merge.
Bằng chứng nộp bài · Mã nguồn mapping Entity · Log so sánh truy vấn persist·merge · Kiểm thử hồi quy save·merge · Đáp án câu hỏi dựa trên căn cứ 1~4
함께 답할 근거형 질문 4개
Spring Data JPA의 save는 어떤 기준으로 persist와 merge를 선택하나요?
Tại sao việc tiếp tục sử dụng đối tượng đã truyền vào merge lại nguy hiểm?
Chiến lược IDENTITY và SEQUENCE có thể tạo ra sự khác biệt nào tại thời điểm INSERT?
Tại sao phải phân biệt giữa flush và commit mới có thể giải thích chính xác log lần này?
W3
Quan hệ thực thể và Lazy Loading
Áp dụng một cách an toàn chủ sở hữu quan hệ (relation owner), proxy, LAZY, cascade và orphan removal.
PR tổng hợp hàng tuầnXác minh ranh giới xóa và quan hệ thực thể cùng câu trả lời dựa trên căn cứ
Xác định chủ sở hữu của mối quan hệ User–Todo và nếu sử dụng quan hệ hai chiều, hãy viết phương thức tiện ích (convenience method) để đồng bộ trạng thái của cả hai đối tượng.
So sánh SQL trước và sau khi truy cập vào liên kết LAZY và ghi lại thời điểm khởi tạo proxy.
Kiểm chứng phạm vi xóa của cascade và orphanRemoval bằng các bài kiểm tra (test) khác nhau.
Bằng chứng nộp bài · Mã nguồn mapping domain · Log SQL trước và sau khi load · Test phạm vi xóa · Câu trả lời cho các câu hỏi lý thuyết từ 1 đến 4
함께 답할 근거형 질문 4개
Tại sao cần có chủ thể quan hệ (owner) để thực sự quản lý khóa ngoại?
Tại sao vấn đề N+1 vẫn có thể xảy ra ngay cả khi đã khai báo là LAZY?
cascade REMOVE và orphanRemoval khác nhau về kết quả trong tình huống nào?
Tại sao các phương thức tiện ích quan hệ lại cần thiết cho trạng thái của đối tượng thay vì cơ sở dữ liệu?
W4
So sánh mapping kế thừa và mở rộng tùy chọn
So sánh cùng một domain thanh toán bằng SINGLE_TABLE và JOINED, đồng thời mở rộng các phần kiểu giá trị (value type) và khóa phức hợp (composite key) thành bài tập tự chọn.
PR tổng hợp hàng tuầnADR quyết định mapping domain và câu trả lời dựa trên căn cứ
Triển khai cùng một domain thanh toán thành các mô hình tái hiện tối thiểu theo hai chiến lược kế thừa là SINGLE_TABLE và JOINED.
So sánh lược đồ được tạo, SQL truy vấn đa hình và chi phí thay đổi trong cùng điều kiện truy vấn và dữ liệu H2, đồng thời nêu rõ phạm vi đo lường.
Ghi lại lý do chọn chiến lược này và bỏ chiến lược kia dưới dạng ADR.
Bạn có thể chọn thử nghiệm tính bất biến của kiểu giá trị (value type) hoặc thỏa ước khóa phức hợp (composite key) như một nhiệm vụ tự chọn.
Bằng chứng nộp bài · Mô hình tái hiện tối thiểu SINGLE_TABLE·JOINED · So sánh SQL truy vấn đa hình·Schema H2 · ADR cuối cùng · Câu trả lời cho các câu hỏi dựa trên căn cứ 1~4
함께 답할 근거형 질문 4개
Khi lựa chọn chiến lược mapping kế thừa, bạn đã so sánh hiệu suất truy vấn và chuẩn hóa schema như thế nào?
Bạn đã xác nhận chi phí của các cột nullable trong SINGLE_TABLE và chi phí join trong JOINED như thế nào trong mô hình lần này?
SQL truy vấn đa hình giữa hai chiến lược khác nhau như thế nào và kết quả thử nghiệm trên H2 có thể được khái quát hóa đến mức nào?
Trong hai phương án mapping, yêu cầu nào sẽ khiến phương án đã bị loại bỏ trở nên phù hợp hơn?
W5
Truy vấn động và N+1
Tái hiện vấn đề N+1 trong truy vấn điều kiện động, đồng thời so sánh số lượng truy vấn và tính nhất quán của kết quả trong cùng một điều kiện.
PR tổng hợp hàng tuầnAPI truy vấn động không có N+1 và câu trả lời dựa trên căn cứ
Triển khai API truy vấn Todo kết hợp từ hai điều kiện lựa chọn trở lên bằng QueryDSL và các Q-Type đã được tạo.
Tái hiện lỗi N+1 trên cùng một dữ liệu và điều kiện truy vấn bao gồm các thực thể liên kết khác nhau, sau đó so sánh số lượng truy vấn trước và sau khi cải thiện bằng công cụ quan sát SQL được cung cấp.
Chọn QueryDSL fetch join hoặc DTO projection để viết bài kiểm tra hồi quy tính nhất quán của kết quả, đồng thời giải thích về chi phí phân trang, trùng lặp và độ kết hợp.
Việc kiểm tra tính nhất quán của ngữ cảnh lưu trữ (persistence context) sau khi thực hiện collection fetch join kết hợp phân trang hoặc các thao tác bulk (벌크 연산) có thể được thực hiện dưới dạng bài tập lựa chọn thông qua các bài kiểm tra riêng biệt.
Bằng chứng nộp bài · API truy vấn động QueryDSL · Số lượng SQL trước và sau khi cải thiện cùng điều kiện · Kiểm tra hồi quy tính nhất quán của kết quả truy vấn · Câu trả lời cho các câu hỏi dựa trên căn cứ từ 1~4
함께 답할 근거형 질문 4개
N+1 xảy ra ở phía nào giữa LAZY và EAGER, và nguyên nhân cốt lõi là gì?
Tại sao phương thức tối ưu hóa truy vấn được chọn lại phù hợp với nhu cầu hiện tại hơn so với các phương án thay thế khác?
Trong việc kết hợp các điều kiện QueryDSL, bạn đã cố định ranh giới của giá trị null và giá trị rỗng bằng những quy tắc và bài kiểm tra (test) nào?
Bạn đã kiểm soát thứ tự như thế nào để bộ nhớ đệm cấp 1 (1st level cache) và fixture INSERT không làm sai lệch kết quả đo lường số lượng truy vấn?
VÒNG LẶP HÀNG TUẦN
Hoàn thành thực tiễn của một tuần trong cùng một PR
Kiểm tra vấn đề thực tế theo từng tuần
Thực hiện nhiệm vụ trên nhánh (branch) cá nhân
Nộp PR bao gồm mã nguồn, bài kiểm tra và giải thích
Kiểm tra tự động và xác nhận AI review
Sửa đổi cùng một PR và tự động hợp nhất
Kiểm tra PR đã thông qua và giải thích chính thức
Phản ánh đánh giá đồng nghiệp tích lũy và hồ sơ học tập của phi hành đoàn
Việc nộp bài chỉ sử dụng GitHub PR. Mã thử nghiệm, nhật ký SQL và ADR được kiểm tra tự động trong một PR và lịch sử sửa đổi được lưu giữ. Hệ thống sẽ tự động xác nhận xem các bằng chứng cần thiết có nằm trong PR hay không.
SỰ THAM GIA CỦA CREW
Chỉ dành 20 phút để thảo luận về "Lời nhắn nhiệm vụ" (Mission Hanmadi)
Từ tuần thứ 2, hãy để lại một lời nhắn trong PR, và các thành viên (crew) chỉ chia sẻ về những điểm đang bị tắc nghẽn và các cách tiếp cận khác.
Lời nhắn nhiệm vụ từ tuần thứ 2 Để lại những điểm còn vướng mắc khi nộp PR từ 10~300 ký tự.
20 phút vào thời gian nhóm đã định Mặc định là 21:15 thứ Ba, chỉ chia sẻ những điểm bị tắc nghẽn và các cách tiếp cận khác.
Trưởng nhóm tóm tắt trong 1~30 ký tự Từ tuần thứ 2, thành viên hoàn thành được +5 điểm, tách biệt với việc hoàn thành cá nhân.
Hoạt động thưởng theo nhóm Người tham gia không viết thêm bài viết nào khác ngoài một câu thực hiện nhiệm vụ. Điểm +5 cho phi hành đoàn được tính riêng biệt với việc hoàn thành cá nhân.
BUỔI LIVE (LIVE SESSION)
Trực tiếp một lần, cùng nhau thống nhất cách thức tiến hành
Trong thời gian diễn ra thử thách, một buổi Live Session sẽ được tổ chức. Chúng ta sẽ cùng nhau thống nhất các tiêu chuẩn hoàn thành và kiểm tra trực tiếp tại chỗ cách thức quy trình nộp bài diễn ra trên màn hình.
KICKOFF LIVE20:00 Thứ Ba, 18/8
60 phút · Trực tuyến
JPA Challenge Kickoff Live
Hướng dẫn cách thức tiến hành trong 5 tuần và tiêu chuẩn hoàn thành
Demo chuẩn bị nhánh nhiệm vụ đầu tiên tại buổi Kickoff thứ Hai và hướng dẫn nộp GitHub PR sau khi bắt đầu vào thứ Tư
Hỏi & Đáp trực tiếp
Link tham gia sẽ được đăng trên thông báo Discord trước khi bắt đầu. Ngay cả khi không thể tham gia trực tiếp, bạn vẫn có thể kiểm tra tiêu chuẩn hoàn thành và cách thức nộp bài trên trang chủ Dingco và thông báo Discord.
BẢN CAM KẾT THỬ THÁCH
Tự học khái niệm, cùng nhau thực hành và phản hồi
Thử thách này không cung cấp bài giảng, giáo trình, Notion hay tài liệu bổ sung. Bạn sẽ áp dụng những nội dung đã biết hoặc tự học vào các vấn đề thực tế và chứng minh thông qua GitHub PR.
Thử thách cung cấp
Các vấn đề thực tế theo từng tuần · Kho lưu trữ thực hành cá nhân (private) · Tiêu chuẩn vượt qua rõ ràng · Kiểm tra tự động và đánh giá bằng AI · So sánh với đồng nghiệp và kỷ lục hoàn thành
Người tham gia chuẩn bị
Khái niệm cơ bản trong lĩnh vực tương ứng · Kinh nghiệm sử dụng Git và GitHub PR · Thời gian thực hiện mỗi tuần · Thái độ tự bổ sung các khái niệm còn thiếu
Học tập bổ trợ tự chọn · Mua riêng · 9 giờ 39 phút
[Lv2] Chinh phục hoàn toàn JPA của nhà phát triển thực thụ - Từ Persistence Context đến các Pattern thực tế
Khóa học và giáo trình này không bao gồm trong thử thách và việc học cũng không bắt buộc. Chỉ chọn khi bạn có lĩnh vực còn thiếu trong bài kiểm tra chẩn đoán trước hoặc khi cần bổ sung khái niệm.
Bất kể bạn đã đăng ký trên Inflearn hay chưa, hãy kiểm tra trạng thái tuyển sinh của khóa hiện tại thông qua nút ‘Xác nhận tuyển sinh·tham gia’ ở trên. Khi bạn đăng nhập bằng Kakao trên Dingco, vị trí của bạn sẽ được đảm bảo, và sau khi hoàn tất tất cả các kết nối, việc chuẩn bị tham gia sẽ sẵn sàng.
Tại trang xác nhận tuyển sinh và tham gia của Dingco, hãy chọn khóa hiện tại và đăng nhập bằng Kakao, tư cách thành viên thử thách sẽ được tạo ngay lập tức và vị trí của bạn sẽ được đảm bảo.
Sau khi vượt qua bài kiểm tra chẩn đoán trước theo từng khóa, bước kết nối GitHub sẽ được mở.
Nếu bạn kết nối GitHub trước, việc xác nhận quyền tổ chức và chuẩn bị kho lưu trữ private để thực hành JPA sẽ tự động được đặt lịch.
Khi kết nối Discord, các quyền cho danh mục JPA Challenge khóa 1 và các kênh thông báo, tài liệu đọc, câu hỏi, thảo luận tự do sẽ được thiết lập.
Tạo nhánh submit/<nhiệm vụ> trên trang chủ, push mã thử nghiệm·SQL log và gửi PR chỉ bằng một nút bấm.
Các commit mới nhất vượt qua kiểm tra tự động và đánh giá AI sẽ được Dingco tự động hợp nhất và cùng chúc mừng trên kênh tự do. Trên Discord của Crew, mọi người cùng chia sẻ câu hỏi và tiến độ công việc; việc đánh giá chính thức sẽ ưu tiên mở các PR đã vượt qua của cùng một Crew, nếu không có sẽ tiếp tục với các PR của Crew khác trong cùng khóa. Bảng điểm sẽ được phản ánh tạm thời trong tuần và được chốt chính thức sau khi kết thúc đợt đánh giá tích lũy cuối cùng.
Quyền đọc của các thành viên cùng khóa Kho lưu trữ cá nhân được giữ ở chế độ riêng tư và những người tham gia cùng khóa chỉ có thể tham khảo ở chế độ chỉ đọc sau khi kết quả hàng tuần được công bố. Quyền ghi chỉ được cấp cho kho lưu trữ của chính bạn. Một nhóm (crew) thường có từ 5 đến 6 người và danh sách sẽ được ẩn cho đến khi công bố. Bảng điểm chi tiết không được công khai, và sau khi điểm số cuối cùng được xác nhận, chỉ những nhóm chiến thắng đã đồng ý mới được giới thiệu trong Hall of Fame, huy hiệu GitHub và tên công khai. Đăng ký tham gia kết thúc vào lúc 19:00 thứ Tư của tuần bắt đầu. Các lộ trình có bài kiểm tra chẩn đoán trước phải vượt qua trước thời điểm đó, danh sách nhóm và kênh Discord riêng sẽ được công bố vào lúc 20:00. Thời gian bắt đầu chính thức và công bố nhiệm vụ tuần 1 là 21:00 cùng ngày, sau đó nhiệm vụ mới sẽ mở vào 21:00 thứ Tư hàng tuần và hạn chót nộp bài là 21:00 thứ Ba tuần sau. Việc đánh giá (review) chính thức không nhất thiết phải thực hiện ngay mỗi tuần, nhưng phải hoàn thành số lượng review cần thiết theo tiêu chuẩn của các tuần khác nhau trước 21:00 Chủ Nhật sau tuần cuối cùng. Đề bài tuần 1, kho lưu trữ cá nhân và nhánh nhiệm vụ có thể được chuẩn bị trước, nút nộp PR sẽ tự động được kích hoạt sau khi việc chuẩn bị kênh nhóm của bạn hoàn tất. Những người tham gia chưa hoàn tất kết nối GitHub/Discord vẫn sẽ được giữ nguyên nhóm đã phân bổ.
KIỂM TRA ĐỘ PHÙ HỢP
Phù hợp với những người này, và không phù hợp với những người này
Đề xuất cho những người sau
Những người có thể tạo CRUD bằng JPA nhưng lo sợ những câu lệnh SQL ngoài dự tính
Những ai muốn hệ thống lại N+1, cascade, save/merge bằng mã nguồn tái hiện thực tế thay vì chỉ bằng lời nói.
Những người muốn rút ra lựa chọn thực tế và giải thích khi phỏng vấn từ cùng một minh chứng cụ thể.
Không đề xuất
Những người chưa từng có kinh nghiệm lưu trữ hoặc truy vấn thực thể (entity) bằng Spring Data JPA
Những người chỉ muốn nhận các mẫu đáp án mà không có nhật ký SQL và kiểm tra hồi quy
HOÀN THÀNH
Công bố tiêu chuẩn hoàn thành trước khi bắt đầu
Trong vòng 5 tuần, nộp tất cả 5 PR nhiệm vụ tích hợp theo từng tuần.
Gửi đánh giá chính thức cho các PR đã vượt qua của 4 tuần khác nhau.
Chuẩn bị trước khi bắt đầu
Cần có kinh nghiệm sử dụng Entity và Repository trong dự án Spring Boot.
Mỗi tuần bạn cần dành khoảng 5-7 tiếng để tham gia vào việc thực nghiệm, so sánh log và chỉnh sửa PR.
Câu hỏi thường gặp
Những điều được hỏi nhiều nhất trước khi tham gia
Đây có phải là khóa học giống với Bootcamp 10 tuần trước đây không?
Không phải vậy. Thử thách này là một lộ trình riêng biệt để hoàn thành một môn học trong vòng 5 tuần. Chỉ trong trường hợp cần khóa học tập trung vào dự án dài hơn hoặc tìm việc làm thì mới tiếp tục với bootcamp 10 tuần.
Có bao gồm bài giảng hay giáo trình không?
Không phải vậy. Thử thách cung cấp các bài toán theo từng tuần, kho lưu trữ thực hành riêng tư (private), tiêu chuẩn nộp bài và vòng lặp đánh giá (review loop). Các bài giảng liên quan là phần học trước tự chọn có thể mua riêng và việc tham gia khóa học là không bắt buộc.
Có thể nộp bài trên trang chủ hoặc dán link vào được không?
Kết quả nộp bài chỉ được chấp nhận thông qua GitHub PR. Tuy nhiên, việc chuẩn bị kho lưu trữ (repository), nhánh (branch), PR và kiểm tra review có thể được thực hiện dễ dàng thông qua các nút bấm trên trang chủ Dingco.
Những gì được công khai trên Discord?
Trên Discord sẽ không đăng các bài đánh giá chi tiết cho từng cá nhân, mà chỉ chia sẻ các bản tóm tắt hàng tuần và thông báo vận hành. Kênh chung của JPA Challenge khóa 1 là không gian dành cho các bài đọc, đặt câu hỏi, trò chuyện tự do và hướng dẫn vận hành.
GHI CHÚ TỪ TÁC GIẢ
Thời đại AI, lập trình viên mới vào nghề nên học gì?
Bạn có thể xem trước trong video về tiêu chuẩn để thực hiện và kiểm chứng vấn đề này.