小引

 在本文中我们将探讨如下问题：

1.  软件工程需要哪些能力以及如何保障这些能力？

2.  哪些地方我们需要注意复杂度的问题？

3.  考试的目的是什么？

4. 莫要让规范束缚了我们的手脚，成为技术的奴隶。

5.  要让人的能力发挥到极致，良好的心境是必须要有的。

6.  专注于自己擅长的事情。那么，在软件工程当中，这样的理念应该如何贯彻呢？

7.  为什么我们需要对代码和设计进行重构？如何做？

8.  如何保证软件开发的质量呢？

考试

考试的目的是提高开发人员的基本素质，是督促大家自觉学习的一个重要手段。

先来分析一下软件开发工作的的特点，再来谈考试的作用。   

关于软件的工作划分， 大体上可以划分为20%脑力和80%体力的比例， 20%这一部分偏重于创造性的工作，包括架构设计代码。创造性的研究工作，主要是明确方向，把握质量，这部分工作需要经验和长期的项目积累，当然有人说需要天赋（这个天赋我强调的是因时、因事、因地变化的能力）也可以，这一部分工作需要这个项目的灵魂人物来担当和把控。

80%这一部分偏重于重复性的工作，代码的编写，文档的编写，通过上面20%工作的指导具体展开实施工作。这一步考察的主要是理解力和纪律性。尤其是在项目快速推进的过程中，让团队上下整齐划一，统一行动，直到完成目标版本的开发任务。

由此衍生到团队建设和成员能力方面，团队的筹建源于某个目标，比如业务需求，研究任务等等。有了这个目标以后，可以着手物色合适的人选去做上面提到的20%的创造性工作。这部分人员素质一定要高，经验丰富，反应迅速，学习能力极强。

基础架构设计工作明确以后，需要把任务分派下去，这就是80%这部分工作的实施阶段。这部分人员素质当然越高越好，但不是第一位的，理解力和认真执行能力更重要。

对应上面的分析，结合关于通过考试来取舍软件工程师的做法, 个人认为不妥当，考试可以作为能力提升的一种手段，比如刚入职的员工没有具体的任务分配，可以通过考试这种简单的问题需求提高自己的能力和经验。

      或者在项目完成以后，大家长期无事可做，也可以通过考试来收敛思绪，督促自己学习。

规范

原则和模式是软件工程质量的基石。原则如SOLID, ACID等等，也就是高内聚低耦合的指导原则。模式是可以借鉴的一些实践经验模板，如MVC, MVP, MVVM, DDD, TDD, BDD, ATDD等等。 

本节要讨论的是不要教条主义，莫要让规范束缚了我们的手脚，成为技术的奴隶。

这个话题借API技术来展开说一下，我有如下的理解跟大家分享一下: 技术是工具, 是为人服务的。而不是反过来。我们不能说为了迎合某种技术而束手束脚，让我们自己特别难受。

你比如说rest的理念，就是提供简单的对单一资源的crud请求操作。而实际的业务场景中，我们需要用到多种资源，而不是单一资源，这样子如果严格的按照rest的理念来教条式的应用，必然就会导致请求效率和计算效率的低下。

那么自然而然的，我们就想我一个请求是不是可以定义一个model，然后这个model包含我需要的多种资源数据。

这里的model的要区别于rest中使用的entity, entity是对应具体资源表格的, model是对应多个资源表格的某些字段的。

我们知道这样的一个请求，在rest中对应着一个路径，若干参数，一个负载payload。在服务器后端处理这个请求的时候，它会对应一个处理函数。

在这个处理函数中，我们可能涉及到多个表格，多个数据源的计算操作。那么通过这样的设计，我们就避免了在前端进行多次的请求，而改成通过一个请求就完成了对于多个数据资源的获取。这样就可以提高整个业务请求的处理速度。

上面这个过程是采用了graphql的理念，使用了rest的技术。

graphql作为一个理念本身没有指定具体的技术, 那么这里就有一个问题: 我们应该选择什么样的技术来践行这个理念。

上面我提到的是一种，我认为这种是目前最好的选择。

