Phần mềm máu lạnh
(dubroy.com)- Một số dự án phần mềm là kiểu máu nóng, chỉ được duy trì khi có hoạt động phát triển liên tục; nếu hoạt động bị gián đoạn mà vẫn có thể tiếp tục lại thì chúng gần với kiểu máu lạnh hơn
- Dự án kiểu máu lạnh chọn công nghệ nhàm chán để ngay cả khi dừng rất lâu thì build và test cũng không bị hỏng, đồng thời tránh phụ thuộc vào các dịch vụ bên ngoài có thể thay đổi hoặc biến mất
- Việc dịch vụ phụ thuộc bị mua lại hoặc đóng cửa, nâng cấp compiler, hay gói phần mềm ngừng được hỗ trợ sẽ quay trở lại thành chi phí bảo trì khi khởi động lại những dự án ít hoạt động
- Với mã nguồn như các dự án cá nhân, có thể bị bỏ không 1 năm, 2 năm, 3 năm, rất khó tạo ra nhiệt liên tục, nên cần thiết kế ngay từ đầu với giả định tỷ lệ thay đổi thấp
- Trình tạo trang tĩnh cho blog, từ commit đầu tiên vào năm 2012, vẫn tiếp tục hoạt động gần như không cần sửa đổi chỉ với Python 2, 4 mô-đun bên thứ ba được chứa ngay trong kho lưu trữ, chạy cục bộ và triển khai bằng
rsyncoverssh
Cách duy trì dự án nhìn qua phép ẩn dụ động vật máu lạnh
- Trong một lớp lịch sử tự nhiên năm 2004, giáo sư đã đặt một painted turtle con vừa được lấy ra từ tủ đông dưới camera rồi bắt đầu bài giảng
- Painted turtle con là một trong số rất ít loài có thể sống sót ngay cả khi ở trạng thái đông cứng
- Trong suốt một giờ, con rùa bắt đầu từ những chuyển động gần như không thể nhận ra, và đến cuối thì đã di chuyển được khoảng một nửa màn hình
- Động vật máu nóng phải duy trì thân nhiệt trong một khoảng hẹp; con người sẽ gặp vấn đề nếu lệch khỏi khoảng 37°C
- Động vật máu lạnh điều chỉnh quá trình trao đổi chất theo nhiệt độ xung quanh, hoạt động mạnh khi ấm và di chuyển chậm dần khi cơ thể và môi trường lạnh đi
- Các dự án phần mềm cũng có thể được chia tương tự
- Phần mềm kiểu máu nóng hoạt động tốt khi dự án có chuyển động và nhiệt lượng liên tục
- Nếu để yên trong 6 tháng, khi mở lại nó có thể đã thành một dự án chết
Điều kiện và ví dụ về phần mềm kiểu máu lạnh
- Lý do khiến dự án kiểu máu nóng khó khởi động lại là vì những thay đổi bên ngoài tích lũy theo thời gian
- Dịch vụ mà CI phụ thuộc vào có thể bị mua lại hoặc cạn tiền nên không còn hoạt động
- Khi thêm phụ thuộc mới, có thể sẽ cần nâng cấp compiler
- Những package khác có thể đã ngừng được hỗ trợ nên không còn chạy với compiler mới nhất
- Những dự án mà bạn làm một mình, chỉ sửa khi có cảm hứng rồi để đó hơn 1 năm mới đụng tới lại thì rất khó vận hành theo kiểu máu nóng
- Dự án kiểu máu lạnh nên giống như painted turtle con bị đông cứng: sau 1 năm vẫn có thể tiếp tục lại từ đúng điểm đã dừng
- Để làm được điều này, cần dùng boring technology và tránh phụ thuộc vào các dịch vụ bên ngoài mà script build·test có thể thay đổi, hỏng hoặc biến mất hoàn toàn
- Phụ thuộc được đưa thẳng vào trong kho lưu trữ của dự án theo kiểu vendored dependencies
- Phần mềm vận hành blog này là một ví dụ về dự án kiểu máu lạnh
- Commit đầu tiên là ngày 8 tháng 1 năm 2012, là một trình tạo trang tĩnh nhỏ để thay thế một cài đặt Wordpress cũ
- Nó được viết bằng Python 2, phụ thuộc vào 4 mô-đun bên thứ ba và tất cả đều đã được commit vào kho lưu trữ của dự án
- Toàn bộ quy trình đều chạy cục bộ, và kết quả được triển khai bằng
rsyncoverssh - Ngoài một vài cải tiến nhỏ, nó vẫn tiếp tục hoạt động mà không cần sửa đổi, và được kỳ vọng sẽ còn tiếp tục chạy thêm 12 năm nữa
1 bình luận
Ý kiến trên Hacker News
Express, framework web trong hệ sinh thái Node và JavaScript, hiện vẫn duy trì phiên bản chính 4.x.x suốt hơn 10 năm https://www.npmjs.com/package/express?activeTab=versions
Dù vậy, nó vẫn được dùng rất nhiều với hơn 17 triệu lượt tải mỗi tuần https://www.npmjs.com/package/express, và tuy không có quá nhiều tính năng hay hiệu năng tốt nhất https://fastify.dev/benchmarks/ thì điểm hay là cho phép phát triển nhanh, ổn định và lập kế hoạch dài hạn
Không cần lo chuyện ngừng vá bảo mật cho phiên bản cũ hay thay đổi API đột ngột, còn Go thì còn ổn định hơn nhờ thư viện chuẩn phong phú và cam kết tương thích, đến mức các chương trình hơn 10 năm tuổi vẫn có thể chạy được https://go.dev/doc/go1compat
Khi mới ra mắt, nó từng bị coi là thứ rác rưởi dành cho lập trình viên giả chỉ vì được viết bằng JavaScript, nhưng sau đó đã giúp nhiều công ty xây dựng những dịch vụ tuyệt vời thực sự kiếm ra tiền bằng Express, và hiện giờ chắc đang xử lý lượng request khổng lồ
Dạo này tôi cũng viết nhiều bằng Go, nhưng vẫn hoàn toàn hài lòng với việc xây dựng dịch vụ bằng Express, và nhìn chung tôi cho rằng đây là phần mềm tốt
Không hẳn là ghét nó, mà là tôi có lẽ sẽ không chọn nó vì guồng quay nâng cấp phiên bản liên tục không dứt
Python là một ví dụ rất tệ cho phần mềm máu lạnh
Cả runtime lẫn công cụ đều liên tục có thay đổi phá vỡ tương thích, và người viết cũng đang ở trong tình huống vẫn phải tiếp tục dùng Python 2, vốn đã hết hỗ trợ từ lâu
Ví dụ tốt hơn là những ngôn ngữ như Go hay Java, nơi mã 10 năm tuổi vẫn chạy tốt với công cụ hiện đại, và cực đoan hơn nữa là Perl, nơi cả mã 30 năm tuổi vẫn còn chạy ổn
Khi làm phần mềm, ta thường lỡ cho phép người dùng làm điều gì đó theo cách không chủ đích, và trong thế giới Java, cách xử lý là thêm tính năng mới hơn, an toàn hơn, rõ ý định hơn rồi khuyến khích người dùng chuyển sang dùng nó
Python cũng tương tự, chỉ là có thêm phần “và sắp tới sẽ tắt tính năng cũ”, còn Java thì không làm vậy
Ví dụ, phương thức
equalscủajava.net.URLđược biết đến là một thiết kế hỏng và bị khuyến cáo rất mạnh là không nên dùng, nhưng vẫn tiếp tục được hỗ trợ suốt hơn 20 nămToán tử rỗng trong Python Airflow từng hỗ trợ tên
DummyOperatormột thời gian, nhưng vì “dummy” từng được dùng như một từ miệt thị trong bối cảnh lịch sử và văn hóa, maintainer đã đổi sang dùngEmptyOperatorvà phá vỡ tên cũKhi nâng cấp, mã sẽ báo lỗi ngay lúc nạp nếu chưa đổi tên tham chiếu, và cá nhân tôi sẽ không chọn phá vỡ người dùng theo kiểu đó
Trong thế giới Java, mức đổi tên như vậy hẳn vẫn sẽ được hỗ trợ cho đến khi có lý do thật sự không thể chịu nổi nữa, vì hoàn toàn có thể xử lý bằng thay thế văn bản
Vì vậy nhìn chung tôi thấy Java và các dependency thư viện Java có thể được nâng cấp tự do hơn rất nhiều so với Python
Chỉ cần dùng bản Java LTS và chọn dependency tốt thì gần như lúc nào cũng có thể làm cho nó chạy lại được
Còn với Python, trong một lớp học machine learning, đã từng có chuyện một dependency đưa vào thay đổi API phá vỡ tương thích chỉ sau một đêm, và giảng viên không hề nhận ra vì vẫn dùng nguyên phiên bản mới nhất tại thời điểm bắt đầu chuẩn bị bài giảng vài tuần trước đó
Việc chuyển từ Python 2 sang 3 đúng là một thay đổi phá vỡ tương thích, nhưng đó là một lần thay đổi chứ không phải “liên tục có thay đổi phá vỡ tương thích”
Nếu giữ nguyên trong cùng một phiên bản chính thì mã cũ sẽ không bị hỏng bởi các phiên bản phụ mới hơn; ví dụ mã 2.x cũ vẫn chạy tốt trên 2.7, và mã 3.x cũ cũng vẫn chạy trên 3.12
Việc đổi phiên bản phụ có thể thêm tính năng mới, nhưng mã 3.x cũ không dùng từ khóa
asynchay type hint thì không vì thế mà bị hỏngĐây là một trong những lý do khiến tôi tránh Python nếu có thể
Tôi cảm thấy mã Python viết hôm nay có khả năng thấp là vài năm nữa vẫn còn chạy được, và tôi xem đó là một vấn đề khá lớn
Ngay cả khi thử chạy mã Java 3 năm tuổi trên SDK mới, lúc nào cũng có chỗ nào đó bị hỏng
Tôi làm việc với IBM mainframe (z/OS), và gần như không thấy nơi nào coi trọng duy trì khả năng tương thích ngược như IBM
Tôi nghĩ Microsoft Windows đứng thứ 2, Linux kernel ABI khoảng thứ 3, nhưng nếu nhìn toàn bộ hệ sinh thái Linux thì đó chỉ là một phần nhỏ
Còn lại phần lớn gần như là churn, và trong mã nguồn mở có vẻ hiếm người muốn dành thời gian cho khả năng tương thích ngược như một việc làm vì đam mê
Về mặt kinh tế, điều này trông giống thế tiến thoái lưỡng nan của tù nhân: ai cũng đẩy chi phí duy trì tương thích sang người khác, và kết quả là tạo thêm nhiều việc vô ích cho tất cả mọi người
Ví dụ, nhìn vào cộng đồng retro computing, chuyện viết driver để phần cứng mới chạy được trên hệ điều hành cũ cũng không phải là hiếm
Nếu không có thù lao, cuối cùng mọi thứ phụ thuộc vào việc bạn yêu quý nền tảng mình tạo ra đến mức nào, và vì Linux kernel đã chứng minh được sự cam kết với tính ổn định ABI nên tôi quyết định nhắm trực tiếp vào system call của nó
Ngược lại, với ngôn ngữ lập trình do chính tôi tạo ra, tôi lại muốn làm nó “hoàn hảo” nhất có thể nên cứ thấy muốn sửa liên tục
Tôi còn ghi chú trong README rằng nó vẫn đang ở giai đoạn phát triển ban đầu và không ổn định, phòng trường hợp có ai đó định dùng nó một cách điên cuồng
Tôi đoán những người tạo ra Ruby hay Python cũng cảm thấy tương tự: ngôn ngữ giống như con của mình, mình muốn nó thành công, nên có thể sẽ nghĩ rằng những sai lầm như việc
printtừng là từ khóa thì phải được sửaTrớ trêu là chính những phần phục vụ khả năng tương thích ngược cũng thường hay bị hỏng
Ở công ty cũ, tôi làm các ứng dụng Node được container hóa và CI xây image từ mã nguồn Node, nhưng rồi việc deploy các service không đụng tới trong một thời gian bắt đầu đột ngột thất bại
Hóa ra Dockerfile được xây trên một Ubuntu image đã hết thời gian hỗ trợ, và kho cập nhật đã bị chuyển sang kho lưu trữ, khiến image không thể build nếu không sửa Dockerfile
Đó là ví dụ điển hình của phần mềm không đụng tới mà vẫn hỏng, và vì thế tôi thích Go cùng binary đơn hơn
Nếu đã đóng gói thành bản phát hành thì không cần build lại nữa, và Docker image Distroless cũng không có phụ thuộc nào ngoài binary của tôi
Tôi đã dùng Go lâu năm nhưng chưa từng gặp chuyện phần mềm hỏng dần theo tuổi tác, còn đủ kiểu vấn đề từng gặp với Node hay PHP thì đã biến mất
Vấn đề lớn thứ hai bên phía Node là các pattern gián tiếp hóa của framework, còn lớn nhất là quản lý package
Các vấn đề peer dependency kiểu như “đã cài phiên bản X nhưng module Y lại cần phiên bản Z” cứ xuất hiện liên tục
Nhiều kỹ sư khi tìm thư viện trên GitHub thường kiểm tra thời điểm commit cuối cùng
Họ có xu hướng cho rằng thư viện có commit càng gần đây thì càng được hỗ trợ tốt hơn
Nhưng nếu một dự án đã được lưu trữ, làm đúng chính xác điều mình cần, có 0 bug và đã ổn định suốt nhiều năm, thì chẳng khác nào tìm được viên ngọc ẩn trong cửa hàng đồ cũ
Dạo này nhiều kỹ sư tự động loại bỏ những thư viện không được cập nhật “liên tục”, như thể đó là điều tốt
Môi trường phát triển phần mềm hiện đại thường không như vậy, và web frontend là ví dụ tiêu biểu của sự thay đổi thường xuyên
Nếu là thư viện hoàn toàn độc lập thì không cập nhật vẫn có thể ổn, nhưng thư viện phụ thuộc vào web frontend framework sẽ gây vấn đề nếu không được cập nhật theo các thay đổi của hệ sinh thái
Tôi không biết con số thực tế, nhưng trong phần lớn áp đảo các trường hợp, không có hoạt động gần đây không có nghĩa là “đã hoàn thiện và không còn bug”, mà là “đã bị bỏ rơi”
Có ngôn ngữ đã trở nên gần như khác hẳn so với phiên bản 1.0, còn có ngôn ngữ thì chỉ chất thêm lên trên trong khi vẫn giữ lại phần lớn mã đã viết
Cuối cùng, có vẻ khuynh hướng đó cũng phản ánh vào cộng đồng và hệ sinh thái
Tôi nhớ Clojure nằm ở nhóm đầu bảng vì gần như không có thay đổi phá vỡ tương thích, và những thư viện lần cuối thay đổi từ 5 năm trước vẫn chạy hoàn hảo trên phiên bản ngôn ngữ hiện tại
Việc nó thuộc họ Lisp, cho phép mở rộng phần lõi ngôn ngữ mà không cần thay đổi upstream, có lẽ cũng giúp ích, dù tất nhiên bản thân điều đó cũng có nhược điểm riêng
Dù vậy, điều tôi thích là nó khiến tôi ngừng nghĩ rằng “mới” đồng nghĩa với “tuyệt vời”
Giờ đây tôi còn dùng các thư viện gần như không thay đổi trong nhiều năm thường xuyên hơn cả thư viện mới tạo từ năm ngoái, mà cũng không gặp vấn đề lớn nào
Có ngôn ngữ phát hành 1–2 năm một lần và được dùng nhiều để bổ sung cú pháp mới thanh lịch hơn hoặc các kiểu dữ liệu trừu tượng trong thư viện chuẩn nhằm thay thế những pattern trước đây tuy phổ biến nhưng khá vụng
Cộng đồng của ngôn ngữ đó gần như lập tức xem cú pháp mới là “idiomatic”, và coi mã được viết theo cách cũ cồng kềnh là thứ nên được sửa lại
Lý do để thay đổi một codebase cụ thể thường là vì cách cũ kém sáng sủa hơn so với cú pháp mới, đồng thời làm cho việc bảo trì và review code khó hơn
Lập luận là nếu cú pháp mới đã tồn tại từ đầu thì chẳng ai nghĩ cách cũ là mã tốt cả, vì vậy cần cập nhật mã để giảm rào cản đọc hiểu và đóng góp cho các nhà phát triển mới
Nếu một thư viện viết bằng những ngôn ngữ kiểu này không được cập nhật quá 3 năm, đó thường là tín hiệu xấu
Điều đó có thể có nghĩa là tác giả không còn gắn kết với cộng đồng đủ để duy trì mã theo phong cách idiomatic mà những người học phiên bản ngôn ngữ mới nhất có thể dễ dàng đọc được, và cũng có thể không còn quan tâm tới việc nhận PR từ bên ngoài
Có thể dự án bị đánh dấu là đã bị bỏ rơi nên chẳng ai buồn báo nữa, trong khi vẫn tồn tại lỗ hổng bảo mật
Phần mềm có thể sống mà không cần cập nhật chỉ là phần mềm được làm đúng ngay từ đầu
Nếu là phần mềm chỉ dành cho riêng mình thì tương đối dễ, vì ngay cả sau 10 năm sở thích của bản thân cũng khó thay đổi nhiều, và nếu
nnhỏ thì có thể bỏ qua những vấn đề nhỏ kiểu dùng hàmO(n^2)dù đã có hàmO(n)Nhưng nếu là phần mềm để người khác dùng thì yêu cầu sẽ khác nhau, và đến khi
Nđủ lớn thì những vấn đề như giá trị của hàmO(n)mới bắt đầu lộ raDù viết cho mình hay cho người khác, vẫn có thể xuất hiện những vấn đề không lường trước được
Ví dụ, xử lý tệp lớn hơn 1GB thì bị crash, nhưng bình thường chỉ dùng tệp dưới 100KB nên không để ý; đến lúc sửa thì có thể phải viết lại một nửa
Đây là phản biện lớn nhất với ý nghĩ rằng phần mềm không thay đổi thì về bản chất tốt hơn phần mềm thay đổi thường xuyên
Phần mềm không thay đổi có thể đã hoàn hảo ngay từ đầu, nhưng cũng có thể ẩn chứa nỗi kinh hoàng ở sâu bên trong, và rất khó phân biệt trước
Điều đó cũng không có nghĩa phần mềm cập nhật nhanh thì về bản chất tốt hơn phần mềm cập nhật chậm; ngoài tốc độ cập nhật còn có rất nhiều yếu tố khác
Nếu yêu cầu thay đổi thì đương nhiên phần mềm cũng phải thay đổi
Nhưng trong 10 năm có thể xảy ra rất nhiều chuyện không liên quan đến thay đổi yêu cầu
Dự án mã nguồn mở có thể bị bỏ rơi hoặc đổi hướng, phần mềm thương mại có thể bị ngừng, công ty có thể bị mua lại, quy định của App Store hay Play Store có thể thay đổi, API có thể biến mất hoặc đổi giá khiến tính kinh tế của dự án sụp đổ
Toolchain, framework, ngôn ngữ lập trình, paradigm và best practice cũng thay đổi
Cốt lõi, theo tôi, là đừng để những thay đổi bên ngoài không liên quan đến yêu cầu ép mình phải thay đổi
Đây là một nguyên tắc tốt, nhưng như mọi khi vẫn có đánh đổi
Ổn định và lỗi thời là hai chuyện khác nhau, và ranh giới đó thường nằm ở bảo mật
Nếu để đáp ứng một yêu cầu mới quan trọng mà bạn phải nâng một thư viện được vendor sẵn lên tới 7 major version, rồi kéo theo hàng loạt lỗi vỡ vẩn không liên quan, thì phải làm sao
Nếu những người quen với bộ công cụ như bị đóng băng trong thời gian đó không còn đủ nữa và cũng chẳng ai muốn học, thì phải làm sao
Chọn dependency một cách cẩn thận và bảo thủ là điều tốt, nhưng đến cả những thay đổi dependency nhỏ như vậy mà cũng không theo kịp thì theo tôi là đã đi quá một bước
Tôi đồng cảm với cảm xúc của bài viết
Tôi thực sự ghét việc ngay cả một ứng dụng di động được tạo ra chỉ vài năm trước mà giờ đây để vá và gửi bản cập nhật cũng cần tới hàng chục giờ
Phần cuối nơi tác giả gọi trình tạo static site của mình là phần mềm máu lạnh và nói nó chạy trên Python 2 cũng khá thú vị
Python 2 ngày nay ngày càng khó cài đặt, và cuối cùng dự án đó rồi cũng sẽ trở thành một dự án máu nóng
Mỗi lần nâng cấp Xcode lại phải sửa lặt vặt để project có thể compile sạch và hoạt động bình thường, điều đó thật sự rất bực mình và lẽ ra không nên bị chấp nhận
Gần đây toàn bộ message trong lịch sử git chỉ là các biến thể của “sửa để chạy được trên Xcode mới nhất”
Nếu những thay đổi ở SDK cấp thấp hay OS này là cần thiết vì mối đe dọa bảo mật thì còn có thể phần nào hiểu được, nhưng hầu như không phải vậy
Phần lớn chỉ là những thay đổi ngớ ngẩn như deprecate API, thêm cảnh báo mặc định, rồi bảo giờ hãy dùng framework này thay vì framework kia
Nền tảng và framework nên ngừng việc cố tình trở thành mục tiêu luôn dịch chuyển, và điều đó lại càng đúng nếu đây đã là những hệ điều hành rất ổn định và đáng tin cậy
Một dự án 10 năm tuổi phải có thể được lấy ra khỏi ngăn đá và vẫn compile sạch, chạy được như 10 năm trước
Các vendor hệ điều hành này đều là những tập đoàn nghìn tỷ, nên tôi không muốn nghe cái cớ rằng việc đảm bảo tương thích ngược đòi hỏi quá nhiều công sức kỹ thuật
Tôi vẫn đang duy trì một side project cá nhân
Nó bắt đầu cách đây 12~13 năm bằng PHP thuần, sau đó được viết lại bằng Laravel, rồi khoảng năm 2017 lại được viết lại lần nữa bằng Symfony
Có những giai đoạn vì làm freelance toàn thời gian nên không còn năng lượng, trong 6~18 tháng chỉ có 2~3 commit rất nhỏ, nhưng hễ có thời gian tôi lại thêm tính năng, nâng cấp, thử nghiệm và học hỏi
Việc đó rất hữu ích để học cách duy trì một dự án trong dài hạn
Tôi đã học được cách cập nhật dependency, loại bỏ những thứ không cần thiết, kiểm tra cập nhật bảo mật, tìm cơ hội đơn giản hóa (từ Vagrant sang Docker, từ Vue + Axios + Webpack v.v. sang Htmx), và cả những thứ nên tránh
Cá nhân tôi dần tránh các dependency mới ra lò, microservice và hạ tầng phức tạp như Kubernetes
Gần đây tôi đã làm thêm nhiều tính năng, nâng cấp lên PHP 8.2 và Symfony 7, và còn tích hợp cả tính năng dựa trên ChatGPT, nên có lẽ nếu muốn thì tôi có thể nghỉ 1~3 năm
Trong 4~5 năm qua, dự án này đã tạo ra doanh thu tương đương thu nhập một năm trung bình của một freelancer, nên nó cũng không phải một side project vô danh đang ngủ quên
Sau vài năm không dùng rồi quay lại, tôi thấy những hàm xử lý ảnh kinh khủng y hệt như lúc tôi rời đi 8 năm trước vẫn còn nguyên ở đó
Ngoài những gì bài viết nói, một mô hình đe dọa vốn dĩ an toàn cũng rất quan trọng
Ví dụ, cả một website luôn phải liên tục đối phó với kẻ tấn công và bot spam, nên về bản chất nó gần với kiểu máu nóng hơn
Ngược lại, một trang tĩnh như TiddlyWiki thậm chí có thể không cần đưa lên web, và trình duyệt là một nền tảng cực kỳ ổn định, nên tốt hơn nhiều
Có vẻ sự khác biệt trong mức độ ưa thích giữa các dự án máu lạnh và các dự án máu nóng có liên quan đến Buxton Index được nhắc tới tại https://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html
Một cửa hàng tạp hóa nhỏ trong khu phố là khoảng 0,5 năm, một tín đồ Cơ Đốc chân chính là vô hạn, một chính trị gia trung bình đang nhắm tới tái đắc cử là khoảng 4 năm, phần lớn các ngành công nghiệp thì dài hơn đôi chút, còn các nhà quản lý phải viết báo cáo theo quý thì ngắn hơn rất nhiều
Lý do Buxton Index quan trọng là vì sự hợp tác chặt chẽ giữa các chủ thể có Buxton Index rất khác nhau chắc chắn sẽ thất bại và dẫn đến những lời chỉ trích mang tính đạo đức
Bên có chỉ số ngắn hơn sẽ bị chê là hời hợt và thiển cận, còn bên có chỉ số dài hơn sẽ bị chê là lơ là nhiệm vụ, trốn tránh trách nhiệm hoặc ăn theo
Họ cũng sẽ coi nhau là ngu ngốc
Ưu điểm của Buxton Index là nó là một khái niệm số đơn giản nên trung lập về mặt đạo đức, và giúp kéo sự khác biệt đó lên trên các cuộc tranh cãi đạo đức
Điều này đặc biệt quan trọng khi nghĩ về sự hợp tác giữa giới học thuật và công nghiệp
Cái tên này thực sự rất tệ
Động vật máu lạnh phụ thuộc rất nhiều vào môi trường, còn động vật máu nóng giảm sự phụ thuộc vào nhiệt độ bên ngoài nhờ trao đổi chất
Dù sao thì nó cũng mơ hồ một cách không cần thiết
Chỉ cần gọi là “phần mềm không phụ thuộc bên ngoài” là có thể bỏ hẳn đoạn giải thích dài dòng
Tôi đã ghét những bài viết về phát triển phần mềm vội vàng rút ra kết luận hời hợt từ các phép ẩn dụ thiên nhiên không phù hợp, nhưng còn ghét hơn những bài làm vậy trong khi lại hiểu hoàn toàn sai chính hiện tượng tự nhiên được đem ra làm ẩn dụ
Việc một vài loài như rùa sơn có thể sống sót sau khi bị đóng băng không phải vì tính máu lạnh, mà nhờ các protein chống đông đặc biệt
Các loài thằn lằn hay động vật máu lạnh khác khi rã đông thì mô của chúng sẽ bị vỡ
https://lobste.rs/s/hitos3/cold_blooded_software#c_mxjzwh