当我写代码时，应该思考什么

毕业至今已经工作一年多了，随着代码量的提高与工作中不断地应对需求的调整，我才开始反思这些代码出了什么问题让他变得难以拓展和维护。

重点在于设计而非实现

过去我一直觉得自己是具有设计能力的，其实不然，到现在我才意识到之前对待问题的角度依旧太过片面与短视。片面是指我在接到一个需求时所进行的设计依然只是用代码去描述这个需求，这是没问题，理清其中的逻辑关系是重要的，但对于一些整体的设计实际上是没有考虑到的，甚至意识不到我的考虑忽视了整体，举个例子来说，最初接到三消的的玩法需求时，处理方块的下落选择直接通过算法计算得到中间数据与最终数据，最后交由界面实现过度动画，这样的方式固然的效率高些的，但也意味这他失去了拓展性，如果中间数据难以描述方块的运动过程，这个需求就会变得很难推进。这同样也能体现过去编程的短视，追求最快的实现需求而没有进一步的深入分析。这让我思考设计时到底是在设计什么。
首先，设计肯定高与实现层面的，对于具体的实现过程只要提供支持即可，基于这个角度，那么设计层面应该实现的更抽象的规则，同样以三消举例，我之前的写法将交互的过程通过一个中间数据来实现具体的表现，这是基于过程，对游戏基本规则的描述。那么实际上的规则呢，对于三消游戏来说，这条规则应该是当格子的下方为空，并且没有到达底部时，格子会往下前进一步与水平或竖直方向连续出现三个以上的色块时，这些色块会被消除，对比我过去的实现方法，这两天规则当然需要被准确的实现，但他是被封闭在算法的计算中的，对于外部来说，只需要得到中间状态与最终状态就能实现基本的交互，这是可行的，但在现在看来，主次有些颠倒。

总结

• 设计应该在需求实现之前并且尽可能的脱离需求
• 设计应该设计规则而非具体过程

当然，这只是一次大概的思考，实际的需求也是多变的，编程实际上也很难总结出一套方法论来应对所有的场景，只是作为感悟，在之后的开发中多加注意，多思考更好的实现方法来保障可程序的稳定与拓展。

另一个问题： 在实现过程中代码的效率重要还是可读性重要

这个问题也是我在反思过程中一直困扰我的点，毫无疑问效率和可读性都是重要的，但在实际编程中总是难找到其中的平衡。如果一定要做出一个解释，只能是根据实际的需求进行取舍，在性能不敏感的场景尽可能的使代码易读，在对一些需要实时处理或者面对大量数据的场景，尽量的切分实现过程并完善备注来保证代码可读性的同时保证代码的效率。最后，时刻需要注意的是对函数块的拆封，避免一个脚本中杂糅过多功能。