Những bài tiểu luận phần mềm đã tạo nên con người tôi

 (refactoringenglish.com)
74 điểm bởi GN⁺ 2025-10-02 | 3 bình luận | Chia sẻ qua WhatsApp
  • Trong 20 năm đọc hàng nghìn bài blog về phần mềm, chỉ một số ít bài tiểu luận thực sự thay đổi tận gốc cách tư duy, và bài viết giới thiệu 10 tiểu luận cốt lõi, từ "Joel Test" của Joel Spolsky đến lập luận ủng hộ JavaScript thuần của Julia Evans
  • "Joel Test" của Joel Spolsky đưa ra 12 câu hỏi để đánh giá liệu nhà tuyển dụng có tôn trọng lập trình viên hay không, kiểm tra xem họ có ưu tiên thời gian và sự tập trung của lập trình viên thông qua quản lý mã nguồn, build hằng ngày, sửa lỗi trước hay không
  • "Parse, don't validate" của Alexis King giới thiệu kỹ thuật chuyển đổi dữ liệu sang kiểu mới khi xác thực, cho thấy hệ thống kiểu có thể góp phần cải thiện bảo mật và độ tin cậy của ứng dụng
  • "No Silver Bullet" của Fred Brooks phân biệt công việc phần mềm thành độ phức tạp bản chất và độ phức tạp ngẫu nhiên, đồng thời lập luận rằng không thể đạt mức tăng năng suất gấp 10 lần chỉ bằng công cụ và phần cứng, dù AI đang tạo ra một biến số mới cho lý thuyết này
  • Bài tiểu luận về JavaScript thuần của Julia Evans mang lại nhận ra rằng chỉ ES2018 JavaScript là đã đủ ngay cả khi không có framework, và từ năm 2020 trở đi tác giả không còn tích hợp framework JavaScript hay bước build nào vào bất kỳ dự án nào

"Joel Test" của Joel Spolsky (2000)

  • Joel Spolsky là blogger phần mềm vĩ đại nhất mọi thời đại, và các bài tiểu luận của ông đã ảnh hưởng sâu sắc đến cách tác giả tiếp cận phần mềm
  • "Joel Test" là bộ 12 câu hỏi để đánh giá mức độ một nhà tuyển dụng đầu tư đúng đắn cho đội ngũ phần mềm

  • Danh sách 12 câu hỏi

    • Có sử dụng quản lý mã nguồn không
    • Có thể build chỉ với một bước không
    • Có thực hiện build hằng ngày không
    • Có hệ thống theo dõi lỗi không
    • Có sửa lỗi trước khi viết mã mới không
    • Có lịch trình cập nhật không
    • Có đặc tả không
    • Lập trình viên có môi trường làm việc yên tĩnh không
    • Có dùng những công cụ tốt nhất có thể mua bằng tiền không
    • Có tester không
    • Ứng viên mới có viết mã trong lúc phỏng vấn không
    • Có thực hiện kiểm thử khả dụng kiểu hành lang không

  • Thông điệp cốt lõi

    • Một số câu hỏi đã lỗi thời, nhưng điều quan trọng không phải là bản thân câu hỏi mà là điểm siêu nghĩa của chúng
    • Điều Joel thực sự đang hỏi là: bạn có tôn trọng lập trình viên không?
    • Tất cả câu hỏi đều đánh giá liệu nhà tuyển dụng có ưu tiên thời gian và sự tập trung của lập trình viên hơn văn phòng rẻ tiền và deadline ngắn hạn hay không
    • Bài viết được đăng vào đỉnh cao của thời kỳ dot-com boom, khi lập trình viên giỏi là tài nguyên quý giá nhưng không phải ai cũng nhận ra điều đó
    • Blog của Joel luôn khắc họa lập trình viên là những thiên tài hiếm hoi và mong manh, những người mà nhà tuyển dụng nên tìm kiếm và trân trọng
    • Trong suốt sự nghiệp, tác giả luôn tìm kiếm những nhà tuyển dụng đạt điểm cao theo Joel Test, và biết ơn Joel vì đã đưa ra kim chỉ nam đó

