有一种情怀只属于程序员

 我是一个程序员，一个很普通的程序员。还记得2014年的8月份，我开始学习代码整洁之道和重构思想。说到这里，不得不提起我的师傅，一个变量命名让我改N次的资深程序员。那时候，刚刚步入工作，对师傅存在着很强的敬畏心，对于其所教的东西，总是紧记于心，生怕忘掉。就是因为这个，不知不觉中，慢慢的养成了我写代码良好的习惯。之后，我就有了一种情怀，喜欢在适当的时间对我的代码进行回归，重构。我总相信，适当时机的一支预防针，比的过生病之后的9针。我记得有一句话是这样说的：小处诚实非小事。”以小见大，细节决定成败，神在细节之中。

2015年1月21号我来到了北京，开始从事一份新的工作。这份工作不同以往，它的特殊之处在于”需求变更速度快，开发周期短，迭代速度快”。一个月发两个版本已经变得很平常，一年来框架主体变更高达到三次，我发现我的代码情怀和高速的迭代起了一点冲突。在极短的时间，写出漂亮的代码，成了我的追求，在代码上我力争追求完美。可是我发现我经常会面临一种选择。A。简单的罗列代码完成功能，优点是速度快，缺点是可读性低。B.考虑未来扩展，代码整洁，完成共功能，优点，代码漂亮，可维护高，扩展强，潜在风险小，缺点：花费时间长。如果工期是死的，那么就需要程序员花费自己的休息时间，这时候不禁就要反思了，有多少人愿意这么做。

这一年来，我发现几乎每个程序员都曾面临着这样的选择题。也有人想出了折中方案C：先快速的写完，有时间在优化。其实，我们知道这是自己骗自己。一来：项目迭代速度快，没有所谓的空闲时间。二来：因快速的迭代，没有及时的纠正错误，只能越来越挫，当回头已经不可能了。三来：人的懒惰和拖延心理。C的方案不同于上面说的对代码及时回归，因为代码开始就是简单的罗列。一旦重构，面临的风险太大了。简单举个列子，楼地基没有夯实，此时楼已经盖完了，回过头，工人的修葺，所用的花费和面临的风险太大了。

小处诚实非小事，以小见大，细节决定成败，神在细节之中。这是属于我的代码情怀。