薛西弗斯是科林斯的國王，也是希臘神話裡出了名的狡猾。
有一次，他把宙斯偷偷帶走河神女兒的事情說了出去，宙斯知道後超級火大，直接派死神塔納托斯去把他帶走，但薛西弗斯不知道用了什麼方法，結果不但沒有被帶走，還反過來把死神綁起來了。
死神被綁住以後，世界上就再也沒有人會死，乍聽之下好像很不錯？完全不是。
戰場上的人怎麼打都死不了，整個世界秩序亂成一團，最後連戰神阿瑞斯都看不下去，只好親自把塔納托斯救出來，再把薛西弗斯交到死神手上。
但事情還沒結束，薛西弗斯早就替自己留了後手，他事先交代妻子，等自己死後不要舉行喪禮，也不要獻上祭品，到了冥界，他便拿自己沒有得到應有的葬禮當理由，說服冥界的主人暫時放他回到人間，讓他把事情處理好。
結果薛西弗斯一回到科林斯，馬上反悔，完全沒有要回去的意思，最後還是得由荷米斯親自出馬，硬是把他帶回冥界。
這次諸神不打算再給他任何鑽漏洞的機會，薛西弗斯得到的懲罰，就是把一顆巨大的石頭推上山，他用雙手撐著石頭，整個身體往前頂，好不容易一點一點推到接近山頂，偏偏就在只差最後一下的時候，石頭又從他面前滾回山腳。
沒有完成不能結束，薛西弗斯只能走回山下，再把同一顆石頭推一次，而每次都差一點，每次又得從頭開始，永遠沒有結束的一天。
時間過得好快，一下子就到第 30 天了，從「Legacy Code 不就是很舊的程式碼嗎？」開始，中間學到不少對付 Legacy Code 的技巧，最後再一路聊到團隊， 回頭看才發現，原來我們已經處理過這麼多麻煩了啊 XD
在這個過程中，可以發現我們的內容很多都圍繞在測試，但其實不管是哪一種測試或工具，需求都是最重要的一步，系統現在怎麼跑、客戶真正想要什麼、這次到底為什麼改，如果連這些都還沒講清楚，後面寫多少測試，都只是在把誤解自動化。
其實我們應該把「想要什麼」這件事拉回最前面，用具體場景讓產品、測試和開發先確認大家說的是同一件事，再找改動點與測試點，決定哪些行為要保護、哪些才是真的要改。
需求清楚之後，才輪到測試幫我們把回饋縮短，我們學到了怎麼保護新需求，總之先想辦法讓測試進得去，測試有了也別太早開心，我們還得回頭確認它真的有能力能夠抓得到錯誤。
我自己覺得看完本系列文章，要是能帶走幾個下次卡住時想得起來的方法，對我來說就很值得了，只是方法知道了不少，試也試過了，每天面對這些 code 的人還是會累，所以最後這一篇，剩下的篇幅就留給我們自己吧。
老實說，每天與 Legacy Code 為伍，真的會有很多讓人身心憔悴的事情，這種日子過久了，很容易開始懷疑自己，明明花了那麼多時間，也學了不少東西，怎麼系統還是這麼難改？銀彈到底在哪裡？
眼前的程式碼，就算整個團隊再做十年，好像也整理不完，就像薛西弗斯的懲罰一樣。
Fred Brooks 早在《人月神話》中就提過：
軟體有些困難並不是因為工具不夠好，而是來自軟體本身就必須處理的複雜性。
我們也許可以靠更好的語言、方法論，甚至是 AI 來減少開發過程中的麻煩，但卻很難把軟體本身需要面對的複雜度全部消除。
往往我們心有餘而力不足，因為需求、時程、人力、溝通、設計與技術債等眾多因素，光靠我們一個人沒有用，軟體工程本來就需要整個團隊一起面對，也需要整個組織願意留出改善的空間，不是靠一個人就能解決的。
說到這裡，自己想開一點，明天要處理的事情並不會變少，所以先不用急著把所有問題，都算成自己不夠厲害。
身陷「焦油坑」的猛獸不是不夠強壯，而是越掙扎，越容易被吞噬，畢竟 Brooks 幾十年前就在找銀彈了，到今天我們也還沒找到，所以要走這行本來就不簡單。
既然如此，就不要硬碰硬了。
軟體的複雜，其實很像一座活著的城市。
城市蓋得越久，就會留下越多不同年代的痕跡，新的道路得繞過舊建築，新的捷運得配合既有管線，有些巷子當初為什麼這樣蓋已經不可考了，我們當然可以重新規劃、拓寬道路、改善交通，但只要還有人生活在裡面，新的需求就會不斷出現，新的問題也會跟著產生。
我們瘋狂追技術，讀一本又一本的書，不是為了有一天能把所有看不慣的東西全部消滅，把系統整理成一個再也不需要修改的完美模樣。
而是讓自己在面對改不完的 Legacy Code、說不清楚的需求、不得不留下的妥協時，仍然知道哪裡可以整理、哪裡暫時不要碰，又該怎麼讓下一次改動比這一次容易一點。
所以學得越多，也許不是讓我們遇到的問題越來越少，而是讓我們面對複雜時，不再那麼手足無措，都市規劃的進步，從來不是為了讓城市停止變化，而是讓我們學會如何在變化之中，繼續好好生活。
軟體工程，大概也是如此，我們終究無法消滅複雜，但可以學著與它共生。
仔細想想，薛西弗斯不只是石頭永遠推不到山頂，而是每一次努力最後都會歸零。
但我們不完全一樣。
今天多補的一個測試、解開一個耦合、整理清楚的一段邏輯，也許改變不了整套系統，卻可能讓下一個碰到這裡的人，不必再從山腳開始。
Feather 在 《Working Effectively with Legacy Code》的後段中曾經說過：
你可能會想：「我做的這點工作相對於整個系統的糟糕現狀來說無異杯水車薪，又能發揮多大作用呢？明天又將如何呢？」
有時候即使回頭看成果時，很容易覺得「整套系統還是很爛」，感覺自己這陣子好像都在白忙，不過我們一樣每天無止盡的測試優化重構，今天留下一點，明天再留下一點，也許在：
「某天早晨一如既往的開始工作時，會驚訝原來那些以前覺得醜陋不堪的程式碼消失了」
我們已經聊了很多，但如果每天還是自己對著螢幕生悶氣，我覺得也可以先看看，除了繼續研究讀書之外，還有沒有別的地方能幫上一點忙。
一杯咖啡： 不一定要是什麼大神或團隊成員，找個時間約出來喝咖啡，一起分享工作上的問題、學到的新東西，除了感情更好，有時心情低落的時候也知道還有人比你更低落 XD
見見世面： 參加社群、研討會，可能會發現原來這個問題早就有人遇過，不用一次把所有新技術追完，帶著目前卡住的問題去找，知道還有什麼方向可以試，有時候真的很有幫助，也順便檢視自己跟其他人的差距有多大。
寫點自己覺得好玩的東西： 使用在工作上沒用過的技術，練習 Kata，或是 SideProjet 都行，範圍自己決定，重新感受一下寫 code 的樂趣，有時候會從不同的角度得到不一樣的靈感，也順便增加自己的技能包，當然下班如果已經累到不想看螢幕，就先去休息，身心靈都很重要，別暴斃了 XD
找個地方輸出： 參加 iT 鐵人賽當然是一種，逼自己重新審視原本的理解，過程中真的會一直遇到我以為我懂，寫出來的時候根本講的不清不楚，查資料、做範例、重新整理之後，才知道自己是卡在哪裡。
這幾件事不用一次全做，挑現在做得到的就好，有時候我們缺的不是再多學一個方法，只是需要暫時把頭抬起來，看看程式碼以外的地方。
走完這三十天，算成年了嗎？我覺得多少算吧，至少現在回頭看，已經不太會把 Legacy Code 只理解成前人留下來的爛東西，也知道面對一段不敢動的 code，不一定要直接重寫，更不是只能改完祈禱。
不過成年也不代表畢業，接下來還是會遇到沒看過的系統、講不清楚的需求、壓得人喘不過氣的時程，現在覺得很有把握的做法，過幾年回頭看，說不定又會覺得自己當時怎麼那麼勇。
開始寫這個系列的初衷，就是分享怎麼讓手上的 Legacy Code，連同每天上班的心情一起慢慢變好，如果能幫助到各位，那這三十天也算不枉此行了。
感謝各位讀者一起走完這三十天，手上的系統大概還有很多地方想改，我自己也是，不過今天就先到這裡吧，剩下的，等明天休息夠了再說 XD
另外如果各位對於我寫文章的方式還算可以接受，也不吝關注我的話，歡迎各位追蹤我的 臉書粉絲團 ><
iThome鐵人賽
看影片追技術