"Parse, don't validate" của Alexis King (2019)

  • Dù là một bài tiểu luận về việc tận dụng hệ thống kiểu của Haskell, nó vẫn thay đổi tận gốc cách nghĩ về phần mềm ngay cả khi bạn không quan tâm đến hệ thống kiểu hay Haskell
  • Có thể áp dụng kỹ thuật của Alexis trong mọi ngôn ngữ hỗ trợ kiểu tĩnh như Go, C++, Rust

  • Khái niệm cốt lõi

    • Mỗi khi xác thực dữ liệu, ta nên chuyển nó sang một kiểu mới
    • Ví dụ: nếu có quy tắc giới hạn tên người dùng ở tối đa 20 ký tự chữ và số, giải pháp ngây thơ là hàm validateUsername(username string) error

  • Vấn đề

    • Mã nguồn về mặc định là không an toàn
    • Vì phải xác thực mọi tên người dùng nhận vào, rất dễ vô tình tạo ra đường đi mã xử lý tên người dùng mà không qua xác thực
    • Nếu người dùng ác ý phát hiện ra sai sót đó, họ có thể chèn mã độc vào trường tên người dùng hoặc điền hàng tỷ ký tự để làm cạn tài nguyên máy chủ

  • Giải pháp của Alexis

    • Dùng hàm parseUsername(raw string) (Username, error)
    • Trong phần còn lại của codebase, dùng kiểu tùy chỉnh Username thay vì string mang tên "username"
    • Hàm duy nhất có thể tạo ra Username là parseUsername, và nó áp dụng các quy tắc xác thực trước khi trả về một thể hiện Username
    • Khi đã có một thể hiện Username, nó phải chứa một tên người dùng hợp lệ
    • Đầu vào không đáng tin cậy luôn là string, nên không thể truyền string vào các hàm mong đợi Username

  • Tác động

    • Trước bài tiểu luận này, tác giả từng nghĩ hệ thống kiểu chỉ là trò thú vị để những người mê ngôn ngữ tự làm mình phân tâm
    • "Parse, don't validate" đã mở mắt cho tác giả về mức độ giá trị của các khả năng do compiler cung cấp trong việc nâng cao bảo mật và độ tin cậy của ứng dụng

"No Silver Bullet" của Fred Brooks (1986)

  • Tác giả đã đọc The Mythical Man-Month của Fred Brooks khi còn học đại học
  • Đây là tập hợp các tiểu luận về kỹ nghệ phần mềm dựa trên kinh nghiệm chỉ huy dự án OS/360 của IBM

  • Độ phức tạp bản chất và độ phức tạp ngẫu nhiên

    • Độ phức tạp bản chất: công việc bắt buộc phải làm bất kể công cụ hay phần cứng ra sao
      • Ví dụ: trong phần mềm tính thưởng cho nhân viên kinh doanh, phải định nghĩa công thức thưởng và bao phủ mọi trường hợp biên
      • Dù là siêu máy tính $5B hay vi điều khiển $1 thì công việc vẫn như nhau
    • Độ phức tạp ngẫu nhiên: mọi thứ còn lại
      • Xử lý rò rỉ bộ nhớ, chờ mã biên dịch xong, tìm hiểu cách dùng thư viện bên thứ ba
      • Công cụ và tài nguyên phần cứng càng tốt thì thời gian tiêu tốn cho độ phức tạp ngẫu nhiên càng giảm

  • Kết luận của Brooks

    • Những tiến bộ về công cụ hay phần cứng không thể tạo ra mức tăng năng suất 10 lần cho lập trình viên
    • Ngay cả khi giảm mọi hoạt động ngẫu nhiên về 0 thời gian, vẫn không thể mở rộng ở mức đó trừ khi chúng chiếm hơn 9/10 tổng nỗ lực

  • Trường hợp áp dụng

    • Trong suốt sự nghiệp, tác giả luôn thấy người ta tìm cách loại bỏ lập trình viên khỏi phần mềm
    • Các nền tảng no-code tạo được tiếng vang khi hứa trao cho người không biết lập trình toàn bộ sức mạnh của một web developer lành nghề
    • Bài tiểu luận của Brooks luôn khiến tác giả yên tâm rằng các nền tảng thời thượng mới nhất không thể thay thế lập trình viên
    • Các nền tảng này tập trung vào độ phức tạp ngẫu nhiên, chứ không phải độ phức tạp bản chất
    • Dù nền tảng có thể tạo ra mã hoạt động một cách thần kỳ từ đặc tả tính năng, vẫn cần ai đó viết đặc tả

  • Tác động của AI

    • AI hiện đại ném một cái cờ lê vào lý thuyết của Brooks
    • AI thực sự giảm bớt độ phức tạp bản chất
    • Nếu đưa cho AI một đặc tả không hoàn chỉnh hoặc mâu thuẫn, AI có thể vay mượn từ những đặc tả tương tự để lấp đầy khoảng trống
    • Ngay cả khi AI loại bỏ việc lập trình như ta biết, bài tiểu luận của Brooks vẫn mang lại hy vọng rằng cuối cùng vẫn cần ai đó quản lý độ phức tạp bản chất ở một mức độ trừu tượng nào đó

