丁哥看软件（六）：工程能力提升

所谓软件工程能力实际上就是解决具体问题的能力，也就是把实际中的问题转化成项目代码的能力。

说一下人员能力的提升这一块儿。一个项目中一定要有一个灵魂式的人物。尽管我们说现在的软件工程开发是一个团队的合作成果，但是这个团队中必须要有一个大脑，不能有多个大脑。

这个怎么理解呢？对于小的团队来说，假设有10个人的团队，那我们就说组长就是这个团队的灵魂。组长需要带领大家进行调研工作，最后作出结论进行取舍。这地方可以理解为架构设计方向的制定。

这一步看清楚以后，接下来就需要把这些活儿分配给各个成员。组长需要紧密跟进项目的进展，比如说遇到难题了，组长需要跟成员一起去解决掉，而不是交给成员去单独攻克。

如果没有难题，成员单独解决了，那么组长需要把解决方案理解透彻，把好关，同时好好学习。

对于组长的要求是假设整个团队10个人，只剩下组长一个人，他也应该有能力把这个项目维护下来。

上面是对组长的要求，这里第1位的是学习能力，就是对于未知领域的热爱和领悟能力。

接下来说组员。组员第一要务就是把分配下来的任务好好完成。

这里面需要理解力和执行力的培养。这个需要一段时间的磨合，整个团队才能够形成强大的战斗力。

再一个是主观能动性的培养。如果任务完成了，就应该主动去寻找新的任务去做，有活的时候好好干，没活的时候找活抢着干。

培养主观能动性需要驱动力，一般来说有这么几个: 

第一，是自我价值实现的欲望，首先是天生我才必有用的自信，也就是每个人都想做些事情，寻找自身的价值，并把自身价值融入到团队的工作当中。

第二是外在的奖励，这些奖励可以包含物质上的，名誉上的等等。也就是杰出的工作得到了认可。

上面是对于组员的要求，这里处于第1位的是执行力，就是得到指令以后快速完成任务的能力。

现在说一下工程方法这一块。比较流行的算是敏捷方法论。在敏捷方法论中一般有两种方向一种是开发团队驱动，一种是项目经理驱动。不管采用哪一种方向，这种方法论的一个基本要求就是能够在短期内有看得见的输出，并且有持续的输出。

这种方法论用的舒服了的话会给整个团队带来很强的成就感和昂扬的斗志，从而激励团队成员把工作当做一种乐趣。在现实的应用中敏捷方法论可能会被形式化，比如每天大家都站在那里花几分钟的时间讲几句话。如果是这样子的话，就走偏了。 为了避免形式化，应该以输出为导向。及时向其他团队成员更新自己的状态。

现在说一下算法和逻辑部分。对于软件技术，我认为大多时候是把它当做一个工程技术来运用的，也就是拿着这个工具去解决实际的用户需求的。在技术运用的过程中，我们会不断地使用各种各样的算法和逻辑来随机应变的处理我们的业务流程。对于具体的算法和逻辑，完全是case by case的。我们先不深入探讨个例。我们要探讨一个非常重要的概念，就是复杂度的问题。

我与很多程序员共事过，尤其是高级程序员，发现很多人都有一个习惯，喜欢把简单的问题复杂化。美其名曰要考虑周全，要考虑周到。这里说一个很简单的例子，比如说我们拿到一个项目，这个项目的需求是拯救地球。

很多程序员上来就会陷入到思考如何拯救星球的迷雾中。这个思路的第一要务就是要先区分有多少种星球，然后对这么多的星球进行分门别类。然后在项目运行时判断某个输入参数来指定是地球以后，再进入到思考如何拯救地球的任务当中去。 

如果你问为什么要把这个问题思考的这么复杂，因为我的需求只是拯救地球而已。一个非常高大上的理由就是他想做一个通用的项目，以后可以支持更多的星球，从而方便扩展。 

基于这种思路去做项目，项目会越做越复杂，团队会越来越庞大，成本自然也就急剧的上升。

亚马逊在这个方面是吃过很多苦头的。在早期的项目中，有些程序员设计项目过于复杂，导致这些人升职离开项目以后，其他人根本无法接手维护这个项目，即使再去找原来的设计者，他们也无能为力了。因为复杂度太高了。

关于流程和工具。这两个方面可以合在一起说。流程需要简洁高效，直击要害解决问题。工具也是一样的。虽然每个人的喜好有些不同，有的人喜欢界面，有的人喜欢命令行，这个都没关系，那就选能够给自己带来最高工作效率的那种工具和流程。 

在嵌入式驱动开发领域里面，有些公司是用普通文本编辑器来写代码的，代码审查是用比较软件的方式手工合入代码的。虽然驱动式开发中的代码量不是应该特别多，比如说一个driver，如果代码量很大的话，可能就存在设计上的问题了。即使代码量很小的情况下也应该使用比较先进的工具来处理, 比如代码编辑可以使用vs code, eclipse, qt creator等等，代码审查可以使用平台工具如github, gitlab, bitbucket, gerrit,等，代码查看可以使用git工具( fork, git extensions)等等。

以上只是用一个例子来阐释避免使用非常原始的工具，既容易出错又效率低下。