Dọn dẹp hậu quả của những lập trình viên rockstar AI
(codingwithjesse.com)- Trước đây, những codebase khó hiểu do các “lập trình viên rockstar” để lại đã là vấn đề, và với sự lan rộng của mã do LLM tạo ra, gánh nặng bảo trì này đang mở rộng ra toàn bộ nhóm
- Lập trình viên rockstar nhanh chóng đưa vào công nghệ mới, mô hình mới và kiến trúc mới, hoàn thành các việc khó rất nhanh, nhưng lại ít quan tâm đến việc viết mã để người khác có thể hiểu và cùng làm việc
- Tác nhân LLM không nhớ các công việc trước đó, nhưng có thể tạo ra hàng chục nghìn dòng mã trong thời gian ngắn, mà không để ý liệu nó có phù hợp với toàn bộ hệ thống hay có cải thiện khả năng hiểu mã hay không
- Càng có nhiều mã sinh ra, độ phức tạp của hệ thống càng tăng mạnh, và có thể xuất hiện một vòng lặp phải tiếp tục phụ thuộc vào LLM để hiểu chính hệ thống đó
- Với phần mềm cần tồn tại lâu dài, cần giới hạn LLM vào việc tạo các mảnh mã nhỏ, để con người dẫn dắt thiết kế, và đơn giản hóa kiến trúc cho phù hợp với độ phức tạp của vấn đề
Cấu trúc mà lập trình viên rockstar để lại
- Sau khi gia nhập nhóm, lập trình viên rockstar đưa ra những ý tưởng mạnh mẽ về công nghệ mới, mô hình mới và kiến trúc mới
- Họ viết lại phần lớn kiến trúc cốt lõi của công ty, đồng thời đưa vào quy trình build, công cụ và ngôn ngữ mới
- Họ từ chối nhiều pull request, nâng tiêu chuẩn mà các thành viên khác phải đáp ứng, còn những người khác thì không thể hiện ra rằng mình có hiểu đoạn mã đó hay không
- Những công việc khó nhất được giao cho lập trình viên rockstar, và họ hoàn thành nhanh hơn bất kỳ ai khác
- Các thành viên còn lại phải học thư viện mới và điều chỉnh theo cách làm của lập trình viên rockstar nên di chuyển chậm hơn
- Vài năm sau, lập trình viên rockstar rời nhóm vì muốn làm dự án khó hơn ở một công ty lớn hơn
Đối phó với hệ quả
- Những người còn lại tiếp quản dự án của lập trình viên rockstar và rơi vào tình trạng bị choáng ngợp giữa đống mã
- Luồng dữ liệu rất khó lần theo, đến mức có cảm giác như ai đó đang cố che giấu một vụ giết người
- Họ bắt đầu từ việc sửa một lỗi đơn giản, nhưng chỉ riêng việc chạy được mã trên laptop cũng đã mất một tuần
- Một nửa mã được viết bằng ngôn ngữ mà họ không hiểu, nửa còn lại dùng các thư viện mà họ chưa từng nghe tới
- Họ nói với cấp trên rằng cần phải viết lại mã, nhưng không được chấp nhận vì đó là mã do lập trình viên rockstar viết
- Trong lúc lạc lối giữa đống mã hỗn độn, họ bắt đầu nhìn các tin tuyển dụng và tưởng tượng đến chuyện rời đi
Dọn dẹp sau rockstar
- Nhiều nhóm và agency cần dọn dẹp các codebase do kiểu lập trình viên rockstar này để lại
- Quá trình hiểu và cứu một codebase phức tạp được ví như gỡ lại một dây đèn bị rối để có thể dùng tiếp
- Lập trình viên rockstar thích viết mã, học hỏi và sử dụng các mô hình mới, luôn đẩy bản thân đến giới hạn năng lực
- Họ cố viết mã càng thông minh càng tốt và tập trung di chuyển nhanh nhất có thể
- Việc viết mã để người khác có thể cùng làm việc lại là ưu tiên thấp nhất đối với lập trình viên rockstar
Sự xuất hiện của trí tuệ nhân tạo
- Trong vài năm gần đây, nhiều nhóm đã rơi vào tình trạng bị áp đảo bởi cả một đạo quân lập trình viên rockstar
- Mỗi khi ai đó bắt đầu một cuộc chat mới, lại có thêm nguy cơ đưa một lập trình viên rockstar mới vào nhóm
- Tác nhân không nhớ hôm qua mình đã làm gì, nhưng chỉ trong vài phút có thể sinh ra hàng chục nghìn dòng mã
- Tác nhân theo đuổi việc hoàn thành công việc với tốc độ nhanh đến mức con người không thể làm nổi
- Chúng không quan tâm liệu mã được tạo ra có ăn khớp với phần còn lại của hệ thống hay có khiến hệ thống dễ hiểu hơn hay không
- AI có một hộp công cụ “best practice” nhưng đôi khi lại không phù hợp với tình huống
- Ngay cả khi độ phức tạp lớn hơn lợi ích, AI vẫn khăng khăng với kiểu phòng bị quá mức theo cách “belt and suspenders”
- Khi được yêu cầu review code, nó tạo ra một danh sách cải thiện dài với rất nhiều mục khó mà đồng tình
- Ngày càng nhiều người cảm thấy nếu không dùng LLM thì mình sẽ mãi tụt lại phía sau
- Nhưng việc để LLM viết toàn bộ mã cuối cùng lại dẫn đến chính kết quả tụt lại phía sau
Dọn dẹp sau hàng trăm rockstar AI
- Việc dọn đống mã sinh ra hỗn độn không thú vị bằng việc dọn mã của một lập trình viên rockstar duy nhất
- Ít nhất thì với lập trình viên rockstar, vẫn có một chủ đích thiết kế nào đó và một nỗ lực làm tốt hết sức mình
- Đống mã hỗn độn tạo ra bởi vibe coding không phải do một “lập trình viên nhân tạo” duy nhất viết ra
- Nó trở thành một codebase được sinh ra qua nhiều cuộc chat và nhiều ngữ cảnh khác nhau, mỗi lần thêm một tính năng hoặc một bản sửa lỗi
- Điều đó giống với một codebase do hàng trăm lập trình viên rockstar khác nhau cùng viết ra
- Trong một số trường hợp, nợ kỹ thuật phình to đến mức không bao giờ có thể trả nổi
Xây dựng phần mềm bền lâu
- Có nhiều cách dùng LLM mà không để nó hành xử như một lập trình viên rockstar
- Con người có thể dẫn dắt việc kỹ thuật, còn LLM chỉ được hướng dẫn tạo ra từng mảnh mã nhỏ trong mỗi lần
- Cần bảo đảm rằng phần mềm được viết theo cách để mọi thành viên trong nhóm đều có thể dễ hiểu và làm việc cùng
- Nếu LLM đang lạc hướng và bạn không hiểu nó đang làm gì, tại sao lại làm như vậy, thì cần giảm tốc độ
- Đi chậm hơn để bảo đảm chất lượng của phần mềm được tạo ra là điều hoàn toàn chấp nhận được
- Hoàn toàn có thể tiếp tục đơn giản hóa để ngăn over-engineering, cho đến khi kiến trúc phù hợp với độ phức tạp của vấn đề
- Đôi khi cũng không sao nếu để LLM yên trong hộp công cụ và tự tay viết mã
- Tinh thần thủ công luôn nằm trong bàn tay con người, và đó là lĩnh vực không thể outsource cho máy móc
2 bình luận
Ý kiến trên Hacker News
Câu cuối nói rằng tinh thần thủ công sẽ luôn nằm trong tay con người và tuyệt đối không thể giao khoán cho máy móc khiến tôi hơi lo
Ở các ngành khác, tinh thần thủ công không hề chết đi, nhưng đã bị lấn át bởi những lựa chọn thay thế rẻ hơn nhiều và dễ kiếm hơn. Bạn vẫn có thể mua giày da thủ công, nhưng rất ít người muốn trả hơn $1000, và bạn cũng vẫn có thể mua một bức tranh mất vài tuần để vẽ, nhưng đa số lại mua đồ trang trí tường và đồ lặt vặt ở HomeGoods
Khác biệt cốt lõi là giả định về tính dùng một lần, và đáng tiếc là phần mềm cũng đang dần trở thành “đồ dùng một lần” như các sản phẩm khác. Ứng dụng đếm ngược đơn giản thì có thể vứt đi, nhưng phần mềm chống đỡ các quy trình nghiệp vụ chạy lâu dài thì không nên bị đối xử như vậy
Nếu tập trung vào tinh thần thủ công trong phần mềm, vấn đề có thể bị nhìn thành “thứ tôi cần cho mục đích của mình” đối lập với “thứ kiểu boutique, đắt đỏ và không cần thiết”. Thực ra nó nên là “thứ có thể bảo trì và đáng tin cậy” đối lập với “thứ có thể vứt đi”
Bất kể xu hướng này có mang lại lợi ích cho các nhà cung cấp mô hình lớn như OpenAI hay Anthropic hay không, đó không phải điều tôi muốn nói ở đây
Cái bàn rẻ tiền được giao trong hộp phẳng mà tôi tự lắp bằng tua vít cũng được sản xuất hàng loạt trong nhà máy, nhưng thiết kế của nó có thể chứa đựng tinh thần thủ công của chuyên gia nhiều hơn rất nhiều so với một món đồ đặt làm riêng. Cấu trúc ở đây là bỏ ra chi phí thiết kế ban đầu cao rồi sản xuất hàng loạt với chi phí cận biên thấp
Phần mềm từ đầu vốn phần lớn đã ở trong trạng thái đó. Khi bạn tải Firefox, không phải một người thợ đang làm trình duyệt web riêng cho bạn, mà là một máy chủ CDN trong trung tâm dữ liệu nào đó đang sao chép các byte từ bộ nhớ đệm cho bạn
Điều AI đe dọa là việc thay thế tinh thần thủ công kiểu đầu tư ban đầu mà chưa từng xảy ra trên quy mô lớn ở các ngành khác. Thứ AI thay thế thành công hơn là phần mềm “thủ công” giá rẻ, mà tới giờ gần như là một hạng mục không tồn tại vì hiệu quả kinh tế quá thấp
Vì vậy đòn bẩy cho đầu tư vào chất lượng lớn hơn nhiều
Tôi cũng khó đồng ý rằng phần mềm là đồ dùng một lần theo cùng nghĩa đó. Nếu là vấn đề tạm thời, bạn có thể vứt code đi và làm mới khi có vấn đề khác phát sinh. Nhưng nếu là vấn đề kéo dài, thì code sẽ tiếp tục ở đó
Ốc vít từng là món đồ quý được làm theo đặt riêng, và để làm ra một con ốc tốt cần lượng thời gian và công sức khổng lồ. Ngay cả thứ ngày nay chúng ta gọi là vít máy cũng chỉ có thể được tạo ra bằng lao động cực nhọc của những người rất lành nghề
Nhưng máy móc có thể chuyển tinh thần thủ công đi nơi khác. Nếu làm được một con ốc thật tốt, máy móc có thể truyền chất lượng của con ốc đó sang vô số con ốc mới
Ngày nay, mọi loại ốc vít ở mọi mức chất lượng gần như đều trở thành hàng tiêu hao, và những con ốc mà ngày xưa có thể phải mất nhiều ngày hay nhiều tuần để gọt bằng tay thì nay được sản xuất hàng chục tỷ cái
Tôi nhìn AI như một máy tiện không có trục vít me. Ban đầu bạn vẫn phải tự tay làm ra con ốc, rồi sau đó bạn có thể chuyển mức chất lượng mình tạo ra sang bao nhiêu con ốc mới cũng được. Khi bạn làm được con ốc tốt hơn, bạn đưa nó vào máy tiện và tạo ra nhiều con ốc tốt hơn nữa. Nhưng về bản chất, bạn vẫn bị giới hạn bởi chất lượng con ốc mà chính bạn có thể tự làm. Nếu bạn chỉ làm ra được thứ méo mó, lổn nhổn và tệ hại, thì máy cũng chỉ cho ra đến thế
Lập trình viên phần mềm tạo ra tài sản trí tuệ độc nhất, chứ không sản xuất các đơn vị phần mềm. Họ giống tác giả sách hay nhạc sĩ hơn
Trong phần mềm không hề có thứ gì tương ứng với sản xuất theo đơn vị. Chỉ đơn giản là sao chép và chuyển các bit đi thôi
Vì thế, trong ngữ cảnh phần mềm, “tinh thần thủ công” nghĩa là bạn quan tâm đến việc thiết kế ra thứ tốt đến mức nào. Nó sẽ không biến mất trừ khi chúng ta đi đến điểm mà ngay cả chất lượng phần mềm mình dùng cũng không còn quan trọng nữa, và hiện không có dấu hiệu nào cho thấy ta đang đi theo hướng đó
So sánh phù hợp hơn có thể là kỹ sư tạo và bảo trì thiết bị sản xuất cho nhà máy giày. Nó cách người tiêu dùng một tầng, nhưng ở đó rõ ràng vẫn có tinh thần thủ công
Tôi thích công việc sửa code AI hoặc code thuê ngoài. Tuần trước tôi phát hiện một khách hàng đã cố làm một công cụ nội bộ cho bộ phận bằng vibe coding, và kết quả là một đống Next.js rác khổng lồ cần 10GB bộ nhớ chỉ để biên dịch, có hàng nghìn lỗi lint, thậm chí còn đẩy cả log phát triển ồn ào lên Git
Giờ chúng tôi phải sửa nó, nên chuyện này thực chất chỉ là nguồn việc miễn phí trị giá 10.000 đến 50.000 euro lặp đi lặp lại. Nếu biết mình đang làm gì thì rất dễ, còn không biết thì là bất khả thi. Cứ mang thêm đến nữa đi
Tôi làm về ứng phó sự cố xâm nhập cho các doanh nghiệp vừa và nhỏ, và vài năm gần đây công việc tăng đến mức khó xoay xở, còn tài khoản ngân hàng thì như một đống vàng của rồng
Tôi luôn cho rằng bảo mật phải được tích hợp và lên kế hoạch từ đầu, hoàn toàn không có ý muốn nhìn thấy các vụ xâm nhập
Chỉ là việc những người có chuyên môn nửa vời giờ có thể tung ra ứng dụng trong một giờ đã trở thành món hời khổng lồ cho những người như tôi
Có thể xem kiểu tư duy này như một máy đánh bạc con người nơi người ta cứ đổ tiền vào
Tôi tò mò không biết khi khách hàng tìm đến thì ngay từ đầu họ đã muốn được giúp đưa sản phẩm lên môi trường production, hay đây là phương án cuối cùng sau khi mọi cách tiếp cận bằng AI đều thất bại
Tôi cũng muốn biết liệu các dự án kiểu này thường sụp đổ theo một mô thức nào đó hay không, hay phần lớn thất bại là theo kiểu âm thầm, tinh vi hơn
Trong đời tôi đã gặp vài người thực sự có thể gọi là xuất chúng. Kiểu khiến mình phải nghĩ: “Rốt cuộc sao họ có thể thông minh đến thế nhỉ?”
Tôi thấy ở những người cực kỳ thông minh thường có hai kiểu, và thường chúng loại trừ lẫn nhau. Một kiểu là họ không biết mình thông minh đến mức nào. Với họ thì mọi thứ đơn giản, hoặc là chủ đề họ đã biết, nên họ mặc định rằng ai có bằng khoa học máy tính cũng đều biết, nhớ và hiểu như vậy. Có lần nhìn mấy người bạn thao thao bất tuyệt về toán học liên quan đến mật mã, tôi đã nghĩ: “Tôi có qua môn đó thật, nhưng không thể nói là mình thực sự hiểu chủ đề cậu vừa nói đâu.”
Kiểu còn lại là những người luôn đau đớn ý thức rằng mình thông minh hơn phần lớn những người xung quanh. Một số người trở nên cay nghiệt, một số khác thì mệt mỏi vì luôn bị bao quanh bởi những người tương đối “kém thông minh” hơn. Tôi phần nào đồng cảm với nhóm sau. Hãy thử tưởng tượng sống một cuộc đời nơi mọi thứ đều rõ ràng, hiển nhiên và dễ xử lý, nhưng lại phải chứng kiến nhân loại cứ lặp đi lặp lại những lựa chọn ngu ngốc dù đáp án đã có từ rất lâu rồi
Nhìn người ta cuống cuồng, hoặc làm X dù rõ ràng làm X sẽ dẫn đến kết quả tệ là -Y, tôi phát điên lên được. Phần lớn chỉ là tôi đã học được cách không nói ra miệng
Trong các mối quan hệ gia đình gần gũi thì điều này đặc biệt không lành mạnh. Tôi nhìn thấy quá nhiều đến mức có cảm giác mình có thể cằn nhằn người ta đến chết
Nhưng không ai trong số họ là lập trình viên 10x kiểu tạo ra một đống hỗn độn khổng lồ để rồi cả nhóm và tôi phải mất hàng tháng dọn dẹp cả
Dù có cố gắng thế nào cũng rất khó kết nối với phần lớn mọi người, và họ cũng đặc biệt khó hiểu được mình. Sự khác biệt trong trải nghiệm sống là rất lớn, và thường rất khó vượt qua
Không phải mọi lập trình viên đều có thể tạo ra cùng một mức sản lượng, nhưng nếu quyết định tiếp tục suy nghĩ vượt lên trên mức trung bình văn hóa, thì ai cũng có thể trở nên thông minh theo cách riêng của mình
Đa số không nhận ra rằng mình có thể làm được điều đó
Hai câu này làm tôi thấy rất thấm
“Lần theo luồng dữ liệu khó đến mức cứ như có ai đó đang cố che giấu một vụ giết người vậy”
“Chỉ riêng việc chạy được code trên laptop đã mất cả một tuần”
Tôi luôn nghĩ chỉ có mình tôi là người gặp khó khăn trong việc hiểu luồng dữ liệu hoặc thiết lập một môi trường phát triển tử tế. Hội chứng kẻ mạo danh và đôi khi cả môi trường độc hại cứ ép phải chạy theo “tốc độ” cũng chẳng giúp ích gì
Biết rằng không chỉ có mình như vậy khiến tôi thấy nhẹ nhõm
Claude Code trên CLI đã giúp việc khởi chạy ứng dụng và debug mấy vấn đề ngẫu nhiên về dependency hay Docker dễ hơn rất nhiều so với trước đây. Ngày xưa tôi vừa phải học kiến trúc, vừa phải tự xử lý những thứ không chạy trên máy mình
Với code AI thì còn tệ hơn nữa. Vì người ta chỉ đơn giản sinh ra thứ gì đó trông có vẻ hợp lý tại thời điểm đó thôi
Tôi hơi ghen tị với những người được đi dọn đống người khác để lại. Ít ra nó còn có cảm giác như đang giải một câu đố
Công việc hiện tại thực sự rất chán. Toàn những việc đơn giản đến mức junior cũng làm được, vậy mà lại bảo là cần lập trình viên mid-level. Không phải tôi nói mình giỏi hơn công việc này, cũng không phải nói mid-level không làm những việc như thế. Chỉ là tôi không thể tự ép mình quan tâm đến thứ code mà công ty này tạo ra. Nó cũ kỹ, phủ bụi, và chẳng ai quan trọng dùng đến. Khách hàng dùng nó chỉ vì ngày xưa từng mua công cụ này, và vì nó là một công cụ nhàm chán đến mức họ cũng chẳng buồn quan tâm để thay thế nó
Tôi đã được hứa là sắp tới sẽ có việc phù hợp hơn với kinh nghiệm của mình, nhưng tôi không nghĩ một công ty trì trệ như thế này lại có thể có kiểu khách hàng đó
Tôi không ngạc nhiên khi công ty này mất cả khách hàng lẫn nhân viên. Nhưng tôi vẫn phải trả tiền thế chấp nhà. Hôm nay tôi nghe nói có thể họ sẽ không gia hạn hợp đồng, và về cơ bản điều đó giống như bị đe dọa phải nhận nhiều trách nhiệm làm chủ hơn và làm nhiều việc hơn với cùng mức lương
Đáng buồn là tôi phải cầm cự cho đến khi tìm được một vị trí mới thực sự thú vị. Tôi cũng không cần quá nhiều tiền, và hoàn toàn không quan tâm đến mấy thứ như “phát triển”. Tôi chỉ cần đủ để sống sót
Có thể bình luận này không liên quan lắm, xin lỗi nhé. Tôi chẳng có chỗ nào khác để xả ra chuyện này
Tôi ở cấp L63 nhưng công việc tôi làm thì L60~L61 cũng làm được, và tôi thường có cảm giác mình đang ở trong một trong những Bullshit Jobs mà David Graeber nói đến. Lương thì hậu hĩnh, nhưng khi số cổ phiếu thưởng lúc gia nhập đã vesting xong, tôi nhận ra mình chỉ còn ở lại công việc đó vì sự ổn định
Tôi có cảm giác mình đã trở thành một trong những kỹ sư tắm nắng trên sân hiên văn phòng Hooli, chờ cổ phiếu vesting. Tôi đã có 9 năm kinh nghiệm, và điều đó không có vẻ là tốt nhất cho sự nghiệp của mình ở thời điểm này
Chỉ là tôi không có nghĩa vụ tài chính lớn nên quyết định của tôi dễ dàng hơn nhiều
Những sản phẩm rác do các công ty rác tạo ra bám vào sự lười biếng và thiếu gu của số đông, rồi đám marketer đem thứ đó đi kiếm tiền
Giờ còn tệ hơn nữa khi cả lĩnh vực đang bị LLM hóa, khiến mọi thứ bị khuếch đại lên gấp 100 lần. Nó làm code trở nên không thể bảo trì được, và tệ hơn nữa là khiến tất cả chúng ta ngu đi
Tôi thực sự ước gì chúng ta chưa từng phát hiện ra thứ này
Không biết ý là chỉ phải làm thêm giờ và nhận thêm việc vô nghĩa, hay thực sự có nhiều cơ hội code hơn, hoặc là đột nhiên bị kỳ vọng phải chứng minh mình có giá trị hơn
Tôi không có ý xem nhẹ những gì bạn đã trải qua. Nếu là trường hợp sau thì tôi tò mò không biết liệu có thực sự làm được gì với nó không
Những phần đầu tiên khá chạm tới mình. Trước đây có lẽ mình từng là một lập trình viên rockstar, nhưng rồi nhận ra đó không phải điều tốt
Có thể mình đã hoàn thành công việc nhanh hơn đồng nghiệp 10 lần. Nhưng đến một lúc, mình nhận ra không phải vì bản thân năng suất hơn người bình thường 10 lần, mà vì cách mình làm việc khiến những người bình thường xung quanh chỉ còn năng suất bằng 1/10
Sau đó mình giảm tốc lại, và đó là một thay đổi tích cực cho cả cuộc sống. Trở thành một người chơi đồng đội không mang lại cùng mức độ thăng tiến điên cuồng trong ngành đầy hỗn loạn này, nhưng lại tốt đáng ngạc nhiên cho sức khỏe tinh thần
Trong trường hợp của mình, thường là trừu tượng hóa quá mức những thứ không cần thiết, hoặc xây dựng gì đó cho các trường hợp sử dụng thực tế không bao giờ xảy ra. Vì vậy, mỗi khi suy nghĩ của mình trôi theo hướng trừu tượng hóa quá mức, mình cố gắng nhớ tới YAGNI và KISS
Bài này có giá trị quá thấp
Mình cũng không rõ nó định nói gì, trông giống một bài tự vỗ về bản thân hơn
Phần lớn cái được gọi là một lượng khổng lồ code tệ do “lập trình viên rockstar” để lại thực ra là kết quả của độ phức tạp tích tụ dần dần, lâu dài và chậm rãi để đáp ứng những thay đổi về yêu cầu
Ngoài ra, nhiều khi mọi người nghĩ họ đang “refactor để cải thiện tính dễ đọc”, nhưng thực tế thường là họ “viết lại code và nhờ quá trình đó mới hiểu được nó” hơn
Mình mong đợi nhiều nội dung hơn hoặc các ví dụ thực tế. 90% bài viết là tác giả than phiền và định nghĩa vấn đề, rồi đến đoạn áp chót mới đưa ra một giải pháp mơ hồ như kiểu vung tay cho có. Hầu như không có tính liên quan hay hữu ích thực sự nào
Việc mình thúc ép mạnh hai production engineer xây hạ tầng xoay quanh hai dự án có lãi do mình tạo ra quả thật là một việc cực kỳ ngu ngốc
Giá như mình cứ làm tất cả bằng spaghetti code như một ông sếp 10x rồi chuyển sang Anthropic và nhận gói đãi ngộ 9 chữ số thì đã kiếm được nhiều tiền hơn rất nhiều. Đúng là ngu hết chỗ nói
Ít nhất thì đó là kết luận mình rút ra được ở đây
Code được viết ra phần lớn rồi sẽ phải do người khác chứ không phải tác giả bảo trì. Vì vậy, nếu bạn viết code mà không ai hiểu nổi thì cuối cùng sẽ dẫn tới thất bại trong bảo trì
Mỗi đội có thể tối ưu cho những thứ khác nhau như code dễ hiểu với cả nhóm, tốc độ, hay sự xuất sắc về mặt kỹ thuật
Nhưng ngay cả khi bạn tối ưu cho sự xuất sắc về mặt kỹ thuật, nếu không ai khác trong nhóm có thể hiểu được code đó thì đó vẫn là thất bại
Mình đã từng thấy code bị thiết kế quá mức
Ý kiến trên Lobste.rs
Bài này hầu như không có lời khuyên thực sự hữu ích nào
Cụm từ “lập trình viên rockstar” lúc nào cũng đáng ngờ, nhưng đúng là có những lập trình viên xuất sắc thật. Chỉ là những người đó không hành xử như mô tả trong bài; họ làm việc hết mức có thể trong môi trường hiện có, cải thiện codebase, không mang đồ mới chưa được kiểm chứng vào như đồ chơi, và khi rời đi thì để lại hệ thống ổn định hơn nhờ test, triển khai được script hóa, linting, v.v.
AI có vẻ chỉ được thêm vào đây với ý rằng nó sẽ làm kiểu hành vi này tệ hơn; điều đó có thể đúng, nhưng có lẽ vẫn chưa được chứng minh đủ rõ. Tôi đã làm tư vấn hàng chục năm và dọn dẹp rất nhiều codebase lộn xộn; đôi khi nguyên nhân là do vài người đi quá đà, nhưng чаще hơn là do cả đội không biết cách tốt hơn. Trong cả hai trường hợp, tôi chưa từng nghĩ “chắc hẳn do kiểu lập trình viên rockstar/ninja/buzzword nào đó làm ra”
Giờ không chỉ phải dọn đống rác mà chatbot đổ xuống đầu, mà còn phải đi xử lý hậu quả cho những người chẳng buồn quan tâm đến nó nữa sao
Chỉ khiến tôi muốn chờ đến lúc bong bóng vỡ
Nếu năm 2026 vào một công ty nào đó rồi phát hiện họ vẫn đang dùng create-react-app, tôi thật sự tò mò không biết cách hành xử được khuyến nghị là gì. Chẳng lẽ cứ im lặng không nói gì sao?
Nếu là dự án cũ thì bạn vừa phát hiện ra technical debt. Ai cũng có thôi. Cách tốt nhất để thuyết phục sửa những thứ như vậy là đưa ra được lý do hợp lý về mặt kinh doanh. Nếu nó vẫn chạy thì đó có thực sự là rủi ro không? So với các technical debt khác thì mức ưu tiên thế nào? Nếu không nâng cấp thì đang ngầm chấp nhận những rủi ro gì? Cần bao nhiêu công sức để nâng cấp?
Nếu công sức ít và đồng nghiệp cũng muốn thì cũng có thể cứ làm luôn mà không cần xin phép. Nhưng cách này hiệu quả nhất khi có sự ủng hộ của những người bị ảnh hưởng bởi thay đổi đó, và khi nó không cản trở đầu việc chính của bạn. Có lẽ không phải việc nên làm ngay trong tuần đầu tiên vào công ty
Thông thường, thay vì nói “đáng ra phải thế này”, lúc nào cũng tốt hơn nếu hỏi và tìm hiểu vì sao hiện tại lại thành ra như vậy. Mọi codebase có lịch sử đều là kết quả của hàng nghìn quyết định mà bạn còn chưa biết. Cần trang bị cả kiến thức lẫn sự cảm thông
Tôi đã ghét nó từ hồi 2020, khi nó vẫn còn trông có vẻ ngầu
Câu “agent không nhớ gì về những gì chính nó đã làm hôm qua” là vấn đề có thể giải được. Có thể dùng các cách tiếp cận về memory, v.v. Không phải lúc nào cũng tốt trên diện rộng, nhưng đang dần cải thiện
Câu “nó không quan tâm liệu đoạn code này có ăn khớp với phần còn lại của hệ thống hay không” thì khác với trải nghiệm của tôi. Thông thường mã do LLM sinh ra có xu hướng khá giống với mã tương tự trong khu vực liên quan. Gần như nó phản ánh lại nguyên xi phần mã đã đọc để lấy định hướng
Câu “nó không quan tâm liệu hệ thống có dễ hiểu hơn hay tệ đi không” cũng có thể giải được. Có thể bảo LLM đánh giá điều đó và giảm dần theo từng bước. Việc cái gì là dễ hiểu thường là một thuộc tính không tất định của hệ thống, nên nghịch lý là LLM có thể là cách đo lường dễ hơn các công cụ khác. Trong một phiên mới, bạn có thể hỏi “để hiểu đoạn code mới thêm này thì cần hiểu bao nhiêu phần của hệ thống” rồi tối ưu để thu hẹp phạm vi đó
Đoạn “AI có một hộp công cụ best practice có thể không phù hợp ở đây” thì quá trình dùng AI nhiều khi khá giống với việc huấn luyện một lập trình viên junior mới vào dự án với cùng những lý tưởng đó. Với junior thì ta nói miệng và mong họ nhớ rồi áp dụng, còn với AI thì chỉ cần ghi lại trong các file AGENTS.md / CLAUDE.md là kiến thức đó sẽ tiếp tục được lưu giữ
Câu “nhờ review code thì nó đưa ra cả đống điểm cải thiện mà mình không đồng ý” thì với Codex, nó được tinh chỉnh để giữ danh sách ngắn, súc tích và có giá trị cao. Mô hình khác có thể khác, nhưng cuối cùng đây vẫn là vấn đề ở mức chỉ dẫn. Những điều bạn quan tâm thường đáng để tài liệu hóa, và khi dùng AI thì điều đó trở nên cần thiết
Một nửa vấn đề khi làm việc với rockstar là cái tôi, nhưng dù sao một rockstar để lại code do con người viết vẫn có sự suy ngẫm và chủ đích đứng sau nó
Ngược lại, những “rockstar” chỉ khoác vỏ con người lên trên AI thì có độ phô trương ngang hoặc hơn, nhưng nhiều khi còn không hiểu trọn vẹn nổi một nửa vấn đề mà họ tuyên bố mình đang giải quyết
Nếu áp dụng tối đa cách tiếp cận lập trình hàm, tạo ra các thành phần độc lập với ngữ cảnh có thể ghép nối theo nhiều cách khác nhau, bạn sẽ có được đòn bẩy rất lớn
Nếu tách riêng các khối xây dựng cá thể hóa những chi tiết triển khai khỏi các tác vụ phụ thuộc vào ngữ cảnh cụ thể, thì khi yêu cầu thay đổi hoặc muốn chọn hướng tiếp cận khác, bạn có thể sắp xếp lại các khối đó rất dễ dàng. Ngoài ra, có thể suy luận độc lập về từng mảnh mà không cần biết toàn bộ bối cảnh của hệ thống, và khi nhìn cách các mảnh đó ăn khớp với nhau thì có thể hiểu được logic ở mức cao hơn
Các ngôn ngữ hàm cung cấp nền tảng tốt để làm việc cùng LLM, vì chúng tự nhiên dẫn đến cách viết mã theo hướng giới hạn ngữ cảnh. Điều này giúp giảm phạm vi cần thiết để hiểu một chức năng cụ thể của chương trình, có lợi cho cả mô hình lẫn người dùng là con người