Working Effectively with Legacy Code - Ch1 - 修改軟體

前言

本書的書名叫做「管理、修改、重構遺留程式碼的藝術」，那麼什麼是「遺留程式碼」呢？

普遍上來說的遺留程式碼的定義為：遺留程式碼就是指從其他人那裡得來的程式碼

而作者對於「遺留程式碼」的定義卻不盡然

作者認為的遺留程式碼定義為：沒有編寫測試的程式碼

作者表示他想透過這本書闡述以下的想法

沒有編寫測試的程式碼是糟糕的程式碼，不管我們多麼細心地去編寫它們，不管它們有多漂亮、物件導向或封裝良好。有了測試，我們就能夠迅速的、可驗證地修改程式碼的行為。沒有測試，我們就不知道修改後的程式碼，實際上是變得更好還是更糟。

以下開始進入第一章正式的內容。

修改軟體的四個起因

一般來說，我們可以將修改軟體的起因區分為以下四大類

1. 添加新特性
2. 修正bug
3. 改善設計
4. 最佳化資源使用

添加特性和修正bug

添加特性與修正Bug常常是相輔相成出現的，只差別在主觀上的認定(工程面及業務面)，作者認為其中最為重要的是，軟體的對外行為做出改變了。

改善設計

其實就是我們所知的重構(Refactoring)，在不改變軟體外在行為的前提下，去改變程式碼的結構，使其達到更好讀、更容易維護、架構耦合更鬆散…諸如此類的結果。

最佳化

最佳化與重構相當類似，同樣在不改變軟體的對外行為的前提下，我們著重的點是想讓效能(如:記憶體使用量、運行時間)可以得到改善。

綜合起來

	添加特性	修正bug	重構	最佳化
結構	改變	改變	改變
新功能	改變
功能		改變
資源使用				改變

在四種情況下，我們都有想要改變的事情，但除了想改變的目標以外，我們必須還得注意到在這之外，其實有相當大的部分是我們不想要改變的，我們除了要顧及想改變的地方以外，還得顧及該如何讓不想改變的地方一如往常。而這些不想改變的部分，往往才是最困難的部分。

危險的修改

如上，保持行為不便其實才是最為險峻的挑戰，為了減少風險，我們考慮以下三個面向

1. 我們要進行那些修改?
2. 我們如何得知已經正確地完成了修改?
3. 我們如何得知沒有破壞任何(既有的)功能?

至於該如何達成以上三個考量，本章節的文末並未提及，應該是想把這些主題留在後面去做討論。