【程式人】轉折 -- 程式能不能寫一輩子？

【程式人】消失的程式碼 << 前情

與朋友閒聊間回憶起過去的一些舊文，當時討論串是聊在台灣寫程式能寫到幾歲？在感性的層次上，當然希望自己能想寫多久就寫多久，不過相對於職業生涯那會是一種「健康管理的問題」，先分享一下當時的記錄。

「程式不能寫一輩子？」

是的，程式無法寫一輩子，因為你的肝會老。

在成為產出程式並賴以維生的工作者之前，我的程式開發總是很天馬行空的。想法跳到哪，程式就寫到那。連帶著，我們 bug 也是這麼的發散。那是一段寫程式等於寫 bug 的惡夢！在那地獄般的回憶，能用來說嘴的只剩不眠不休連續瘋狂 coding 與 debug 的時數。說實在的，那只是用一個浪費生命的偽成就，來掩飾一再地犯錯與無能。

會基本語法，稍懂些邏輯確實可以寫出程式。但是不佳的設計、不良的結構、重複的 Copy & Paste。程式碼一整份，一整份地複製，到底哪一個版本才是對的，大概只能靠運氣了。

這一切就像在開始 coding 的同時，今日流程被標上了反覆記號。重複著相似的邏輯，相仿的錯誤，相同的疲勞感。心理的壓力，隨著進逼的死線更加無法承受。

那時的我，只寫得出自己想要的東西。但無法正確地掌握客戶想要的需求。還是學生的我，是個非常不成熟的程式設計師。經驗幾次爆肝的接案歷程，對自己的能力感到相當的懷疑。並且看著論壇對程式設計師生涯的討論，也相信吃這行飯需要新鮮的肝，而寫 bug 是個常態。但真的是這樣嗎？

「程式能寫一輩子！」

不，程式可以寫一輩子，因為你將不斷地重構你的工作方法。

我想每一份需要專業的職業都有著一群持續貢獻的工作者。對軟體開發來說，其實我們擁有許多寶藏。有些知識是無法獨自領略的。這得感謝過去曾與我一起工作過的前輩們，透過 Pair Programming 的手法，快速被優良典範感染。開啟了我對 XP 相關知識的接觸。在那段不算長的時間，啟發了我對於下列知識的興趣：

1. 統一撰碼風格
2. 重構的使用
3. 單元測試
4. 版本控制系統

統一撰碼風格不單純是符合團隊的 coding style，這是團隊總體思考模式的同步。像是一個類別，它會有個負責主要流程的 method，但我們不在這個 method 內有任何條件判斷 (強烈地期望)。它的內容是直敘的 method call 序列，就像平順地交辦一些事項。而原本在直覺的實作方式，應該出條件判斷的地方，可能只是在其他細節中的一個 if/else。或直接在多型的結構消耗掉了。

判斷出現地越少，程式結構就簡潔許多，也減少因寫作的失誤而產出的 bug。有時無法直接寫出較少條件式的實作，透過重構技巧學習自我整理程式碼。而重構技術包含的項目可深可淺，淺如替換變數名稱，提取程式碼成為函式。深如結合設計模式，調整外部無法觸及的程式結構。

程式結構變換最要緊的是前後的邏輯保持一致，要確保邏輯正確性。單元測試就是個不可缺少的技巧。反覆地，撰寫測試、重構、再測試、再重構。這些小技巧其實都環環相扣支持著我們，對於面對的程式碼產生良好的改變。而給與我們無比信心的，那就是版本控系統。寫亂了，再拿回原先的那一份，重來一次。這麼友善的開發環境，您說軟體人悲哀得起來嗎？

這是我想要分享的，是能以寫程式作為一輩子的工作的正反理由。如果您總是讓自己處於險境，再強的意念都會被磨碎。如果您試著讓自己處於友善的開發環境，就能獲得走下去的動力。當然，您可以看作是我的樂觀宣言。但不去經營友善的開發環境，怎麼能期待做這行一輩子呢？

