3.7 Bảo trì phần mềm

Tổng quan và động lực

Hầu hết phần mềm dành phần áp đảo vòng đời của nó không phải để được xây dựng, mà để được bảo trì. Khoảnh khắc một hệ thống đi vào môi trường thực, nó bước vào một giai đoạn (thường kéo dài nhiều năm hoặc nhiều thập kỷ) sửa lỗi, thích nghi với môi trường thay đổi, cải thiện những gì đã hoạt động, và ngăn ngừa rắc rối tương lai. Trong các doanh nghiệp lớn, và đặc biệt trong chính phủ, giai đoạn này chi phối. Các công cụ thuế, hệ thống trợ cấp, nền tảng quốc phòng và sổ cái tài chính lõi thường xuyên được bảo trì lâu hơn nhiều so với bất cứ ai đã đặt hàng chúng mong đợi. Bảo trì phần mềm là kỷ luật giữ cho phần mềm đã bàn giao luôn đúng, cập nhật và có giá trị suốt vòng đời vận hành của nó.

Bảo trì bị đánh giá thấp và xem nhẹ kinh niên, và sai lầm đó rất đắt. Hết nghiên cứu này đến nghiên cứu khác, qua nhiều thập kỷ, đặt bảo trì ở mức vượt xa một nửa tổng chi phí vòng đời phần mềm, thường được trích dẫn trong khoảng 60 đến 90 phần trăm cho các hệ thống sống lâu. Vậy mà các tổ chức hoạch định, lập ngân sách, bố trí nhân sự và ăn mừng đợt xây dựng ban đầu như thể đó là toàn bộ công cuộc. Rồi họ coi mọi thứ sau đó là chuyện nghĩ sau, được tài trợ từ một quỹ ngày càng teo lại và giao cho bất cứ ai rảnh. Kết quả có thể đoán trước: các hệ thống giòn, người bảo trì nản lòng, chi phí thay đổi leo thang, và cuối cùng là một cuộc khủng hoảng bị đóng khung thành “vấn đề hệ thống cũ” (chương 3.6) trong khi thực ra suốt thời gian đó nó là vấn đề bảo trì không được quản lý.

Chương này theo khu vực kiến thức Bảo trì Phần mềm của SWEBOK (Bộ Kiến thức về Kỹ thuật Phần mềm) và ISO/IEC 14764. Nó bao quát các nguyên lý cơ bản của bảo trì và bốn loại được công nhận; các vấn đề chính khiến bảo trì khó, bao gồm chi phí, nhân sự và tinh thần; quy trình bảo trì; các kỹ thuật cốt lõi về hiểu chương trình, tái kỹ thuật và tái cấu trúc; cách ước tính chi phí bảo trì; và (ý tưởng có đòn bẩy cao nhất trong chương) cách thiết kế cho khả năng bảo trì ngay từ đầu. Niềm tin trung tâm là bảo trì không phải một hoạt động thấp kém theo sau kỹ thuật. Nó là phần lớn nhất của kỹ thuật phần mềm, và nó phải được hoạch định, cấp nguồn lực và tôn trọng đúng như vậy.

Các nguyên tắc chính

Bảo trì là phần lớn của vòng đời, không phải phần kết. Hãy hoạch định và lập ngân sách cho nó từ ngày đầu; nó sẽ tốn hơn việc xây dựng.
Bốn loại là các công việc khác nhau. Bảo trì sửa lỗi, thích nghi, hoàn thiện và phòng ngừa có các động lực và nhịp độ khác nhau; phần lớn công sức không phải là sửa lỗi.
Bạn không thể thay đổi những gì bạn không hiểu. Hiểu chương trình là hoạt động đơn lẻ lớn nhất trong bảo trì; hãy làm cho mã và lịch sử của nó dễ đọc.
Khả năng bảo trì là một thuộc tính thiết kế. Chi phí của thay đổi trong tương lai phần lớn được định bởi các quyết định lúc xây dựng; hãy thiết kế cho nó một cách có chủ đích.
Thay đổi nhỏ, an toàn, liên tục thắng thay đổi lớn bị trì hoãn. Tái cấu trúc và hiện đại hóa tăng dần dưới lưới an toàn kiểm thử thay vì tích lũy nợ thay đổi.
Phần mềm già đi ngay cả khi đứng yên. Môi trường chuyển động (phụ thuộc, nền tảng, quy định), nên một hệ thống tĩnh mục nát trong âm thầm; bảo trì phòng ngừa là công việc thật.
Người bảo trì xứng đáng có địa vị hạng nhất. Tinh thần, lưu giữ kiến thức và nhân sự của các đội bảo trì trực tiếp quyết định chi phí và rủi ro dài hạn.

Khuyến nghị

Phân biệt bốn loại bảo trì và bố trí nhân sự cho tất cả

