Có nên vứt bỏ code cũ?

Trong chúng ta hẳn đã có không ít người từng đối mặt với 2 lựa chọn: sử dụng lại source code có sẵn hay viết mới lại từ đầu. Phần lớn ta chọn cách thứ 2 vì đơn giản ngồi đọc lại code do người khác viết hay thậm chí do chính mình viết không hề đơn giản chút nào. Vậy liệu có phải source code cũ chỉ là thứ bỏ đi hay không? Chúng ta hãy cùng thảo luận về vấn đề này.

[Vào tháng 4 năm 2000] Cuối cùng thì Netscape 6.0 bản beta cũng được đưa ra giới thiệu. Chưa từng có bản 5.0 trước đó, bản mới nhất trước đó là bản 4.0 được giới thiệu cách đây 3 năm. 3 năm là một quãng thời gian quá dài trong thế giới mạng, trong khoảng thời gian đó, Netscape đã gần như không được sử dụng khiến cho thị phần của nó đã bị tụt giảm.

Chúng ta đã phải chờ quá lâu để có được bản Netscape 6.0, liệu đó có phải là sự cố ý của Netscape?

Thật ra thì họ đã gặp phải vấn đề đó do đã phạm phải một sai lầm chiến lược nghiêm trọng nhất mà bất kỳ công ty phần mềm cũng thể mắc phải: họ quyết định viết lại từ đầu toàn bộ code. Netscape không phải là công ty đầu tiên mắc phải sai lầm này. Borland cũng từng mắc phải sai lầm tương tự khi họ mua Arago và cố gắng biến nó thành dBase cho Windows (dBase là một hệ quản trị cơ sở dữ liệu đầu tiên được dùng cho máy vi tính được sản xuất bởi Ashton-Tate trong các hệ máy tính Apple II, Apple Macintosh,… trên môi trường DOS và nó đã từng là phần mềm bán chạy nhất trong nhiều năm), tuy nhiên dự án này của Borland đã thất bại thê thảm vì nó mất quá nhiều thời gian, trong thời gian đó thì Microsoft Access ra đời đã làm kinh ngạc người dùng với các ưu điểm mà nó có. Microsoft cũng từng mắc phải sai lầm tương tự trong 1 dự án có tên là Pyramid khi họ cố gắng viết lại Word hoàn toàn mới cho Windows, dự án sau đó đã phải dừng lại và ném vào sọt rác. May mắn cho Microsoft là họ đã không dừng làm việc trên cơ sở code cũ, nhờ thế mà họ vẫn còn cứu vãn được tình hình, biến nó đơn thuần là một tai nạn tài chính.

Chúng ta là lập trình viên. Lập trình viên cũng như kiến trúc sư vậy, điều đầu tiên họ muốn làm khi đến một công trường là dùng xe ủi ủi cho bằng phẳng, rồi từ đó xây dựng lên những công trình đồ sộ. Chúng ta không khoái những việc tỉ mẩn như xây bồn hoa lắm.

Có một lý do tế nhị nữa khiến cho những lập trình viên không thích phải ngồi đọc code mà luôn muốn bắt đầu lại từ đầu. Đó là vì họ nghĩ là code cũ chỉ là một mớ hỗn độn. Và đây chính là điều thú vị, đó là: có lẽ họ đã sai.

Lý do họ nghĩ thế là do một quy tắc cơ bản, tất yếu trong lập trình: “Đọc hiểu code luôn luôn khó hơn nhiều là viết code mới”.

Đó là lý do tại sao mà việc dùng lại code lại khó khăn đến thế. Đó cũng giải thích tại sao mỗi người trong nhóm bạn lại có 1 cách khác nhau để cắt chuỗi thành các mảng. Đơn giản là việc code riêng cho họ dễ hơn và thú vị hơn là ngồi đọc hiểu các hàm có sẵn.

Như một hệ quả tất yếu, bạn có thể hỏi bất cứ lập trình viên nào về code họ đang làm, câu trả lời sẽ là: “Đó là một mớ hỗn độn, tôi chỉ muốn vứt quách nó đi và làm lại từ đầu thôi”.

Tại sao lại là một mớ hỗn độn chứ? Họ trả lời: “Này, hãy nhìn cái hàm này này. Nó dài tận 2 trang liền, chẳng có gì trong này được dùng cả, tôi không biết 1 nửa trong số các API này được gọi để làm gì.”

Trước khi bảng tính (spreadsheet) mới của Borland được giới thiệu, Philippe Kahn, một trong những sáng lập viên của Borland, đã nhiều lần khoác lác trước báo chí rằng Quattro Pro tốt hơn nhiều Microsoft Excel vì nó được viết lại hoàn toàn mới. Tất cả đều là mã nguồn mới, cứ như thể code cũ là rác thải vậy. Ý nghĩ là code mới tốt hơn code thật là lố bịch. Code cũ đã được sử dụng, chúng đã được kiểm định. Rất nhiều lỗi đã được tìm thấy và giải quyết. Không có gì sai sót nào nữa cả. Chẳng thể nào chỉ ngồi quanh quẩn cái ổ cứng của mình là có thể gỡ rối được đâu. Liệu phần mềm có giống như là chiếc Dodge Dart cũ, bị bỏ gỉ sét khi để trong garage? Hay nó giống như một con gấu bông xấu xí, thô thiển chỉ bởi nó không được làm ra bằng tất cả vật liệu mới?

