Note sách tháng 5

Book Notes - Tháng 5/2025

1. Antifragile (Khả năng cải thiện nghịch cảnh) – Nassim Nicholas Taleb

Tư tưởng cốt lõi

Antifragile là khái niệm trung tâm của cuốn sách, dùng để chỉ những thứ không chỉ chịu được cú sốc mà còn trở nên tốt hơn nhờ hỗn loạn, biến động và stress. Trái ngược với "fragile" (mong manh), và khác cả "robust" (bền vững nhưng không cải thiện).

Phân loại thế giới

• Fragile: Những hệ thống dễ tổn thương khi thay đổi xảy ra. Ví dụ: hệ thống tài chính tối ưu hóa quá mức, các tổ chức phụ thuộc vào dự đoán.
• Robust: Đứng vững trước biến cố nhưng không học hỏi hay cải thiện từ đó.
• Antifragile: Càng bị thử thách, càng phát triển – như cơ bắp khi luyện tập, hệ miễn dịch khi tiếp xúc vi khuẩn.

Các nguyên lý chính

1. Barbell Strategy

Kết hợp 2 thái cực: một phần cực kỳ an toàn, một phần cực kỳ mạo hiểm nhưng tiềm năng cao. Tránh vùng trung bình rủi ro lớn.

• 90% tài sản bảo thủ (trái phiếu, tiền mặt), 10% đầu tư mạo hiểm (startup).
• Trong cuộc sống: ổn định phần cứng (sức khỏe, an toàn), mạo hiểm phần mềm (ý tưởng, sáng tạo).

2. Skin in the Game

Chỉ nên tin và nghe lời người có "da thịt trong cuộc chơi", tức là phải chịu hậu quả cho quyết định của họ.

• Ví dụ: bác sĩ chịu trách nhiệm với bệnh nhân vs chuyên gia ngồi phòng máy lạnh đoán thị trường.
• Giúp loại bỏ "tư duy học thuật xa rời thực tế".

3. Via Negativa – Nghệ thuật bỏ bớt

Không thêm vào, mà bỏ bớt để cải thiện:

• Cắt caffeine thay vì uống thêm thuốc ngủ.
• Xóa app mạng xã hội thay vì học kỹ năng tập trung.
• Trong code: refactor, xóa dead code.

4. Optionality – Sở hữu tùy chọn

Tăng các lựa chọn "upside lớn, downside nhỏ":

• Không dự đoán tương lai, mà tạo điều kiện để phản ứng nhanh với bất kỳ điều gì xảy ra.
• Startup nhỏ linh hoạt tốt hơn tập đoàn cồng kềnh.

5. Lindy Effect

Thứ gì tồn tại càng lâu thì càng có xu hướng tồn tại thêm:

• Sách cổ, triết lý cổ, ngôn ngữ cổ thường bền hơn công nghệ mới nổi.

6. Tùy cơ ứng biến hơn tối ưu

• Tối ưu hóa quá mức dẫn đến dễ vỡ khi điều kiện thay đổi.
• Cái không "hiệu quả" hôm nay có thể sống sót tốt hơn ngày mai.

Bài học ứng dụng

• Thiết kế hệ thống (sự nghiệp, tài chính, codebase) để trở nên tốt hơn sau biến cố.
• Tránh lệ thuộc vào dự đoán. Tăng sự ngẫu nhiên nhỏ có kiểm soát.
• Thích nghi hơn là kiểm soát.

2. Stumbling on Happiness (Tình cờ gặp hạnh phúc) – Daniel Gilbert

Ý tưởng chủ đạo

Con người rất tệ trong việc dự đoán điều gì sẽ khiến mình hạnh phúc trong tương lai. Sự tưởng tượng thường sai vì các giới hạn trong bộ não và định kiến nhận thức.

Những ảo tưởng thường gặp

1. Ảo tưởng về trí nhớ