ISO/IEC 14764 và SWEBOK công nhận bốn loại, và nhầm lẫn chúng là một lỗi hoạch định phổ biến. Bảo trì sửa lỗi khắc phục các khiếm khuyết được phát hiện khi vận hành. Bảo trì thích nghi giữ cho phần mềm hoạt động khi môi trường thay đổi: hệ điều hành, trình duyệt, phụ thuộc, phần cứng, quy định, hoặc hệ thống giao tiếp mới. Bảo trì hoàn thiện cải thiện phần mềm cho người dùng và người bảo trì, qua tính năng mới, hiệu năng tốt hơn, khả năng sử dụng được cải thiện và khả năng bảo trì được nâng cao. Bảo trì phòng ngừa sửa các lỗi tiềm ẩn và giảm rủi ro tương lai trước khi nó bộc lộ, qua gia cố, dọn dẹp và hiện đại hóa các vùng mong manh. Một cách chia nhỏ hữu ích hơn nhóm sửa lỗi và phòng ngừa thành hiệu chỉnh (xử lý lỗi) và thích nghi cùng hoàn thiện thành nâng cao (xử lý yêu cầu mới). Quan trọng là các nghiên cứu thực nghiệm nhất quán thấy rằng phần lớn bảo trì không phải sửa lỗi; nâng cao và thích nghi chiếm ưu thế. Hãy lập ngân sách và nhân sự tương ứng, và theo dõi công sức của bạn thực sự thuộc loại nào để bạn quản lý được nó.

Đầu tư vào hiểu chương trình

Hoạt động đơn lẻ lớn nhất trong bảo trì là hiểu hệ thống hiện có đủ tốt để thay đổi nó một cách an toàn. Người bảo trì thường xuyên dành nhiều thời gian đọc và suy luận về mã hơn là sửa nó. Hãy làm điều này rẻ hơn một cách có chủ đích. Giữ tài liệu gần mã và cập nhật (chương 2.7). Bảo tồn lịch sử quyết định qua hồ sơ quyết định kiến trúc (chương 1.6) và lịch sử commit sạch (chương 2.6). Dùng phân tích tĩnh, đồ thị phụ thuộc và công cụ điều hướng mã để vẽ bản đồ vùng lạ. Kiểm thử đặc tính (các bài kiểm thử ghim hành vi hiện tại, bao gồm cả những điều kỳ quặc) biến sự hiểu ngầm thành kiến thức thực thi được, bền vững. Khi sự hiểu biết tốn kém, mỗi thay đổi chậm và rủi ro. Khi nó rẻ, bảo trì trở thành thường lệ.

Tái cấu trúc liên tục dưới lưới an toàn kiểm thử

Tái cấu trúc là việc tái cơ cấu mã có kỷ luật nhằm cải thiện chất lượng nội tại mà không đổi hành vi bên ngoài. Được thực hiện liên tục và theo các bước nhỏ, nó chống lại sự trôi tự nhiên về phía phức tạp và giữ chi phí thay đổi phẳng thay vì tăng. Điều kiện tiên quyết không thể thương lượng là một bộ kiểm thử tự động đáng tin cậy (chương 2.4). Không có nó, “tái cấu trúc” chỉ là viết lại đầy rủi ro. Hãy đưa tái cấu trúc vào công việc hằng ngày: để mỗi mô-đun sạch hơn một chút so với khi bạn thấy nó, thay vì để dành cho những cuộc dọn dẹp hiếm hoi, lớn, nguy hiểm. Đây là bảo trì phòng ngừa trong thực tế, và nó là kiểu bảo trì rẻ nhất.

Tái kỹ thuật khi thay đổi tăng dần không còn đủ

Khi một thành phần đã suy thoái đến mức thay đổi thường lệ quá tốn kém hoặc rủi ro, tái kỹ thuật (kiểm tra và thay đổi một hệ thống để tái cấu thành nó dưới hình thức mới) là công cụ nặng hơn. Tái kỹ thuật thường kết hợp kỹ thuật đảo ngược (khôi phục thiết kế và ý định từ cài đặt) với tái kỹ thuật tiến (xây lại theo cấu trúc tốt hơn trong khi bảo toàn hành vi). Hãy ưu tiên tái kỹ thuật theo các lát có giới hạn, tăng dần bằng các mẫu như cây đa bóp nghẹt và phân nhánh bằng trừu tượng (chương 3.6), thay vì viết lại toàn bộ. Tái kỹ thuật nằm trên dải liên tục từ bảo trì đến hiện đại hóa: tái cấu trúc cho cái nhỏ và cục bộ, tái kỹ thuật cho cái cấu trúc, và hiện đại hóa cho cấp nền tảng.

Vận hành một quy trình bảo trì được xác định

Bảo trì hưởng lợi từ một quy trình tường minh, lặp lại được, như mô tả trong ISO/IEC 14764: triển khai quy trình (thiết lập kế hoạch và thủ tục), phân tích vấn đề và sửa đổi (phân loại, tái hiện, đánh giá tác động và chi phí), thực hiện sửa đổi, rà soát và nghiệm thu bảo trì, di chuyển, và ngừng sử dụng. Bọc nó trong quản lý thay đổi có kỷ luật: mỗi yêu cầu bảo trì (dù là báo cáo lỗi hay nâng cao) nên được ghi lại, phân loại theo loại, đánh giá tác động, ưu tiên, thực hiện dưới quản lý phiên bản với kiểm thử, được rà soát, và phát hành qua đường ống thông thường (chương 11.2). Phân tích tác động, hiểu mọi thứ một thay đổi đề xuất có thể chạm đến, là trung tâm và xứng đáng có công sức thực sự. Ngừng sử dụng cũng là một phần của quy trình: ngừng hoạt động một hệ thống an toàn, di chuyển dữ liệu và người dùng của nó, và bảo tồn hồ sơ là công việc bảo trì phải được hoạch định, không ứng biến.

