关于代码的是不是麻烦的问题

刚入行的时候写代码很随意，基本就是能用就行，毕竟没有那么多可选的方案支撑，后俩发现只是实现要求慢慢维护起来是非常痛苦的事情，就慢慢的开始追求代码洁癖了，希望代码可以写的很简洁很好维护，少一些hard code，多一些配置的问题，并以此为荣，可是现实总是和理想有冲突的，有的时候就是会有一些需求，他们不难，但是会破坏代码的协调，会产生很多的hard code，会影响代码的可读性，会产生很多的if else，每当这个时候我就会很生气，很痛苦，感觉这一切是为什么，甚至陷入自我怀疑，是不是我的能力不够，所以实现这些需求的时候会产生那么多的hard code。

可是慢慢的经过我的分析，这些并不是个例，即使是一些大厂的开源项目里也是会有很多这样的hard code的，归根结底代码是为了解决现实的问题的，但是现实的问题是复杂的，那么反应到代码上就肯定会是复杂的，会是麻烦的，会有很多hard code的，那么多的框架、库他们解决的问题更通用，他们就没有这方面的困扰吗，我现实是肯定有的，因为他们要解决的问题更通用，那么就要考虑的更加全面，所以这样的问题解决起来就更有可能有别的hard code方案，那些作者是相对而言能力更加好的，所以他们的解决方法也相对更优雅一点，技术至上是从程序员的角度来想的，但是项目和产品不是这样想的，他们想的是如何把产品的功能做起来，如果交付用户，如何提高用户体验，如何把钱挣回来。

所以视角的不同导致了想法的不同，如果一心只是在代码上，可能技术会成长，但是不一定能解决现实的问题，而一个产品最终的评价是用户使用的体验，以及是否有人愿意买单，那么我们就必须把这个问题提到第一问——那就是讨好用户，尤其是付费用户，只有这样才能实现价值。如果一个作品代码非常好，但是不实用那也只是屠龙之技，看起来厉害但是没有任何实际价值的东西。

所以不能因为需求导致代码不那么好看而着急，而是用代码是适应需求，在最大的能力范围内阻止代码走向混沌，延长代码的寿命。而不是抱怨，因为用户不会在乎代码难不难，好不好看，他们只在乎使用。遇到任何事情先考虑使用性，在考虑可行性，最后考虑代码，只要能实现的可以增强用户体验的，那么就要努力去做。