完结心得

第三年参加铁人赛，心态上比起前两年稳定许多。即使如此，过程中仍然有些遗憾，可以写得更好但没有达成。

跟往年一样，列出几点个人的体悟：

花费的时间超出预期

大约今年农历新年期间就决定今年的题目是 Design Pattern，接着陆陆续续把书籍买好（物件导向设计模式、深入浅出设计模式、大话设计模式），没有压力地随意阅读，到了开赛前两个月开始构思要怎麽写，开赛前完成四篇，这四篇都是前置作业，不是模式的介绍。开赛第一天，才完成第一篇模式介绍文（Simple Factory Method），同时往後二十三篇模式介绍文的格式也定义完成。

这边提一下模式介绍文要如何准备：

1. 翻书（以大话设计模式为主）。
2. 上网看其他人怎麽解释。
3. 试着用自己的话讲出该模式的重点（目的、说明、总结）。
4. 举一反三，制作模式的范例程序码（UML 图、用 Java 与 JavaScript 实作范例程序码）。

这四点中，需要最多时间完成的绝对是最後一点，因为举一反三等同要教导其他人如何学习，那势必自己必须完全学会，没有混水摸鱼的空间，如果当天忽然无法理解模式的定义，那就会消耗库存，这三十天还真的让我遇上这件事（谢谢你，Flyweight 模式）。到了第十八天就变成弹尽粮绝的情况，必须当天写好文章，使我的压力开始变大，每天都想要逼自己快一点，但是越逼反而越没有用，总是拖拖拉拉到最後三、四小时才愿意开始动手写。

刚好前阵子在阅读专案管理的书籍，提到专案在截止日之前，需要多次的审查，好确保专案的进度在轨道上，如果没有任何审查，到了截止日才见真章，肯定会影响专案的品质。

说来好笑，我在第二十几天时就再问自己「怎麽不早点开始写？」

这是一个深刻的教训，事情（尤其是完成时间很长的计画）的发展绝对不会如人所愿。

产出的内容没有达到预期

这要搭配上一点，因为时间的压力：

• 放弃比较模式优缺点的段落。
• 放弃更详尽实用的范例程序码，只能写出为了符合模式定义的内容。

收获

上面两点是个人的遗憾，而事情永远是一体两面，收获肯定有。

最大的收获莫过於熟悉「弹性」这名词，如何让程序码拥有面对变动时也不会造成开发工作浩劫的能耐？经过这三十天的训练，渐渐地能感受出「这样写会给未来的自己找麻烦」的想法。

具体表现在这阵子的工作上，花费更多的时间在思考，为了达到新的开发需求：

• 那采用方法 A 会有什麽好处？什麽坏处？
• 采用方法 B 呢？
• 还是我被困在现有的架构内，尝试往更上一层来思考呢？

对於开发资历要满三年的我来说，引用套件、思考演算法等快速编写程序码的部分，已经不再是个大挑战。因此乐见自己在动手开始写之前，花费更多的时间思考「怎麽写？」

能够往架构的方向前进，对於此发展感到十分满意。

总结

还记得刚开始工作时，朋友就提醒我：

只会听着主管的建议，要你写 A 就写 A，岂不是跟机器人没两样？
有机会的话，试着让自己思考架构的层面，要拥有「绘制蓝图」的能力。
不再局限於交代的事项，而是聚焦在更广的事情上，如此一来，才算是一个好的开发人员。

对於菜鸟的我来说，这段话深深烙印在我的脑海中！同时，也是连续三年参加铁人赛的动力，让自己有更多的学习、成长。

藉由完成三十篇文章，让自己又成长一些，拥有更多的能力。

我感到十分开心。

学习资源

书籍推荐（论阅读的优先顺序）：

• 大话设计模式
• 深入浅出设计模式
• 物件导向设计模式
  • 这本圣经内容肯定最齐全，但是缺点是不容易理解，在购入前可以去图书馆翻越，了解自己有能耐吸收。

网站推荐：

• Refactoring Guru
  • 这网站在这三十天帮助我超级多，因为大话设计模式的范例过於简单，我一度卡在如何想复杂的范例程序码，幸好有这网站的帮忙，藉由他们的范例程序码，使我能够举一反三。