定義棕地應用程式。接手維護既有的程式。棕地應用程式的挑戰。說服你的老闆。
書名：軟體構築美學
作者：Kyle Baley，Donald Belcham
譯者：蔡煥麟，張簡才祿
發行公司：悅知文化，精誠資訊股份有限公司
定義棕地應用程式
brownfield 棕地：年久失修的荒蕪建地，好好整理一番，可能恢復其價值。
brownfield application 棕地應用程式：一個既有的軟體（有不好的開發方式、結構與設計等問題），經過仔細整理與『重構』，有機會起死回生。
三種應用程式：綠地 棕地 老舊
| 考量 | 綠地 | 棕地 | 老舊 |
| 專案狀態 | 開發生命週期的初期：專注於新功能 | 新功能的開發與測試或正式環境（production）的維護 | 維護模式 |
| 程式碼成熟度 | 積極撰寫所有的程式碼 | 有一些新的程式碼：積極處理既有的程式碼瑕疵 | 除了修正瑕疵之外，很少開發新程式 |
| 架構檢閱 | 隨著程式規模的成長，經常檢閱和調整所有層次的架構 | 只有重大變動時（事務面或技術面） | 極少檢閱或修改 |
| 實務作法與流程 | 隨著開發過程持續發展、演進 | 大多已經有了，雖然對團隊或專案而言不見得合用 | 著眼於維護應用程式和解決嚴重瑕疵 |
| 專案團隊 | 新組成的團隊，嘗試找出合適的流程與實務作法 | 新舊成員混合，創新構想與既有成見一起出現 | 只用非常小的團隊來維持系統現況 |
brownfield application 主要的元素包含：既有程式碼 污染 改善的潛力
既有的程式碼
你得要有存取程式碼的權限。
程式碼應該正處於積極開發的狀態。
污染（差勁實務作法所造成的污染）
程式的壞味道（smell）。
技術債。
改善的潛力（仍有改善或重複使用的潛力）
程式不僅還有救，你也願意積極改善它。
讓你有動力維護的理由
商業邏輯已經以某種形式存在。
從你第一天接手維護開始就能看到生產力。
修改既有的程式碼比從無到有容易些。
專案可能已經上線運行，而且正持續產生收入。
接手維護既有的程式
改善程式：重構程式碼 -> 持續整合（版本控制）
痛點 pain point
令你感到不對勁的地方，他會促使你尋找解決方法或替代方案。
最容易的方法：擷取方法（Extract to Method）與建立變數（Intriduce Variable）
沒有痛點，就沒有必要動程式碼。
辨識阻礙
任何妨礙正常開發流程的東西都叫阻礙。
挑戰自己的想法
重新思考既定的想法。
平衡用戶的期望
軟體天平：時間＋資源 範圍＋品質。
大幅重寫
仔細評估重構與重寫。
程式碼無法滿足使用者的需求與目標，在考慮重寫。
棕地應用程式的挑戰
身為開發人員，我們通常只注意技術面的問題。
五項挑戰：技術 政治因素 團隊士氣 用戶的信心 管理階層的士氣
技術因素
關鍵在於，一次只專注在一個問題上，並依問題的嚴重程度排定處理的優先順序。
政治因素
循序漸進，別一開始就下猛藥，了解為什麼團隊或個人會產生那些抗拒，然後對症下藥。
團隊士氣
讓團隊成員對於整體的程式碼品質都有一份責任感。
程式的問題屬於團隊，而非個人。
用戶信心
最好提升用戶信心的方式，就是開發並持續的交付，讓用戶參與也是個好主意。
管理階層士氣
在既定預算之內準時交付高品質的軟體。
保持溝通管道的暢通。
成為改變的推手
應付質疑聲浪
不要為了逃避學習新東西，而產生各式各樣的藉口。
先尋求願意接納的成員支持，然後教授各種技巧，並灌輸他們持續改善的觀念。
需要管理階層適度的回應與支援也非常重要。
改變要有實際的成效。
挑戰既有的想法，做出改變
改變的過程，應著重於溫和的心態調整，而非震攝威逼的手段。
勿感情用事
不免會出現各種情緒化的反應，保持頭腦清醒，專注於達成最終目標。
說服你的老闆
概念驗證 proof of concept＋模型 mockup
最好的方法是，提出實際的數據來證明，可以先簡單寫一個獨立的小模組實驗你的構想。
總結
先解決最大痛點，然後再解決下一個大痛點。
無論什麼樣的改變，只要是正面的，對專案都會有很大的幫助。
用一個獨立的小實驗來證明你建議的方法或技術確實可行。
改變脫離不了兩大範疇：整體環境（ecosystem） 程式碼
技術債不是累積然後一次解決，而是每一個週期中分配一些時間來處理，團隊一起即早還債。