Ước tính chi phí bảo trì tường minh và tài trợ cho nó

Đừng coi bảo trì là miễn phí, hoặc là nhiễu trong ngân sách xây dựng. Hãy ước tính nó. Các cách tiếp cận phổ biến gồm tỷ lệ công sức bảo trì (quy tắc ngón tay cái được dùng rộng rãi rằng bảo trì hằng năm vào khoảng 15 đến 25 phần trăm chi phí phát triển ban đầu, dù các hệ thống quan trọng sống lâu tích lũy nhiều hơn hẳn trong vòng đời), các mô hình tham số như COCOMO II (Mô hình Chi phí Kiến tạo) với các phần mở rộng bảo trì và tái sử dụng, và dự báo dựa trên chỉ số từ dữ liệu lịch sử của chính bạn về tỷ lệ lỗi, khối lượng thay đổi và chi phí thay đổi. Hãy đưa các ước tính này vào phân tích tổng chi phí sở hữu và kinh tế học được thảo luận trong chương 10.10. Giá mua hay chi phí xây dựng của một hệ thống là một khoản đặt cọc. Khoản thế chấp là bảo trì, và nó nên xuất hiện trong mọi luận chứng kinh doanh.

Thiết kế cho khả năng bảo trì từ đầu

Đòn bẩy lớn nhất lên chi phí bảo trì được thực hiện trước khi bảo trì bắt đầu. Khả năng bảo trì (khả năng phân tích, khả năng sửa đổi, khả năng kiểm thử và tính mô-đun, theo từ vựng của ISO/IEC 25010) là một chất lượng thiết kế phải là yêu cầu tường minh, không phải một may mắn. Hãy ưu tiên các thiết kế mô-đun, liên kết lỏng, gắn kết cao (chương 2.2); giao diện rõ ràng và tách biệt các mối quan tâm; kiểm thử tự động mạnh; mã dễ đọc và tài liệu cập nhật; và khả năng quan sát phong phú để người vận hành và người bảo trì thấy hệ thống đang làm gì (Phần 9). Mỗi quyết định này đánh đổi thêm chút công sức bây giờ lấy khoản tiết kiệm lớn, cộng dồn qua nhiều thập kỷ hệ thống thực sự sẽ sống. Xây dựng cho khả năng bảo trì là khoản đầu tư có lợi tức cao nhất trong toàn bộ vòng đời.

Đánh đổi: ưu và nhược điểm

Cách tiếp cận	Ưu điểm	Nhược điểm
Tái cấu trúc liên tục / bảo trì phòng ngừa	Giữ chi phí thay đổi phẳng, giảm rủi ro, ROI cao	Công sức liên tục không có tính năng mới nhìn thấy được; cần kiểm thử mạnh
Trì hoãn bảo trì (“giữ đèn sáng”)	Rẻ nhất quý này; giải phóng năng lực cho tính năng	Nợ thay đổi cộng dồn; khủng hoảng cuối cùng và hành động đắt đỏ bị ép buộc
Tái kỹ thuật một thành phần suy thoái	Khôi phục khả năng bảo trì và kéo dài tuổi thọ hữu ích	Công sức và rủi ro đáng kể; hành vi phải được bảo toàn cẩn thận
Thiết kế cho khả năng bảo trì ngay từ đầu	Tiết kiệm cộng dồn suốt vòng đời; mọi thay đổi tương lai dễ hơn	Chi phí và kỷ luật ban đầu cao hơn; lợi ích bị trì hoãn và ít thấy

Đánh đổi lặp lại trong bảo trì là chi phí hiện tại so với chi phí tương lai, và cám dỗ luôn chạy về phía trì hoãn. Bỏ qua tái cấu trúc, để các phụ thuộc già đi, và bỏ đói đội bảo trì đều trông miễn phí quý này, vì hóa đơn đến sau: dưới dạng một hệ thống chậm hơn, rủi ro hơn, đắt hơn, và cuối cùng là một “khủng hoảng hệ thống cũ.” Kỷ luật của bảo trì tốt là trả các chi phí nhỏ, liên tục, hiển thị bây giờ để tránh các chi phí lớn, đột ngột, định đoạt sự nghiệp sau này. Vì khoản tiết kiệm bị trì hoãn và vô hình, đánh đổi này đòi hỏi ban lãnh đạo hiểu kinh tế học vòng đời, không chỉ các ngày ra mắt.

Câu hỏi để thảo luận với đội của bạn

