Cách Xử Lý Task Khi Bạn Không Biết Tech Stack

Bạn vừa vào dự án mới. Hoặc được điều sang team khác. Hoặc một ticket vừa được assign cho bạn và code được viết bằng một framework bạn chưa biết.

Stack mới, xa lạ. Codebase thì lớn. Không ai giải thích gì cả. Và ticket thì ghi "should be straightforward."

Đây là một trong những tình huống rất phổ biến mà junior developer phải đối mặt — và cũng là một trong những tình huống ít được nói đến. Hầu hết các tutorial dạy bạn một công nghệ trong điều kiện lý tưởng. Không ai dạy bạn phải làm gì khi bị thả vào một dự án thực tế đang dùng công nghệ đó theo những cách mà tutorial chưa từng đề cập.

Đây là cách tiếp cận.

Bước 1: Đừng Bắt Đầu Bằng Học — Bắt Đầu Bằng Hiểu

Bản năng đầu tiên thường sai: mở tab trình duyệt và bắt đầu một tutorial về framework mới.

Đừng làm vậy.

Trước khi đụng vào bất kỳ tài liệu nào, hãy dành một tiếng đầu tiên để đọc codebase hiện có. Bạn cần trả lời những câu hỏi này:

Dự án được cấu trúc như thế nào? Code của feature này nằm ở đâu?
Những pattern nào lặp lại trong codebase? (cách đặt tên, cách tổ chức file, luồng dữ liệu đi như thế nào)
Có feature nào tương tự đã được implement chưa? Nó trông như thế nào?

Cách nhanh nhất để học cách framework được dùng trong dự án này là đọc xem nó đang được dùng như thế nào. Codebase là người thầy tốt hơn tutorial trong tình huống này, bởi vì tutorial không biết các ràng buộc, quy ước, hay quyết định thiết kế của dự án bạn đang làm.

Cần tìm gì

src/
├── features/
│   ├── users/        ← nhìn vào đây để tìm ví dụ "hoàn chỉnh"
│   │   ├── UserList.tsx
│   │   ├── useUsers.ts
│   │   └── users.service.ts
│   └── orders/       ← task của bạn có thể ở đây — xem users/ đã được làm thế nào
├── components/       ← UI pattern dùng chung
└── lib/              ← utilities và wrappers

Tìm module hoàn chỉnh và sạch nhất trong codebase rồi đọc từ đầu đến cuối. Đó là nguồn tham khảo của bạn. Đó là style guide bạn sẽ phải tuân theo.

Bước 2: Hiểu Task Trước Khi Hiểu Stack

Trước khi đào sâu vào tài liệu, hãy chắc chắn rằng bạn thực sự hiểu mình cần xây dựng cái gì. y Viết yêu cầu bằng ngôn ngữ đơn giản theo cách hiểu của chính bạn. Nếu bạn không làm được điều đó, vấn đề không phải là bạn không biết framework — mà là bạn không hiểu yêu cầu. Đó là vấn đề khác với giải pháp khác: hãy hỏi để làm rõ.

Khi đã hiểu rõ yêu cầu, hãy tự hỏi:

Tôi cần dữ liệu gì và nó đến từ đâu?
Chức năng sau khi làm xong sẽ trông như thế nào? Output là gì?
Cái gì đã có sẵn mà tôi có thể tái sử dụng?

Cách suy luận này giữ bạn đi đúng hướng khi bắt đầu đào sâu vào tài liệu framework. Nếu không có nó, bạn sẽ rất dễ dành hai tiếng đọc về một tính năng mà bạn thực ra không cần.

Bước 3: Thu Hẹp, Không Đi Sâu

Khi bạn không biết một tech stack, điều tệ nhất có thể làm là cố học hết tất cả trước khi viết một dòng code.

Bạn không cần hiểu toàn bộ framework. Bạn cần hiểu những phần cụ thể của framework mà task của bạn sẽ đụng đến.

Hãy tự hỏi: lượng kiến thức tối thiểu tôi cần để bắt đầu là gì?

Nếu bạn cần thêm một API endpoint mới trong một dự án Spring Boot cái mà bạn chưa biết:

Bạn không cần hiểu Spring Security
Bạn không cần hiểu relationship trong JPA
Bạn không cần hiểu toàn bộ request lifecycle

