Trong một kỷ nguyên mà máy tính sở hữu sức mạnh chưa từng có, một cuộc tranh luận nảy lửa đang diễn ra giữa các lập trình viên về hiệu quả của phần mềm. Trong khi phần cứng hiện đại có thể xử lý các ứng dụng khổng lồ, nhiều lập trình viên đang đặt câu hỏi liệu chúng ta đã đi quá xa với tình trạng phần mềm béo phì. Cuộc thảo luận đã vượt ra khỏi các diễn đàn kỹ thuật để bước vào các nhóm phát triển chính thống, với những lập luận đầy nhiệt huyết từ cả hai phía về những gì được coi là sự đánh đổi chấp nhận được trong bối cảnh điện toán ngày nay.
Sự Chia Rẽ Lớn: Hiệu Suất vs. Hiệu Quả Của Nhà Phát Triển
Cốt lõi của cuộc tranh luận tập trung vào việc liệu mức tiêu thụ tài nguyên của phần mềm hiện đại đại diện cho sự tiến hóa cần thiết hay là sự lãng phí không cần thiết. Những người ủng hộ các phương pháp phát triển hiện tại lập luận rằng các lớp trừu tượng, framework và các phụ thuộc cho phép chu kỳ phát triển nhanh hơn và mã code dễ bảo trì hơn. Họ chỉ ra những nhu cầu hợp pháp như cách ly bảo mật, tính năng trợ năng và khả năng tương thích đa nền tảng mà đơn giản là không tồn tại trong các kỷ nguyên điện toán trước đây.
Tuy nhiên, các nhà phê bình phản bác rằng tư duy này đã đi quá xa. Nhiều nhà phát triển báo cáo về những khó chịu hàng ngày với các ứng dụng cảm thấy ì ạch bất chấp việc chạy trên phần cứng mạnh mẽ. Cuộc trò chuyện tiết lộ một sự căng thẳng ngày càng tăng giữa tốc độ phát triển và chất lượng trải nghiệm người dùng. Như một nhà phát triển nhận xét về các phương pháp phát triển hiện đại, Suy nghĩ thật khó khăn, vì vậy bất kỳ sản phẩm nào cho mọi người một cái cớ để ngừng làm điều đó sẽ hoạt động khá tốt, ngay cả khi nó tạo ra nhiều bất tiện hơn như sự phình to của framework hoặc tình trạng phụ thuộc thối nát.
Những đánh đổi trong phát triển được thảo luận:
- Các lập luận ủng hộ bloat: Phát triển nhanh hơn, tương thích đa nền tảng, tính năng bảo mật, hỗ trợ khả năng tiếp cận
- Các lập luận chống bloat: Hiệu suất tốt hơn, dung lượng nhỏ hơn, khởi động nhanh hơn, giảm độ phức tạp, bảo trì dễ dàng hơn
Tác Động Thực Tế: Từ Khởi Động Tức Thì Đến Độ Trễ Nhiều Giây
Hậu quả thực tế của phần mềm béo phì ngày càng trở nên rõ ràng đối với người dùng cuối. Các nhà phát triển đang chia sẻ những so sánh rõ rệt giữa trải nghiệm trong quá khứ và hiện tại. Một lập trình viên nhớ lại việc chơi Quake 1 multiplayer, nơi thời gian cần thiết từ lúc bạn khởi chạy trò chơi đến lúc vào được máy chủ chỉ khoảng 1 giây. Tương tự, những người đam mê game cổ điển lưu ý rằng các trò chơi Game Boy nguyên bản tải ngay lập tức trên phần cứng như ModRetro Chromatic.
Những trải nghiệm này tương phản rõ rệt với các ứng dụng hiện đại. Nhiều nhà phát triển báo cáo các ứng dụng Electron tiêu thụ hàng trăm megabyte, với một người lưu ý rằng bản cập nhật MS Teams mới nhất trên MacOS đã tải về một trình cài đặt yêu cầu tôi 1.2GB dung lượng ổ đĩa. Một nhà phát triển khác phát hiện Teams chiếm hơn 5 GB trên máy tính xách tay của họ. Sự khác biệt về thời gian khởi động giữa các ứng dụng hiện đại này và các ứng dụng tiền nhiệm được đo bằng các bậc độ lớn thay vì phần trăm.
Ví dụ So sánh Hiệu suất:
- Quake 1 (1996): ~1 giây từ khi khởi chạy đến khi vào chơi
- Các ứng dụng Electron hiện đại: Thời gian khởi động thường mất vài giây
- Game Boy nguyên bản: Tải game tức thì
- Steam Deck hiện đại: Thời gian khởi động kéo dài cần vài phút
Cuộc Chiến Framework: Electron, React và Cuộc Tìm Kiếm Các Giải Pháp Thay Thế
Các công nghệ cụ thể đã trở thành tâm điểm trong cuộc thảo luận về sự phình to. Các ứng dụng Electron, gói gọn toàn bộ trình duyệt web cùng với ứng dụng desktop, phải đối mặt với sự giám sát đặc biệt. Mặc dù một số thừa nhận rằng các ứng dụng Electron được tối ưu hóa tốt như Visual Studio Code mang lại trải nghiệm người dùng tốt, nhiều nhà phát triển bày tỏ sự thất vọng với yêu cầu tài nguyên của công nghệ này.
Cuộc trò chuyện cũng mở rộng sang các framework web. Một số nhà phát triển ủng hộ việc cấm React và các framework tương tự, lập luận rằng 99% trang web sẽ hoạt động tốt hơn rất nhiều với SSR và một vài dòng JavaScript ở đây và đó. Những người khác chỉ ra các giải pháp thay thế mới nổi như Tauri, hứa hẹn kích thước ứng dụng nhỏ hơn đáng kể - có khả năng giảm một ứng dụng Electron 500MB xuống chỉ còn 20MB.
Khẩu hiệu Thời gian phát triển quan trọng hơn hiệu suất coi hiệu suất kém là vấn đề của phần mềm, trong khi thực tế, hiệu suất kém là triệu chứng của sự phức tạp phần mềm ngày càng tăng.
Ví dụ về Kích thước Ứng dụng:
- Super Mario Bros. (1985): 31-40KB
- Windows 11 Calculator: sử dụng ~30MB RAM
- Các ứng dụng Electron hiện đại: Thường từ 100-500MB
- Bộ cài đặt MS Teams: yêu cầu 1.2GB dung lượng ổ đĩa
- Giải pháp thay thế Tauri: Có khả năng giảm xuống còn ~20MB
Nghịch Lý Về Khả Năng Bảo Trì
Một sự căng thẳng thú vị đã nổi lên liên quan đến cách phần mềm béo phì ảnh hưởng đến việc bảo trì lâu dài. Một số cho rằng các framework và lớp trừu tượng hiện đại cải thiện khả năng bảo trì thông qua tính mô-đun và các mẫu rõ ràng. Tuy nhiên, những người khác cho rằng việc phân lớp quá mức tạo ra hiệu ứng ngược lại - các hệ thống trở nên phức tạp đến mức không ai hiểu đầy đủ về chúng.
Nghịch lý về khả năng bảo trì này thể hiện trong các phiên gỡ lỗi đòi hỏi phải khảo cổ xuyên qua 17 lớp gián tiếp. Như một nhà phát triển giải thích, Khi bạn xếp chồng framework lên thư viện, lên lớp trừu tượng, lên sự phụ thuộc - và không ai hiểu hệ thống đó làm gì nữa. Không thể nắm giữ nó trong đầu bạn. Điều này gợi ý rằng khoản tiết kiệm thời gian ban đầu từ việc sử dụng các framework nặng nề có thể bị bù đắp bởi sự phức tạp gỡ lỗi gia tăng sau này trong vòng đời phần mềm.
Phổ Tối Ưu Hóa: Từ Tối Ưu Hóa Vi Mô Đến Lựa Chọn Kiến Trúc
Cuộc thảo luận tiết lộ những cách giải thích khác nhau về điều gì cấu thành sự tối ưu hóa phù hợp. Nhiều nhà phát triển tham khảo câu nói nổi tiếng của Donald Knuth tối ưu hóa non là gốc rễ của mọi tội lỗi, nhưng có một cuộc tranh luận đáng kể về việc non thực sự có nghĩa là gì. Một số hiểu nó là việc tránh tối ưu hóa vi mô trước khi phân tích hồ sơ, trong khi những người khác sử dụng nó để biện minh cho các quyết định kiến trúc ưu tiên tốc độ phát triển hơn hiệu suất.
Các nhà phát triển có kinh nghiệm nhấn mạnh tầm quan trọng của việc chọn đúng thuật toán và cấu trúc dữ liệu ngay từ đầu, lưu ý rằng các vấn đề hiệu suất nhỏ trong các đường dẫn nóng có thể tích lũy đáng kể. Như một chuyên gia cơ sở dữ liệu quan sát thấy, Truy vấn này chạy trong 2 mili giây, nó đủ nhanh. Được thôi, nhưng nó được gọi 10 lần cho mỗi luồng vì ORM cực kỳ ngu ngốc; nếu bạn cắt giảm nó xuống 500 micro giây, bạn sẽ tiết kiệm được 5 mili giây.
Tương Lai Của Phần Mềm Hiệu Quả
Bất chấp sự phổ biến của các ứng dụng béo phì, vẫn có sự quan tâm mạnh mẽ đến việc phát triển phần mềm hiệu quả. Các nhà phát triển làm việc trên các ứng dụng quan trọng về hiệu suất như hiển thị khoa học, công cụ trò chơi và phần mềm hệ thống tiếp tục ưu tiên tối ưu hóa. Các dự án như Datoviz chứng minh rằng vẫn có một thị trường cho phần mềm được tối ưu hóa cẩn thận, đặc biệt là trong các lĩnh vực mà hiệu suất trực tiếp tác động đến khả năng sử dụng.
Cộng đồng dường như đang đạt được sự đồng thuận rằng mặc dù một số sự phình to đại diện cho sự đánh đổi hợp pháp, phần lớn trong số đó bắt nguồn từ các lựa chọn kỹ thuật kém hơn là sự phức tạp cần thiết. Thách thức trong tương lai sẽ là tìm ra sự cân bằng phù hợp giữa hiệu quả phát triển và hiệu suất phần mềm - công nhận rằng cả hai thái cực đều có chi phí đáng kể.
Cuộc tranh luận về phần mềm béo phì phản ánh những căng thẳng rộng hơn trong phát triển phần mềm hiện đại giữa việc lặp lại nhanh chóng và chất lượng thủ công. Khi phần cứng tiếp tục phát triển, cuộc trò chuyện về cách chúng ta sử dụng những tài nguyên đó có thể sẽ gia tăng, với các nhà phát triển ngày càng tìm kiếm các giải pháp trung gian vừa mang lại năng suất cho nhà phát triển vừa mang lại trải nghiệm người dùng tuyệt vời.
Tham khảo: Some software bloat is OK