"Choices" của Joel Spolsky (2000)

  • Vì khó chọn chỉ một bài tiểu luận Joel Spolsky yêu thích, tác giả chọn hai bài
  • "Choices" nói về việc xây dựng giao diện người dùng và cái giá tinh vi của việc trao quyền cho người dùng

  • Thông điệp cốt lõi

    • Mỗi khi cung cấp một lựa chọn, bạn đang yêu cầu người dùng đưa ra quyết định
    • Điều đó có nghĩa là người dùng phải suy nghĩ và quyết định về một điều gì đó
    • Điều này không hẳn luôn xấu, nhưng nhìn chung ta nên cố gắng giảm thiểu số quyết định mà con người phải đưa ra

  • Ví dụ Windows 98

    • Joel chia sẻ một hộp thoại lố bịch xuất hiện khi tìm kiếm tài liệu trợ giúp trong Windows 98
    • Lý do hộp thoại này khiến Joel nổi giận:
      • Nó ngắt quãng người dùng khi họ đang cố nhận trợ giúp
      • Nó yêu cầu họ đưa ra một quyết định thiếu thông tin về tối ưu hóa cơ sở dữ liệu
      • Windows né tránh việc ra quyết định và đẩy nó sang cho người dùng

  • Phạm vi áp dụng

    • Dù bài tiểu luận của Joel tập trung vào giao diện người dùng đồ họa, tác giả áp dụng nó ở mọi nơi có ai đó chạm vào mã nguồn, bao gồm cả dòng lệnh hoặc những lập trình viên khác gọi các hàm mình viết
    • Liệu ta có thể đưa ra các quyết định hữu ích thay cho người dùng, đồng thời vẫn trao cho họ quyền kiểm soát đối với những gì họ quan tâm hay không
    • Bài tiểu luận của Joel đã vô số lần ngăn tác giả đẩy cho người dùng những quyết định mà chính mình hoàn toàn có thể tự đưa ra

Raymond Chen, “Application compatibility layers are there for the customer, not for the program” (2010)

  • Raymond Chen là một trong những nhà phát triển làm việc lâu năm nhất trong nhóm Microsoft Windows
  • Blog của ông có hàng nghìn câu chuyện bổ ích và thú vị về lịch sử lập trình Windows

  • Một trường hợp yêu cầu từ khách hàng

    • Yêu cầu từ khách hàng về chế độ tương thích của Windows Vista:
      • Một chương trình được thiết kế cho Windows XP và Windows Server 2003 gặp khó khăn trên Windows Vista
      • Khi đặt sang chế độ tương thích Windows XP thì nó hoạt động tốt trên Vista
      • Họ hỏi cần thay đổi gì trong trình cài đặt để khi chạy trên Vista, chương trình tự động chạy ở chế độ tương thích XP

  • Phép so sánh của Raymond

    • “Tôi thường vứt rác trên vỉa hè trước cửa hàng thú cưng, và mỗi sáng khi cửa hàng mở cửa, sẽ có ai đó quét rác và bỏ vào thùng. Nhưng cửa hàng thú cưng không mở vào Chủ nhật, nên vào Chủ nhật rác cứ nằm ở đó. Tôi phải làm thế nào để bắt cửa hàng thú cưng mở cửa cả ngày Chủ nhật?”

  • Bài học

    • Phép so sánh này buồn cười đến mức mãi sau tôi mới nhận ra Raymond đã sai
    • Chế giễu cái tội của nhà phát triển khi mong đợi Windows sẽ không làm hỏng ứng dụng chỉ sau một bản phát hành
    • Dù không đồng ý với chi tiết, bài viết của Raymond rất hài hước và sắc bén nên có thể bỏ qua khuyết điểm đó
    • Một bài học tuyệt vời về ảnh hưởng đến hành vi người dùng:
      • Nếu bạn muốn thúc đẩy người dùng làm điều gì đó có lợi cho bạn, bạn phải cân nhắc kỹ con đường ít kháng cự nhất từ góc nhìn của người dùng
      • Nếu bạn cho họ thấy rằng vứt rác ra vỉa hè là cách giải quyết hoàn toàn vấn đề, họ sẽ tiếp tục làm vậy

