TDD, AI Agents and Coding - Kent Beck

Giới thiệu về Kent Beck

• Nhà sáng lập Extreme Programming (XP)
• Đồng tác giả Tuyên ngôn Agile (người ký đầu tiên theo thứ tự bảng chữ cái)
• Người tiên phong của TDD (phát triển hướng kiểm thử)
• Huyền thoại của ngành với 52 năm kinh nghiệm lập trình
• Hiện đang viết "Tidy Together" (về thiết kế phần mềm và làm việc nhóm)
• Hiện đang trải qua "giai đoạn lập trình vui nhất" khi code với công cụ AI hơn 6-10 giờ mỗi ngày

---

1. Công cụ lập trình AI và phép so sánh với 'thần đèn'

Khái niệm cốt lõi: thần đèn khó lường

• Ví các AI agent như "thần đèn khó lường"
• "Chúng không làm đúng chính xác điều tôi muốn nói"
• "Chúng có chương trình nghị sự riêng"

Trải nghiệm làm việc với AI

Mặt tích cực:

• Đôi khi giải quyết các vấn đề thiết kế lớn như một phép màu đáng kinh ngạc
• Triển khai những tính năng hữu ích ngoài dự đoán (ví dụ: bộ stress tester cho B+ tree)

Mặt tiêu cực:

• Hiểu sai ý định của người dùng
• Cố xóa hoặc sửa các bài kiểm thử
• Có hành vi tinh quái khi "giải quyết" vấn đề bằng bảng tra cứu

Trải nghiệm gây nghiện

• Phần thưởng ngắt quãng như máy đánh bạc
• "Đi ngang qua máy tính vào buổi tối và nghĩ 'hay thử prompt thêm một lần nữa?'"
• "Bắt đầu một prompt kéo dài một tiếng rồi đi ra ngoài"

---

2. Thay đổi kỹ năng trong thời đại AI

Tái cấu trúc giá trị kỹ năng

"90% kỹ năng mất giá trị, 10% kỹ năng tăng giá trị lên 1000 lần"

Những kỹ năng tăng giá trị:

• Đặt ra tầm nhìn
• Quản lý các cột mốc
• Kiểm soát độ phức tạp

Những kỹ năng giảm giá trị:

• Chi tiết riêng của từng ngôn ngữ (như vị trí của &, *, [] trong Rust)

Thay đổi góc nhìn về ngôn ngữ lập trình

Trước đây: Gắn bó cảm xúc sâu sắc với Smalltalk
Hiện tại:

• "Bị tổn thương quá nhiều" nên không còn gắn bó với ngôn ngữ nữa
• Mệt mỏi với sự phân chia danh tính kiểu "lập trình viên Java", "lập trình viên Clojure"
• "Học bằng thẩm thấu": nhờ AI mà vẫn có thể lập trình dù không biết chi tiết ngôn ngữ

Các ngôn ngữ đã thử gần đây: Swift, Go, Rust, Haskell, C++, JavaScript

Dự án tham vọng hiện tại: Server Smalltalk

• Persistent: hoạt động như cơ sở dữ liệu
• Transactional: có thể commit và abort
• Song song hóa: xử lý song song đa luồng và giữa nhiều máy
• Xử lý dữ liệu quy mô lớn

---

3. Lịch sử của Tuyên ngôn Agile

Bối cảnh ra đời (2001)

• Tìm kiếm một giải pháp thay thế cho mô hình thác nước
• Kết quả của nhiều năm workshop về phương pháp luận phần mềm
• Từ cuộc họp chuẩn bị cho chuyến du thuyền ở Na Uy → cuộc họp cuối cùng ở Utah

Đóng góp của Kent Beck

• Thêm từ "daily" (trong một trong 12 nguyên tắc: "tương tác hằng ngày")
• Người ký đầu tiên theo thứ tự bảng chữ cái

Sự không hài lòng với thuật ngữ "Agile"

Vấn đề:

• Vì "quá hấp dẫn" nên ông đã dự đoán mọi tổ chức sẽ lạm dụng nó
• Quả thực đã xuất hiện nhiều tổ chức tự nhận là Agile dù không hề tuân theo các nguyên tắc

