关于代码设计的几点思考

关注公众号：xy的技术圈

这篇文章主要总结一下本身在平时编码中遇到一些问题的思考。不少时候，代码设计很难十全十美，咱们面对的每每是选择题，如何在多个选择之间权衡取舍，并非一件简单的事情。

性能与可读性

“性能”是一个优秀的程序员都会注意的点。在写代码的时候，咱们每每但愿本身可以以最优的性能写出知足需求的程序。可是有时候，一味的高性能可能会下降代码的可读性。

好比在数据库字段设计的时候，有一个“年份”的字段，咱们都知道年份通常都是4位数，因而咱们使用了SMALLINT来做为这个字段的类型。使用ORM映射到Java，就是short类型了。

熟悉Java语言的同窗应该知道，Java语言在设计数值的运算的时候，会隐式地把它转换为int类型，而int类型必需要显式地强转才能转成short，因此形成了在代码里有很是多的(short)强转，以下：

short year = repository.getYearById(id);
short nextYear = (short)(year + 1);
复制代码

这样的强转其实并无多大的意义，下降的可读性的同时，并无带来多大的性能提高。

因此咱们在写程序的时候，有时候须要在追求性能和代码可读性方面权衡，在可接受的性能下，尽可能让代码更加可读。

通用性与过分设计

若是有多个地方用到相同的逻辑，咱们能够考虑把它抽出去，封装成一个私有方法甚至是一个类。咱们称这段抽取后的代码具备“通用性”，也称为“复用性”。

你们或多或少都了解过一些设计模式，事实上许多设计模式解决的问题正是代码的“复用性”。代码的复用性很重要，但有时候可能也会带来复杂性的上升。尤为是在抽取了一些额外的类以后，你的代码就会多出不少xxBuilder, xxFactory, xxProxy之类的。更有甚者，直接是xxUtils, xxHelper等不明职责的类，里面许多杂乱的方法。

公共的方法和类带来的另外一个问题是，若是两个业务同时用了这一段代码，后来需求发生了更改，其中一个业务在这段代码里面的逻辑须要发生一些小的变化，那若是去改公共代码，就会影响另外一个业务。

因此在“通用性”和“复杂性”之间怎么权衡？答案就是“简单设计”，不要“过分设计”。

在写代码的时候，尽可能让代码简单，不为了复用性去抽取不少的方法和类，只为了可读性去作必要的重构。只有到了必要的时候才抽取公共的方法或类，好比多个业务确实用到了同一段复杂逻辑，且大几率不会发生更改。

代码是这样，接口亦是这样。不要由于考虑到“之后可能会用到”就去过分设计，到时候作到了那个功能再重构不迟。

至于具体怎样去实施？我认为没有一个明确的准则，须要多写代码，多思考，多了解业务，才能敏锐地判断是否须要抽取。

写多少测试？

笔者平时项目上都是遵循的TDD流程，因此写的测试还算比较多。在咱们项目上，尽可能是优先写单元测试，而后集成测试只写必要的happy-path，有些比较简单的类甚至能够不写集成测试，好比controller层。先写测试，再写实现，测试驱动出实现代码。

《重构》这本书里面讲到，写测试不该该是一个固定的，死板的开发流程，咱们写测试的时候，应该只写必要的测试，只写那些咱们没有十足的信心的代码的测试。

但这彷佛与TDD的“测试先行”的观点有些相违背。若是咱们先写测试，那怎么能知道咱们的实现代码长怎样呢，又怎么能知道咱们有没有十足的信心呢？

其实在实际的项目开发中，测试想要100%覆盖是十分困难的。尤为是在“白名单”这种状况下，咱们每每只能测出白名单内的参数是符合条件的，但不可能测完全部的白名单外的参数是不符合条件的。因此只能选一两个去测试。

有时候想要先写测试是十分困难的。好比咱们在实现的时候可能会依赖其它的类，因此咱们在测试的时候可能会去mock这个类，但在写实现代码的时候，发现这个类不合适，可能须要换成调用另外一个类。这个时候又回过头来改测试，就显得有些麻烦。因此有时候并不必定是彻底的测试先行，而是造成了一个环，测试-实现-重构。

总结

上面讲到的是笔者对平常开发中遇到的一些问题的思考。其实有时候也得要根据实际状况去考虑，在写代码的时候，须要考虑的东西不少，好比可读性、可维护性、可扩展性、性能、测试等等。

编程是一项工程，如何把这件工程作好，就须要咱们掌握更多的知识。多研究一下别人是怎么写代码的，它们有什么优劣，看得多了，总结得多了，“经验”天然就有了。

推荐书籍：

• 《重构》
• 《代码整洁之道》
• 《Effective Java》
• 《设计模式》
• 《实现领域驱动设计》

认真写文章，用心作分享。

我的网站：yasinshaw.com

公众号：xy的技术圈