Erik Kuefler, “Don’t Put Logic in Tests” (2014)

  • Tác giả vốn luôn thích unit test và rất tự hào về code test của mình
  • Bài luận này xuất hiện như một cú đánh giữa chừng và phơi bày rằng ông đã viết những bài test khủng khiếp suốt cả sự nghiệp

  • Ví dụ về một bài test có vấn đề

    @Test public void shouldNavigateToPhotosPage() {  
  String baseUrl = "http://plus.google.com/";  
  Navigator nav = new Navigator(baseUrl);  
  nav.goToPhotosPage();  
  assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl());  
}

  • Những vấn đề được phát hiện

    • Khi lần đầu đọc bài luận, tôi đã nghĩ: “Cách tôi viết unit test đúng y như thế này!”
    • Tại sao lại lặp chuỗi http://plus.google.com/ ở hai nơi? Hãy tạo một nguồn chân lý duy nhất như code production
    • Tác giả luôn làm vậy: thêm helper function, biến và vòng lặp để loại bỏ lặp lại trong test
    • Vấn đề là cách tiếp cận này che giấu những bug tinh vi: trên thực tế, nó assert http://plus.google.com//u/0/photos (hai dấu gạch chéo)

  • Sự giác ngộ

    • Bài luận của Erik cho thấy rằng không nên đối xử với code test như code production
    • Hai loại này có mục tiêu và ràng buộc hoàn toàn khác nhau
    • Code test tốt, trên hết, phải rõ ràng
    • Code test không có test riêng cho chính nó, nên cách duy nhất để xác minh tính đúng đắn là kiểm tra trực tiếp
    • Một bài test phải hiển nhiên đến chói mắt với người đọc về việc nó đang assert hành vi nào
    • Vì mục tiêu này, có thể chấp nhận lặp lại để giảm độ phức tạp

Julia Evans, “A little bit of plain Javascript can do a lot” (2020)

  • Là một kỹ sư phần mềm, tôi bước vào thế giới web muộn đến mức hơi đáng xấu hổ
  • Trong 10 năm đầu sự nghiệp, tôi chỉ viết code cho ứng dụng desktop và server backend
  • Mãi đến năm 2017 tôi mới bắt đầu quan tâm đến HTML hay JavaScript

  • Hiểu lầm về framework

    • Khi bắt đầu nghiêm túc học frontend, tôi có ấn tượng rằng JavaScript là một ngôn ngữ lộn xộn được tạo ra trong 10 ngày, và hành vi lại khác biệt rất nhiều giữa các trình duyệt
    • Để viết web app, bạn cần một thứ gì đó hiện đại và tinh tế để bảo vệ mình khỏi mọi sự điên rồ và khiếm khuyết của JavaScript
    • Tôi đã thử những web framework phổ biến như Angular, React và Vue
    • Tôi đã học Vue khá kỹ, nhưng vẫn tốn vô số thời gian cho các vấn đề dependency và những cái bẫy của framework
    • Ngay cả sau tất cả những gì các frontend framework này làm để sửa JavaScript, lập trình web vẫn tệ như cũ

  • Điều bài luận của Julia giúp tôi nhận ra

    • Tôi nhận ra mình đã quá tin rằng JavaScript cần được sửa chữa nên chưa bao giờ cho nó một cơ hội
    • Khi đó tôi đang làm prototype cho TinyPilot và dự định triển khai giao diện web bằng Vue
    • Bài luận của Julia truyền cảm hứng để tôi xem mình có thể đi xa đến đâu chỉ với JavaScript thuần
    • Không framework, không thư viện wrapper, không bước build, không Node.js, chỉ dùng JavaScript thông thường (ES2018)
    • Tôi cứ nghĩ rồi mình sẽ đụng phải vấn đề buộc phải chuyển sang framework hay builder, nhưng điều đó chưa từng xảy ra
    • Có vài cạm bẫy liên quan đến WebComponents, nhưng chẳng là gì so với nỗi đau tôi từng trải qua với Vue và Angular

  • Sự tự do không framework

    • Tôi rất thích cảm giác thoát khỏi framework
    • Khi có lỗi runtime, stack trace không còn là cơn ác mộng của đoạn code đã bị minify, biến đổi và tree-shake
    • Tôi có thể debug chính code của mình đúng như cách mình đã viết ra nó
    • Thành kiến của tôi về JavaScript là sai
    • JavaScript hiện đại khá tốt, và đã hấp thụ nhiều ý tưởng từ các thư viện wrapper đến mức giờ không còn cần wrapper nữa
    • Các trình duyệt đã tỉnh táo hơn để đảm bảo hành vi nhất quán giữa các nền tảng và thiết bị
    • Từ sau năm 2020, tôi không còn tích hợp JavaScript framework hay bước build nào vào các dự án mới, và không hề ngoái lại
    • Với JavaScript thuần, bạn có được 90% lợi ích của framework với chỉ 5% phiền toái

