Sự phát phì của phần mềm (software bloat), thực trạng, nguyên nhân và quản lý.

Thời gian gần đây, trên phương tiện thông tin đại chúng, ở các quán cafe hay lúc trà dư tửu hậu, một chủ đề mà người ta thường nói nhiều là tình trạng béo phì của trẻ em, của người lớn. Những chiếc ghế trên xe buýt, trên tàu hỏa, hay trên những chuyến bay giá rẻ trở nên chỉ còn phù hợp khi 2 chiếc cạnh nhau được nhập vào một, những chiếc giường đôi đã được tăng kích thước từ 1m50 lên 1m80 và có lẽ sẽ còn tăng nữa. Xã hội lên tiếng cảnh báo, chuyên gia ra sức khuyên can, nhưng tình hình này dường như ngày càng trầm trọng hơn, chưa có cách nào cải thiện.

Bài viết này không có ý đinh thảo luận về tình trạng phát phì đó, vì dù sao viblo là một blog về công nghệ (thông tin) chứ không phải một trang web về chăm sóc sức khỏe trẻ em hay giảm cân cho phụ nữ. Ở đây, chúng ta muốn nói về một tình trạng cũng là phát phì, nhưng trong lĩnh vực công nghệ, đó là sự béo phì của phần mềm. Nếu quay trở lại những năm 50-70 khi ngành kỹ thuật phần mềm mới ra đời, khi máy tính bắt đầu bước ra khỏi kỹ thuật quân sự và được ứng dụng nhiều trong các ngành dân sự, dân dụng, chúng ta có thể thấy những chương trình ban đầu yêu cầu cấu hình phần cứng, CPU, bộ nhớ tương đối nhỏ và các lập trình viên khi viết code phải suy nghĩ để tiết kiệm từng bit, byte hay từng lệnh tính toán, từng thanh ghi của hệ thống. Phần mềm lúc này tương đối "gầy", chúng sử dụng phần xương (phần cứng) một cách hiệu quả thậm chí là tiết kiệm tối đa. Do sự phát triển của kỹ thuật và công nghệ mạch điện tử, vi xử lý, phần cứng ngày càng mạnh lên. Bộ xử lý của những chiếc máy tính cá nhân ngày nay có thể tương đương với những máy chủ mạnh của những thập niên trước. Bộ nhớ RAM thậm chí lớn gấp nhiều lần, đĩa cứng thì ngày càng khủng, nhưng nghịch lý là sự phát triển ấy vẫn không đáp ứng đủ yêu cầu xử lý của những phần mềm cả cũ và mới. Người dùng càng ngày càng có cảm giác phần mềm càng ngày chậm đi, cồng kềnh hơn mỗi khi nâng cấp một phiên bản mới hơn, nghĩa là chúng ngày càng béo lên so với bộ xương. Tình trạng như vậy được gọi là sự béo phì của phần mềm. (tiếng Anh: software bloat https://en.wikipedia.org/wiki/Software_bloat).

1. Nguyên nhân của sự béo phì của phần mềm Có nhiều nguyên nhân khác nhau dẫn tới tình trạng béo phì của phần mềm. Từ góc độ nội tại, trong quá trình phát triển phần mềm, những chức năng mới được liên tục thêm vào, những lỗi liên tục được khắc phục để làm phần mềm hoàn thiện hơn. Đáng tiếc là trong quá trình đó, rất nhiều chức năng cũ, những dòng code cũ vẫn tồn tại ở đó bởi vì rất ít nhà thiết kế, nhà phát triển quan tâm tới việc loại bỏ chúng.Tính tương thích ngược (backward-compatibility) luôn luôn được viện dẫn như là một cái cơ hợp lý để giữ lại những đoạn mã đã lỗi thời. Chính vì thế, mã chương trình chỉ có thêm vào làm tăng kích thước, khối lượng chương trình khi nạp và khi chạy, dẫn tới làm cho phần mềm to phình dần lên. Ví dụ điển hình cho nguyên nhân này là ký hiệu @Deprecated trong Java. Nếu bạn là lập trình viên Java, lớp java.util.Date đã có rất nhiều phương thức được đánh dấu @Deprecated hàng năm trời mà vẫn tồn tại trong Java mới nhất (java8), và vài lập trình viên vẫn tiếp tục sử dụng chúng, trong khi đó đã có lớp Calendar với nhiều tính năng hoàn toàn thay thế được java.util.Date. Thế là cả 2 lớp này được sử dụng song song một cách không cần thiết trong rất nhiều chương trình mới, mà không biết khi nào mở bỏ được java.util.Date. Đối với một chức năng cụ thể trong một phần mềm cụ thể, không hiếm gặp cảnh tượng vài phương thức làm việc tương tự nhau. Lý do là đã có một phương thức trước đây đã xử lý việc này , nhưng nó không hoạt động với một bộ dữ liệu cụ thể nào đó. Thay vì tìm nguyên nhân để khắc phục, lập trình viên tạo một phương thức mới tương tự để xử lý cho trường hợp cụ thể đó, sau đó tạo một lệnh: if(bộ dữ liệu A) <gọi phương thức mới> else <gọi phương thức cũ>, thế là code bị tăng kích thước, tăng một lệnh xử lý if. Tích tiểu thành đại, việc làm như vậy cũng đóng góp vào nguyên nhân của sự phát phì của phần mềm. Từ góc độ người dùng, do các nhu cầu liên tục nảy sinh, hoặc do người dùng khó tính, họ luôn luôn muốn phần mềm ngày càng phải chi tiết, cụ thể tỉ mỉ, nhiều khi là không cần thiết. Để phục vụ người dùng, các đoạn mã mới được thêm vào để chi tiết hóa các đoạn mã có sẵn và điều này cũng làm tăng kích thước, tăng thời gian xử lý của phần mềm. Ví dụ như khi chúng ta đang có một thông báo lỗi: "Hệ thống gặp sự cố khi xử lý yêu cầu, xin vui lòng kiểm tra lại điều kiện tìm kiếm" thì thông báo đó có thể được dùng chung cho rất nhiều trường hợp. Tuy nhiên người dùng muốn có thông báo lỗi rõ ràng hơn: "điều kiện ngày tháng không hợp lệ, xin vui lòng kiểm tra lại". Mặc dù yêu cầu này là nhỏ, nhưng về mặt chương trình, nó làm cho thông báo chỉ có thể dùng được cho một trường hợp nhất định, thêm xử lý riêng cho trường hợp đó... và kết quả là tăng xử lý của hệ thống. Từ góc độ công nghệ, việc các máy tính có năng lực xử lý ngày càng mạnh cũng làm cho lập trình viên có xu hướng viết các đoạn mã cồng kềnh hơn, dễ viết hơn nhưng lại tốn thời gian xử lý hơn. Điển hình như trong xử lý song song, khi bộ xử lý còn chưa đủ mạnh, lập trình viên thường dùng các thuật toán song song nhỏ (ma trận phân chia) để xử lý. Nhưng khi năng lực xử lý tăng lên, lập trình viên sẵn sàng tạo một process mới, phó mặc cho hệ điều hành lo liệu việc tạo, giải phóng bộ nhớ, chuyển đổi ngữ cảnh.... làm cho phần mềm cũng phình lên.
2. Tác hại/ tác dụng của sự phát phì của phần mềm. Tác hại rõ ràng có thể nhìn thấy được của sự béo phì của phần mềm là sự nặng nề đối với người sử dụng. Như đã nêu ở phần đầu bai, mỗi khi cập nhật phần mềm, người dùng đều cảm thấy chúng nặng nề hơn, nhiều chức năng không cần thiết... và đôi khi họ cảm thấy họ phải trả thêm tiền cho những thứ mà họ không dùng. Đôi khi họ lại còn cảm thấy phần mềm nhiều lỗi hơn, do việc bổ sung nhưng đoạn kiểm tra, chuyển đổi điều kiện....vào chương trình. Đối với lập trình viên, việc béo phì của phần mềm làm tăng công việc bảo trì các đoạn mã cũ (vì chúng vẫn tồn tại trong chương trình dù không còn dùng đến). Nếu các đoạn mã đó xuất hiện những lỗi nhỏ, lạp trình viên lại tiếp tục bổ sung code, sửa lỗi nhưng đôi lúc các thư viện không còn được duy trì nữa (discontinued) làm cho việc khắc phục lỗi cũ trở nên khó khăn, nhiều khi làm bất khả thi (dead-end). Đối với việc quản lý phần mềm, béo phì là một tình trạng không hoàn toàn xấu không hoàn toàn tốt. Tuy phải quản lý nhiều hơn, viết nhiều tài liệu hơn, nhưng với những lý do như vậy, ngân sách đầu tư thêm cũng đáng kể hơn, tạo ra thêm việc làm, thu nhập.... nên vấn đề là phải quản lý một cách hợp lý, đúng mức.
3. Quản lý sự béo phì của phần mềm. Sự béo phì của phần mềm không phải lúc nào cũng xấu, cũng như việc trẻ em phụ nữ tăng cân không nhất thiết lúc nào cũng phải hạn chế. Người gầy cần tăng cân để có năng lượng họat động, cũng như phần mềm cần được béo lên để bổ sung chức năng. Nhưng việc béo lên quá mức thì cân phải được cân nhắc để nằm trong tầm kiểm soát, tránh được những tác hại không mong muốn. Đối với nguyên nhân béo phì từ các đoạn code cũ, sau nhiều năm duy trì, cần thiết phải có một sự nâng cấp toàn diện, viết lại (re-write) toàn bộ phần mềm, thiết kế lại toàn bộ và có thể thay thế bằng các thuật toán hiệu quả hơn ra đời trong quá trình phát triển của hệ thống. Điển hình là các phiên bản windows có thay đổi lớn như từ W95 lên W2000, MS đã phải đập đi rất nhiều code cũ, thiết kế và viết lại. Mặc dù vẫn còn duy trì nhiều tính tương thích về chức năng, nhưng việc viết lại làm cho W2K sử dụng phần cứng hiệu quả hơn nhiều, gọn nhẹ và nhanh nhẹn hơn. . Tuy nhiên không phải lúc nào chúng ta cũng có điều kiện để viết lại cả một phần mềm, vì lý do ngân sách hoặc kỹ thuật, hoặc lý do thời gian. Do đó, trong quá trình viết code, mỗi lập trình viên cần hạn chế sử dụng những phương thức đã được đánh dấu @Deprecated..., tạo điều kiện cho việc refactor sau này. Code reviewer cũng cần nắm được quan điểm từ manager để có thể kiểm tra trong quá trình lập trình viên submit code lên hệ thống. Phương châm cơ bản là: cố gắng sử dụng những phương thức mới hơn, thống nhất để làm cho phần mềm luôn ở trạng thái cập nhật, không bị @Deprecated quá sớm. Về phía người dùng, đối với các yêu cầu đã cũ có thể bao trùm trong những chức năng mơi, có thể duy trì các chức năng cũ đó trong một thời gian ngắn rồi hủy đi, hướng người dùng sang những chức năng mới thay thế cho những chức năng cũ. Tất nhiên quá trình đó tốn thời gian công sức, nhưng không thể không làm. Đối với các yêu cầu mới phát sinh, có thể tiếp cận theo 2 hướng: nếu chức năng phát sinh thực sự mang lại một thay đổi cho hệ thống, thì có thể xem xét để tổng hợp, nhưng cũng đồng thời xem bỏ bớt những chức năng trùng lặp trong khi thiết kế.
4. Kết luận Sự phát phì của phần mềm là một vấn đề đang nổi lên trong ngành kỹ nghệ phần mềm cần được nghiên cứu sâu sắc. Việc tìm hiểu, nghiên cứu nó sẽ giúp quản lý sự phát triển và vòng đời của phần mềm một cách toàn diện và hiệu quả hơn.