Ai sở hữu con số bảo trì trong ngân sách của bạn, và nó là một dòng hạng nhất hay một phần dư cạo ra từ bất cứ thứ gì đợt xây dựng chưa tiêu hết? Bảo trì là phần lớn chi phí vòng đời, thường 60 đến 90 phần trăm cho các hệ thống sống lâu, nhưng nó thường xuyên được tài trợ như chuyện nghĩ sau và bố trí cho bất cứ ai rảnh. Khi ngân sách là phần dư, công việc phòng ngừa là thứ đầu tiên bị cắt, nợ thay đổi cộng dồn, và một cú trượt có thể đoán trước vào “khủng hoảng hệ thống cũ” theo sau. Hãy mang một ước tính thực (tỷ lệ công sức bảo trì, mô hình tham số, hoặc dữ liệu chi phí thay đổi lịch sử của chính bạn) và nêu tên người chịu trách nhiệm tài trợ nó suốt vòng đời hệ thống. Cách sửa là lập ngân sách bảo trì tường minh trong mọi luận chứng kinh doanh, như một khoản thế chấp nằm cạnh giá mua. Ban lãnh đạo chỉ ăn mừng các lần ra mắt sẽ tiếp tục tài trợ thiếu giai đoạn nơi phần lớn tiền và rủi ro thực sự nằm.
Bạn có dành riêng năng lực cho bảo trì phòng ngừa không, hay nó luôn thua tính năng kế tiếp? Công việc phòng ngừa (tái cấu trúc dưới lưới kiểm thử, giữ các phụ thuộc cập nhật, gia cố các vùng mong manh) là kiểu bảo trì rẻ nhất, vì nó giữ đường cong chi phí thay đổi phẳng thay vì để nó leo lên. Nó cũng là thứ dễ trì hoãn nhất, vì bỏ qua nó trông miễn phí quý này và hóa đơn đến sau dưới dạng một hệ thống chậm hơn, rủi ro hơn. Một cơ chế cụ thể có ích: một phần phân bổ thường trực, và nhiều đội mạnh bảo vệ khoảng một phần năm năng lực, được canh giữ thay vì bị thương lượng mất mỗi sprint. Hãy mang xu hướng chi phí thay đổi của bạn làm bằng chứng; nếu nó đang tăng, bạn đã đầu tư thiếu. Kỷ luật là trả các chi phí nhỏ, hiển thị bây giờ để tránh những chi phí lớn, đột ngột, định đoạt sự nghiệp sau này, và điều đó đòi hỏi ban lãnh đạo đọc kinh tế học vòng đời thay vì các ngày ra mắt.
Kế hoạch ngừng sử dụng một hệ thống của bạn là gì, và lần cuối bạn thực sự ngừng hoạt động một hệ thống là khi nào? Ngừng sử dụng là một phần tường minh của quy trình bảo trì (di chuyển dữ liệu, chuyển đổi người dùng, bảo tồn hồ sơ, tắt an toàn), nhưng các tổ chức mang theo các hệ thống chết và dư thừa nhiều năm vì ngừng hoạt động không hào nhoáng và không có ngân sách. Mỗi hệ thống xác sống vẫn tiêu thụ giấy phép, vá lỗi bảo mật, bề mặt tích hợp, và sự chú ý của những người lẽ ra có thể ở nơi khác. Hãy mang bản kiểm kê và đánh dấu các hệ thống không còn người dùng hoạt động hoặc đã có bản thay thế đầy đủ đang chạy, rồi hoạch định việc tắt chúng như bất kỳ công việc nào khác: di chuyển dữ liệu, bảo tồn những gì luật yêu cầu, và xác nhận không còn gì phụ thuộc vào chúng. Đặc biệt trong chính phủ, luật lưu giữ hồ sơ định hình cách bạn ngừng sử dụng, nên hãy đưa tuân thủ vào sớm. Một tín hiệu trưởng thành đáng theo dõi: lần cuối tổ chức của bạn cố ý tắt thứ gì đó là khi nào?
Bao nhiêu phần của mỗi thay đổi được dành để hiểu hệ thống trước khi chạm vào, và hệ số xe buýt của bạn trên các hệ thống quan trọng nhất là bao nhiêu? Hiểu chương trình là hoạt động đơn lẻ lớn nhất trong bảo trì, và chi phí của nó được định bởi việc bạn đã giữ mã, lịch sử và hành vi của nó dễ đọc đến đâu. Khi sự hiểu biết chỉ sống trong vài cái đầu lâu năm, mỗi lần ra đi hay nghỉ hưu nâng giá của mọi thay đổi tương lai, và một sự vắng mặt đơn lẻ có thể đình trệ một bản sửa quan trọng. Hãy mang bằng chứng: tỷ lệ thời gian đọc-và-suy-luận so với thời gian sửa trong các thay đổi gần đây, số người có thể sửa đổi an toàn từng mô-đun lõi, và liệu quy tắc nghiệp vụ cùng quyết định có được lập tài liệu cạnh mã hay phải dựng lại từ trí nhớ mỗi lần. Cân nhắc đối lập là tài liệu và kiểm thử đặc tính tốn công sức bây giờ cho khoản tiết kiệm chỉ hiện ra sau, nên dễ bị bỏ qua. Trong doanh nghiệp và chính phủ, nơi hệ thống sống lâu hơn tác giả gốc hàng thập kỷ và các quy tắc luật định bị chôn trong một công cụ tính toán không ai nhớ đầy đủ, hãy coi sự hiểu biết đã được nắm bắt (hồ sơ quyết định kiến trúc, kiểm thử đặc tính, tài liệu hiện tại) là tài sản bạn tài trợ có chủ đích, không phải sự lịch sự xảy ra khi ai đó có thời gian rảnh.
Ai thực sự bố trí nhân sự cho công việc bảo trì của bạn, và địa vị cùng tinh thần của nó có khớp với tầm quan trọng của nó không? Bảo trì là phần lớn chi phí vòng đời và là kỹ thuật khó nhất, thay đổi an toàn các hệ thống bạn không xây và có thể không hiểu đầy đủ, nhưng nó thường xuyên bị giao cho những người ít kinh nghiệm nhất và bị đóng khung là “giữ đèn sáng” địa vị thấp. Tín hiệu đó ăn mòn: kỹ sư giỏi nhất của bạn tránh công việc này, kiến thức tập trung rồi bước ra khỏi cửa, và chi phí thay đổi leo lên trong khi không ai để ý. Hãy mang hồ sơ thâm niên của người bảo trì các hệ thống sống lâu nhất của bạn, dữ liệu luân chuyển và lưu giữ kiến thức, và một đánh giá trung thực về việc bảo trì là ngõ cụt sự nghiệp hay một chuyên môn được kính trọng trong tổ chức của bạn. Căng thẳng là thật, vì kỹ sư có hoài bão muốn xây thứ mới và lãnh đạo muốn ăn mừng các lần ra mắt, nên tôn trọng bảo trì cần cấu trúc có chủ đích. Với một doanh nghiệp lớn hay cơ quan công vận hành các hệ thống mang rủi ro quy định và tài chính hàng thập kỷ, bố trí các kỹ sư cấp cao được kính trọng cho bảo trì là một quyết định quản trị rủi ro, và để bảo trì thành một vị trí bị phạt là cách bạn chế tạo cuộc khủng hoảng hệ thống cũ kế tiếp.
Bạn có theo dõi công sức của mình thực sự thuộc loại nào trong bốn loại không, và bạn có đo chi phí thay đổi như một chỉ báo dẫn đầu không? Các đội thường xuyên hoạch định bảo trì như thể nó chủ yếu là sửa lỗi, trong khi các nghiên cứu thực nghiệm cho thấy nâng cao và thích nghi chiếm ưu thế, nên một danh mục chỉ được tài trợ cho công việc sửa lỗi bị định sai phạm vi ngay từ đầu. Không có theo dõi theo loại bạn không thể thấy một hệ thống đang được định hình lại bởi một dòng đều đặn các thích nghi quy định, và không có chỉ số chi phí thay đổi (thời gian dẫn thay đổi, tỷ lệ thất bại thay đổi, xu hướng độ phức tạp) bạn không thể biết đường cong của mình phẳng hay đang lặng lẽ leo lên khủng hoảng. Hãy mang bảng phân tích theo loại thực tế của bạn trong năm qua, xu hướng chi phí thay đổi nếu có, và một ghi chú trung thực về việc phân tích tác động là một bước thật hay một hình thức bị bỏ qua dưới áp lực hạn chót. Lực kéo đối lập là bản thân việc đo lường tốn công sức và có thể cảm thấy như chi phí chung khi hệ thống vẫn chạy. Trong các danh mục doanh nghiệp và chính phủ, nơi nhiều đội bảo trì nhiều hệ thống và một đường cong chi phí tăng ở bất kỳ hệ thống nào là cảnh báo sớm đáng hành động, theo dõi loại dùng chung và chỉ báo chi phí thay đổi là thứ cho phép ban lãnh đạo tái kỹ thuật một mô-đun trước khi nó suy thoái thay vì sau khi nó thất bại công khai.