Dan McKinley, “Choose Boring Technology” (2015)

  • Đây là một bài luận khá lạ khi xuất hiện trong danh sách này, vì thực ra tôi chưa từng đọc nó
  • Mọi người vẫn trích dẫn bài này, và khi hiểu ý tưởng của nó, tôi thấy nó quá trực quan nên không còn cảm thấy cần phải đọc

  • Ý tưởng cốt lõi

    • Khi bắt đầu một dự án mới, luôn có sự cám dỗ muốn dùng công nghệ tối tân đang được bàn tán sôi nổi
    • Google vừa công bố một cơ sở dữ liệu mới có thể mở rộng đến mức exabyte, nhanh hơn Postgres 40% và chi phí chỉ bằng 20%
    • Dùng Postgres khi lựa chọn mới hấp dẫn kia ở ngay trước mắt thì thật ngốc
    • Nhưng trên thực tế, công nghệ mới có bug và điểm yếu mà lúc đầu chưa lộ rõ
    • Khi đâm phải chúng, bạn sẽ bế tắc
    • Postgres cũng có vấn đề, nhưng sau 30 năm chinh chiến thực tế, nó có giải pháp đã được kiểm chứng cho gần như mọi vấn đề bạn có thể gặp

  • Khái niệm innovation token

    • Dan thừa nhận rằng đôi khi vẫn nên dùng công nghệ mới, nhưng phải có chiến lược và chỉ với số lượng hạn chế
    • Mỗi doanh nghiệp có ba “innovation token” để tiêu dùng
    • Nếu muốn dùng cơ sở dữ liệu mới hào nhoáng kia, bạn phải tiêu một trong số token đó
    • Bài luận của Dan khớp với bài của Julia một cách rất tự nhiên
    • Giá như tôi đọc một trong hai bài đó trước khi lãng phí ngần ấy thời gian cho frontend framework

Terence Eden, “I’ve locked myself out of my digital life” (2022)

  • Terence Eden là một blogger công nghệ vui tính và chiết trung
  • Mỗi tuần anh viết nhiều bài mới, nhưng bài có ảnh hưởng lớn nhất là "Tôi đã tự khóa chính mình khỏi đời sống số"

  • Kịch bản thảm họa

    • Mô phỏng điều gì sẽ xảy ra nếu sét đánh trúng nhà của Terence và phá hủy mọi tài sản
    • Lưu mật khẩu cho mọi thứ trong trình quản lý mật khẩu
    • Nếu mọi thiết bị đều bị phá hủy thì không thể truy cập trình quản lý mật khẩu
    • Lý do không thể thay thế bằng passkey phần cứng là vì chúng cũng ở trong nhà

  • Sự thức tỉnh

    • Tác giả cảm thấy mình khá an toàn về dữ liệu vì lưu mọi thứ trên ổ đĩa dự phòng và có sao lưu ngoài địa điểm trên ba châu lục với hai nhà cung cấp
    • Bài viết của Terence khiến tác giả nghĩ đến nhiều mối đe dọa đáng tin cậy có thể xóa sổ mọi thiết bị cùng lúc: hỏa hoạn, lũ lụt, tăng áp điện, điều tra hình sự
    • Vì toàn bộ dữ liệu đều được mã hóa bằng những mật khẩu nằm trong đầu, nên mất trí nhớ, mất năng lực hoặc tử vong cũng được thêm vào danh sách

  • Vấn đề của các dịch vụ trực tuyến

    • Các dịch vụ trực tuyến rất yếu trong việc giúp người dùng phục hồi sau thảm họa
    • Tác giả dùng nhiều dịch vụ giả định rằng việc làm mất điện thoại là điều không thể xảy ra, chưa kể tài khoản email và mọi thiết bị số mình sở hữu

  • Ảnh hưởng

    • Kể từ khi đọc bài tiểu luận của Terence, tác giả suy nghĩ nhiều hơn về dịch vụ và thiết bị nào là quan trọng, cũng như cách có thể phục hồi trong kịch bản mà Terence mô tả
    • Khi mua chiếc laptop tiếp theo, tác giả đã thiết lập nó trong thư viện để thử xem liệu có thể khôi phục quyền truy cập vào trình quản lý mật khẩu và các tài khoản quan trọng mà không cần thiết bị ở nhà hay không
    • Tác giả vẫn có thể chuẩn bị ứng phó thảm họa số tốt hơn, nhưng bài viết của Terence vẫn vang vọng trong đầu mỗi khi nghĩ về cách bảo mật thiết bị và dữ liệu
    • Điều gì sẽ xảy ra nếu mọi thứ đột ngột bị phá hủy?