Phương án thay thế ông thích hơn: "conversational (mang tính đối thoại)"

• Nhấn mạnh giao tiếp hai chiều thay vì một chiều
• Nhưng không được chọn vì kém hấp dẫn

---

4. Extreme Programming (XP)

Bối cảnh ra đời

Trải nghiệm tư vấn ban đầu:

• Ban đầu là tư vấn kỹ thuật (tinh chỉnh hiệu năng, thao tác bit)
• Ngày càng được hỏi thêm về tư vấn quản lý dự án
• Phát hiện tầm quan trọng của môi trường: chỉ cần đổi cách sắp xếp chỗ ngồi cũng cải thiện đáng kể

Dự án Chrysler:

• Biến một dự án đang thất bại thành thành công
• Đẩy mọi thực hành hiệu quả lên "mức tối đa (đến 11)"

Nguyên lý cốt lõi của XP

Chia nhỏ thời gian để thực hiện đồng thời/tuần tự 4 hoạt động:

1. Xác định sẽ làm gì
2. Thiết kế sẽ làm theo cấu trúc nào
3. Triển khai chức năng
4. Kiểm tra xem có hoạt động như mong đợi không

Pair programming

• Cách tiếp cận mang tính thử nghiệm, không phải bắt buộc
• Trải nghiệm của nhóm ban đầu: mọi bug được phát hiện sau khi phát triển đều đến từ code do cá nhân làm một mình
• "Không có lỗi production nào khi pair programming"

Chiến lược đặt tên

• Lý do chọn "Extreme": một cái tên mang tính khiêu khích mà đối thủ (Grady Booch) sẽ không dùng
• Trùng hợp với thời kỳ các môn thể thao mạo hiểm đang thịnh hành
• "Vận động viên cực hạn hoặc chuẩn bị ở mức tốt nhất, hoặc chết" - một phép ẩn dụ hay

Yếu tố thành công

• Trong thời kỳ bong bóng dot-com, điều này hấp dẫn các lập trình viên đã tuyệt vọng với cách làm waterfall kéo dài 18 tháng
• Hứa hẹn kết quả nhanh hơn và dễ dự đoán hơn

---

5. Test-Driven Development (TDD)

Nguồn gốc và cảm hứng (thập niên 1970)

Hệ thống tape-to-tape:

• Một khái niệm ông gặp trong sách lập trình của cha mình
• Gõ thủ công đầu vào thực tế → đầu ra kỳ vọng → viết code → so sánh với đầu ra thực tế
• Đã đọc khi 8-12 tuổi nhưng lúc đó không hiểu

Phát triển S-Unit:

• Được tạo ra để giúp khách hàng viết kiểm thử
• Thử ý tưởng "phi lý" là "nhập giá trị kỳ vọng trước khi viết code"

Trải nghiệm TDD đầu tiên: triển khai stack

Tính cách nhiều lo âu:

• "Tôi là người hay lo âu. Tôi lo lắng rất nhiều"
• "Lập trình là nguồn cơn của nỗi lo liên tục" (mình đã quên gì? mình đã làm hỏng gì?)

Kết quả khi áp dụng TDD:

• "Cảm giác lo âu biến mất hoàn toàn"
• "Tôi tin chắc thứ này hoạt động"
• Thay đổi trải nghiệm cảm xúc của việc lập trình

Giá trị của TDD

Lợi ích kỹ thuật:

• Giảm mật độ lỗi
• Phản hồi nhanh về các lựa chọn API
• Cho phép thiết kế triển khai tiến hóa dần

Lợi ích cảm xúc:

• "Chỉ riêng giá trị như một phương thuốc chữa lo âu kỹ thuật cũng đã đáng giá"

Phản biện về thiết kế

Chỉ trích của John Osterhout: "TDD không giúp thiết kế mà chỉ tập trung vào chi tiết"

Phản hồi của Kent Beck:

