「程式不能寫一輩子？」。 是的，程式無法寫一輩子，因為你的肝會老 在成為產出程式並賴以維生的工作者之前，我的程式開發總是很天馬行空的。 想法跳到哪，程式就寫到那。連帶著，我們 bug 也是這麼的發散。 那是一段寫程式等於寫 bug 的惡夢！ 在那地獄般的回憶，能用來說嘴的只剩不眠不休連續瘋狂 coding 與 debug 的時數。 說實在的，那只是用一個浪費生命的偽成就，來掩飾一再地犯錯與無能。 會基本語法，稍懂些邏輯確實可以寫出程式。 但是不佳的設計、不良的結構、重複的 Copy & Paste。 程式碼一整份，一整份地複製，到底哪一個版本才是對的， 大概只能靠運氣了。 這一切就像在開始 coding 的同時， 今日流程被標上了反覆記號。 重複著相似的邏輯，相仿的錯誤，相同的疲勞感。 心理的壓力，隨著進逼的死線更加無法承受。 那時的我，只寫得出自己想要的東西。但無法正確地掌握客戶想要的需求。 還是學生的我，是個非常不成熟的程式設計師。 經驗幾次爆肝的接案歷程，對自己的能力感到相當的懷疑。 並且看著壇論對程式設計師生涯的討論， 也相信吃這行飯需要新鮮的肝，而寫 bug 是個常態。 但真的是這樣嗎？ 不，程式可以寫一輩子，因為你將不斷地重構你的工作方法。 我想每一份需要專業的職業都有著一群持續貢獻的工作者。 對軟體開發來說，其實我們擁有許多寶藏。有些知識是無法獨自領略的。 這得感謝過去曾與我一起工作過的前輩們， 透過 Pair Programming 的手法，快速被優良典範感染。 開啟了我對 XP 相關知識的接觸。 在那段不算長的時間，啟發了我對於下列知識的興趣： 1. 統一撰碼風格 2. 重構的使用 3. 單元測試 4. 版本控制系統 統一撰碼風格不單純是符合團隊的 coding style，這是團隊總體思考模式的同步。 像是一個類別，它會有個負責主要流程的 method， 但我們不在這個 method 內有任何條件判斷 (強烈地期望)。 它的內容是直敘的 method call 序列，就像平順地交辦一些事項。 而原本在直覺的實作方式，應該出條件判斷的地方， 可能只是在其他細節中的一個 if/else。或直接在多型的結構消耗掉了。 判斷出現地越少，程式結構就簡潔許多，也減少因寫作的失誤而產出的 bug。 有時無法直接寫出較少條件式的實作，透過重構技巧學習自我整理程式碼。 而重構技術包含的項目可深可淺，淺如替換變數名稱，提取程式碼成為函式。 深如結合設計模式，調整外部無法觸及的程式結構。 程式結構變換最要緊的是前後的邏輯保持一致，要確保邏輯正確性。 單元測試就是個不可缺少的技巧。 反覆地，撰寫測試、重構、再測試、再重構。 這些小技巧其實都環環相扣支持著我們，對於面對的程式碼產生良好的改變。 而給與我們無比信心的，那就是版本控系統。 寫亂了，再拿回原先的那一份，重來一次。 這麼友善的開發環境，您說軟體人悲哀得起來嗎？ 這是我想要分享的，是能以寫程式作為一輩子的工作的正反理由。 如果您總是讓自己處於險境，再強的意念都會被磨碎。 如果您試著讓自己處於友善的開發環境，就能獲得走下去的動力。 當然，您可以看作是我的樂觀宣言。 但不去經營友善的開發環境，怎麼能期待做這行一輩子呢？ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.231.48.59