Góc nhìn theo lĩnh vực

Công ty khởi nghiệp. Với một nhúm kỹ sư và đường băng ít ỏi, bạn không thể gánh một quy trình bảo trì nặng nề, nhưng cũng không thể gánh một cơ sở mã không ai muốn chạm. Hãy dành ra một lát thường trực nhỏ của mỗi chu kỳ (khoảng một ngày trong năm) cho công việc phòng ngừa: vá phụ thuộc, dọn các lỗi nhỏ trước khi chúng cộng dồn, và tái cấu trúc những góc bạn đã sợ dưới bất cứ kiểm thử nào bạn có. Mục tiêu là giữ cho mã rẻ để thay đổi trong khi bạn chuyển hướng, để bạn không bao giờ tỉnh dậy với hai mươi kỹ sư mà nhầm bảo trì bị trì hoãn thành một “vấn đề hệ thống cũ.”

Doanh nghiệp nhỏ. Không có chuyên gia bảo trì riêng và ngân sách eo hẹp, hãy nghiêng về mua và lưu trữ hơn là xây, để bảo trì thích nghi (bản vá bảo mật, cập nhật nền tảng và phụ thuộc) phần lớn là việc của người khác. Ở nơi bạn sở hữu mã, hãy giữ nó nhỏ, nhàm chán và được lập tài liệu tốt, và bảo đảm ít nhất hai người hiểu bất cứ thứ gì doanh nghiệp phụ thuộc vào. Hãy theo dõi một nhúm hệ thống bạn không thể chịu mất, và ngân sách một dòng khiêm tốn, tường minh để giữ chúng cập nhật thay vì giả vờ bảo trì là miễn phí.

