day 27 - 持续改善, 持续优化, 持续重构

今天的你和去年的你写出来的程序会是一样的吗？

程序语言会不断地更新迭代,不断地有新的功能或套件出现, 那我们自己写出来的程序码是否也应该与时俱进?
曾经有前辈告诉我, 程序至少要改过三遍才是比较完整的。 每个阶段都要回头看看之前写的程序, 一遍遍去审视过往的思维, 持续改善, 程序码才会持续的成熟。

为什麽要持续小范围的改善与优化?
首先是越大型的专案在初步设计跟规划阶段不确定因素会越多, 长期的专案可能到上线会历时一年以上, 最终交付的成品大概只有40~50%是当初设计的样子。那当初的设计是否有足够的弹性可以支持後来的发展呢？
专案最害怕看到的就是叠床架屋, 东补一点、西补一点, 最终虽然看起来是专案想要的样子, 但内部却可能债台高筑, 技术债消耗的不仅仅是维护成本, 也可能成为之後拖住团队前行的负担, 最终最糟糕的情况是动不了又拿不掉。持续地回头去小范围优化跟重构就像是在帮专案定期检康检查, 及早发现, 及早治疗。

再来, 随着时间推进收到各种回馈之後, 我们可以更全面地看到专案的全貌。开发的当下或许有时程压力、需求接踵而至等等各种状况, 当时所采行的可能不是最好的方式, 等到一段时间後回头看才发现需求之间息息相关, 可以有更多整合的空间、或是哪段code可以再分工得更乾净更好阅读。
每隔一段时间回头检视过往的程序码, 感觉会像是站在比当初更高一点的角度俯瞰全局, 自己对自己code review, 哪怕是加个注解也是帮助未来读程序码的人可以更好理解, 自己写出来的孩子要自己教。

优化跟重构听到的时候都会觉得是个大工程, 所以不要等到变成大工程的时候才开始, 每隔一段时间持续的去做就是积少成多。