Q&A加餐丨关于代码质量，你关心的那些事儿

第二个问题个人认为目标还是——经济 关于第二个问题，个人认为可能不能算是鱼和熊掌，可能更偏向于鱼和鱼竿。 一面是很多鱼，而另一面是一根鱼竿。二选一。 另外效率这个词，个人认为不恰当。效率是保障质量的前提下更高的产出。个人把这个理念替换为速度。 速度质量二选一。理想化肯定是质量。但是实际上还要参考实际情况。 类似于我们公司的团队，碰到这样的项目，明天就要求能看到效果。都来不及做详细设计，直接把以前的项目拿来改一改调试一下就拿去演示了。然后后续再进行优化调试完善。 这种硬环境下，不是不保障。而是无暇保障。 另一种情况，是有些功能模块，重要性不是很高，甚至根本不会有人用。只是个凑数投标的模块，但是这个模块测试以及优化的话可能很复杂。这时候，去花费大量时间精力在上面明显是不合适的。就假设，这个模块定价1000，但是为了这个模块的测试优化就花了800的成本，公司是不愿意为你的高质量代码买账的。 再举个反例。某模块追求速度开发。两天做完，节约了一天代码优化以及测试的步骤。但是未来的某天，发现这里有个坑。因为代码很久没有看过。导致这个坑难以找到问题所在，最后导致功能模块几乎重写。这里就是不应该因为速度舍弃质量的例子。 综上所述，个人认为，取舍的终极目标。还是老师之前说到的——经济 但是达到这个，并不容易。不仅仅是编写高质量代码的习惯与能力。还有不可或缺的经验，以至于可以灵活取舍。 但是——我们至少要有高质量编码的能力与基础。这样，在你有经验的时候才可以做到灵活的取舍。

最近接手一个质量不高的JAVA工程，读代码过程中 摸索出一个经验——用eclipse的bookmark功能为代码创建索引，现实世界的代码库 大多数像是没有索引的图书馆，运气好的你遇到有文档的项目 也不过是残缺的过期的和错误的引索。 所以需要你去重建准确的索引，eclipse的bookmark用好了 可以达到这个目的。

作为团队负责人，以前推行过upsource作为代码审查工具，这工具和idea结合起来，非常好用。结果怎么样呢，发现工具是次要的，项目各种赶，各种应标废标，各种演示项目。能谈下的项目经过商务的一再拖延最后留给研发的时间少的可怜，结果就是导致低效的加班赶进度，代码都不忍直视，怕小心脏受不了。理想很丰满，现实很骨感，对于主要业务是短期外包的公司来说，只希望用廉价劳动力快速交差。

老师讲得很好，我觉得很多人跟我一样，就因为见识不够，不知道如何去编写高质量的代码。老师可以提供一些实践性的项目或者资源，供大家学习、操作。

广博精深，做好取舍。大处着眼，细处着手；质量从过程抓起，从细节抓起，做好质量把控；同时注重反馈总结。方向对了，过程把握好了，结果不会太坏。

是否可以通过调用链路来帮助我们从整体去认识类与类、方法与方法之间的关系，然后再去“剥洋葱”？

从编写，测试，交付，使用的大视角拆解效率，结论是质与量两个变量，质跟效率相关性更高，又一次证明了慢慢做会更快

打卡

老师您好，质量高的代码是否意味着使用恰当的设计模式？

养肥了 可以开始看了