Doanh nghiệp lớn. Ở quy mô lớn bạn đang bảo trì nhiều hệ thống sống lâu qua nhiều đội, nên ưu tiên là một quy trình được xác định, lặp lại được: một đường ống yêu cầu được ghi lại và phân loại, phân loại thành bốn loại, phân tích tác động thường lệ, và một phần phân bổ phòng ngừa thường trực được canh giữ thay vì bị thương lượng mất. Hãy tài trợ bảo trì như một chương trình hạng nhất, đo các chỉ báo chi phí thay đổi trên toàn danh mục, và dùng một đường cong tăng làm tác nhân để tái kỹ thuật một mô-đun trước khi nó thành gánh nặng. Kỳ vọng về quản trị và kiểm toán nghĩa là theo dõi loại và hồ sơ thay đổi không phải chi phí chung, chúng là bằng chứng rằng hệ sinh thái đang được kiểm soát.

Chính phủ. Quy tắc mua sắm, minh bạch và trách nhiệm giải trình công định hình bảo trì nhiều như kỹ thuật. Bảo trì thích nghi do luật định đến với các hạn chót cứng hằng năm không thể trượt, nên hãy lập ngân sách bảo trì như một chi phí vận hành vô thời hạn và bố trí một đội chuyên gia ổn định để giữ kiến thức về các quy tắc mà tác giả đã nghỉ hưu từ lâu. Việc ngừng sử dụng bị ràng buộc bởi luật lưu giữ hồ sơ, nên hãy hoạch định ngừng hoạt động cùng tuân thủ từ đầu, và ưu tiên các hợp đồng và kiến trúc giữ cho hệ thống bảo trì được và di động được thay vì mắc kẹt bạn với một nhà cung cấp duy nhất hàng thập kỷ.

Ví dụ

Công ty khởi nghiệp. Một công ty khởi nghiệp vừa phát hành MVP bị cám dỗ đổ mọi giờ vào tính năng mới, nhưng kỹ sư sáng lập của họ dành ra một lát thường trực của mỗi sprint (khoảng một ngày trong năm) cho bảo trì ngay từ tháng đầu tiên. Ngân sách đó giữ các phụ thuộc được vá, dọn các lỗi nhỏ trước khi chúng cộng dồn, và tái cấu trúc những góc đội đã sợ, nên cơ sở mã vẫn rẻ để thay đổi khi sản phẩm chuyển hướng. Những công ty khởi nghiệp bỏ qua điều này đến hai mươi kỹ sư với một cơ sở mã không ai muốn chạm và nhầm nó với một “vấn đề hệ thống cũ” trong khi suốt thời gian đó nó là bảo trì bị trì hoãn.

Doanh nghiệp lớn. Một ngân hàng toàn cầu chạy một nền tảng thanh toán đã ở trên môi trường thực mười lăm năm. Họ tài trợ bảo trì như một chương trình thường trực, hạng nhất thay vì một dòng ngân sách dư. Công việc được phân loại thành bốn loại: một dòng đều đặn các thay đổi thích nghi theo dõi quy định mới và cập nhật giao diện ngân hàng đối tác, công việc hoàn thiện thêm tính năng và cải thiện thông lượng, công việc sửa lỗi dọn các khiếm khuyết theo các thỏa thuận mức dịch vụ (SLA) nghiêm ngặt, và một phần phân bổ phòng ngừa thường trực (khoảng một phần năm năng lực đội) trả dần độ phức tạp qua tái cấu trúc liên tục dưới một bộ kiểm thử toàn diện. Đội đo thời gian dẫn thay đổi và tỷ lệ thất bại thay đổi, và coi chi phí thay đổi tăng là cảnh báo sớm để tái kỹ thuật một mô-đun trước khi nó thành gánh nặng. Người bảo trì là các kỹ sư cấp cao, được kính trọng, không phải nhân viên cấp thấp bị gửi vào việc “giữ đèn sáng.”

Chính phủ. Một cơ quan thuế quốc gia bảo trì một hệ thống đã chạy hơn ba mươi năm và được sửa đổi mỗi năm khi luật thuế thay đổi. Loại chi phối ở đây là bảo trì thích nghi do luật định, với các hạn chót cứng hằng năm không thể trượt. Cơ quan đầu tư mạnh vào hiểu chương trình: quy tắc nghiệp vụ được lập tài liệu cạnh mã, kiểm thử đặc tính ghim hành vi của các quy tắc mà tác giả gốc đã nghỉ hưu từ lâu, và phân tích tác động là một bước chính thức trước bất kỳ thay đổi nào đối với công cụ tính toán. Vì môi trường (luật) thay đổi liên tục, hệ thống không bao giờ có thể “hoàn thành”, nên cơ quan lập ngân sách bảo trì như một chi phí vận hành vô thời hạn, bố trí một đội chuyên gia ổn định để giữ kiến thức, và hiện đại hóa các thực hành phân phối xung quanh như quản lý mã nguồn, tích hợp liên tục (CI) và kiểm thử tự động, ngay cả khi lõi vẫn tồn tại.

Luận chứng kinh doanh: động lực, ROI và TCO

