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

Câu lệnh defer trong Swift dùng để lên lịch thực thi một đoạn mã ngay trước khi phạm vi (scope) hiện tại kết thúc, bất kể phạm vi đó kết thúc như thế nào (thông qua return, break, hay ném ra lỗi throw).

Type Casting trong Swift là cách kiểm tra kiểu của một thể hiện hoặc xử lý thể hiện đó như thể nó là một kiểu siêu lớp hoặc lớp con khác trong cùng hệ thống phân cấp.

Lazy Stored Property là thuộc tính mà giá trị ban đầu của nó không được tính toán hoặc khởi tạo cho đến lần truy cập đầu tiên.

Phân tích bản chất

• Ad-hoc Queries: Là các câu lệnh SQL được gửi trực tiếp từ ứng dụng tới Database Management System (DBMS) mỗi khi cần thực thi. Mỗi câu lệnh thường phải trải qua quá trình phân tích cú pháp (parsing), tối ưu hóa (query optimization) và biên dịch (compilation) lại từ đầu.
• Stored Procedures: Là tập hợp các câu lệnh SQL được biên dịch sẵn và lưu trữ trực tiếp bên trong cơ sở dữ liệu. Lần gọi đầu tiên sẽ tạo execution plan, và các lần gọi sau sẽ tái sử dụng plan này.

Lợi ích khi sử dụng Stored Procedures

1. Hiệu năng (Performance): Giảm tải thời gian biên dịch nhờ tái sử dụng execution plan và giảm lưu lượng mạng truyền tải giữa ứng dụng và database.
2. Bảo mật (Security): Giảm thiểu rủi ro tấn công SQL Injection vì các tham số thường được truyền qua SqlParameter một cách an toàn.
3. Bảo trì (Maintainability): Logic nghiệp vụ tập trung tại database, giúp dễ dàng cập nhật mà không cần biên dịch lại mã nguồn ứng dụng.

Khi nào Junior nên sử dụng?

• Khi thực hiện các tác vụ phức tạp liên quan đến nhiều bảng và cần bảo mật cao.
• Khi cần chuẩn hóa dữ liệu đầu vào qua các hệ thống khác nhau gọi chung một thủ tục.

Ví dụ minh họa Stored Procedures

CREATE PROCEDURE sp_GetEmployeeByDepartment
    @DepartmentID INT
AS
BEGIN
    SELECT EmployeeID, FullName, Salary
    FROM Employees
    WHERE DepartmentID = @DepartmentID;
END;

Kinh nghiệm thực chiến: Không nên lạm dụng Stored Procedures cho toàn bộ ứng dụng vì sẽ làm giảm khả năng kiểm soát version control của mã nguồn ứng dụng và gây khó khăn khi scale ứng dụng sang các hệ thống ORM hiện đại.

Khái niệm N+1 Query Problem

N+1 Query Problem xảy ra khi ứng dụng thực hiện 1 câu lệnh SQL để lấy danh sách bảng cha (1 query), sau đó thực hiện thêm N câu lệnh SQL riêng lẻ để lấy dữ liệu bảng con cho từng bản ghi trong danh sách đó (N queries). Điều này làm suy giảm nghiêm trọng hiệu năng hệ thống khi số lượng bản ghi lớn.

Phân tích bản chất

• Primary Key (Khóa chính):
  • Đảm bảo tính duy nhất (Uniqueness) cho mỗi bản ghi trong bảng.
  • Tuyệt đối không được chứa giá trị NULL (Not Null).
  • Thường được tự động tạo một clustered index để tối ưu hóa tốc độ tìm kiếm.
• Foreign Key (Khóa ngoại):
  • Thiết lập mối quan hệ giữa hai bảng (Parent - Child).
  • Đảm bảo tính toàn vẹn tham chiếu (Referential Integrity), ngăn chặn việc chèn dữ liệu con khi dữ liệu cha không tồn tại.

Các thiết lập quan trọng khi cấu hình Foreign Key

• ON DELETE CASCADE: Khi bản ghi cha bị xóa, các bản ghi con liên quan cũng bị xóa tự động.
• ON DELETE RESTRICT / NO ACTION: Ngăn cản việc xóa bản ghi cha nếu vẫn còn bản ghi con tham chiếu.
• ON DELETE SET NULL: Đặt giá trị khóa ngoại ở bảng con thành NULL khi bản ghi cha bị xóa.

