软件工程

一，现状

    随着社会日益发展，互联网日益发达，it技术服务的需求也越来越多。很多企业为了满足这些需求，都采取快速迭代的方式，对软件产品进行开发。但很多情况下，需求无法控制，迭代质量没有办法保证，一个项目越来越难维护，维护人员难以为继，逐渐离职。

出现上面提到的问题，其实很多情况是可以避免的，但是由于许多实际的原因，导致无法控制。例如，做产品定制的一些需求，有些需求对软件原来的系统逻辑改变很大，甚至与原来的逻辑压根不着边，如果还要强制开发，就无亚于在已经建好的大楼下面加停车场。因此，此文希望能够提供一些技巧性的方式，来减少因为这些实际性的问题导致的软件工程无法正常继续的问题。

二，技巧

1，代码注释

目前大多数的项目，虽然都提倡多写注释，但是却很多情况下没有做好。为什么呢？一来，注释每个人的写法都不一样，二来，每个人总是按照自己的一套思路去写，没有一个规范去限制注释应该是怎么样的。所以了，下面我从实际出发，希望软件开发的注释是有以下特征的：

注释应该是有条理性，有顺序性的，模块化的。

为什么呢？举个例子，假如你在维护一个500行以上的代码块时，你会发现，很多时候上面有n个人的注释，每个人都只是在上面写自己的注释，后面维护的人接手的时候，你会发现这个代码块上面的注释有时候前面的和后面的都已经没有什么关系了，甚至一些不维护的注释都与原来改过的代码不想干了，导致后面的人还要一点点的切入代码，刨数据才能确定这个代码块当前到底是做什么事情。因此，注释应该也是要维护起来的，最好是有顺序性的，像书一样，有目录，有段落，有顺序，有模块，标注于代码的关键位置。

2，知识体系构建

    一个产品涉及的业务非常多，甚至会出现很多专业化的名词，例如对于电信boss系统，有商品产品的概念，订单概念等等，对于oa系统里面的考勤，有排班等等的概念，每个业务还有它们独立的规则。或许一个系统在研发的初始阶段会比较少这些东西，但是当一个系统越来越大，例如一个开发了一个几年的系统，为了方便后续维护以及交流，对系统内的一些业务做一个比较好的定义和定性是十分需要的。传统的软件工程理论是十分值得借鉴的，Uml的使用也十分重要。

但这里，我想提的一个观点就是，要做好知识体系的构建。

要理解一个庞大的系统的确不容易，总不能一下子就都了解完毕，但是总需要有先后顺序去了解，就例如学习数学总是要从有理数过渡到无理数一样，学习是有过程的，也是有它的知识体系的。对于一个系统内的知识体系，如果构建的比较恰当，那么，对于后续来的人员去理解系统就容易许多了。举个例子，做过电信相关系统的，应该都多少接触过boss系统、三户模型等的概念，因为有这些概念，才得以让如此复杂的电信系统能够让开发人员去理解和研发。
目前，绝大多数的公司都仅仅是通过最原始的方式去理解一个系统，看界面，熟悉业务，看代码。这种方式是多么的原始，导致很多程序员遇到一个方法几千行的时候，都有种三十六计，走为上策的想法。可想而知，我们要有一个知识体系，去让程序员能够更好的理解系统，完善系统。其中，软件工程相关的知识或者一些工具应该要拿部分适合自己公司的去实行，例如uml图。又例如可以建立类似电信系统类似于三户模型的一些概念，让各个系统模块能够清晰的表达出来，相信这个对于连续开发周期以年为单位的系统，能够有很大的帮助。

3，工欲善其事，必先利其器

软件开发不容易，对于一个庞大的组织架构中，不同的人归属于不同的部门，各个部门彼此之间缺乏沟通，导致很多情况下，每个部门都有自己造自己的轮子的情况。最近流行的“中台”概念，其实也是为了更好的将资源利用起来，减少不必要的浪费，让部分轮子得以复用。软件开发需要庞大的工具链支撑，除了开源的一些工具、中间件外，应该还有很多是属于公司自己开发的业务组件，属于公司自己的架构方法、方式、工具，所有的这些如果都能够尽量利用起来，那么对于开发系统的效率将会有极大的提升。然而很多的公司却只注重业务，却少了对基础技术、框架的重视。例如，业界常见的数据库分裤分表相关组件，对于大公司来说基本上都会有，然而对于某些公司来说，却连用都没用过，连基础的组件都不愿意花时间去构造，那么后面的研发时间对于拥有这些基础组件的公司来说，那是多很多很多的。这里多出的不仅是研发时间，还有后续的维护成本，甚至可能会面临重新开发的风险。