Sự thật kinh doanh cốt lõi của phần mềm là bảo trì, không phải xây dựng, là nơi tiền đi. Qua cả ngành và qua nhiều thập kỷ nghiên cứu, bảo trì chiếm phần lớn rõ ràng của chi phí vòng đời, thường được trích dẫn ở mức 60 đến 90 phần trăm cho các hệ thống sống lâu, mà trong doanh nghiệp và chính phủ là hầu hết. Bất kỳ phân tích tổng chi phí sở hữu nào dừng ở thời điểm đưa vào hoạt động đều sai lệch cả mấy lần. Luận chứng kinh doanh chính cho việc coi trọng bảo trì đơn giản là sự chính xác: lập ngân sách cho toàn bộ vòng đời của hệ thống, hoặc liên tục bị bất ngờ bởi hóa đơn.

Lợi tức đầu tư đến từ việc bẻ cong đường cong chi phí. Trong một hệ thống bị bỏ bê, chi phí của mỗi thay đổi tăng theo thời gian khi độ phức tạp tích tụ và sự hiểu biết phân rã, cho đến khi thay đổi trở nên chậm và rủi ro một cách cấm đoán. Trong một hệ thống được bảo trì tốt, công việc phòng ngừa liên tục (tái cấu trúc, cập nhật phụ thuộc, độ bao phủ kiểm thử, tài liệu) giữ đường cong đó phẳng, nên thay đổi thứ một nghìn tốn xấp xỉ thay đổi thứ mười. Đầu tư vào khả năng bảo trì và bảo trì phòng ngừa do đó không phải một chi phí cần tối thiểu hóa. Nó là đòn bẩy quyết định liệu một hệ thống vẫn đủ rẻ để thay đổi hay trôi vào chi phí và rủi ro leo thang của một hệ sinh thái hệ thống cũ (chương 3.6) và những thách thức duy trì của chương 10.4. Hãy tài trợ bảo trì có chủ đích, đo chi phí thay đổi như một chỉ báo dẫn đầu, và coi một đường cong tăng là tín hiệu để hành động, không phải sự thật của tự nhiên. Kinh tế học được bàn thêm trong chương 10.10.

Phản mẫu và cạm bẫy

Coi bảo trì là chuyện nghĩ sau. Chỉ lập ngân sách và ăn mừng việc xây dựng, rồi bỏ đói giai đoạn bảo trì lớn hơn và dài hơn nhiều.
Bố trí người ít kinh nghiệm nhất cho bảo trì. Giao công việc khó nhất (thay đổi an toàn các hệ thống bạn không hiểu đầy đủ) cho những người ít được trang bị nhất, và báo hiệu rằng bảo trì là địa vị thấp.
Nhầm bảo trì với sửa lỗi. Chỉ hoạch định cho công việc sửa lỗi trong khi thích nghi và nâng cao thực sự chi phối công sức.
Trì hoãn bảo trì phòng ngừa vô thời hạn. Không bao giờ tái cấu trúc, không bao giờ cập nhật phụ thuộc, cho đến khi nợ thay đổi buộc một cuộc khủng hoảng đắt đỏ.
Thay đổi mã không phân tích tác động. Thực hiện một “bản sửa nhỏ” lan thành các thất bại không lường trước ở nơi khác.
Tái cấu trúc không có lưới an toàn kiểm thử. Tái cơ cấu mã mà không có cách chứng minh hành vi được bảo toàn: đó chỉ là viết lại đầy rủi ro.
Để kiến thức bước ra khỏi cửa. Không lập tài liệu quy tắc nghiệp vụ và quyết định, nên mỗi lần nghỉ hưu hay ra đi nâng chi phí của mọi thay đổi tương lai.
Không bao giờ ngừng sử dụng gì cả. Mang theo các hệ thống chết và dư thừa mãi mãi vì ngừng hoạt động không hào nhoáng và không có kế hoạch.

Mô hình trưởng thành