健康管理

前二段的分享是於 2010 年時於 PTT 上參與討論的記錄，大約是剛入行一年多的時間。幸運的是，因為遇到了一些眼光前瞻的同事，開啟了我新的工作視野，才會有這份工作該如何繼續下去的轉折。慶興的是在頭一年就大幅修正不良的開發習慣，並養成吸收、內化良好習慣、提昇效率知識的節奏。

若沒有將工作體驗由糟糕的循環轉向為正向的循環，也許現在我已經不在這個行業裡。稍為再年長些有了不同的體悟，重新分析整件事情總結來說是「健康管理」。一份職業的工作生涯如同一個人的能活到幾歲的問題，當阻止你工作的因素多超過一個門檻，你就再也跨不過去。因此，我們得用健康管理來想這件事。

如同生活中用什麼、吃什麼、吸收哪些保健知識，提前預防自己某些疾病一般，只要還在線上的工作者也需要注意這些。像最近有一篇討論「[心得] 眼睛快瞎了，才肯給大螢幕有什麼用」，作者有提到公司未配發適當品質的螢幕供開發者使用，也不允許員工自行攜帶。這樣 NG 的工作環境，應儘早逃之夭夭才是。除了自身的工作能力之外，還得注意工作環境是否正在加速「工作餘命」的耗盡。

工作環境理的文化與配備多在你選擇公司的那一個決定好了，這也是健康管理的第一要素。因為在「公司」這個框架下能改變的事物是有限的，另外還有「部門」或「團隊」的框架是難以突破的，除非搶當領頭羊的位置，或任務性領導的地位。不然多數的時間是處理相互配合的狀態。這得呼應前面「轉折」對比式的經驗，你已經知道有些方法確實能改善目前的工作品質（速度、準度），但苦於沒有人願意改變這就會若入「[心情] 前輩拒絕導入任何其他工具」困境。

要扭轉惡性循環需具備某些條件：

1. 運氣（有老闆貴人、上司貴人、同事貴人）
2. 眼光（知識）
3. 信譽（戰功）

可遇不可求的運氣就甭提了，多花點時間在能自己掌握的眼光培養上，吸收些能讓自己工作效率提昇的方法論，學習些能增進開發品質的硬知識，再透過前二項以戰養戰增加自己的信譽。

知識是絕對重要的，因為它需要的運氣成份最低，主控權多數在自己手中。在早些年大家還不太注重單元測試，那時候開發要品質就靠個人天賦與蠻力。有些人能在腦中先寫好大致的程式，只差「打字」的工作。有些人做不太到，只能靠著把訊息印出來，在 console 內來回比對著。這麼做絕對有害健康，特別是眼睛。因為有時問題卡很久，得從大量的 print 訊息內找出一些微小的差異，進行程式的調整，反覆重複這樣的動作。沒有效率的工作方法，讓我們的施作速度緩慢，並大大延長了工作的耗時。

如果是有「測試」的情況呢？跑個「測試工具」看一下是紅燈、綠燈，就可以知道問題在哪兒，並同為了讓程式能方便地測試，每個處理邏輯的相依關係會儘可能減少，閱讀到的程式碼也會較為單純。程式的進入點不同是某一個大區塊下，再一一設中斷點去攔截，而是由 test method 單獨進入一小部分邏輯有問題的程式。問題變小了，需要理解的範圍也縮小，可以合理期望耗時減少，伴隨著用眼睛死盯著螢幕的時間也少了，能減少許多杯具發生。

人生還長著，得多方面思考怎麼讓自己健康地工作，儘可能讓工作的效率、成就感、心情都顧得到。個人的心得是：用知識換得手藝、用手藝換得戰績、用好戰績換得好工作（內容或著新公司）。各位辛勤的工作者，往正向循環前進吧。