好代码的用处 实际上本书建立在一个相当不可靠的前提之上：好的代码是有意义的。我见过太多丑陋的代码给他们的主人赚着大把钞票，所以在我看来，软件要取得商业成功或者广泛使用，“好的代码质量”既不必要也不充分。即使如此，我仍然相信，尽管代码质量不能保证美好的未来，他仍然有其意义：有了质量良好的代码以后，业务需求能够被充满信心的开发和交付，软件用户能够及时调整方向以便应对机遇和竞争，开发团队能够再挑战和挫折面前保持高昂的斗志。总而言之，比起质量低劣，错误重重的代码，好的代码更有可能帮助用户取得业务上的成功。
以上文字摘抄于《实现模式》的前言，距离本书翻译已经时隔 10 年了，但是这本书仍旧有着很大的价值。同时对于上述言论，我并不持否认意见。但是我认为，坏代码比好代码更加的费财(嗯，没打错，我确定)。对于相同的业务需求，坏代码需要投入的精力，时间更多，产出反而会更少。同时根据破窗理论( 此理论认为环境中的不良现象如果被放任存在，会诱使人们仿效，甚至变本加厉 )，坏代码会产生更坏的代码。这是一个恶性循环，如果不加以控制，完成需求的时间会慢慢失去控制。需要完成需求的人也会失落离开。
也就是说，好代码可以实现多赢，能够让用户爽，能够让老板爽，能够让开发者爽。总之，大家爽才是真的爽。
怎么写出好代码 少即使多利用开源出来的设计与代码来减轻来自于业务线的时间压力。
The best way to write secure and reliable applications. Write nothing; deploy nowhere.以上取自 github 上最火的项目之一 nocode。懒惰是程序员的美德之一。所以学习业务，理解业务，拒绝不必要的需求也是一个程序员的必修功课。详情可以参考如何杜绝一句话需求？ 这一篇 blog，当然，在大部分场景下，我们是不具备对需求说不的能力与权力的，但是无论如何，深度的理解业务，对客户有同理心是对程序员的更高要求。解决问题才是一个程序员需要做的事情。能够理解好题意才能解决问题。
对于软件开发而言，时间一定是最宝贵，最有价值的资源。相应的，尽量把时间耗费在解决新的问题，而不是对已经存在确切解决方案的问题老调重弹。所以，尽量不要自己写代码，而是借用别人的设计与实现。而在事实上，你也很难在极短的时间压力下设计并完成比开源更加合适的代码。
当然，开源作者一定是想让他的产品有更多的受众，所以从设计上而言，会采用较为通用的设计，如果你的需求较为特殊并且你觉得不能说服作者帮你“免费打工”(或者作者拒绝了)，那么你也只需要在特定之处进行包装与改写,但是要比完全重写要简单太多了。
当然，调研新的技术方案并且使用到项目中是一种能力，但是千万不要因为一个小功能添加一个非常大的项目。
笔者在之前就遇到过其他小伙伴因为无法使用数字四舍五入。说 fixed 方法有问题而使用 math.js 的小伙伴。
(11.545).toFixed(2) // "11.54"如果想要了解 fixed 方法为何有问题的，可以参考 为什么(2.55).toFixed(1)等于2.5？ 作者以 v8 源码来解释为何会有这样的问题，以及提供了部分修正 fixed 的方案。
事实上如果没有很大的精度需求，前端完完全全利用一个函数便可以解决的问题，完全不需要复杂的math 这种高精度库。
function round(number, precision) { return Math.round(+number + \'e\' + precision) / Math.pow(10, precision); }当然，也有小伙伴来找我询问大量数据的表格优化，我第一反应就是 React Infinite 或者 vue-infinite-scroll 此类解决方案。但是对方能够多提供一些信息包括上下文，采用的技术栈，当前数据量大小，未来可能需要达到的大小，当前表格是否需要修改等。得到了这些信息，结合业务来看，相比于增加一个库，是否如下方式更为便捷与快速。
// 因为 vue 模型的原因，使用 Object.freeze 性能可以有很大增益 this.xxx = Object.freeze(xxx);随着堆积业务，代码的增长。管理复杂度的成本与日俱增，把依赖降低。 利用开源代码使得任务更容易实现。时间就是成本。关键是让收益可以最大化。
学习更多是为了做的更少。
统一不同的人由于编码经验和编码偏好不同，项目中同一个功能的实现代码可能千差万别。但是如果不加以约束，让每一个人都按照自己的偏好写自己的模块，恐怕就会变成灾难。