Mức 1: Khởi đầu. Bảo trì không có kế hoạch và không được tài trợ, được xử lý phản ứng bởi ai rảnh. Nó bị xem là sửa lỗi và là công việc địa vị thấp. Không có theo dõi theo loại, không có ước tính chi phí, và kiến thức sống trong vài cái đầu. Chi phí thay đổi tăng mà không ai để ý cho đến khi một bản sửa đình trệ hoặc khủng hoảng buộc phải chú ý.
Mức 2: Phát triển. Một số đội đã bắt đầu ghi lại và phân loại yêu cầu bảo trì và mang một dòng ngân sách, nhưng thực hành không nhất quán trong tổ chức và ngân sách thường là phần dư. Công việc sửa lỗi được theo dõi trong khi công sức thích nghi và hoàn thiện không được phân biệt rõ. Một số kiểm thử và tài liệu tồn tại rải rác, nên thay đổi được kiểm soát một phần nhưng sự hiểu biết vẫn tốn kém và không đồng đều giữa các đội.
Mức 3: Chuẩn hóa. Một quy trình bảo trì được xác định (theo ISO/IEC 14764) được lập tài liệu và thực thi toàn tổ chức: công việc được phân loại thành bốn loại, phân tích tác động và quản lý thay đổi là thường lệ, và bảo trì được ước tính và tài trợ tường minh trong mọi luận chứng kinh doanh. Bảo trì phòng ngừa và tái cấu trúc là thực hành tiêu chuẩn dưới một bộ kiểm thử vững chắc, và khả năng bảo trì (khả năng phân tích, sửa đổi, kiểm thử, tính mô-đun) là một yêu cầu thiết kế tường minh thay vì thói quen cục bộ.
Mức 4: Quản lý. Bảo trì được đo và kiểm soát bằng dữ liệu theo các đường cơ sở. Các chỉ báo chi phí thay đổi (thời gian dẫn thay đổi, tỷ lệ thất bại thay đổi, xu hướng độ phức tạp và lỗi) được theo dõi cho mỗi hệ thống, hỗn hợp công sức bốn loại được định lượng so với kỳ vọng, và tỷ lệ công sức bảo trì cùng ước tính tham số được kiểm tra so với chi phí thay đổi lịch sử thực tế. Một đường cong chi phí tăng được phát hiện như chỉ báo dẫn đầu và kích hoạt hành động, và phần phân bổ phòng ngừa được định cỡ từ bằng chứng thay vì đoán. Các quyết định tái cấu trúc, tái kỹ thuật hoặc ngừng sử dụng được đưa ra dựa trên ngưỡng đo được, không phải trực giác.
Mức 5: Điều phối. Bảo trì được cải thiện liên tục và tích hợp trong toàn tổ chức và kinh tế học vòng đời của nó. TCO vòng đời dẫn dắt đầu tư danh mục, tái kỹ thuật được áp dụng có chủ đích trước khi các thành phần suy thoái, kiến thức được chủ động lưu giữ, và việc ngừng sử dụng được hoạch định và thực hiện thường lệ. Tổ chức cân bằng lại công sức bảo trì khi môi trường dịch chuyển (quy định, nền tảng, phụ thuộc), người bảo trì là các kỹ sư cấp cao được kính trọng, và cả hệ sinh thái thích ứng để chi phí thay đổi giữ phẳng qua các hệ thống sống hàng thập kỷ.

Ý tưởng để thảo luận

Bao nhiêu phần công sức kỹ thuật của bạn thực sự dành cho bảo trì, và ngân sách cùng nhân sự của bạn có phản ánh thực tế đó không?
Bạn có thể chia công việc bảo trì thành bốn loại không, và hỗn hợp có khớp với giả định của bạn không?
Bao nhiêu phần của một thay đổi điển hình dành cho việc hiểu hệ thống so với sửa đổi, và điều gì sẽ làm sự hiểu biết rẻ hơn?
Chi phí thay đổi của bạn đang tăng, phẳng hay giảm theo thời gian, và bạn có đo nó không?
Các đội của bạn có lưới an toàn kiểm thử đáng tin cậy khiến tái cấu trúc liên tục an toàn không, hay việc tái cơ cấu quá rủi ro để thử?
Ai bảo trì các hệ thống sống lâu nhất của bạn, kiến thức của họ được nắm bắt thế nào, và địa vị cùng tinh thần của công việc đó ra sao?

Những điểm cần ghi nhớ

Bảo trì là phần lớn chi phí vòng đời của phần mềm (thường 60 đến 90 phần trăm cho các hệ thống sống lâu) và phải được hoạch định, lập ngân sách và bố trí nhân sự như một hoạt động hạng nhất.
Bốn loại (sửa lỗi, thích nghi, hoàn thiện, phòng ngừa) là các công việc riêng biệt, và nâng cao cùng thích nghi, không phải sửa lỗi, thường chi phối.
Hiểu chương trình là hoạt động bảo trì đơn lẻ lớn nhất; hãy làm cho mã, lịch sử và hành vi dễ đọc để giữ mọi thay đổi rẻ.
Tái cấu trúc liên tục dưới lưới an toàn kiểm thử và tái kỹ thuật tăng dần các thành phần suy thoái để giữ chi phí thay đổi phẳng.
Ước tính chi phí bảo trì tường minh và đưa nó vào tổng chi phí sở hữu và các quyết định kinh tế.
Thiết kế cho khả năng bảo trì từ đầu (đó là khoản đầu tư có lợi tức cao nhất trong toàn bộ vòng đời) và coi người bảo trì là những chuyên gia cấp cao mà họ cần là.

Tài liệu tham khảo và đọc thêm

IEEE Computer Society, SWEBOK Guide (Bộ Kiến thức về Kỹ thuật Phần mềm), khu vực kiến thức Bảo trì Phần mềm
ISO/IEC 14764 / IEEE 14764, Software Engineering: Software Life Cycle Processes, Maintenance
ISO/IEC 25010, Systems and software Quality Requirements and Evaluation (SQuaRE): các đặc tính chất lượng về khả năng bảo trì
Martin Fowler, Refactoring: Improving the Design of Existing Code
Michael Feathers, Working Effectively with Legacy Code
Thomas M. Pigoski, Practical Software Maintenance
Penny Grubb và Armstrong A. Takang, Software Maintenance: Concepts and Practice
Barry Boehm và cộng sự, Software Cost Estimation with COCOMO II (các mô hình bảo trì và tái sử dụng)
Meir M. Lehman, “Laws of Software Evolution” (về việc vì sao phần mềm phải liên tục thay đổi hoặc trở nên kém hữu ích)
Robert C. Seacord, Daniel Plakosh và Grace A. Lewis, Modernising Legacy Systems