Thư Viện Câu Hỏi Phỏng Vấn

Trong quản lý mã nguồn, việc đồng bộ hóa dữ liệu từ remote repository về local repository là cực kỳ quan trọng. Dưới đây là phân tích chi tiết sự khác biệt giữa hai lệnh này.

Merge Conflict xảy ra khi Git không thể tự động hợp nhất các dòng code do có sự thay đổi chồng chéo trên cùng một vị trí của tệp tin giữa hai nhánh.

Tệp .gitignore đóng vai trò định nghĩa các tệp tin và thư mục mà Git sẽ bỏ qua, không theo dõi (track) trong kho lưu trữ mã nguồn.

Trong quá trình phát triển, việc quên thêm một tệp nhỏ hoặc viết sai chính tả trong thông điệp commit gần nhất là rất phổ biến. Thay vì tạo một commit mới với nội dung như 'fix typo', chúng ta sử dụng tính năng Git Amend.

Bản chất cơ chế hoạt động

• val (value) đại diện cho một tham chiếu chỉ đọc (read-only reference). Khi một biến được khai báo là val, giá trị của nó không thể được gán lại sau khi đã khởi tạo lần đầu (immutable reference). Tuy nhiên, cần lưu ý rằng đối tượng bên trong vẫn có thể thay đổi trạng thái nếu nó là mutable.
• var (variable) đại diện cho một biến có thể thay đổi giá trị (mutable variable), cho phép gán lại nhiều lần trong vòng đời.

Tác động trong môi trường Enterprise

• Lạm dụng var làm tăng độ phức tạp của mã nguồn, đặc biệt trong các ứng dụng đa luồng (multi-threaded applications) hoặc kiến trúc hướng sự kiện (event-driven architecture). Khi trạng thái có thể bị thay đổi tự do bởi bất kỳ hàm nào, việc theo dõi luồng dữ liệu (data flow) trở nên khó khăn, dễ dẫn đến các lỗi khó phát hiện như race conditions hoặc side effects không mong muốn.
• Sử dụng val giúp thúc đẩy lập trình hướng bất biến (immutability), giúp mã nguồn dễ đoán hơn, dễ viết Unit Test và an toàn hơn khi chạy đồng thời.

Ví dụ minh họa

class UserService {
    // Khuyến nghị: Sử dụng val cho các thuộc tính không đổi
    private val maxRetryCount = 3

    fun processUser(userId: String) {
        // Tránh dùng var nếu không thực sự cần thiết gán lại giá trị
        var attempts = 0 
        while (attempts < maxRetryCount) {
            try {
                // Xử lý logic kết nối
                break
            } catch (e: Exception) {
                attempts++
            }
        }
    }
}

Lưu ý kinh nghiệm thực chiến

Ở cấp độ Junior, lập trình viên thường có thói quen dùng var cho mọi biến số vì tính tiện lợi. Trong các dự án Enterprise tại Unicode Academy, chúng tôi luôn yêu cầu ưu tiên tuyệt đối val, và chỉ sử dụng var khi thực sự bắt buộc phải thay đổi trạng thái trong một phạm vi hẹp (local scope).

Bản chất cơ chế hoạt động

• Kotlin được thiết kế để giải quyết triệt để vấn đề Null Safety thông qua hệ thống kiểu phân biệt rõ ràng giữaNullable và Non-null types.
• Tuy nhiên, khi gọi mã từ Java, Kotlin không thể biết chắc chắn liệu một phương thức Java có trả về giá trị null hay không do Java không có hệ thống Null Safety tương tự. Kotlin giải quyết việc này bằng cách sử dụng Platform Types (ký hiệu bằng dấu chấm hỏi kép T!). Platform Types cho phép lập trình viên tùy ý coi kiểu dữ liệu đó là nullable hoặc non-null.

Các bước xử lý an toàn

1. Sử dụng Safe Calls (?.): Tránh gọi trực tiếp phương thức trên đối tượng Java nếu chưa chắc chắn nó khác null.
2. Sử dụng Elvis Operator (?:): Cung cấp giá trị mặc định khi gặp giá trị null.
3. Sử dụng Not-null Assertion (!!): Chỉ dùng khi tuyệt đối chắc chắn Java trả về giá trị non-null, nếu không sẽ ném ra NullPointerException.
4. Khai báo Annotation phía Java: Sử dụng các annotation như @NotNull và @Nullable trong mã nguồn Java để Kotlin nhận diện chính xác kiểu dữ liệu.

Ví dụ minh họa

// Giả sử gọi một phương thức từ thư viện Java cũ
val javaUser: JavaUser? = LegacyJavaLibrary.getUser()

// Xử lý an toàn bằng Safe Calls và Elvis Operator
val userName: String = javaUser?.name ?: "Unknown"

// Xử lý khi Java không có annotation
val email = javaUser?.email.orEmpty()

Lưu ý kinh nghiệm thực chiến

Khi tích hợp các thư viện Java trong dự án Enterprise lớn, không bao giờ lạm dụng toán tử !!. Nếu thư viện Java không có sẵn annotation quản lý null, hãy luôn giả định rằng giá trị trả về có thể là null và áp dụng chiến lược phòng thủ mã nguồn (defensive programming).

Bản chất cơ chế hoạt động

• lateinit var:
  • Dùng cho kiểu dữ liệu biến đổi (var) không phải kiểu nguyên thủy (primitive types như Int, Boolean).
  • Cho phép hoãn thời điểm khởi tạo giá trị của biến sau khi đối tượng đã được khởi tạo (thường dùng trong Dependency Injection hoặc Android Activity/Fragment lifecycle).
  • Nếu truy cập biến lateinit trước khi nó được gán giá trị, hệ thống sẽ ném ra ngoại lệ UninitializedPropertyAccessException.
