Việc viết bài viết này xuất phát từ một vài yếu tố:
Các vấn đề với mã nguồn được tạo tự động khi làm việc nhóm.
Gánh nặng nhận thức ngày càng tăng.
Sự áp đặt mạnh mẽ (ép buộc) từ phía Giám đốc Công nghệ (CTO) và tầng lớp quản lý.
Nhìn
chung, tôi cũng khó thảo luận sâu sắc với các đồng nghiệp xung quanh
nên cần một lượng khán giả lớn hơn. Khi đưa ra những gợi ý để cùng suy
ngẫm, tôi thường chỉ nhận lại các bài viết tiếp thị từ những bên hưởng
lợi từ Mô hình ngôn ngữ lớn (LLM), hoặc là những cách so sánh rất kỳ
quặc mà tôi cũng sẽ phân tích trong bài viết này.
Nhìn chung,
trong bài viết này tôi không cố gắng (thôi được rồi, thực ra là có cố
gắng) thuyết phục bất kỳ ai, thông điệp của tôi chỉ là muốn chúng ta đặt
ra nhiều câu hỏi hơn và suy nghĩ về những ranh giới áp dụng rõ ràng hơn
của AI/LLM trong phát triển phần mềm.
Những điều bài viết này sẽ không đề cập
Tôi
không thấy có lý do gì để bài xích việc sử dụng LLM hoàn toàn. Chúng rõ
ràng mang lại lợi ích và chắc chắn giúp đẩy nhanh một số công việc lặp
đi lặp lại mang tính thủ tục.
Các ví dụ về câu lệnh như: "Tạo cho
tôi một file json để làm dữ liệu giả (mock data), đây là sơ đồ hợp
đồng", "Bạn nghĩ gì về...", "Bạn có thấy vấn đề gì trong đoạn mã này
không...", "Đây là một truy vấn ORM, tôi cần một truy vấn SQL tương
đương theo ngôn ngữ của postgreSQL", "Tôi đang viết bằng ngôn ngữ X,
khung làm việc (framework) Y, gặp phải vấn đề này, đây là nhật ký lỗi
(log), nguyên nhân là gì và tôi có thể khắc phục như thế nào..."
Đó
là những câu lệnh mà theo tôi hoàn toàn hợp lý và LLM xử lý chúng rất
tuyệt vời trong hầu hết các trường hợp. LLM rất tốt đóng vai trò như một
ý kiến tham khảo thứ hai (second opinion). Vì vậy, sẽ không có sự thù ghét cực đoan nào đối với LLM ở đây.
Và những điều bài viết này sẽ đề cập
Trong bài viết này, tôi sẽ xem xét các vấn đề khi sử dụng LLM như một công cụ chính. Tôi xin nhấn mạnh lại: Không phải là một công cụ tham khảo phụ trợ,
mà là một công cụ chính, tự viết phần lớn mã nguồn trong các yêu cầu
hợp nhất (merge requests) lên tới hàng trăm và hàng ngàn dòng mã. Đồng
thời, tôi cũng xem xét các trường hợp ranh giới, khi lập trình viên được
cho là đang đọc mã được tạo ra và kiểm soát các tác nhân AI (agents).
Các vấn đề
1. Mã nguồn được tạo tự động khi làm việc nhóm
Về
các yêu cầu hợp nhất (merge requests): LLM tạo ra rất nhiều mã, nhưng
LLM không có khả năng suy nghĩ sâu sắc về một tính năng, không thể lập
ra danh sách các câu hỏi để tìm gặp giám đốc sản phẩm/nhà thiết kế/nhà
phân tích nhằm có thêm thông tin giúp tư duy và viết ra những đoạn mã
đơn giản, trực quan hơn.
LLM chỉ viết mã cho yêu cầu hiện tại,
chúng không quan tâm đến ngày mai sẽ ra sao, không quan tâm đến lộ trình
phát triển (roadmap), không quan tâm đến hệ lụy đối với các dịch
vụ/mô-đun lân cận. Kết quả là chúng ta thấy một lượng mã khổng lồ chỉ
cho một tính năng nhỏ trong yêu cầu hợp nhất.
Vài ngày sau, có yêu
cầu thêm một tính năng khác vào chính mô-đun đó, LLM lại xáo trộn toàn
bộ mã và một bản so sánh khác biệt (diff) với +1500 dòng và -1400 dòng
lại xuất hiện. Việc đọc những khối lượng lớn như vậy một cách thường
xuyên là điều không thể. Điều này không những không tăng tốc độ phát
triển mà còn xóa sạch mọi điểm cộng của công nghệ. Nó làm tăng tốc độ
thay đổi của kho mã (codebase) đến mức bộ não không thể tải nổi.
Sau
vài lần lặp đi lặp lại như vậy, tôi không còn hiểu dịch vụ mà mới ngày
hôm qua tôi còn nắm khá rõ và có thể nhanh chóng sửa các lỗi đột xuất
nhờ hiểu sâu về kho mã. Giờ đây, ngay cả việc sửa lỗi cũng sẽ mất nhiều
thời gian hơn. Gánh nặng nhận thức tăng vọt lên tận trời xanh. Lập trình
viên đáng lẽ phải chiến đấu chống lại sự phức tạp, nhưng điều ngược lại
đã xảy ra.
Hệ quả là chất lượng đánh giá mã (code review) giảm
sút. Từ đó kéo theo chất lượng của mã nguồn và chất lượng của các bản
phát hành/sản phẩm nói chung cũng đi xuống.
2. Gánh nặng nhận thức ngày càng tăng
Ý
này có phần trùng lặp với ý trước. Tuy nhiên, tôi muốn tập trung vào
những khía cạnh khác một chút. Tính đến năm 2026, hầu hết các bên tham
gia vào thế giới IT vẫn đang đánh giá thấp mức độ gánh nặng nhận thức.
Yếu tố này lại ảnh hưởng trực tiếp đến cả áp lực cảm xúc lẫn sức khỏe
của lập trình viên nói chung.
Hiện nay, trong công việc hàng ngày,
lập trình viên phải sử dụng hàng tá công cụ khác nhau ngoài kiến thức
về chính ngôn ngữ lập trình đó. Đó là các công cụ kiểm tra lỗi cú pháp
(linters), công cụ định dạng mã (formatters), các thùng chứa
(containers), quy trình CI/CD, hệ thống theo dõi công việc, các phương
pháp luận, các kiến trúc khác nhau cùng các nguyên lý như SOLID, công cụ
kiểm tra kiểu dữ liệu, công cụ kiểm tra tải, các trình giả lập, hệ
thống quản lý phiên bản, cơ sở dữ liệu, các hệ thống chuyển tiếp tin
nhắn (brokers) và nhiều, nhiều thứ khác nữa.
Chưa kể bản thân các
ngôn ngữ lập trình ngày càng trở nên phức tạp hơn. Tôi chưa thấy ngôn
ngữ nào trở nên đơn giản đi cả. Ngôn ngữ hướng đối tượng của ngày hôm
qua thì ngày hôm nay đã liên tục chạy các nhánh bằng so khớp mẫu
(pattern matching) thay cho các câu lệnh if quen thuộc. Để làm quen với
toàn bộ "sở thú" này cần vài tháng, còn để làm chủ được nó thì phải mất
nhiều năm.
Và tất cả những điều đó là câu chuyện của ngày hôm qua.
Còn ngày hôm nay, một công cụ nữa lại được thêm vào: LLM. Nó khác biệt
hoàn toàn so với tất cả các công cụ khác. Giao diện của nó thay đổi quá
nhanh. Ranh giới áp dụng của nó bị mờ nhạt. Không có thời gian để suy
nghĩ, bạn buộc phải dùng, nếu không ngày mai thị trường sẽ đào thải bạn –
đó là lời cảnh báo từ mọi phía, từ người đứng đầu nhà cung cấp LLM cho
đến đồng nghiệp của bạn, và nhìn chung là xuất hiện trong mọi yêu cầu
tuyển dụng hiện nay.
LLM tạo mã rất nhanh. Bạn phải đọc nó, hiểu
nó, sửa lại nó, rồi lại đọc lại, hiểu lại và sửa lại lần nữa. Không ai
mảy may suy nghĩ xem liệu bộ não có thể hoạt động ở nhịp độ như vậy hay
không. Nhưng như thường lệ, chẳng có thời gian để nghĩ đâu, tính năng đã
được hứa hẹn sẽ phát hành từ hôm qua rồi.
3. Sự áp đặt mạnh mẽ (ép buộc) từ phía CTO/tầng lớp quản lý
Ở
đây thì mọi chuyện vẫn diễn ra như thường lệ. Quản lý luôn bị dẫn dắt
bởi sự cường điệu (hype). Quản lý dễ sa vào hội chứng sùng bái hình thức
(cargo-cult) hơn. Hôm qua vừa đạt lợi nhuận +x, hôm nay họ đã nghĩ ngay
đến +10x. Và không gì có thể ngăn cản họ. Không một bài báo, sự thật
nào, không một lời giải thích về nguyên lý hoạt động, không một mô tả về
các vấn đề, hay những câu hỏi về việc chúng ta sẽ làm gì với đống mã
được tạo tự động này sau nửa năm nữa, không gì cả.
Nhưng khác với
bất kỳ làn sóng cường điệu nào khác, làn sóng này rất đặc biệt. Nó tiêm
nhiễm vào đầu óc của cả những người thông minh nhất trong chúng ta. Rất
nhiều CTO, kỹ sư trưởng (techleads), trưởng nhóm (teamleads), vốn là
những kỹ sư của ngày hôm qua, giờ đây không thể chữa khỏi căn bệnh này.
Nhìn chung, điều đó cũng dễ hiểu. Một mặt, họ chịu áp lực từ cấp quản lý
cao hơn. Mặt khác, LLM tạo ra những đoạn mã trông cực kỳ có vẻ hợp lý.
Một chút về lý thuyết
Nhiều người dẫn nguồn từ bài viết này và tôi cũng không ngoại lệ. Đó là bài viết của Peter Naur: Programming as Theory Building (Lập trình như một quá trình xây dựng lý thuyết).
Trong
đó, tác giả nói rằng vai trò thiết yếu trong việc phát triển phần mềm
là xây dựng một lý thuyết trong đầu. Lý thuyết về việc các thành phần
khác nhau của hệ thống liên kết với nhau như thế nào, mô hình được xây
dựng phản ánh các quy trình kinh doanh được tích hợp vào đó ra sao, mô
hình hiện tại linh hoạt đến mức nào, các sự đánh đổi khác nhau, v.v.
Và
tất cả những điều này nằm trong đầu của các lập trình viên. Một phần
của nó có thể được đưa vào tài liệu hướng dẫn, vào các thông số kỹ
thuật, vào các dòng ghi chú (comments), nhưng dù thế nào đi nữa, khi các
lập trình viên mới tham gia vào dự án, họ cần phải xây dựng toàn bộ lý
thuyết này trong đầu ngay từ đầu. Và việc này tiêu tốn rất nhiều thời
gian, chưa kể việc giao tiếp cũng sẽ lấy đi thời gian của các đồng
nghiệp khác.
Tài liệu hướng dẫn là tốt, nhưng trước hết, tài liệu
không phải lúc nào cũng là sự thật tuyệt đối. Tốc độ phát triển có thể
vượt quá tốc độ viết tài liệu. Sẽ có người nói rằng LLM có thể giúp viết
tài liệu. Nhưng LLM sẽ không viết trong tài liệu lý do tại sao một lớp
(class) nào đó lại được triển khai chính xác theo cách đó và nó đã ảnh
hưởng thế nào đến các lớp lân cận, mặc dù điều này có thể cực kỳ quan
trọng cho việc phát triển chức năng sau này. Không ai kiểm tra những gì
LLM viết ở đó cả.
Và nếu trừu tượng hóa hơn nữa, chúng ta có thể
chuyển hẳn sang một ngôn ngữ hình thức tối đa – toán học. Các phương
trình vi phân hay Lý thuyết trường đã được viết ra từ lâu và rất chi
tiết. Nhưng:
Thứ nhất, điều đó có cho phép ai đó áp dụng
chúng vào thực tế để giải quyết các bài toán mà không cần xây dựng các
lý thuyết này trong đầu mình không?
Thứ hai, bạn đã thấy nhiều người giải thích các phương trình vi phân hoàn toàn giống nhau chưa?
Mà
đó là ngôn ngữ hình thức tối đa rồi đấy. Huống chi là những thứ mang
tính ứng dụng và logic kinh doanh (business logic). Do đó, ngay cả trong
trường hợp có tài liệu chi tiết và mã nguồn chất lượng, con người vẫn
cần một khoảng thời gian nhất định để hiểu được bản chất của dự án.
Ở cuối bài viết, bạn có thể tìm thấy một số nghiên cứu khoa học về đề tài này.
Những câu hỏi dành cho trạng thái hiện tại của LLM
Tất
cả chúng ta đều thấy và tự mình cảm nhận được áp lực tiếp thị mạnh mẽ
từ các công cụ LLM và AI nói chung. Tuy nhiên, hãy tạm rời xa các tin
tức kiểu như "vừa ra mắt phiên bản x.yz mới của mạng ABC, tốt hơn
e^100000 lần so với tất cả các phiên bản trước cộng lại" và nhìn vào kết
quả tác động của LLM đối với việc phát triển phần mềm từ một khía cạnh
khác.
Từ vài năm nay, người ta đã quả quyết với chúng ta rằng
chẳng mấy chốc sẽ không còn việc làm cho lập trình viên nữa. Nghĩa là,
LLM sẽ làm hết mọi việc thay chúng ta. Thế nhưng, điều gì đang xảy ra
với các sản phẩm, chuyện gì đang xảy ra với các bộ công cụ, với các ngôn
ngữ lập trình?
Phải chăng đã xuất hiện các cơ sở dữ liệu nhanh hơn, đáng tin cậy hơn do LLM viết?
Có
phải mọi thứ đã được viết lại bằng ngôn ngữ Rust và không còn vấn đề
với các ứng dụng chạy trên nền Electron ngốn hàng tấn bộ nhớ nữa?
Các môi trường phát triển (IDE) đã thôi giật lag khi gõ văn bản thông thường chưa?
Đã hoàn thiện xong Wayland và không còn lỗi nào sót lại?
Có lẽ trong cpython, người ta đã đưa vào những tối ưu hóa cốt lõi bằng LLM và nó đã đuổi kịp tốc độ của các ngôn ngữ biên dịch?
Trình duyệt của Anthropic tiến triển đến đâu rồi?
Còn Bun thì sao, chạy trên môi trường thực tế (production) có bị sập không?
Vậy câu hỏi là: Hàng tấn sản phẩm đó đang ở đâu? Khi nào thì mỗi lập trình viên sẽ tự biến mình thành một chủ doanh nghiệp?
Đúng
là có nghe nói về thành công riêng lẻ của một vài dự án nhỏ mang tính
chất ngẫu hứng (vibe-projects), nhưng đó thường là các dự án nhỏ, mang
lại thu nhập chỉ ở mức của một lập trình viên bậc trung/cao cấp
(middle/senior), hoặc là... những trường hợp cực kỳ cá biệt mà chúng ta
vẫn cần phải kiểm chứng kỹ lưỡng. Còn trong thế giới nguồn mở
(opensource) có gì mới và thú vị không? Thật sự trong giai đoạn
2025/2026, trên GitHub không thấy có gì rầm rộ lắm về khía cạnh này.
Những điểm nghẽn thực sự
Không
biết từ lúc nào, chẳng cần báo trước, bỗng nhiên tất cả mọi người đều
quyết định rằng điểm nghẽn lớn nhất trong phát triển phần mềm là việc
viết mã. Không rõ kết luận này dựa trên nghiên cứu nào. Những người dùng
Vim với phương pháp gõ phím 10 ngón vẫn chưa thuyết phục được ngành
công nghiệp này.
Những điều mà khách hàng đã quên/không hiểu/hoặc không muốn nhìn thấy:
Thiết kế chương trình/dịch vụ – từ các lớp và phương thức, cho đến thiết kế hệ thống (system design) của toàn bộ sản phẩm.
Giao tiếp với các giám đốc sản phẩm, nhà thiết kế, nhà phân tích, và các đồng nghiệp.
Tìm kiếm giải pháp.
Đảm
bảo chất lượng (QA) cho mã đã viết. Đúng vậy, các lập trình viên cũng
mất thời gian tự kiểm thử trước khi bàn giao cho đội ngũ kiểm thử phần
mềm (testers).
Viết tài liệu, giải quyết vấn đề, tư duy
và dự đoán các tình huống khác nhau có thể ảnh hưởng đến tải của hệ
thống, đến hành vi của nó trong các trường hợp ngoại lệ.
Tất cả những việc này tiêu tốn rất nhiều thời gian. Không, LLM không làm được những việc này, hoặc làm không tốt lắm.
Hãy
thử thực hiện một thí nghiệm tưởng tượng. Cứ cho là tất cả những việc
này không phải do LLM làm mà do một lập trình viên cấp cao đóng vai trò
trợ lý thực hiện. Bất kể có đạt được thành công nào, trách nhiệm cuối
cùng vẫn thuộc về lập trình viên được thuê. Và để duy trì trách nhiệm
đó, anh ta cần phải chắc chắn về tính đúng đắn của các giải pháp. Để nạp
được điều đó vào đầu mình, người ta vẫn sẽ cần một khoảng thời gian
đáng kể.
Luận điểm của các tín đồ AI
1. "Hãy tưởng tượng bạn có một đội ngũ gồm 10 lập trình viên trung cấp/cao cấp. Các tác nhân AI cũng tương tự như vậy thôi"
Không,
không hề giống nhau. Tôi đã có kinh nghiệm làm trưởng nhóm khoảng 2.5
năm. Không phải quá nhiều, nhưng để đưa ra kết luận và chỉ ra sự khác
biệt thì không khó đối với tôi:
Trách nhiệm. Con
người thực sự chịu trách nhiệm về công việc của mình. Mỗi thành viên
trong đội ngũ đều có động lực (bằng lương) và áp lực (bằng các khoản
phạt tiềm ẩn hoặc nguy cơ sa thải). Còn trong cuộc sống là các khoản vay
mua nhà, mua xe, các nhu cầu cá nhân, v.v. Động lực và áp lực của họ
buộc họ phải gánh vác trách nhiệm đó. Lập trình viên sẽ không nói câu
"Ôi, bạn đúng rồi, đây mới là giải pháp đúng" tới 10 lần trong vòng một
tiếng đồng hồ.
Tính dự đoán được. Từ yếu tố thứ
nhất sẽ suy ra tính dự đoán được. Mỗi thành viên trong đội ngũ sẽ trở
nên dễ đoán biết sau một khoảng thời gian nhất định (khoảng thời gian
thử việc). Trưởng nhóm sẽ hiểu được trình độ kỹ thuật, tốc độ làm việc,
mức độ tương tác trong quá trình phát triển và hàng loạt đặc điểm khác.
Bản thân các thành viên cũng không muốn mình trở thành người vô định
hướng, bất thường. Do đó, trưởng nhóm biết có thể kỳ vọng gì từ một con
người. Ngược lại, LLM hoàn toàn không thể đoán trước và hỗn loạn tối đa.
Nó quên bối cảnh, nó lặp lại chính những lỗi cũ, nó không biết cách rút
lui. Còn các bản cập nhật thì chỉ làm tăng thêm sự hỗn loạn.
2. "Tất cả mọi người đều dùng thì chúng ta cũng bắt buộc phải dùng"
Đây
là hội chứng sùng bái hình thức thông thường, các lập luận sẽ không cứu
vãn được. Nhưng xin vui lòng, chúng ta hãy thử đặt ra nhiều câu hỏi hơn
một chút trước khi mang một thứ gì đó về áp dụng cho mình.
3.
"Nhưng rõ ràng LLM giúp đẩy nhanh tốc độ phát triển mà. Mặc kệ chuyện gì
sẽ xảy ra với dự án/dịch vụ sau 3-6-9 tháng nữa, hiện tại tất cả mọi
người đều vui vẻ và hài lòng là được"
Không, tôi không hài lòng.
Tôi thấy mệt mỏi khi phải đánh giá các yêu cầu hợp nhất lên tới hàng
ngàn dòng khác biệt. Tôi thấy đau lòng khi không còn những con người
thực sự hiểu mã nguồn nữa. Và điều quan trọng nhất là niềm vui công
việc. Niềm vui từ việc tạo mã tự động nằm ở đâu chứ? Khi viết mã bằng
tay, tôi liên tục nhận được một lượng dopamine nhất định (để bù lại hàng
tấn cortisol căng thẳng nhận được từ thời còn là lập trình viên sơ
cấp/trung cấp).
Hàng tấn mã nguồn không một ai hiểu sẽ ảnh hưởng
trực tiếp đến doanh nghiệp và sản phẩm. Đường cong khả năng bảo trì
(maintainability), sau một thời gian đi ngang, sẽ vọt thẳng lên trời. Và
thế là việc phát hành các tính năng ngày càng bị trì hoãn lâu hơn. Lỗi
xuất hiện thường xuyên hơn, còn sửa chúng thế nào thì không ai hiểu nổi.
Một doanh nghiệp lành mạnh, bình thường rõ ràng cũng cần tính dự đoán
được từ dự án và quá trình phát triển giống như cần nước vậy thôi.
Các trường hợp ranh giới
Ở
đây thì mọi chuyện phức tạp hơn. Tôi sẽ xếp vào nhóm này trường hợp:
LLM viết mã, nhưng lập trình viên vẫn đánh giá mã của mình ở mức độ
tương đối. Trước những lời phản đối về việc số lượng dòng mã tăng lên
trong các yêu cầu hợp nhất và việc thường xuyên phải viết lại cùng một
đoạn mã, họ sẽ trả lời kiểu như: "Cứ đọc lướt qua bản yêu cầu hợp nhất
thôi", "Mô-đun này không quan trọng đến thế đâu", v.v.
Theo tôi,
trường hợp này đối với sản phẩm vẫn rất rủi ro. Có chăng chỉ có thể chấp
nhận được đối với các dịch vụ chỉ cần viết một lần rồi quên đi, chứ
không thể hơn được. Xác suất xảy ra lỗi chắc chắn sẽ tăng lên, ý nghĩa
của việc đánh giá mã bị tiêu tan. Trách nhiệm có thể bắt đầu bị đùn đẩy,
mờ nhạt đi. Chúng ta có thể bắt đầu nghe thấy những câu đại loại như:
"Do con LLM nó gợi ý đoạn mã lỗi đấy thôi", "Con LLM làm sai cấu hình
(config) rồi", v.v.
Tôi cho rằng trách nhiệm luôn luôn phải thuộc
về lập trình viên. Trong trường hợp xảy ra sự cố đến từ các công cụ
khác, cho dù đó là CI/CD, các thành phần hạ tầng hay thậm chí là trình
soạn thảo mã – thì lập luận kiểu đó mới hợp lý. Chúng ta tin tưởng vào
các đồng nghiệp, vào thời gian tồn tại của dự án, vào những người duy
trì hệ thống, vào các công ty, v.v. và hiểu rằng không có phần mềm nào
là không có lỗi. Tuy nhiên, chúng ta vẫn tiếp tục tin tưởng cho đến một
điểm tới hạn nào đó. Điểm tới hạn có thể đơn giản là công cụ đó không
chịu nổi mức tải đặc thù của sản phẩm hiện tại. Nhưng ít ra chúng ta vẫn
có phản hồi từ những con người thực tế rằng trong các trường hợp còn
lại, công cụ đó hoạt động tốt.
Nhưng với mã do LLM tạo ra, chúng
ta không thể cho phép mình làm như vậy – chúng ta không có các công cụ
để đánh giá rủi ro và xác suất của mã nguồn lỗi. Và tôi tin rằng, bất kỳ
sự mờ nhạt nào về mặt trách nhiệm trong trường hợp này đều dẫn đến các
rủi ro và rắc rối, xét cả về góc độ mức độ hiểu sản phẩm của lập trình
viên lẫn mức độ tin tưởng nói chung đối với lập trình viên đó.
Kết luận
LLM
không ổn định. Không có các công cụ cho phép xác định/nâng cao/làm việc
với mức độ tin cậy từ LLM. Chúng ta đã chứng kiến điều này một năm
trước với xu hướng Phát triển phần mềm dựa trên kiểm thử bằng AI
(Test-Driven AI Development), điều mà tôi không muốn bình luận hay
nghiên cứu vì nó đã biến mất như một bong bóng. Ngày hôm nay chúng ta có
Phát triển phần mềm dựa trên đặc tả (SPEC-Driven Development), thứ mà
tôi cũng không đặt nhiều kỳ vọng, bởi vì một lần nữa, tôi không thấy mỗi
lập trình viên đều đã trở thành chủ doanh nghiệp và cũng không thấy có
làn sóng các dự án chất lượng trong thế giới nguồn mở.
Với việc sử
dụng LLM làm trình tạo kho mã chính, mức độ tin tưởng vào lập trình
viên cũng như mức độ hiểu biết về kho mã, về các vấn đề và về sản phẩm
của chính lập trình viên đó sẽ bị mất đi. Điều này ảnh hưởng tiêu cực
đến gánh nặng nhận thức, có thể làm tăng xác suất kiệt sức (burnout). Có
những rủi ro không hề nhỏ khi sử dụng trên các dự án dài hạn.
Tôi xin được lặp lại câu nói trong bài viết: Chúng ta hãy thử đặt ra nhiều câu hỏi hơn một chút trước khi mang một thứ gì đó mới mẻ vào quá trình phát triển phần mềm.
Danh mục tài liệu tham khảo
Peter Naur. Programming as Theory Building. Microprocessing and Microprogramming, Vol. 15, Issue 5, 1985, pp. 253–261. — pages.cs.wisc.edu/~remzi/Naur.pdf
Teun A. van Dijk, Walter Kintsch. Strategies of Discourse Comprehension. Academic Press, 1983. — discourses.org
Nancy Pennington. Stimulus Structures and Mental Representations in Expert Comprehension of Computer Programs. Cognitive Psychology, Vol. 19, Issue 3, 1987, pp. 295–341. — doi.org/10.1016/0010-0285(87)90007-7
