你是否也有接手過別人程式碼的經驗？

無論是加入新的專案或是工作環境，我們都有很大的機會承接這些遺產。作為一個新進成員，在閱讀舊有程式碼時難免會有許多疑問。

• 為什麼這裡會這樣寫？
• 為什麼這裡會需要這樣的 Workaround？
• 為什麼這裡要這樣設計？
• 為什麼會寫的這麼差？

『全部重寫好了？！』 難免會這樣想。

為什麼會有技術債？

請先等一等，思考為什麼這些技術債存在？也許是下列幾種原因：
– 時辰壓力：為追趕產品上線時程，不夠時間考慮周全
– 需求變更：過去符合需求但不符合新的需求
– 技術演進：新的程式碼語法只要一行就能解決

如果從一間企業的成長歷程中去看技術債這個議題，你會發現在草創時機不太會請到厲害的工程師加盟。

為什麼這樣說呢？

從軟體工程師的角度來看

以成長面來看，新創公司變動很快，通常是邊摸索需求邊開發功能，而團隊中很可能只有你一位 iOS 工程師，在孤軍奮戰加戰況危急的情況下你很難有時間好好累積良好的開發知識與經驗。

從風險與報酬面來看，參加新創的風險很高，但報酬率不一定高，也許先加盟較穩定的企業，等新創公司的價值被證明再帶刀投靠也不遲。

從公司的角度來看

當商業模式還未被證明可行，又有資金壓力的前提下，創業家必須要在花多少成本來請多厲害的人這兩件事情上取得平衡。

如果要請 A 咖勢必要付出比較多資金成本，而且人家也不一定會願意加盟。
如果請 C 咖資金成本比較低，但當然技術債會欠得多。

為了讓公司存活必須要積極的驗證市場，因此需求劇烈變動是可預期的，而在需求頻繁修改的情況下，幾乎不可能設計出好的架構，因為設計好的架構也是需要時間跟經驗。

綜合上述兩個角度來看，創業初期就有超棒的軟體架構不是不可能，但不是活下去的必要條件。

技術債是必然的產物，有程式碼就有技術債。

不需要還的技術債

公司開了 3 個產品線，為了快速驗證市場需求同時兼顧公司營運成本，一年後會只留下賺錢的產品。在這個情況下，你會秉持職人心態每行程式碼斤斤計較而拖慢產品進程，還是快速開發適時留下技術債？

現實是當產品下線時，程式碼再漂亮架構再好都是沒有意義的。

你要先活著才能還債。
又或者說，不活著就不用還債。

講到這你已清楚技術債的生長模式，要處理它就不會這麼難受。

更健康的心態去面對技術債

想像你是一位籃球選手，在比賽下半場教練把你換上場，此時球隊輸 20 分，你會覺得？
1. 輸 20 分根本追不回來，派我上來幹嘛？
2. 覺得球隊就靠我了，把球都給我單打
3. 能追多少算多少，一球一球打好來

最壞的時代是最好的機會

你也可以想這是證明自己能力的好機會，除了幫助公司解決當前的難題，自己也能從中獲得成就感，當然也有使用者因此而受惠等等的好處。

而工作這回事就是公司花錢交換你來解決問題。

選擇值得還的技術債

綜觀整個 Code base ，需要還的債滿坑滿谷，究竟該先處理哪一個？
在這提供兩個考量的指標「還債的效益」，以及「還債的困難度」。

還債的效益

學貸，房貸，信用卡債，先還哪個？

房貸跟學貸的利率比較低的，而信用卡債則是相對高。也就是說在同樣的時間，要付更多利息在信用卡債上，因此優先償還信用卡債是比較聰明的選擇。

醫院急診室先救誰？

突然間有很多病人湧進急診室，有些病患的問題比較緊急，10 分鐘內不處理可能會死亡，有些病患相對不危及性命，面臨這樣的問題應該怎麼選擇？

作為醫生的救援原則就是先避免死亡數字上升，再服務其他病人。

從上述兩個案子可以歸納出處理順序的重要性，債不是先來的先還，債也不是最大的先還，注意順序可以幫助你相對輕鬆的償還債務。

還債的困難度

假如有2個病患危及性命，其中有一個手術難度較高，需要全身麻醉的大型手術，且其成功率僅30%。

另一個病患同樣也是性命垂危，僅需要小手術即可，其手術成功率為 90%。
只能先救一個，你會怎麼選擇？

大範圍的重構或重寫，難度越高且越有可能造成其他問題，從上面的例子可以看出來，在同樣效益前提下，相對較小較容易的任務代表花費時間越短，總體效益會更高。

未完待續

技術債是一個有趣的議題，只要你還有在寫程式就很有可能遇到，不論你加入的是 Facebook, Google 等世界級的軟體公司，還是一些小型軟體公司服務都避不開它。

現在用的最新技術，也會隨著時間過去日換星移而被人們當成技術債。

技術：『想當初你是這麼愛我的不是嗎？』

下集💸還技術債的藝術II會以實際案例跟大家分享我們有哪些技術債，我們怎麼去選擇優先還哪個，還有在面對抉擇時我們怎麼權衡。