Bạn cần hiểu: làm thế nào để định nghĩa một controller endpoint, gọi một service, và trả về response?

Tìm điều đó. Đọc chỉ điều đó. Bắt đầu làm.

Phần còn lại sẽ đến khi bạn tiến về phía trước. Khi bạn cần đụng phần nào khác của framework đó để làm task của bạn — lúc đó, bạn sẽ học nó trong ngữ cảnh cụ thể, bạn sẽ học được nó rất nhanh và bạn sẽ ghi nhớ nó rất lâu.

Bước 4: Dùng Codebase Như Tài Liệu

Hầu hết junior developer khi bị kẹt sẽ lập tức tìm đến official docs hoặc Stack Overflow. Senior developer sẽ tìm đến codebase trước.

Tại sao? Vì codebase cho bạn thấy:

Chính xác cách library hoặc framework được cấu hình trong dự án này
Phiên bản nào đang được dùng và những API nào có sẵn
Những pattern mà team đã quyết định tuân theo (có thể khác với khuyến nghị của official docs)
Ví dụ thực tế xử lý các edge case mà các tutorial không đề cập

Cách dùng grep để search và hiểu codebase

Khi bạn không chắc thứ gì đó hoạt động ra sao, hãy tìm kiếm trong codebase:

# Tìm cách các service khác được cấu trúc
grep -r "class.*Service" src/ --include="*.java" -l
 
# Tìm tất cả chỗ dùng một library (ví dụ axios)
grep -r "import.*axios" src/ --include="*.ts" -l
 
# Tìm chỗ các biến môi trường đang được sử dụng
grep -r "process.env" src/ --include="*.ts" | head -20

Điều này cho bạn các ví dụ thực tế trong code đang chạy trên production. Không có tutorial nào giúp bạn có được điều này.

Bước 5: Xây Dựng Phiên Bản Tối Giản Trước

Đừng cố viết code hoàn hảo ngay trong lần đầu với stack mới. Mục tiêu của bạn là code ra thứ gì đó hoạt động càng nhanh càng tốt, dù còn thô.

Một giải pháp thô chạy được dạy bạn nhiều hơn một giải pháp hoàn hảo vẫn đang còn trong ý tưởng.

Hãy làm theo vòng lặp này:

Giá trị của việc có thứ gì đó chạy được sớm là bạn có ngay feedback loop. Lỗi (bug) trở thành người thầy của bạn. Thông báo lỗi (error message) cho bạn biết chính xác framework không thích điều gì — đó là việc học có mục tiêu hiệu quả hơn nhiều so với đọc tài liệu từ đầu.

Bước 6: Hỏi Đúng Câu Hỏi Vào Đúng Thời Điểm

Đây là kỹ năng mà hầu hết junior không biết tận dụng và phát huy:

**Câu hỏi tệ:**m

"Em không hiểu framework này hoạt động thế nào, anh có thể giải thích cho em không?"

**Câu Emi tốt:em

"Em đang cố thêm bộ lọc tìm kiếm vào endpoint GET /products. Em mô phỏng theo endpoint GET /orders đang dùng Specification object. Nhưng khi chạy, em gặp lỗi JPA query failed. Em nghĩ nguyên nhân là trường filter không được map đúng. Đây là code của em — trông có đúng chưa anh?"

Sự khác biệt: bạn đã làm bài tập, bạn có giả thuyết, bạn đang hỏi một điều cụ thể. Điều này tôn trọng thời gian của mentor và buộc bạn phải hiểu vấn đề của chính mình rõ hơn trước khi hỏi.

Một quy tắc hữu ích: cố giải quyết tự mình ít nhất 30 phút trước. Nếu vẫn bí, hãy hỏi — nhưng nhớ liệt kê những gì bạn đã thử và giả thuyết/phỏng đoán của bạn về nguyên nhân lỗi.

Nên liệt kê những gì khi hỏi mentor/lead

Bạn đang cố làm gì
Bạn mong đợi điều gì xảy ra
Lỗi bạn đang gặp phải (bao gồm thông báo lỗi)
Bạn đã thử những cách gì rồi
Phỏng đoán tốt nhất của bạn về lý do tại sao nó lỗi/failed

Cách tiếp cận này rất hiệu quả dù bạn đang hỏi đồng nghiệp/mentor/lead, hỏi trên Stack Overflow, hay cả hỏi AI.

