关于最近重构代码的一些思考

最近一直在参与重构项目中的代码。

以前写的代码最大的问题在于“想到哪里写到哪里”，没有从功能上先总体地进行分析，而后将相似的业务分类到一些，有条理地书写代码。应该来讲原本是能够这么去作的， 由于咱们花了很多时间去作详细设计。写代码的同事已经对业务的逻辑有了相对完整的理解。但因为很多同事在写代码方面经验还比较少，所以很难作到这一点。因此就想到哪里写到哪里，也比较少审视先后写的代码一块儿来看是否是结构合理的，原本能够共通进行处理的部分也没有合并到一块。代码中出现大量的重复。这是最明显的一个问题，也是最初级的一种问题。

第二种问题来自于对状态迁移表的理解的僵化。咱们几乎全部的模块（除了共通的API层）都是使用状态迁移表的方式来进行设计的。这有不少的好处（找机会另写一篇文章聊），可是并非说除了状态迁移表以外其它的设计手法（模式）就不能用了，或者说不知道如何把其它手法融合到状态迁移表中去。所以业务逻辑稍微复杂一些的时候状态迁移表就变得巨大无比，并且特别容易出现其中某些格子处理特别复杂，不少格子中的处理又过于简单甚至不须要处理。使得设计文档变得比较难以理解。

第三个问题是不懂得细分。特别是使用C++的模块，原本能够用类/类体系很好地将各类类似的逻辑放在一块儿去处理。用C++来走C的路。

具体的例子由于涉及到公司的IP，不能贴出来。之后找机会总结一下，换些Dummy的代码来讲明。

再说一个关于语言的问题：

对于一个项目来讲，业务的逻辑复杂度是本质性的，需求不变的状况下，复杂度是必定的。咱们要作的就是让代码实现能尽可能地接近业务复杂度，我重构的目标基本上也是这样：把因为拙劣实现而产生的多余的复杂度去除。因为某些限制，咱们的项目中有些模块必须使用C来写，有些模块能够用C++写。可能因为本身写程序长期使用C++的缘由。在重构C和C++代码的时候，感受明显不同。C++在语言上给出了更多功能，所以，咱们有更多的手段去让代码更贴合业务，就容易写出更好维护，更容易懂的代码来。好比OO（以及所以发展出来的相应的模式），泛型（将语言数据类型这种在业务描述中并不太关心的东西的影响去除掉）。用C++写明显要“轻松”不少，能够给出的办法也比较多，代码量也要小很多。而C++11/14的进步，使用C++在写业务层的东西的时候变得更加简单的高效（不管是语言层或者标准库）。C++很是适合在嵌入式的领域。C除了在特别靠近硬近的代码的时候没有明显地劣势以外，写业务逻辑时明显要感受到要为语言的简陋走些弯路，作些妥协。我以为这个观点的一个更好的例子就是用函数式编程语言写快速排序。代码极其简洁，贴近算法自己，而用OO和过程式的语言就要带入那些与“算法”自己无关的东西进来，这些都会加大编程和维护的负担。固然，对于C++我也有不少不爽的地方，好比模块的语法我以为很丑，Lambda表达式也是各类语言中比较笨重的一种，编译器还应该能为程序员作更多的事，就像Scala那样。

在我看来，只要有可能，就应该选用更多“选择”的语言（在个人选择中，嵌入式开发中能用C++就用C++，能用C++11/14就用C++11/14）。目标就是如何能实现得更简单更快更好维护。

PS: 这几天的新闻，ARM的新编译工具链是基于LLVM进行构建的。LLVM在C++语言以及各类C++代码处理/分析工具上的支持都很棒。我相信在嵌式开发中，C++11/C++14会很快地获得很是好的支持。只要工程团队技能跟上，那么是能够提升开发效率的。