Bonus: "parsing user input" của Brad Fitzpatrick (2009)

  • Xét về mặt kỹ thuật thì đây không phải tiểu luận, nhưng tác giả vẫn luôn nghĩ về một câu trích dẫn từ cuộc phỏng vấn phần mềm
  • Đã đọc Coders at Work nhờ bài đánh giá hết lời khen ngợi của Joel Spolsky năm 2009
  • Đây là tuyển tập các cuộc phỏng vấn với những lập trình viên thành công

  • Câu nói nổi tiếng của Brad Fitzpatrick

    • Brad Fitzpatrick, nhà sáng lập LiveJournal và Memcached, là một trong những người được phỏng vấn
    • Khi đó ông 28 tuổi, là lập trình viên trẻ nhất trong sách, đồng thời cũng là người chửi thề nhiều nhất và hài hước nhất
    • Khi được hỏi về đạo đức trong kỹ thuật phần mềm, ông đã có một phát biểu đầy nhiệt huyết về việc kiểm tra đầu vào:
      • "Tôi chỉ mong mọi người nhất quán cho phép nhập dấu cách hoặc dấu gạch nối vào biểu mẫu thẻ tín dụng. Máy tính rất giỏi trong việc loại bỏ những thứ đó. Đừng bảo tôi phải định dạng con số của mình thế nào."

  • Ứng dụng

    • Mỗi khi cố dán số điện thoại vào biểu mẫu web, tác giả lại nhớ đến câu trích dẫn này
    • Rồi lại càu nhàu rằng dấu ngoặc hoặc dấu cách không được chấp nhận, hoặc tệ hơn là số điện thoại bị cắt mất vì dấu ngoặc rồi hệ thống lại phàn nàn rằng dấu ngoặc không được phép
    • Mỗi khi tạo trường nhập liệu trong phần mềm và nghĩ về các ký tự ngoài dự kiến, tác giả lại nghe thấy Brad Fitzpatrick nói rằng "Máy tính rất giỏi trong việc loại bỏ những thứ đó."

Bài viết liên quan

3 bình luận

 
shakespeares 2025-10-07

Có lịch sử nên mới có hiện tại.
 
