Day 01: 缘由、大纲

缘由

大家好，我是维特，去年铁人赛介绍 用 JavaScript、Java、C 刷 Leet Code 、前年介绍 VS Code 的人。

去年写完的当下，「解脱」是第一时间的反应，事前没有妥善规划，导致每天的流程是：

• 一早起来阅读新的演算法、资料结构。
• 白天思考、吸收新知识、找适合的题目。
• 晚上回到家开始刷题。
• 找出最佳解之後转译成其他语言。
• 将以上内容转换成文字稿之後按下缴交钮，完成当天的进度。
• 预览明天的进度。

回忆起这段日子，往往觉得我干麻整自己，过度操劳让身体不健康一个月。

当然，事情永远都是一体两面，有坏处肯定也有好处。

经过这段高压特训後，在开发时会慎选资料结构、for 回圈的利用，尽可能让程序码拥有高效率；此外，还会多多注意有没有遗漏的变数，是不是有机会造成记忆体滥用。这些成长让我有更多的自信在软件开发上。

因此，参与铁人赛宛如身处在精神时光屋，只要认真面对自己挑选的题目、努力学习以及产出相关知识的文章，便可有所进步。

这次选择 Design Patterns 的原因在於，在资讯科学的环境内一定听过、公司经手的专案肯定有使用特定的 Pattern，甚至学习网路开发时一定会碰到的 MVC 其实算是一种 Pattern。不论在哪种情境，Pattern 无所不在。既然每天都会接触，哪不妨趁这三十天，好好学习、了解 Design Patterns 吧！

什麽是 Design Pattern

学习如何绘制设计蓝图，好解决不同情境下的问题，达成原先设下的目标。

这一年来，因为 LeetCode 提升撰写最佳解的能力，一旦有机会，我会写出效率优先但是「一长串」的程序码，同事多次提醒我，这会增加他们的阅读理解难度，不是每个人都能快速熟悉不是他负责专案内的程序码。

这件事给我不小的启发，追求最佳解是刷题时的唯真理，可是专案几乎是团队运作，增加讨论的门槛会让专案的进度受到拖延。因此，实务上追求效率不一定永远是最佳解。

多次跟同事讨论後，对方告诉我关键字：「耦合度」，从这个节点开始，慢慢找寻相关知识後了解到，Design Pattern 就是我目前缺乏的核心知识，，

我会怎麽写

本身不是大专院校资讯相关科系出身、从网页开发入门软件开发，工作经手的专案接触到 Java 与 C。

论语言的熟悉度：JavaScript > Java > C。

熟悉度是这次挑战最棘手的，在於 Design Patterns 是建立在物件导向程序设计（OOP）之上，适合使用具有 OOP 特性的语言学习。JavaScript 基本上不太具有完整的 OOP 特性（少了 Abstract Class 与 Interface），造成在学习 Design Patterns 上多多少少感到不相容。

这次撰写会交互使用 Java 与 JavaScript，力求把每个 Pattern 的前因後果交代清楚。

结语

回顾去年的第一篇的最後写道：

每一年都要帮自己的职涯制作该年度的代表作。平常不怎麽写 side project 的我，决定用今年的铁人赛当作是年度代表作。

今年我也抱持着相同的想法，努力付出，创作出不後悔的代表作！