Fluent Python bản 2: những chương giúp FDE đọc code khách hàng như người viết ra nó

Trong bảng mục lục của Fluent Python bản 2, chỉ bốn chương mang dấu 🆕: Data Class Builders (chương 5), Type Hints in Functions (8), More About Type Hints (15) và Concurrency Models in Python (19). Luciano Ramalho, tác giả cuốn sách (O’Reilly, 2022), còn viết lại đáng kể các chương về đồng thời.

Những thay đổi đó khớp với công việc của một FDE. Thử hình dung tuần đầu ở một khách hàng: rất có thể bạn sẽ dành nhiều thời gian đọc code người khác viết, và code ấy nhiều khả năng có type hint, có class dữ liệu dựng bằng công cụ, có pipeline gọi API song song.

Nếu đúng vậy, bốn chương mới rất có thể trùng với những loại code bạn cần đọc nhanh nhất. Hai ví dụ về type hint và đồng thời bên dưới cho thấy vì sao, kèm thứ tự đọc và việc cần làm ở mỗi phần.

Ai nên mở cuốn này, và khi nào?

Đây không phải sách nhập môn: cả người điểm sách của ACCU lẫn blog hamatti.org đều cho rằng nó dành cho người đã có kinh nghiệm viết Python.

Nếu bạn mới học, hãy viết code thật vài tháng rồi hẵng mở; còn nếu đã viết Python vài năm mà vẫn thấy mình “dịch” từ Java hay C# sang, đừng đọc từ đầu đến cuối mà đi theo thứ tự trong sơ đồ ở đầu bài.

Ý thứ nhất: hành vi của object nằm trong special method

Sách mở đầu bằng Python data model, rồi tới list, dict, set. Đây là nền móng để đọc code Python “bản địa”: các phương thức có hai dấu gạch dưới như __len__ hay __getitem__ quyết định một object ứng xử thế nào khi được truyền vào các hàm có sẵn như len().

Lấy một ví dụ giả định: trong code khách hàng có dòng len(batch), với batch là object của một class tự viết. Đi tìm một phương thức tên len thì sẽ không thấy; câu trả lời nằm ở __len__. Quen cách nhìn này, bạn đọc một class lạ bằng cách liệt kê các special method của nó trước, rồi mới đọc phần còn lại.

Chương 5 là chương mới hoàn toàn. Nên đọc nó ngay sau phần data model, vì rất nhiều class dữ liệu bạn gặp có thể được sinh ra bằng công cụ dựng class thay vì viết tay từng dòng.

Ý thứ hai: type hint là tấm bản đồ, không phải lớp bảo vệ

Bản 2 dành hẳn hai chương mới, 8 và 15, cho type hints. Với FDE, giá trị của chúng nằm ở chỗ bạn hiểu được hệ thống trước khi chạy nó.

Hình dung một hàm trong SDK của khách có chữ ký def fetch(ids: list[str]) -> dict[str, Order] | None. Chỉ một dòng đó đã cho bạn biết đầu vào là gì, đầu ra ra sao, và rằng phải xử lý trường hợp None. Thiếu hint, bạn sẽ phải đặt breakpoint và đoán.

Nhưng có một điều Ramalho nhấn mạnh trên podcast công nghệ của Thoughtworks: annotation không có tác dụng gì lúc chạy; chính công cụ như mypy mới dùng chúng để bắt lỗi trong mã nguồn. Tấm bản đồ chỉ đáng tin khi có người thường xuyên kiểm nó.

Ý thứ ba: chọn mô hình đồng thời trước khi viết

Chương 19 về các mô hình đồng thời là chương mới, nằm trong phần sách được viết lại nhiều nhất. Nó đáng đọc kỹ vì cho bạn từ vựng để phân biệt thread, process và async trước khi đụng vào code.

Thử hình dung một job tích hợp phải gọi 200 endpoint của khách, mỗi lần mất khoảng 0,5 giây, gần như toàn bộ là chờ mạng. Chạy tuần tự hết 200 × 0,5 = 100 giây, trong khi CPU gần như ngồi không. Đây là tác vụ chờ I/O, nên song song hóa việc chờ là đúng hướng.

Nếu SDK của khách là thư viện đồng bộ, một thread pool 20 worker là cách phải sửa ít code nhất: 200 lời gọi chia thành 10 đợt, còn khoảng 5 giây. Nếu cả chuỗi đã có client async, asyncio với giới hạn 20 request cùng lúc cho kết quả tương tự. Còn nếu phần chậm là parse dữ liệu nặng CPU, cả hai cách đều không cứu được bạn.

Ba cái bẫy khi mang sách vào dự án thật

Bẫy đầu tiên là chép nguyên mẫu asyncio từ sách vào code của khách. Người điểm sách của ACCU cho rằng các chương lập trình bất đồng bộ đã lỗi thời, vì thế hãy lấy tư duy từ chương 19, còn API cụ thể thì đối chiếu với tài liệu Python hiện hành trước khi dùng.

Bẫy thứ hai là tin hint trong một repo chưa bao giờ chạy mypy. Vì annotation không có tác dụng lúc chạy, hint có thể đã lệch khỏi thực tế từ lâu mà không ai hay.

Việc nên làm trong ngày đầu là hỏi đội của khách xem CI có chạy type checker không; nếu không, hãy chạy thử mypy trên máy mình và coi số lỗi là thước đo độ tin cậy của tấm bản đồ.

Bẫy thứ ba là song song hóa trước khi đo. Trước dòng song song đầu tiên, đo xem một lời gọi mất bao lâu và đặt giới hạn số request, để job của bạn không làm quá tải API của chính khách.

Biến việc đọc thành bằng chứng trong CV

Mã ví dụ chính thức nằm ở repo fluentpython/example-code-2e trên GitHub, còn fluentpython.com là site đồng hành của bản 2, có thêm các bài mở rộng ở mục extra.

Cách đọc hiệu quả nhất là vừa đọc vừa refactor. Chọn một project Python cũ của chính bạn, chuyển các class dữ liệu viết tay sang data class, thêm type hint và để mypy chạy trong CI. Trong CV, một dòng ghi rõ bạn đã làm gì kèm link tới commit sẽ thuyết phục hơn nhiều so với chữ “thành thạo Python”.

Thuộc lòng cú pháp không phải đích đến. Đích đến là mở một repo lạ ra và hiểu nó đủ nhanh để đội của khách tin bạn, và mấy chương trên là lộ trình ngắn nhất để luyện đúng kỹ năng đó.