Ví dụ minh họa

CREATE TABLE Customers (
    CustomerID INT PRIMARY KEY,
    CustomerName VARCHAR(100)
);

CREATE TABLE Orders (
    OrderID INT PRIMARY KEY,
    OrderDate DATE,
    CustomerID INT,
    CONSTRAINT FK_CustomerOrder FOREIGN KEY (CustomerID)
    REFERENCES Customers(CustomerID)
    ON DELETE CASCADE
);

Kinh nghiệm thực chiến: Không nên bỏ qua việc khai báo Foreign Key trong database chỉ vì lý do muốn tăng tốc độ chèn dữ liệu. Việc kiểm soát logic ở tầng ứng dụng không an toàn bằng việc ép buộc ràng buộc trực tiếp tại tầng database.

Phân tích bản chất

• CHAR (Character):
  • Là kiểu dữ liệu chuỗi có độ dài cố định (fixed-length).
  • Nếu chuỗi ngắn hơn độ dài khai báo, hệ thống sẽ tự động độn thêm khoảng trắng (spaces) vào cuối cho đủ kích thước.
  • Tốc độ truy xuất nhanh hơn một chút đối với các trường có độ dài đồng nhất do kích thước bản ghi cố định.
• VARCHAR (Variable Character):
  • Là kiểu dữ liệu chuỗi có độ dài thay đổi (variable-length).
  • Chỉ lưu trữ đúng số lượng ký tự thực tế cộng thêm một vài byte metadata để quản lý chiều dài.
  • Tiết kiệm dung lượng lưu trữ đáng kể khi dữ liệu có chiều dài biến động.

Ảnh hưởng đến hiệu năng

1. Dung lượng lưu trữ: Sử dụng CHAR cho các cột có chiều dài thay đổi lớn (như ghi chú, địa chỉ) sẽ làm lãng phí nghiêm trọng dung lượng ổ cứng và bộ nhớ đệm (Buffer Pool).
2. Index Performance: Kích thước bản ghi lớn hơn làm giảm số lượng bản ghi trên mỗi trang dữ liệu (Page), dẫn đến việc tăng số lần đọc đĩa (Disk I/O) khi thực hiện Index Scan.

Ví dụ minh họa

-- Sử dụng CHAR cho mã định danh có độ dài cố định chính xác 10 ký tự
EmployeeCode CHAR(10),

-- Sử dụng VARCHAR cho họ tên có độ dài thay đổi
FullName VARCHAR(100)

Kinh nghiệm thực chiến: Luôn ưu tiên sử dụng VARCHAR cho các cột văn bản có độ dài không cố định, và chỉ dùng CHAR khi chắc chắn rằng mọi dữ liệu nhập vào đều có độ dài hoàn toàn bằng nhau (ví dụ: mã quốc gia, mã hash cố định).

Quy trình tối ưu hóa một Slow Query

1. Xác định câu lệnh chậm: Sử dụng công cụ giám sát như SQL Server Profiler, Slow Query Log trong MySQL, hoặc APM tools để khoanh vùng câu lệnh gây nghẽn.
2. Phân tích Execution Plan: Sử dụng lệnh EXPLAIN hoặc xem Graphical Execution Plan để hiểu cách cơ sở dữ liệu thực thi truy vấn.
3. Kiểm tra Index: Phát hiện các hiện tượng Table Scan / Clustered Index Scan không cần thiết và đề xuất tạo Non-Clustered Index phù hợp.
4. Tối ưu cấu trúc truy vấn: Tránh dùng SELECT *, hạn chế sử dụng hàm trên cột điều kiện (sẽ làm mất tác dụng của Index), và tối ưu hóa các phép nối JOIN.

Ví dụ phân tích bằng EXPLAIN

EXPLAIN SELECT * FROM Orders WHERE CustomerID = 5 AND OrderDate >= '2023-01-01';

• Nếu cột CustomerID hoặc OrderDate không có Index, hệ thống sẽ quét toàn bộ bảng (Table Scan).
• Giải pháp là tạo Composite Index:

  CREATE INDEX IX_Orders_Customer_Date ON Orders(CustomerID, OrderDate);

Lưu ý quan trọng

• Không phải lúc nào có Index cũng tốt. Index làm tăng tốc độ đọc nhưng làm chậm tốc độ ghi (INSERT, UPDATE, DELETE).
• Tránh lạm dụng các toán tử phủ định như NOT IN, !=, <> vì chúng thường khó tận dụng được Index.