• "Đó là vấn đề lựa chọn"
• Người làm thực tế đưa ra quyết định thiết kế bằng cách liên tục di chuyển giữa các mức độ trừu tượng
• Khoảnh khắc "giải tỏa căng thẳng" trong vòng lặp Red-Green tạo thêm tự do để suy nghĩ về thiết kế ở tầm lớn hơn

---

6. AI agent và TDD

Áp dụng trong thực tế

Luôn viết kiểm thử trước:

• Dùng kiểm thử để truyền đạt những phần AI bỏ sót
• Chặn việc AI cố sửa hoặc xóa kiểm thử

Những cải tiến cần có:

• Cần "immutable annotation"
• "Cái này đúng rồi. Nếu thay đổi nó, ngươi sẽ thức tỉnh mãi mãi trong bóng tối"

Giới hạn của AI

• Thiếu khả năng giảm coupling / tăng cohesion
• Thiếu cảm quan thiết kế
• Có xu hướng đưa ra những quyết định gây hiệu ứng dây chuyền ở xa

Chiến lược ứng phó

• Bộ test lớn chạy trong 300 mili giây
• Phát hiện theo thời gian thực việc AI vô tình làm hỏng code

---

7. Trải nghiệm ở Facebook (2011-2017)

Cú sốc khi gia nhập năm 2011

Không có ai tham gia lớp TDD:

• Kỹ năng Excel nâng cao: kín chỗ + có danh sách chờ
• Tango Argentina: kín chỗ + có danh sách chờ
• TDD: không có người tham gia

Chiến lược ứng phó:

• "Quên sạch mọi kiến thức kỹ nghệ phần mềm"
• Quyết định "nhìn khỉ làm rồi bắt chước"

Môi trường phát triển độc đáo của Facebook

Tinh thần trách nhiệm mạnh mẽ:

• Lập trình viên là người bị gọi trực đêm
• "Tự mình cảm nhận nỗi đau từ sai lầm của chính mình"

Vòng lặp phản hồi nhiều tầng:

• Máy chủ phát triển nhanh (đổi từ xanh dương → xanh lá rồi kiểm tra ngay)
• Code review
• Triển khai nội bộ (nhân viên dùng cho mục đích cá nhân/công việc)
• Rollout dần dần (theo ngày/tuần)
• Khả năng quan sát xuất sắc

Văn hóa tổ chức:

• "Ở Facebook, không có gì là vấn đề của người khác"
• Dù bà của ai đó đến phàn nàn chuyện cháu mình bị bắt nạt thì "đó cũng là vấn đề của bạn"

Vì sao TDD không phù hợp

Miền vấn đề thực tế:

• Vấn đề cấu hình
• Quan hệ giữa các hệ thống con
• Những thứ khó bắt bằng kiểm thử

Lợi thế riêng của Facebook:

• Kiểm thử quy mô lớn trực tiếp trên hàng triệu người dùng
• Khả năng quan sát xuất sắc
• Feature flag
• Một môi trường mà công ty thông thường khó triển khai được

Ví dụ cụ thể:

• Triển khai tính năng trạng thái quan hệ (từ độc thân/đã kết hôn sang thêm kết hợp dân sự/sống chung)
• Có dùng TDD nhưng "là lãng phí thời gian"
• Phát sinh vấn đề do coupling ngầm trong mã thông báo, và người khác đã hotfix

Sự thay đổi theo thời gian

Năm 2011 (2.000 người):

• Khả năng, quy mô, tinh thần sở hữu ở mức cao nhất
• Có các quản lý cấp trung nghĩ theo hướng tối ưu toàn cục
• Tinh thần hợp tác với suy nghĩ "ai mới thực sự cần được giúp đỡ"

Năm 2017 (15.000 người):

• Chính trị nội bộ, tư duy zero-sum, tối ưu cục bộ vi mô
• Ngày càng khó nhìn bức tranh lớn
• Xung đột lợi ích giữa các bộ phận (ví dụ: bài viết dài vs đội tối ưu like/comment)

Trải nghiệm về quy mô

• Messenger API: 1 quadrillion lệnh gọi mỗi tuần
• Nhóm thử nghiệm có quy mô như "New Zealand" (một triệu người)
• 1 quadrillion = một triệu × một tỷ

