Khi đề cập đến cụm từ “bảo trì phần mềm” tới một nhóm lập trình viên thì họ sẽ cảm thấy kinh hãi (cho dù đó là đàn ông hay đàn bà). Bảo trì phần mềm được xem như là công việc lau dọn vậy.
Nhưng có thể đó là một sự mô tả không công bằng.
Bảo trì phần mềm giống như công việc lau dọn vậy.Bảo trì phần mềm giống như công việc lau dọn vậy.
Trong cuốn sách Software Conflict 2.0 : The Art and Science of Software Engineering, tác giả Robert L. Glass đã ca tụng những ưu điểm của việc bảo trì phần mềm:
Bảo trì phần mềm là công việc…
- Phức tạp về mặt trí tuệ – nó đòi hỏi sự đổi mới trong khi đưa ra những ràng buộc khắt khe đối với người tiến hành đổi mới.
- Khó khăn về mặt kỹ thuật – người bảo trì phải có khả năng làm việc với khái niệm, thiết kế và tất cả code của nó cùng một lúc.
- Không công bằng – người bảo trì chẳng bao giờ nhận được tất cả những thứ mà họ cần, ví dụ như tài liệu chẳng hạn.
- Không chiến thắng – người bảo trì chỉ nhìn thấy những người đang gặp vấn đề.
- Công việc vất vả – người bảo trì phải làm việc ở mức độ chi tiết của những dòng code “thối”.
- Sống trong quá khứ – phần code đó có thể đã được viết bởi một người nào đó trước khi họ là một lập trình viên giỏi.
- Phải thận trọng – phương châm hành động trong việc bảo trì là “nếu nó không có vấn đề thì đừng sửa nó”.
Bảo trì phần mềm là công việc khá phức tạp và đầy thử thách.
Trong ngành phát triển phần mềm, người làm công việc bảo trì phần mềm có xu hướng là những người mới vào nghề hoặc không phải là lập trình viên giỏi. Có một lý do cho điều đó. Hầu hết mọi người đều thích công việc phát triển sản phẩm từ đầu hơn; bảo trì là công việc bị hạn chế sự sáng tạo nên rất ít người thích làm nó. Và theo mặc định, người có ít khả năng nhất và có ít nhu cầu nhất là những người thường làm công việc bảo trì.
Tình trạng hiện tại là hoàn toàn sai. Bảo trì là một thách thức trí tuệ đáng kể cũng như một giải pháp chứ không phải là một vấn đề. Nếu chúng ta muốn tối đa hoá hiệu quả của mình khi thực hiện nó, chúng ta cần phải thay đổi đáng kể cách mà chúng ta phân công người làm công việc đó.
Có lẽ nó phụ thuộc vào cách bạn nhìn vào code của mình. Theo Andy và Dave, tất cả công việc lập trình chính là bảo trì:
Dave Thomas: Tất cả lập trình chính là bảo trì, bởi vì bạn hiếm khi viết code mới. Nếu bạn nhìn vào thời gian thực sự dành cho lập trình, bạn viết một chút ở đây và sau đó quay trở lại và thực hiện một số thay đổi. Hoặc bạn quay lại và sửa một lỗi. Hoặc bạn bỏ hoàn toàn và thay thế nó bằng một cái khác. Nhưng bạn nhanh chóng trở thành bảo trì code ngay cả khi đó là một dự án hoàn toàn mới. Bạn dành phần lớn thời gian trong chế độ bảo trì. Vì vậy, bạn cũng có thể nói, “Tôi đã làm công việc bảo trì từ ngày đầu tiên.” Các nguyên tắc áp dụng cho bảo trì nên áp dụng trên tổng thể.
Andy Hunt: Khi bạn gõ code, chỉ 10 phút đầu tiên phần code đó là code mới. Chỉ có vậy.
Theo Joel Spolsky, các lập trình viên quá lười biếng để làm bảo trì phần mềm:
Chúng ta là lập trình viên. Trong trái tim họ thì lập trình viên là các kiến trúc sư, và điều đầu tiên họ muốn làm khi đến một công trường là dùng xe ủi để san phẳng và xây dựng một cái gì đó mới và hoành tráng. Chúng ta không hào hứng với việc bảo trì: sửa đổi, cải tiến, trồng hoa…
Có một lý do tế nhị khiến các lập trình viên luôn muốn vứt bỏ code và bắt đầu lại từ đầu. Lý do là họ nghĩ rằng code cũ là một mớ hỗn độn. Và đây là quan sát thú vị: có lẽ họ sai. Lý do họ nghĩ rằng code cũ là một mớ hỗn độn là do một nguyên tắc cơ bản trong lập trình:
Việc đọc hiểu code còn khó hơn là viết mới ra nó.
Đây là lý do tại sao việc tái sử dụng code là rất khó. Đây là lý do tại sao mỗi người trong nhóm của bạn đều có một function khác nhau để tách chuỗi thành các phần tử của mảng. Họ tự viết function của riêng mình bởi vì điều này dễ dàng và thú vị hơn so với việc phải tìm hiểu cách mà function cũ hoạt động.
Như một hệ quả của điều này, bạn có thể hỏi gần như bất kỳ lập trình viên nào ngoài kia về phần code mà họ đang làm việc trên đó. Họ sẽ nói với bạn rằng: “Đó là một đống bùi nhùi lớn” hoặc “Tốt hơn là nên đập đi làm lại.”
Tôi đồng ý rằng hầu hết các lập trình viên đều có một khuynh hướng muốn viết lại code vì việc này có vẻ dễ hơn. Nhưng khác với việc chống lại sự thôi thúc này, tôi không thể đồng ý với Joel.
Đó là một hành động cân bằng.
Có lẽ chúng ta nên gán những lập trình viên giỏi nhất của mình làm bảo trì phần mềm chứ không phải những người kém nhất như hiện nay. Tôi đã nhìn thấy quá nhiều hệ thống chuyển thành một bản vá của những thứ hổ lốn và người ta ngồi cầu nguyện cho nó có thể hoạt động được. Có lẽ bởi vì những lập trình viên ít kinh nghiệm và kém tài năng là những người duy nhất còn lại để làm công việc bảo trì này.
Tại một số thời điểm, bạn phải can đảm để xây dựng lại nền tảng của mình để nó trở nên ổn định hơn. Nếu nền móng của căn nhà không ổn định, thì không có quá trình bảo trì nào có thể sửa được nó. Việc viết lại code như Mozilla và Windows NT có thể đã kéo dài nhiều năm để có được sức ảnh hưởng, nhưng hãy tưởng tượng những trình duyệt nguồn mở — và Microsoft– sẽ ra sao là nếu họ chưa bao giờ bắt đầu.
Công việc bảo trì phần mềm hiện tại không được tôn trọng cho lắm. Đã đến lúc chúng ta nên thay đổi nhận thức đó. Nhưng đừng sử dụng bảo trì như một cái nạng cho những vấn đề sâu hơn; đừng sợ đổi mới khi tình hình đòi hỏi điều đó.
Về tác giả bài viết:
Jeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow và cũng là đồng sáng lập của Stack Exchange và Discourse.