以appello为代表的SDK为graphql的理念践行了很多有意义的工作。

让程序员感到比较兴奋的是对前端工作的简化。这部分工作的具体实施跟我上面提到的用model来代替entity的模式是一样的，异曲同工。

但是后端这一块儿, 使用graphql的复杂度增加了, 在rest中一个handler function可以做的事情, 在graphql中需要endpoint class, schema, resolver, parser等等。不仅仅是编码的复杂度，程设计的复杂度也提高了。相比，rest中直接调用repository或者service处理逻辑, graphql需要绕一圈以后再去调用repository或者service进行处理,执行效率也相比rest下降了。

      gRPC使用二进制数据作为传输媒介，相比graphql和rest，传输效率更高了。定义proto文件以后，使用编译工具生成客户端和服务器端代码的方式提高了编码效率。

通过函数调用的方式来实现网络请求也简化了代码的编写。

但是它的一个问题是不支持HTTP1.0和1.1。这意味着网页程序无法使用gRPC的API。

关于编程规范部分, 首先需要通过工具来规范，比如说代码编辑器里面的语法检查高亮功能。一个团队里面所有的开发者，都应该使用相同设置的语法检查工具，配置相同的规则。通过这种方式可以让编码者把主要的精力放在业务代码逻辑的编写上，而不需要过多的考虑规范的限制。

其次，命名规则和格式的共识可以写到编程规范里面，通过人为的约定来制定共识，从而避免不必要的代码重构。

再次，实际上，代码让别人看不懂的主要原因是代码的复杂度过高。所以在代码功能完成以后，一定要回过头来看一看能不能把代码的复杂度降到最低。

关于架构和设计部分，在业界有很多种方法都比较流行，都可以把任务完成。最忌讳的一点就是生搬硬套。应该活学活用，结合具体的业务场景，以这些方法为参考，服务于我们的工作，而不是反过来让我们的工作去迎合这些方法。

• 规范是助力不是阻力。

• 规范是参考的路标，不能生搬硬套，也不是“画地为牢”，应该作为参考书。

• 规范越简单越好。

• 架构与设计的原则是简约，不能生搬硬套。

• Simple is not simple.

• 做到简单并不容易。

• 大道至简。

良心

这一节说一下软件人员心境的问题。软件工程中的一个核心因素是人的因素。要让人的能力发挥到极致，良好的心境是必须要有的。 

我本人在头条，知乎，B站和油管上有《丁哥开讲》这个栏目，在向广大软件从业人员分享经验的同时，也不断地收到大量的业内反馈。

各方问题涉及到方方面面，其中影响心境的因素，我大体归结了一下，有如下几种：

1. 入职的时候工资和级别要低了，很纠结。

这个问题非常普遍，也很现实，这会非常影响工作效率。很多人纠结这一点主要是因为入职以后发现有些能力不如自己的同事级别比自己高很多。感觉自己亏了，搞得心情很不好，于是就问该怎么办。我在回答这类问题的时候，我的建议要点如下：

a.  钱是王八蛋，有能力就能赚；

b.  能力是安身立命之本，不能让心境影响能力的发挥；

c.  摆正心态，假定自己的级别比现在的自己高出许多来做事情，更严格的要求自己；

d.  假以时日，即使所在公司无法识别你的付出，你依然拥有强大的自己；

e. 有了强大的能力，天下之大，你哪里去不得？

2. 被加班文化搞得筋疲力尽。

很多朋友提问了这类的问题，说哪些公司不能进。下面就粗浅的谈谈这个问题。 

先说一说对于加班的看法。国内最严重的是阿里系的公司。我了解到在国内科技公司，公司上下形成一种氛围，就是说大家在比谁每天在公司待的时间长，所以就有了996的说法，还有5+2白加黑。还有的人说996是福报。

这个是非常可怕的，这是一种典型的消耗战法。不仅仅是针对体力和脑力，也是对员工斗志的消耗，进而是公司工作效率的消耗，对企业文化也是一种极大的摧残。

研究开发类工作是充满激情的工作。在没有想透彻之前不应该动手去做，需要继续想，继续思考。这跟生产零件的工作不一样，开动机器以后，只要看着这个机器在运作，零件就会不断的生产出来。

