引言

逐渐发现很多的概念和想法在初学时感觉理所应当，并且视为方法论和必须关注的东西，但实际的开发过程中其实是错误的。比如写出高效率的代码，这是一个正确但是十分浅显的感受，为什么这么说是因为凡事都有代价的，在编程过程中，任何决定或者每一行代码后面都可以带一个问题，那就是“代价是什么？”。所以为什么说这种感受浅显，因为在初期我很难关注到代价是什么，甚至觉得这是一种标准答案，那么自然就认为就应该这么做。或许未来ai的发展能告诉其他人，当前情况下最优的代码是什么，但是现阶段，代码的落地实现就是没有标准答案的。

基于此，在写代码的过程中，摆在第一位的应该是如何完成需求，而不是如何写出最优的代码，也就是说，应该先保证代码的可用性，然后再考虑如何优化代码，而不是一开始就追求最优的代码。

反直觉

类似的概念还有很多，我开始认识到过去接触的一些明显正确和错误的结论其实大多是狭隘的。而真正开发时的经验往往是反直觉的。

比如：代码能跑就行。这样的调侃第一眼看的时候肯定是觉得搞笑并且不应该的。但对于业务代码能做到这一步就足够了，因为本身就算一次性代码（项目与项目之间难以复用）。但是，对于一些底层代码，这些代码是必须追求稳定的，因为它们是基础，是支撑上层代码的，如果这些代码写的不好，那么上层代码写的再好，最终的意义也是不大。对于上层的业务代码，可读性应该是第一位的，甚至可以为此使用一些重复运行的笨方法，这也是反直觉的。

但是同时，一次性代码与一次性代码也不能一概而论，总结就是写更通用的代码而不是写更高效的代码。

完成永远比怎么完成重要

学生思维容易让人有标准答案的写法，但前面也提到目前的阶段，甚至未来也不会有标准化的项目解决方案，只有相对较差和相对较好的解决方案，所以，对于代码，应该追求的是完成，而不是怎么更好的完成。代码洁癖和完美主义反而是一种绊脚石。

软件开发的侧重点应该如何高效稳定的实现而不是去追求更好的实现，这反而是一种脱离现实的自我感动。

按计划推进项目

在项目开发中，应该按照计划推进。对于已完成的代码，可优化的点肯定是非常多的，在平时的开发中必然会暴露之前的代码不合理的地方，但是这时候依然需要评估修改这段代码的成本，再决定是否和当前的开发任务一起解决。更合适的做法是记录下这个问题，只要不是完全无法实现就顺着之前的代码实现，而到后期再集中解决。

会出现这种问题，相信每个开发者都知道思路上一个微小的偏差会随着开发过程而与预期越差越大，所以看到问题立即修改是理所当然。但是更深层次的问题是，现实的开发环境中，这样的问题数不胜数，适应这些偏差，控制后续代码与预期之间的差距，才是更符合现实的做法。

这事实上也是一个反直觉的经验。

现代计算机性能

最后一点，现代的计算机性能基本上是远远超出的大部分软件的需求的（客户端层面，即使是服务端，优化服务器配置也比优化代码更有性价比），大部分优化的行为基本上是出现在图形，表现，资源管理的部分而不是代码的运行效率。对于cpu的计算部分，只需要关注一些显眼的敏感位置即可。

比如对于界面的显示，与其一个数据一个状态的对应，不如在状态变化时，直接将数据全部更新，这样能减少很多不必要的代码，并且有更高的可读性。