# Software Engineering at Google: cuốn sách dạy FDE nghĩ bằng năm tháng thay vì bằng dòng code

> Cuốn sách của ba kỹ sư Google gần như không bàn chuyện viết code. Nó bàn chuyện gì xảy ra với code sau khi bạn đã rời dự án, và đó lại là câu hỏi một FDE phải trả lời ở mọi khách hàng.

Bản gốc: https://fdetimes.net/vi/sach-khoa-hoc/sach-software-engineering-at-google/

Chương đầu của một cuốn sách mang tên Google không mở bằng thuật toán hay kiến trúc. Nó mở bằng một định nghĩa ngắn: kỹ thuật phần mềm là lập trình trải dài theo thời gian.

Câu đó là chìa khóa của *Software Engineering at Google*, cuốn sách của Titus Winters, Tom Manshreck và Hyrum Wright. Theo trang của Google Research, sách do O'Reilly xuất bản năm 2020. Trang của nhóm tác giả trên Abseil ghi mốc ra mắt là tháng 3/2020.

Với người muốn làm FDE, đây là cuốn đáng đọc hơn nhiều sách "clean code". Thử nghĩ về công việc ấy: nếu code bạn viết ở khách hàng vẫn chạy sau khi bạn đã chuyển sang dự án khác, thì câu hỏi về thời gian của cuốn sách cũng là câu hỏi của chính bạn.

## Không phải sách dạy code, cũng không phải sách thiết kế

Trang Abseil nói thẳng rằng cuốn sách không hẳn bàn về lập trình mà bàn về các thực hành kỹ thuật được dùng ở Google. Lời nói đầu còn nói rõ thêm: sách không bàn về thiết kế phần mềm. Nội dung được chia thành ba nhóm là văn hóa, quy trình và công cụ.

Các tác giả cũng cẩn thận nói rằng kinh nghiệm trong sách không nhằm áp đặt điều tổ chức của bạn nên làm. Chi tiết này quan trọng với người đọc ở Việt Nam. Bạn sẽ không có monorepo cỡ Google hay đội tooling riêng, nên hãy đọc để lấy cách đặt câu hỏi, không phải để sao chép quy trình.

Một điểm cộng thực tế: nhóm tác giả cung cấp bản HTML miễn phí tại abseil.io/resources/swe-book. Họ vẫn khuyến khích mua bản in từ O'Reilly nếu bạn muốn ủng hộ.

## Ý thứ nhất: code của bạn phải sống lâu hơn dự án

Sách chỉ ra ba khác biệt cốt lõi giữa lập trình và kỹ thuật phần mềm: thời gian, quy mô và các đánh đổi. Một script viết xong chạy một lần là lập trình. Một pipeline dữ liệu chạy ở khách hàng suốt ba năm, qua nhiều đời kỹ sư, là kỹ thuật phần mềm.

Từ đó sách định nghĩa một codebase bền vững là codebase mà bạn thay đổi được mọi thứ đáng phải thay đổi. Định nghĩa này không nói về code đẹp. Nó nói về khả năng sửa: thay thư viện, vá lỗ hổng bảo mật, đổi phiên bản runtime mà hệ thống không sụp.

Thử hình dung bạn deploy một agent cho một ngân hàng. Sáu tháng sau, model nền tảng có bản mới và SDK đổi interface. Nếu khách hàng không tự nâng cấp được khi bạn đã đi, deployment đó không bền vững, dù demo hôm bàn giao có đẹp đến đâu.

## Ý thứ hai: mọi hành vi đều sẽ có người dựa vào

Chương 1 phát biểu Hyrum's Law, định luật mang tên chính đồng tác giả Hyrum Wright. Đại ý: khi đủ nhiều người dùng một hệ thống, mọi hành vi quan sát được của nó sẽ có ai đó phụ thuộc vào.

Với FDE, định luật này giải thích gần như mọi sự cố "tôi đâu có đổi gì". Thử nghĩ tới một API bạn dựng cho khách hàng trả kết quả theo một thứ tự mà tài liệu không hề cam kết. Đội báo cáo của họ âm thầm dựa vào thứ tự đó. Bạn tối ưu query, thứ tự đổi, và dashboard của giám đốc sai số liệu.

**Điểm mấu chốt:** Hợp đồng thật của một hệ thống không nằm trong tài liệu API, mà nằm trong mọi thứ người dùng quan sát được.

Bài học ở đây là bản năng hỏi trước khi sửa: ai đang đọc output này, đọc bằng cách nào, và họ có thể đang dựa vào điều gì mà bạn chưa từng hứa.

## Ý thứ ba: nâng cấp là bài toán đánh đổi, không phải nguyên tắc

Sách không bảo bạn lúc nào cũng phải nâng cấp. Quyết định ấy phụ thuộc vào chi phí nâng cấp, giá trị nó mang lại và tuổi thọ dự kiến của dự án. Một prototype sống ba tuần không cần cùng kỷ luật với hệ thống lõi sống mười năm.

Lời khuyên cho buổi phỏng vấn: nếu được hỏi về một quyết định kỹ thuật khó, hãy kể nó bằng ba biến này. Một câu trả lời nêu rõ chi phí, giá trị và vòng đời dự án sẽ thuyết phục hơn câu "tôi chọn công nghệ mới nhất".

## Ai nên đọc, và nên mở trang nào trước?

Nếu bạn có 2-4 năm kinh nghiệm và mới chỉ làm feature trong một sản phẩm, hãy bắt đầu với Lời nói đầu và Chương 1. Hai phần này đủ để thay cách bạn nhìn công việc của mình. Sau đó, chọn đọc tiếp theo ba nhóm văn hóa, quy trình, công cụ, ưu tiên nhóm gần nhất với vấn đề bạn đang gặp.

Nếu bạn đã 5-8 năm và từng giữ hệ thống qua nhiều lần nâng cấp, cuốn sách sẽ cho bạn từ vựng để gọi tên những gì đã trải qua. Từ vựng đó có giá trị khi phỏng vấn và khi thuyết phục một khách hàng vì sao chưa nên nâng cấp ngay.

Còn nếu bạn đang tìm sách dạy thiết kế hệ thống, đây không phải cuốn đó, chính tác giả đã nói vậy.

Một FDE giỏi được đánh giá bằng câu hỏi ít ai hỏi lúc demo: một năm sau khi bạn rời đi, hệ thống ở khách hàng còn sửa được không?

**Thử ngay tuần này:**

- Đọc Lời nói đầu và Chương 1 trên abseil.io/resources/swe-book, ghi ra ba trục thời gian, quy mô, đánh đổi bằng ví dụ từ dự án của chính bạn.
- Chọn một API hoặc integration bạn đang giữ, liệt kê mọi hành vi quan sát được ngoài tài liệu (thứ tự kết quả, format lỗi, độ trễ) và đánh dấu cái nào có thể đã có người phụ thuộc.
- Viết lại một gạch đầu dòng trong CV mô tả một quyết định nâng cấp hoặc không nâng cấp, nêu rõ chi phí, giá trị và tuổi thọ dự án đã được cân nhắc.

## Nguồn

- [Software Engineering at Google (Abseil)](https://abseil.io/resources/swe-book)

- [Software Engineering at Google (Google Research)](https://research.google/pubs/software-engineering-at-google/)

- [Chapter 1 - What Is Software Engineering? (Software Engineering at Google)](https://abseil.io/resources/swe-book/html/ch01.html)

- [Preface - Software Engineering at Google](https://abseil.io/resources/swe-book/html/pr01.html)