关于代码的不完美性

    从毕业到工作已经大概5年时间了，在这期间一直做着写代码的工作，老老实实写代码，安安分分领薪水，今天来说一下在这不短的时间里发现的一些问题，在我身边工作的小伙伴们，特别是对自己的技术水平有要求的小伙伴，在新接手一个老项目或者自己有比较多的时间完成一个比较大的迭代的时候，总会有那么一种冲动去重构或者说重写某一模块或者这个项目。当然我不是说重构这件事情做的不对，而是想和大家聊一聊关于代码的不完美性。

    对自己有要求的程序员，总是希望从自己的手里写出来的代码是完美的，可是即使上机跑了很多遍，甚至没有crash,没有warning的情况过段时间再看自己的代码也会有冲动删掉重写，为什么呢？我认为是代码是生来就不完美的，最好最完美的代码永远是明天写出来的，代码的不完美性就像人一样，人生来就不是一个完美的生物，代码也是一样，代码的不完美性一方面体现在语言本身的缺陷，一方面也体现在一个问题定义的的无穷尽性上。

    举一个简单的例子来说，在OC的世界里写一个hello world,NSLog("hello world"),这样的确从表象上来看是满足了我们的需求，而我们很大一部分一部分程序员在现实中解决需求也是这样的，现在我们再来考虑考虑其他问题，比如我需要在测试环境上打出hello world，生产环境上确不需要，在测试环境上还需要知道这个hello world出现在哪个文件，哪一行，什么时间log的，有人会说很简单直接写一个宏定义，用DEBUG的预编译的标识来区别测试环境，生产环境。这很好，但是后面我们又需要支持多语言,这个时候我们又需要在log上增加location strings文件，这个时候生产环境又有需要打日志上传的需求，这个时候就需要把输出流定向到沙盒文件上，然后写上定时文件上传的代码，总之对一个问题的定义会严重影响一个问题的解决方案，这一点在用代码来实现需求的时候特别明显，而一个好的程序员总是对着问题的定义考虑的比较深入，对程序健壮性，扩展性，可测试性等都会做充分的考虑。而对问题的定义考虑越是深入，越会反应出当前解决方案的不完美。

    那我们在工作中应该怎么正确的对待代码的不完美呢，首先我们要树立个观念，我们不是艺术家，一行代码写出来以后不是供人瞻仰膜拜，然后升值的，一行代码写出来是为了在未来某个合适的时机删掉它，所以我在工作中喜欢一个叫刚刚好的程序员，刚刚好的程序员写代码不是刚刚好能够跑起来，完成业务需求，而是刚刚好能覆盖到未来2-3个版本的迭代和修改的可能性，刚刚好的程序员写出来的代码不是完美的，但是能够在未来2-3个版本的变化中刚刚好的应对各种需求的变化，刚刚好的程序员能够正视代码的不完美性，在项目需要的时候可能会留下一部分比较丑陋的代码，但是在项目演进的过程中又能够在恰当的世纪刚刚好改掉他，所以，我的程序员伙伴们，在你们的程序员生涯中，如果遇到了一些比较难堪的代码，特别是你认为很厉害的程序员留下的，不妨了解下程序背后的故事。