人生来就不完美的生物，代码的不完美性就像人一样

毕业和工作已经有5年了。这段时间一直在做代码写工作，老老实实写代码，挣着自己的薪水。今天，我就来说说我在这短短的时间里发现了什么。有些问题，在我身边工作的朋友，尤其是对自己的技术水平有要求的朋友，当他们接手一个老项目或者有更多时间完成一个更大的迭代时，总会有问题。然后是重构或重写模块或项目的冲动。当然，我不是说重构是错的，只是想和大家谈谈代码的不完美。

对自己有要求的程序员总是希望自己写的代码是完美的，但即使在电脑上运行多次，也没有出现崩溃的情况。代码也会有删改的冲动，为什么？我认为代码天生不完美。最好和最完美的代码总是在明天写出来。代码的不完美就像一个人。人类不是天生的完美生物。代码是一样的。完美一方面体现在语言本身的缺陷上，另一方面体现在问题定义的无穷无尽上。

举个简单的例子，在OC世界里写一个hello world，NSLog("hello world")，从外观上确实满足了我们的需求，而我们的大部分程序员在解决实际需求时也是如此现在让我们考虑其他问题。比如我需要在测试环境中输入hello world，而在生产环境中不需要。在测试环境下，我还需要知道这个hello world出现在哪个文件中，在哪一行，什么时候登录，有人会说直接写宏定义很简单，用DEBUG的预编译标识来区分来自生产环境的测试环境。这个很好，但是我们后面需要支持多种语言。这时候，我们需要在日志中添加文件。此时生产环境需要上传日志。这时，我们需要将输出流定向到沙箱文件。 ，然后编写常规文件上传的代码。总之，问题的定义会严重影响问题的解决。这在使用代码实现需求时尤其明显，一个好的程序员总是面临这个问题。该定义被认为是深入的，并将充分考虑程序的健壮性、可扩展性和可测试性。而且你对问题的定义思考得越深入，就越会反映出当前解决方案的不完善。

那我们应该如何正确处理工作中代码的不完美呢？首先，我们要树立一个观念，我们不是艺术家。一行代码写完后完美世界经典版代码，不是让人佩服崇拜，然后是欣赏。写一行代码的时候，是为了以后在合适的时候删掉，所以我喜欢一个叫“恰到好处”的程序员。只写代码的程序员，不仅能运行和完成业务需求完美世界经典版代码，还刚好能覆盖到接下来2-3个版本的迭代和修改的可能性，那些刚刚好的程序员写的代码并不是完美，但他们可以在接下来的2-3个版本的变化中响应各种需求的变化。恰到好处的程序员可以正视代码的不完美，在项目需要的时候可能会留下一部分丑陋的代码，但在项目演进的过程中，恰到好处的世纪就可以改变，所以，亲爱的程序员，如果你在程序员的职业生涯中遇到了一些尴尬的代码，尤其是那些你认为很厉害的程序员留下的代码，不妨了解一下程序背后的故事。