今天的你和去年的你寫出來的程式會是一樣的嗎？

程式語言會不斷地更新迭代,不斷地有新的功能或套件出現, 那我們自己寫出來的程式碼是否也應該與時俱進?
曾經有前輩告訴我, 程式至少要改過三遍才是比較完整的。 每個階段都要回頭看看之前寫的程式, 一遍遍去審視過往的思維, 持續改善, 程式碼才會持續的成熟。

為什麼要持續小範圍的改善與優化?
首先是越大型的專案在初步設計跟規劃階段不確定因素會越多, 長期的專案可能到上線會歷時一年以上, 最終交付的成品大概只有40~50%是當初設計的樣子。那當初的設計是否有足夠的彈性可以支持後來的發展呢？
專案最害怕看到的就是疊床架屋, 東補一點、西補一點, 最終雖然看起來是專案想要的樣子, 但內部卻可能債台高築, 技術債消耗的不僅僅是維護成本, 也可能成為之後拖住團隊前行的負擔, 最終最糟糕的情況是動不了又拿不掉。持續地回頭去小範圍優化跟重構就像是在幫專案定期檢康檢查, 及早發現, 及早治療。

再來, 隨著時間推進收到各種回饋之後, 我們可以更全面地看到專案的全貌。開發的當下或許有時程壓力、需求接踵而至等等各種狀況, 當時所採行的可能不是最好的方式, 等到一段時間後回頭看才發現需求之間息息相關, 可以有更多整合的空間、或是哪段code可以再分工得更乾淨更好閱讀。
每隔一段時間回頭檢視過往的程式碼, 感覺會像是站在比當初更高一點的角度俯瞰全局, 自己對自己code review, 哪怕是加個註解也是幫助未來讀程式碼的人可以更好理解, 自己寫出來的孩子要自己教。

優化跟重構聽到的時候都會覺得是個大工程, 所以不要等到變成大工程的時候才開始, 每隔一段時間持續的去做就是積少成多。