Bước 7: Note Lại Những Gì Bạn Học Được

Đây là bước bị bỏ qua nhiều nhất và có giá trị nhất về lâu dài.

Sau khi giải quyết một vấn đề trong stack mới, hãy viết ra những gì bạn học được. Không cần phải trang trọng — một file notes trong dự án, một trang Notion riêng, thậm chí một comment trong code.

## [2026-02-22] Spring Boot — Custom Query with JPA Specifications
 
**Problem**: Needed to filter products by multiple optional fields.
**Solution**: Used `JpaSpecificationExecutor` interface + a `ProductSpec` class.
**Key learning**: Specifications compose with `Specification.where().and()`.
**Reference**: `src/features/orders/OrderSpecification.java` is a good example.
**Notice**: Fields must be mapped as `@Column` or the query fails silently.

Hai tuần sau, bạn sẽ gặp pattern tương tự ở phần khác trong codebase. Thay vì phải research lại từ đầu, bạn đọc lại note và hoàn thành task trong 5 phút.

Đây là cách bạn tích lũy kiến thức. Nó là lãi kép theo thời gian.

Thay Đổi Tư Duy: Bạn Không Được Kỳ Vọng Biết Tất Cả

Điều quan trọng nhất cần nhận thức: không ai kỳ vọng bạn bước vào là đã biết stack mới đó.

Những gì họ đang đánh giá là liệu bạn có thể tự tìm ra giải pháp, tự học được hay không.

Bạn có thể đọc code người khác viết không? Bạn có thể thu hẹp vấn đề không? Bạn có thể hỏi đúng câu hỏi không? Bạn có thể code được một giải pháp thô nhanh chóng hay không?

Những kỹ năng này quan trọng hơn việc bạn đã biết framework hay chưa.

Một developer đứng hình ba ngày vì không biết stack và không nhờ giúp đỡ bị đánh gía kém hơn nhiều so với người biết đọc codebase, code được bản thô vào ngày đầu tiên, rồi tinh chỉnh từ từ thông qua review của lead.

Tốc độ đến từ vòng lặp này, không phải từ việc biết mọi thứ ngay từ đầu.

Checklist Thực Tế Cho Task Mới Với Stack Lạ

Khi bạn nhận task trong stack chưa biết:

Trước khi viết code:
✅ Đọc codebase để hiểu cấu trúc và pattern
✅ Viết yêu cầu theo cách hiểu của chính bạn
✅ Tìm feature tương tự đã được implement và dùng làm tham chiếu
✅ Xác định lượng kiến thức tối thiểu cần có để bắt đầu

Trong khi implement:
✅ Implement phiên bản tối giản trước
✅ Tìm trong codebase trước khi tìm trên internet
✅ Đọc thông báo lỗi đầy đủ trước khi Google/ChatGPT
✅ Có giả thuyết/phỏng đoán về nguyên nhân trước khi hỏi lead

Sau khi hoàn thành:
✅ Viết ra những gì bạn học được và các lưu ý quan trọng
✅ Ghi lại phần nào trong codebase là tham chiếu hữu ích
✅ Nếu bạn tốn hơn một tiếng cho thứ gì đó phát sinh, đề cập trong PR description

Tóm Tắt

Là junior trong stack lạ không có nghĩa là bạn phải biết nó rồi. Mà là bạn cần một quy trình để học nó hiệu quả, trong ngữ cảnh cụ thể, trên dự án thực tế.

Quy trình đó là:

Đọc codebase trước — đó là tài liệu tốt nhất cho dự án cụ thể này
Hiểu task trước khi hiểu tech — sự rõ ràng quan trọng hơn kiến thức
Thu hẹp — chỉ học những gì task thực sự cần
Build thô, rồi tinh chỉnh — bản thô (prototype) chạy được tốt hơn nhiều một kế hoạch hoàn hảo trong đầu
Đặt câu hỏi hiệu quả — sau khi đã thử, với giả thuyết, với ngữ cảnh
Viết ra những gì bạn học được — nó là lãi kép theo thời gian

Những developer phát triển nhanh nhất không phải là người đã biết nhiều nhất. Họ là những người học đúng cái cần học và tích luỹ kiến thức để học nhanh hơn theo thời gian.

Đó là một kỹ năng có thể học được. Và mỗi task lạ là một cơ hội để học được nhiều thứ mới.