• val lazy:
  • Dùng cho thuộc tính chỉ đọc (val).
  • Giá trị chỉ được tính toán và khởi tạo tại lần truy cập đầu tiên (lazy initialization).
  • Mặc định cơ chế thread-safety là LazyThreadSafetyMode.SYNCHRONIZED, đảm bảo chỉ có một luồng thực thi việc khởi tạo.

Bảng so sánh nhanh

• lateinit: Dùng cho var, khởi tạo thủ công sau, không hỗ trợ kiểu nguyên thủy.
• lazy: Dùng cho val, tự động khởi tạo khi gọi lần đầu, hỗ trợ mọi kiểu dữ liệu.

Ví dụ minh họa

class DatabaseManager {
    // lateinit dùng khi phụ thuộc vào Dependency Injection
    @Inject
    lateinit var connectionPool: ConnectionPool

    // lazy dùng khi tài nguyên nặng, chỉ khởi tạo khi thực sự cần thiết
    val heavyConfiguration: ConfigData by lazy {
        ConfigData.loadFromDisk()
    }
}

Lưu ý kinh nghiệm thực chiến

Lập trình viên Junior thường hay nhầm lẫn hai khái niệm này. Hãy nhớ nguyên tắc vàng: Dùng lateinit khi bạn biết chắc chắn giá trị sẽ được gán trước khi sử dụng (nhưng chưa thể gán lúc khai báo). Dùng lazy khi bạn muốn tối ưu hóa hiệu năng, hoãn việc tải tài nguyên nặng cho đến thời điểm gọi lần đầu tiên.

Bản chất cơ chế hoạt động

Scope Functions là các hàm có nhiệm vụ duy nhất là thực thi một khối mã trong ngữ cảnh của một đối tượng. Sự khác biệt giữa chúng nằm ở hai yếu tố:

Bản chất cơ chế hoạt động

• Coroutine trong Kotlin không gắn liền với một luồng cụ thể nào. Một Coroutine có thể tạm dừng (suspend) việc thực thi trên một luồng và tiếp tục chạy trên một luồng khác.
• Dispatcher chịu trách nhiệm quyết định coroutine nào sẽ được thực thi trên luồng nào bằng cách quản lý mộtpool các luồng (thread pool).
• Các Dispatcher phổ biến:
  • Dispatchers.Main: Chạy trên luồng chính (thường dùng cho UI operations).
  • Dispatchers.Default: Được tối ưu cho các tác vụ nặng về CPU (CPU-bound) như xử lý thuật toán, parsing dữ liệu lớn. Số lượng luồng bằng số lượng nhân CPU.
  • Dispatchers.IO: Được tối ưu cho các tác vụ đọc ghi mạng, truy vấn cơ sở dữ liệu hoặc đọc ghi file (I/O-bound). Pool luồng của Dispatchers.IO có thể mở rộng linh hoạt (lên đến 64 luồng hoặc số nhân CPU tùy theo giá trị lớn hơn).

Vai trò trong Enterprise

Trong các ứng dụng backend hoặc mobile quy mô lớn, việc chặn luồng chính (blocking main thread) sẽ làm sập ứng dụng hoặc gây nghẽn cổ chai hệ thống. Dispatchers.IO giúp chia sẻ tài nguyên hiệu quả, cho phép xử lý hàng ngàn request đồng thời mà không làm cạn kiệt tài nguyên hệ thống nhờ cơ chế chia sẻ chung một shared thread pool.

Khái niệm cơ bản

Trong Unit testing, việc cách ly (Code Isolation) đơn vị mã nguồn cần kiểm thử khỏi các phụ thuộc bên ngoài như cơ sở dữ liệu, API bên thứ ba hoặc hệ thống file là cực kỳ quan trọng. Stubbing và Mocking là hai kỹ thuật chính:

Khái niệm cơ bản

Edge cases (trường hợp biên) là các tình huống xảy ra ở giới hạn cực đoan của đầu vào hoặc trạng thái hệ thống, ví dụ như giá trị null, undefined, số âm, mảng rỗng, chuỗi quá dài hoặc tràn bộ nhớ. Việc kiểm thử các trường hợp này giúp đảm bảo tính bền bỉ và ổn định của ứng dụng khi đưa lên môi trường Production.

Khái niệm cơ bản

Nguyên tắc FIRST là tiêu chuẩn vàng trong thiết kế unit test:

Khái niệm cơ bản

Trong hệ thống cấp độ Enterprise, việc phân định rõ phạm vi của các loại kiểm thử giúp tối ưu hóa thời gian chạy CI/CD Pipeline và sớm phát hiện lỗi.

Khái niệm cơ bản

Refactoring là quá trình tái cấu trúc mã nguồn hiện tại mà không làm thay đổi hành vi bên ngoài của ứng dụng nhằm cải thiện tính dễ đọc, khả năng bảo trì và hiệu năng. Unit testing chính là chiếc lưới an toàn (safety net) tuyệt vời nhất khi thực hiện refactoring.

Bản chất cơ chế

Pattern Matching trong Rust cho phép so khớp một giá trị với một tập hợp các mẫu cấu trúc khác nhau. Điểm mạnh lớn nhất của cơ chế này là tính cạn kiệt (Exhaustiveness), nghĩa là trình biên dịch Rust bắt buộc lập trình viên phải xử lý mọi trường hợp có thể xảy ra, giúp loại bỏ hoàn toàn các lỗi tiềm ẩn như Null Pointer Exception.