Kinh nghiệm thực chiến: Khi làm việc với dữ liệu lớn, hãy luôn kiểm tra xem các cột tham gia vào mệnh đề WHERE, JOIN, ORDER BY đã được đánh chỉ mục đúng cách hay chưa trước khi nghĩ đến việc tối ưu phần cứng.

Delegates pattern là một thiết kế quan trọng trong Objective-C dùng để truyền thông tin và xử lý sự kiện giữa các đối tượng theo mô hình một-chiều (one-to-one communication).

Quản lý bộ nhớ tự động Automatic Reference Counting (ARC) dựa trên việc đếm số lượng tham chiếu đến đối tượng. Hiểu rõ sự khác biệt giữa strong và weak giúp lập trình viên tránh được lỗi rò rỉ bộ nhớ (Memory Leak) và lỗi truy cập vùng nhớ đã giải phóng (Dangling Pointer / Crash).

Grand Central Dispatch (GCD) là công nghệ cốt lõi giúp quản lý các tác vụ bất đồng bộ và đa luồng trong Objective-C. Junior lập trình viên cần nắm vững cách sử dụng các hàng đợi (Dispatch Queues) để tối ưu hóa hiệu năng ứng dụng.

Khác với các ngôn ngữ hiện đại sử dụng cơ chế try-catch phổ biến cho mọi loại lỗi, Objective-C phân chia rõ ràng giữa hai khái niệm: Ngoại lệ nghiêm trọng mang tính lập trình (NSException) và Lỗi thời điểm chạy có thể phục hồi (NSError).

UITableView là thành phần giao diện phổ biến nhưng rất dễ gây sụt giảm khung hình (drop frame) hoặc tốn kém bộ nhớ nếu không được cấu hình và tối ưu hóa đúng cách.

Phân tích sự khác biệt cốt lõi

1. Pages Router (Mô hình cũ)

• Sử dụng thư mục pages/ để định tuyến tập tin (File-based Routing).
• Mặc định tất cả các Component trong một trang đều là Client Components, nghĩa là mã nguồn được gửi về trình duyệt và thực thi ở client.
• Việc fetch dữ liệu dựa trên các hàm đặc biệt như getServerSideProps (cho SSR) hoặc getStaticProps (cho SSG). Các hàm này chạy hoàn toàn trên server trước khi render trang.

2. App Router (Mô hình mới - Khuyên dùng)

• Sử dụng thư mục app/ dựa trên React Server Components (RSC).
• Mặc định tất cả các Component đều là Server Components, giúp giảm thiểu đáng kể kích thước JavaScript Bundle gửi về client.
• Cung cấp các tính năng nâng cao như Layouts, Loading UI, Error Handling, và Streaming thông qua Suspense một cách tự nhiên và tối ưu hơn.

Lý do Next.js khuyến khích sử dụng App Router

• Hiệu năng vượt trội: Server Components thực thi trực tiếp trên server và chỉ trả về HTML tĩnh hoặc luồng dữ liệu gọn nhẹ, giúp cải thiện chỉ số Core Web Vitals (đặc biệt là First Contentful Paint và Time to Interactive).
• Trải nghiệm lập trình tốt hơn: Hỗ trợ tính năng bố cục lồng nhau (Nested Layouts) giúp tái sử dụng giao diện và giữ trạng thái tốt hơn khi chuyển trang.
• Hỗ trợ React mới nhất: Tận dụng triệt để các tính năng bất đồng bộ của React 18+ như Suspense để xử lý bất đồng bộ mượt mà.

Lưu ý thực chiến cho Junior

Khi mới chuyển từ Pages Router sang App Router, lập trình viên thường gặp lỗi khi cố gắng sử dụng các React Hooks như useState, useEffect hoặc các event listener bên trong Server Components. Hãy nhớ khai báo chỉ thị 'use client' ở đầu file khi bạn thực sự cần tương tác với trình duyệt hoặc quản lý trạng thái tại client.

Mục đích của file not-found.js

Trong Next.js App Router, file not-found.js được sử dụng để hiển thị giao diện tùy chỉnh (Custom 404 Error Page) khi người dùng truy cập vào một đường dẫn không tồn tại hoặc khi hàm notFound() được gọi chủ động trong code.