GN⁺ 2025-10-02
Ý kiến Hacker News

  • Sau khi đọc bài viết "I've locked myself out of my digital life", tôi cảm thấy nó đã diễn tả rất đúng nỗi lo mà tôi luôn mang trong mình nhưng khó giải thích
    Trong thế giới analog, có lẽ tôi vẫn có thể thuyết phục một con người về việc mình là ai để xác thực danh tính và lấy lại quyền truy cập tài khoản, nhưng trước những thuật toán vô cảm của thế giới số, nếu không có thông tin xác thực thì van nài thế nào cũng vô ích
    Ngay cả công ty cung cấp dịch vụ trình quản lý mật khẩu của tôi cũng không có quyền truy cập vào mật khẩu của tôi
    Thậm chí còn không có ai để thuyết phục, và rốt cuộc chỉ có code là luật
    Tôi nghĩ mọi người cần hiểu rõ vấn đề này trước khi cổ vũ việc loại bỏ hoàn toàn các quy trình trực tiếp trong mọi quy trình
    Trong bài báo, điều này có thể nghe như một tình huống hiếm gặp, nhưng hoàn toàn có thể xảy ra trong thiên tai hoặc khi bị trộm cắp
    Bài liên quan: https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my-digital-life/

    • Tôi nghĩ thực ra không có nhiều người ủng hộ kiểu tự động hóa cực đoan này hoặc việc cắt giảm tương tác trực tiếp đến mức đó
      Và đây cũng không chỉ là vấn đề của AI, mà phần mềm dựa trên luật lệ cũng vậy
      Ở Liên minh châu Âu (EU), pháp luật bảo đảm quyền được khiếu nại với con người đối với bất kỳ quyết định nào

  • Grug Brained Developer là một bài viết luôn ở lại trong đầu tôi, nhưng nó không có trong danh sách
    Có lẽ vì đó vốn là điều tôi đã đồng ý sẵn rồi, nên nó để lại ký ức hơn là tạo ra một cuộc thay đổi trong tư duy
    Tham khảo: https://grugbrain.dev/

    • Trong số đó, tôi thực sự rất thích đoạn nói rằng "cảm giác tuyệt nhất là cuối cùng nhốt được con quỷ phức tạp vào viên pha lê đã được sửa chữa"

    • Tôi là người song ngữ và dùng tiếng Anh như ngôn ngữ thứ hai, nên kiểu viết grug brain khá khó đọc và khó hiểu với tôi
      Tôi cũng không biết từ 'grug' nghĩa là gì
      Dù vậy tôi vẫn thấy blog đó rất thú vị

  • Tôi không đồng ý với kết luận về "No Silver Bullet" của Fred Brooks
    Tôi không đồng ý với lập luận gần đây cho rằng AI đã làm giảm độ phức tạp bản chất đến mức phá vỡ luận điểm của Brooks
    AI có thể tự động lấp đầy những đặc tả chưa hoàn chỉnh hoặc mâu thuẫn bằng cách tham chiếu các trường hợp tương tự, nhưng độ phức tạp bản chất vẫn không được AI giải quyết đủ mức, và tôi nghĩ sau này cũng sẽ không thể
    Phân tích chi tiết hơn của tôi ở đây: https://smartmic.bearblog.dev/no-ai-silver-bullet/

    • Cảm ơn vì đã đọc và chia sẻ bài viết của tôi
      Tôi đồng ý rằng LLM không thể loại bỏ hoàn toàn độ phức tạp bản chất, như bạn đã nói trong phần diễn giải của mình
      Nhưng tôi nghĩ LLM có thể giảm bớt độ phức tạp bản chất ở một mức độ nào đó
      Ví dụ thực tế là tôi đã nhờ Claude 4.1 Opus định nghĩa một ngôn ngữ đặc thù miền cho việc tạo hình ảnh bằng máy tính
      Tôi chỉ truyền đạt yêu cầu và để lại các chi tiết cụ thể ở mức mơ hồ, nhưng LLM vẫn viết ra đặc tả
      Trong trường hợp như vậy, tôi tin chắc rằng LLM đã giảm bớt độ phức tạp bản chất
      Tự tôi cũng có thể định nghĩa mới với chất lượng cao, nhưng nếu kết quả LLM đưa ra đã đủ tốt thì tôi ít có lý do để bỏ thêm công sức chỉ để cải thiện chất lượng
      Trước đây tôi vốn cảm thấy mình không cần LLM lắm vì tôi code tốt hơn và cũng thích tự làm hơn, nhưng khi dùng thử thì thấy trong những phần không nhất thiết phải tự bỏ thời gian và năng lượng, LLM đã gánh giúp một phần đáng kể độ phức tạp bản chất
      Ví dụ: https://kagi.com/assistant/1b8324a2-ae54-4a1b-9c69-51d76fc5c7d1

    • Độ phức tạp mà AI làm giảm rốt cuộc chỉ là gánh nặng nhận thức của người viết code
      Cái Brooks gọi là 'độ phức tạp không bản chất (nonessential complexity)' vẫn hầu như còn nguyên trong chính đoạn code
      Kết quả là gánh nặng đó bị chuyển sang cho người đọc code
      Giống như mặc một bộ exoskeleton để nâng vật nặng lên kệ rồi bảo đồng nghiệp sơn nó cho đẹp vậy

  • Bài luận "Parse, don't validate" theo tôi là một tác phẩm kinh điển
    Còn câu "Don't put logic in tests" thì tôi thấy khó đồng ý
    Vấn đề trong ví dụ xuất phát từ chỗ đáng ra phải dùng kiểu URI thay vì chuỗi, và tôi nghĩ code test cũng nên được coi là code production vì nó ảnh hưởng đến việc triển khai thành công hay thất bại
    Dù sao thì những thảo luận kiểu này vẫn rất đáng để tự mình xem xét và cân nhắc xem có áp dụng được cho bản thân hay không

    • Tôi cũng thấy lạ là "Parse, don't validate" lại ít được biết đến như vậy
      Quanh tôi đa số là người làm Go, Python, C++, nên có vẻ nó chỉ nổi tiếng trong giới ngôn ngữ hàm
      Tôi nghĩ góc nhìn phê phán ví dụ của "Don't put logic in tests" là hợp lý
      Ví dụ có thể được thay bằng một trường hợp tốt hơn một chút, nhưng điểm cốt lõi là ngay cả việc nối chuỗi đơn giản cũng có thể thêm độ phức tạp vào test và khiến bỏ sót bug

    • Cá nhân tôi thấy triết lý không đưa (quá nhiều) logic vào test khá hấp dẫn
      Tôi đã nhiều lần gặp false positive do bug trong code test, nên dần trở nên mất niềm tin vào chuyện này
      Tôi cho rằng không nên cảm thấy cần phải viết 'test cho test'
      Thực tế thì những trường hợp như vậy hiếm gặp, nhưng gần đây test code tệ hại do LLM viết đang dần thành xu hướng chủ đạo, nên vấn đề ngày càng lớn hơn bất kể triết lý này

  • Tôi muốn giới thiệu tài liệu điều tra và tổng kết của Nancy Leveson về tai nạn Therac-25

  • Với tôi, bài viết tôi thích nhất trong lĩnh vực này là "The Parable of the Two Programmers" của Neil W. Rickert
    Đây là một câu chuyện cô đọng rất hay về cuộc đời và những thử thách của lập trình viên
    https://c00kiemon5ter.github.io/code/philosophy/2011/10/30/Tale-of-two-Programmers.html

    • Tôi biết Neil khá rõ vì đã thường xuyên trao đổi với ông ấy nhiều năm trong nhóm Usenet comp.ai.philosophy
      Giọng văn và nội dung đúng là rất mang phong cách của ông ấy

    • Bài này thực sự rất tuyệt

  • Với tôi, đây là bài viết mang tính bước ngoặt
    https://stevemcconnell.com/articles/software-quality-at-top-speed/

    McConnell có vẻ không quá nổi tiếng ở đây

    • Cảm ơn vì đã chia sẻ!
      Đây là lần đầu tôi đọc bài này, còn tôi thì từng rất ấn tượng khi đọc Code Complete vào đầu sự nghiệp
      Tôi vẫn để cuốn đó trên giá sách, và mỗi lần đọc lại vài đoạn đều nghĩ 'cuốn này thực sự quá hay! Nhất định phải đọc lại trọn vẹn'
      Tôi đã không nghe tin gì về McConnell trong một thời gian, nên cũng thắc mắc vì sao trong khi các tác giả cùng thời như Kent Beck, Martin Fowler, Ward Cunningham vẫn tiếp tục viết dù mức độ nổi tiếng sau những năm 2000 có giảm đi, thì riêng McConnell lại im ắng
      Hóa ra việc ông ấy rời ngành phần mềm để chuyển sang làm cố vấn tài chính là một chuyện khiến tôi khá bất ngờ
      https://raindogllc.com/steve-mcconnell-investment-advisor/

  • Dù không hẳn là một bài luận phần mềm theo nghĩa chính thống, bài blog "Ban on Imports" của Gilad Bracha đã khiến góc nhìn của tôi về hệ thống mô-đun thay đổi hoàn toàn
    Nó nhấn mạnh rằng import/export về bản chất cũng giống trạng thái toàn cục, và vì thế mang theo toàn bộ vấn đề của trạng thái toàn cục
    Từ đó trở đi tôi đánh giá cao khái niệm dependency injection hơn nhiều
    https://gbracha.blogspot.com/2009/06/ban-on-imports.html

  • Có thể khó xếp nó vào loại bài luận phần mềm theo nghĩa chặt chẽ, nhưng "Don't Call Yourself A Programmer, And Other Career Advice" của Patrick McKenzie là một kho báu thực sự
    https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

  • Là người đặc biệt quan tâm đến ngôn ngữ lập trình, bài "slumming with basic programmers" là một thứ đọng lại rất lâu trong đầu tôi
    https://prog21.dadgum.com/21.html
 
secret3056 2025-10-02

Tôi thực sự đồng cảm với chuyện phân tích cú pháp đầu vào của người dùng.
Không hiểu phần lớn các lập trình viên phát triển tính năng nhập số điện thoại thay thế làm việc trong môi trường nào mà lại sợ đến thế việc gọi replace() hai lần trên một chuỗi?