恰如其分的代码

从业多年，也接触过java,c#,go,php,python,js等多种编程语言，每一种语言都能实现既定的业务逻辑，抛开底层运行原理来说，并没有丝毫的不同。
所以说代码之美应该超越边界之外来思考。一件事情的答案也许总是在更大的一个逻辑层面得到很好的解释。

好比买一张桌子，其实不单单应该考虑的座子的整体舒适度，用料。更应该搭配到整个房间的布局上。

很难说清楚一个代码片段的优秀与否。更应该讨论的是在整个服务乃至系统中的整体价值，是否做到了解耦（易修改，高度自治，不会有修改蔓延等问题），是否遵循设计原则（SOLID）做到了关注点分离（控制与逻辑业务的分离）。

有位文豪说得好：“看一个作家的水平，不是看他发表了多少文字，而要看他的废纸篓里扔掉了多少。” 我觉得同样的理论适用于编程。好的程序员，他们删掉的代码，比留下来的还要多很多。如果你看见一个人写了很多代码，却没有删掉多少，那他的代码一定有很多垃圾。— 王垠的博客

写到这里想起了《代码整洁之道》的一个片段

鲍勃进入模块。
他向下滚动到要修改的函数。
他停下来考虑可以做什么。
哦，他滚动到模块顶端，检查变量初始化。
现在他回到修改处，开始键入。
喔，他删掉了键入的内容。
他重新键入。
他又删除了！
他键入了一半什么东西，又删除掉。
他滚动到调用要修改函数的另一函数，看看是怎么调用的。
他回到修改处，重新键入刚才删掉的代码。
他停下来。
他再一次删掉代码！
他打开另一个窗口，查看别的子类，那是个负载函数吗？
…
复制代码

相信只要是工作过几个年头的程序员都有这样的经历，项目过程中花了大量的时间在阅读和理解系统代码的细节。良好的分离关注点，分层模块，就能极大的减少修改的担忧，也提升了代码的整洁性，为读者而写代码就能极大的提高后续的工作效率，即便那会使得编写过程更难。优秀的代码几乎都是不断演进提炼的，不可能一蹴而就。

物皆有其位，而后物尽归其位，不要陷入到思考的误区，书写糟糕的代码只会影响您的工作。走快的唯一方法是先走好。工程师就有义务去梳理其中的恰如其分，使得读者赏心悦目。

总结：
如果说代码的恰如其分我想那就是阅读代码的人能一目了然，无需花费很多时间分析其中的不当之处。并无多少自己的东西，只是恰如其分的使用了一些老的论点来聊一聊自己对于优秀的代码的理解。希望能对您有所启发。