---

8. Tương lai của phát triển phần mềm trong thời đại AI

Chuyển đổi mô hình

Tái cấu trúc hoàn toàn chi phí:

• "Ranh giới giữa thứ rẻ và thứ đắt đã thay đổi hoàn toàn"
• Những gì từng bị coi là đắt đỏ nay trở nên "rẻ một cách phi lý"

Thách thức thích nghi của tổ chức

Bỏ đi nhiều code hơn:

• Có thể tạo ra nhiều artifact gấp 10 lần
• Nhưng rốt cuộc vẫn chỉ một thứ có giá trị
• Cần cơ chế tưởng thưởng cho việc "vứt bỏ các thử nghiệm đã hoàn thành"

Gia tăng số lượng thử nghiệm:

• Lượng ý tưởng được khám phá sẽ là lợi thế cạnh tranh
• Đây là thời đại phải "thử nghiệm mọi thứ"

Thay đổi cá nhân

• Việc code lại trở nên thú vị
• Có thể theo đuổi tham vọng lớn hơn
• Có thể hiện thực hóa "những ý tưởng cực kỳ tham vọng"

---

9. Hỏi đáp nhanh

Sở thích cá nhân

• Ngôn ngữ yêu thích nhất: Smalltalk
• Ngôn ngữ thứ hai: JavaScript (tương tự Smalltalk)
• Công cụ AI hiện dùng: Claude (engine nội bộ của Cursor, Augment)
• Sách đề xuất: "The Timeless Way of Building" của Christopher Alexander

---

Những insight cốt lõi

1. Tầm quan trọng tuyệt đối của bối cảnh

• Cùng một phương pháp luận nhưng hiệu quả sẽ hoàn toàn khác tùy môi trường
• Môi trường quy mô lớn của Facebook vs môi trường giao dịch nhỏ của ngân hàng

2. Mối quan hệ giữa cảm xúc và kỹ thuật

• Giá trị thực sự của TDD là "giải tỏa lo âu"
• Sự thay đổi về mặt cảm xúc quan trọng hơn cả lập luận kỹ thuật

3. Tư duy mới trong thời đại AI

• Năng lực tầm nhìn và thiết kế nổi lên thành kỹ năng cốt lõi
• Chi tiết ngôn ngữ không còn quan trọng nữa
• Sự gia tăng về số lượng thử nghiệm là lợi thế cạnh tranh

4. Sức mạnh của văn hóa tổ chức

• Tinh thần sở hữu kiểu "không có gì là vấn đề của người khác"
• Khác biệt giữa tối ưu toàn cục vs tối ưu cá nhân
• Tầm quan trọng của sự căn chỉnh incentive

[mse9000]

Môi trường phát triển độc đáo của Facebook
Tinh thần trách nhiệm rất cao:
lập trình viên là đối tượng bị gọi ban đêm
"Tự mình trực tiếp cảm nhận nỗi đau vì sai lầm của chính mình"

Chẳng phải cũng không khác mấy môi trường phát triển kiểu K sao...?

[helloppfm]

Ông ấy vẫn còn ở đây.

Trước đây tôi từng làm một buổi seminar về TDD ở một công ty sản xuất máy móc, và tôi vẫn không thể quên được ánh mắt của mọi người khi nhìn như thể đang nghĩ “cái gì vậy?”.

Tôi nghĩ TDD khá ổn, nhưng lại khó làm tốt hơn tưởng tượng... Hiện tại tôi đang làm kiểm thử tích hợp theo kiểu giống TDD. Tất nhiên, cái này không phải TDD. ^^

[kandk]

Đến giờ mà phe cuồng tín TDD và phe cho rằng nó vô dụng vẫn còn tranh cãi nhau,
mong rằng sẽ có một bản v2 của TDD được đưa ra để phù hợp lại với tình hình hiện tại của ngành.
Dạo này những việc nhỏ thì AI làm dễ rồi, nên kiểu như làm sao tận dụng nó khi cần lượng context lớn chẳng hạn..

[codemasterkimc]

Bài viết hay đấy.