比如说，一个典型的案例，工程师忙碌了一天，把事情收个尾，到下班的时间该走了。很多老板不是看你做了多少工作，而是觉得你做完了别人没做完，说明你的工作量不饱和。所以你不能走，走了就会给你绩效低分。可以给你扣些帽子，比如说你不团结，不考虑集体，起坏的带头作用。

这种企业思维在国内是非常普遍的，我了解到很多来温哥华这边交流或者开公司的老板，他们的思维和行事风格就是这样子的。

这种思维的一个好处，俗称傻大胆儿。什么都敢干。至少可以起到“吆喝一声，引起别人注意”的作用。这一点对大公司来说非常重要，就像跟大家说一声，嘿，这个事我要做了哈，这里可是高工资996，5+2白加黑，你们小心点儿。那别人如果想入这个行业的话都会掂量一下，因为这个块头儿这么大，实力这么强，我们还是不要做了？这样子就会吓退很多比较小的竞争者。

但是坏处也是很显然的。如果工程师不是发自内心的想把这个事情做好的话，工作的产出很难保证高质量。

要解决这样的问题，首先要确定公司文化的正确理念，以产出为导向，以高质量为导向，而不是以坐班时间长短为导向。

说的直白一点，就是你并不是想让员工在公司里熬时间，而是想让员工身心愉悦，能够产出更多更高质量的产品。这个需要给员工很大的时间支配自由度，有条件的话，可以让员工拥有更多空间的自由度。

上面说的是文化的一种构建。

3. 赶鸭子上架，痛苦不堪。 

钱和时间是优质产品的必要条件而非充分条件，产品和输出都是有灵魂的，不是想当然就能出来的。赶鸭子上架是不行的，鸭子会很难受。

这些文化构建当然还不够，不是说把这个文化建立起来了就万事大吉了。打破机械式管理是为了提高生产效率。

归根结底还要关联到产品上，输出上。那么我们该怎么做呢？这个地方我的观点还是要不厌其烦的重复这个产品灵魂的观点。也就是对于某个产品或某个具体的输出必须要有一个灵魂人物。这个人需要从0~1，一直把这个事情跟完。这个产品可能涉及很多种技术，那么这就要求这个人要有很强的学习能力，最开始的时候可能对一些技术不是很熟悉，但是在做的过程中，要通过不断的学习，才能够把相关的一些技术理解明白，只有这样他才能够对自己做的产品心中有数。

4. 对抗文化不是出路，看似竞争，实则内耗，互相伤害。

有的人推崇丛林文化，弱肉强食，讲的是一个“杠”字；

我推崇潜移默化，以柔生刚，以柔克刚，讲的是“容”字，“化”字。

我认为“杠”无法持久，无法形成合力，一个火车不能有多个方向的牵引力，否则最终会作鸟兽散。

     “容”“化”追求的是相互融合，彼此扶持。这种模式不仅可以成就工作上的伙伴，也可以找到生活中的朋友。此时的状态已经不是追求一城一池的得失，不再在意一两个项目的成败，而是有一个共同的目标、彼此欣赏的情怀。基于此理念打造的团队，其毅力是顽强的，战斗力是强悍的，成果是可期的。

前段时间有人跟我讲阿里内部就很崇尚对抗文化，认为这样很有血性和斗志。的确有的人喜欢搞对抗文化，比如说一个团队里多个大牛，让这些大牛互相顶牛，形成彼此的掣肘。讨论茴香豆的HUI字有几种写法，然后某些领导就感觉自己的位置比较安全。这样的情形说明领导把自己的主要精力放在办公室政治文化上了。

这种对抗文化实际上不利于整个团队的协同作战。软件工作内容的划分大体而言就是20%的脑力、80%的体力的划分。

在项目工作的常态中，服从和执行的情形，是占绝大多数时间和工作量的。

如果说经常产生争执，团队成员疲于奔命，沟通成本占了很大的比重，那绝对是浪费时间和精力的，进而影响产出和质量。

(未完待续……)