Chúng ta hãy quay trở lại với hàm được viết dài 2 trang ở trên. Vâng, tôi biết đó chỉ là hàm đơn giản để hiển thị một cửa sổ, nhưng không ai hiểu tại sao nó lại có nhiều đoạn trông khó coi. Xin trả lời: đó là các bugs được fix vào trong chương trình. Một trong những bug đó xảy ra khi Nancy cố gắng cài đặt 1 chương trình trên máy tính không có Internet Explorer. Một bug khác xảy ra trong tình trạng thiếu bộ nhớ. Một bug thì gặp phải khi dữ liệu đang được lưu trên đĩa mềm thì bị giật mạnh giữa chừng. Những thứ đó được gọi là LoadLibrary trông xấu xí nhưng nó lại làm cho code hoạt động được trong những phiên bản cũ của Windows 95.

Để tìm được một bug như thế phải mất hàng tuần để tìm ra trong quá trình sử dụng trên thực tế. Những lập trình viên có thể cũng đã phải mất một vài ngày để tái hiện và giải quyết những bug như thế. Có nhiều bug chỉ mất một dòng code, đôi khi là một vài ký tự, nhưng rất nhiều chương trình, thời gian bị tiêu tốn chỉ vì vài ký tự đó.

Khi bạn vứt bỏ những code cũ đi và bắt đầu code lại từ đầu, bạn đang vứt đi tất cả các kiến thức cũ. Tất cả các bug đã được fix, cũng như nhiều năm lập trình. Bạn đang vứt bỏ khả năng chiếm lĩnh thị trường của mình, đang tặng cho đối thủ đến 2, 3 năm và hãy tin tôi, đó là một quãng thời gian dài trong ngành phần mềm.

Bạn đang tự đặt mình vào tình thế khó khăn đó, bởi có thể bạn sẽ không thể đáp ứng được các yêu cầu của thị trường khi mà không có các code dự phòng, và có thể bạn sẽ phải tạm dừng kinh doanh trong một thời gian.

Bạn đang lãng phí tiền bạc và thời gian khi ngồi viết lại những thứ đã có sẵn.

Vậy có lựa chọn nào không? Có thể với Netscape, các source code cũ của họ không thực sự tốt, nhưng bạn biết không, nó đã chạy được tốt trên rất nhiều hệ thống máy tính.

Khi những lập trình viên ca thán code của mình chỉ là một mớ hỗn độn (mà đa phần họ vẫn làm vậy), thì họ đã có thể gặp phải những sai lầm sau:

Thứ nhất, đó là các vấn đề về kiến trúc. Code đã không được phân tích chính xác. Vấn đề này có thể giải quyết bằng những người lập trình thật cẩn thận và làm việc tập trung. Ngay cả những thay đổi kiến trúc lớn cũng có thể sửa lại mà không cần vứt bỏ toàn bộ code cũ đi. Giống như trong dự án Juno chúng tôi đã từng làm, chúng tôi đã mất hàng tháng để sửa một lỗi thôi, nhưng chúng tôi vẫn làm cẩn thận trên cơ sở code cũ và chúng tôi đã không gặp phải lỗi nào và chúng tôi cũng không phải vứt bỏ code đi.

Lý do thứ 2 mà lập trình viên nghĩ code của mình là một mớ hỗn độn đó là vì nó không thật sự hiệu quả. Theo tin đồn thì các mã nguồn ở Netscape được sinh ra khá chậm nhưng nó chỉ ảnh hưởng đến một phần dự án và toàn có thể chỉ cần viết lại phần đó thôi mà không cần phải làm lại toàn bộ, như thế sẽ giúp ta tiết kiệm được nhiều thời gian.

Thứ 3 là code cũ có thể có những thứ làm bạn khó chịu. Như trong một project tôi từng tham gia người ta đã đặt tên cho một kiểu dữ liệu là FuckedString. Hay trong một dự án khác thì khi mới bắt đầu thì người ta quy ước các biến sẽ được đặt tên bắt đầu bằng “_”, nhưng sau đó họ lại chuyển sang thành “m_”. Cuối cùng thì một nửa các hàm có tên bắt đầu với “_”, một nửa kia lại là “m_”, thật là khó nhìn. Thật ra với một macro trong Emacs bạn chỉ mất 5 phút để giải quyết vấn đề này mà không phải vứt toàn bộ code đi và làm lại từ đầu.

Và cũng nên nhớ rằng khi bạn viết lại toàn bộ code từ đầu chẳng có lý do gì để bạn tin tưởng là mình sẽ làm tốt hơn lần trước cả. Trên tất cả, nhóm lập trình của bạn thậm chí có thể bị thay đổi, như thế thì bạn sẽ chẳng thu thêm được chút kinh nghiệm nào đâu. Có thể bạn lại sẽ tạo ra những sai lầm khác, gặp phải các vấn đề mới không có trong lần trước.

Bí quyết cũ mèm “phiên bản đầu tiên viết ra chỉ để bỏ đi” nếu đem ứng dụng vào các ứng dụng thương mại sẽ thật nguy hiểm. Nếu bạn chỉ đang viết code để thử nghiệm khả năng thôi, thì bạn có thể sẽ muốn bỏ các hàm cũ mà bạn đã viết tuần trước khi bạn nghĩ ra thuật toán mới hay hơn. Điều đó tốt thôi. Có thể bạn muốn làm lại các lớp cho dễ sử dụng, điều này cũng tốt thôi. Nhưng vứt bỏ toàn bộ chương trình cũ thì quả là điên rồ. Nếu Netscape không làm vậy, có lẽ họ đã không rơi vào hoàn cảnh tồi tệ đến thế.

#ntechdevelopers