• Ký ức không chính xác: chúng ta nhớ lại cảm xúc theo cách “bóp méo” để phù hợp với hình ảnh bản thân hiện tại.
• Ví dụ: nhớ lần chia tay đau khổ hơn hay nhẹ nhàng hơn thực tế.

2. Ảo tưởng về trí tưởng tượng

• Khi tưởng tượng tương lai, ta lấp đầy chỗ trống bằng hiện tại + định kiến.
• Ví dụ: tưởng tượng làm ở Google sẽ rất hạnh phúc vì hình ảnh hiện tại về Google.

3. So sánh phi lý

• Hạnh phúc phụ thuộc vào ngữ cảnh so sánh: người ít tiền nhưng ở xã hội nghèo có thể thấy vui hơn người giàu ở nơi toàn tỷ phú.
• So sánh làm giảm cảm nhận thực sự về hạnh phúc.

4. Không tin người khác

• Chúng ta từ chối lời khuyên từ người đã trải nghiệm và tin rằng mình sẽ cảm thấy khác.
• Nhưng thực tế, hỏi người đã trải qua là cách dự đoán tốt nhất về cảm xúc tương lai.

Một số minh họa nổi bật

• Người trúng số không hạnh phúc lâu như tưởng tượng.
• Người bị liệt có thể cảm thấy vui vẻ sau một thời gian, dù lúc chưa bị thì nghĩ đó là tận thế.

Bài học ứng dụng

• Đừng đánh giá tương lai chỉ dựa trên tưởng tượng.
• Lắng nghe trải nghiệm người khác, đặc biệt là những người từng trải điều bạn đang cân nhắc.
• Hạnh phúc là ngắn hạn và dao động – học cách tận hưởng quá trình hơn là tìm kiếm điểm đến hoàn hảo.

3. Clean Architecture – Robert C. Martin (Uncle Bob)

Mục tiêu của kiến trúc phần mềm tốt:

• Dễ thay đổi, test, bảo trì.
• Không bị “khóa chết” vào framework hay công nghệ.
• Giảm nợ kỹ thuật và tăng tuổi thọ hệ thống.

Các tầng kiến trúc (Onion Architecture)

1. Entities – Tầng cốt lõi

• Luật nghiệp vụ trung tâm, độc lập với bên ngoài.
• Không có phụ thuộc.
• Ví dụ: Invoice, Order chứa quy tắc kiểm tra hợp lệ.

2. Use Cases – Quy trình ứng dụng

• Triển khai logic ứng dụng cụ thể.
• Có thể gọi repository, entity, gửi email, tạo báo cáo...
• Không quan tâm cách lưu trữ hay UI.

3. Interface Adapters – Bộ chuyển đổi

• Chuyển dữ liệu để các tầng hiểu nhau.
• Gồm: Controller, Presenter, ViewModel, Gateway (Data Access).
• Ví dụ: chuyển Entity sang DTO cho UI.

4. Frameworks and Drivers

• Layer ngoài cùng, thay đổi thường xuyên nhất.
• Gồm: Database, UI, Framework (Angular, Spring...).
• Phụ thuộc vào tầng trong nhưng không được làm ngược lại.

Dependency Rule – Quy tắc phụ thuộc

• Mọi phụ thuộc đều hướng vào trong.
• Không có tầng trong nào biết tầng ngoài.
• Điều này giúp dễ thay đổi UI, framework, DB mà không ảnh hưởng business logic.

Các nguyên tắc hỗ trợ:

• SRP, OCP, DIP: Các nguyên lý SOLID giúp chia module dễ test, dễ bảo trì.
• DI (Dependency Injection): Inject phụ thuộc thay vì hardcode – tăng khả năng test.

Bài học ứng dụng

• Luôn đặt logic nghiệp vụ ở vị trí trung tâm – tách biệt UI, DB, framework.
• Tạo code base có thể sống 10 năm bất kể công nghệ thay đổi.
• Test unit từng layer dễ dàng, giảm bug khi thay đổi.