笔记 | 这就是软件工程师（一）

一：新手上路 1.1基本储备：入门必学的语言和工具

①入门推荐语言：

这些语言的语法比较简单，有大量的库和语法糖

②入门必学工具：

操作系统 编程工具 Code

③正式入门语言：

Java 它是所有语言中综合实力最强的，除此之外还需要更专业的编程工具，比如更专业的操作系统Linux，更专业的编程的IDE（集成开发环境，比如），版本管理工具Git，相关的编程框架（比如 ）等。

④数学：

至少要学习离散数学中的数理逻辑和集合论，还有能力的话可以深入一下：数学建模，图论，抽象代数，拓扑学，运筹学，博弈论等这些都是机器学习，AI的基础。

⑤英语

英语是编程技能提升的关键，一定要学好英语，尽可能的用英文去检索技术关键词，在技术方面美国是领跑，学好英语有助于我们去源头学习。

1.2选择平台：去面向未来，技术驱动的公司

选择平台时，新人应该判断两件事:这家公司是否面向未来，是否受技术驱动。

第一，这家公司做的事情,能不能适应未来的发展。计算机与互联网的发展都太快，如果要选择，一定优先选走在未来航道上的那些快速发展的公司。

第二，你要去的这家公司是不是一家技术驱动、以技术文化为主导的公司。也就是说要去对技术和软件工程师都非常重视的公司。

1.3认识自己：找到适合自己的路线

一个人要想认识自己，就得看清自己的特长，兴趣，热情。

①特长

你要找到自己可以干成的事,找到别人找你请教的事，这是找到自己特长非常重要的方法。找到特长后，扬长避短就好。

②兴趣

如果你没有找到自己的特长，就找自己有兴趣、有热情的东西，即使再难再累都不会放弃的事。不怕困难,痴迷其中，就算你没有特长，有了这种特质，你也是头部人才。

③方法

如果你没有特长，也没有兴趣和热情，就要学方法。比如学习时间管理，学习做计划，学习统筹，学习总结犯过的错误，举一反三，学习探究事物之间的因果关系，等等。

④勤奋

如果你前三者都没有，你还能做的事就是勤奋。勤奋注定会让你成为一个比较劳累的人，也是很有可能被淘汰的人。虽然勤奋越来越不值钱。但是只要你勤奋，至少能够自食其力。

1.4编码规范：不要逆着规范做事

新人动手编码前,必须先熟悉公司的规范,特别是编程规范。这样的目的是为了高效协作，你只需要花很少的时间就能看懂,哪怕这个程序你不熟悉或完全没见过。这对提升团队效率的影响是巨大的。

1.5公司差异：即使没有规范，也得自我要求

新人进了公司先要熟悉规范、按规范做事，这是最基础的训练。即使没有规范，也得自我要求。即使公司没有对新员工做相关培训，自己也要有意识的去关注和学习一些规范。

①编码规范

我们需要关注的不仅仅是编码，还有代码评审、单元测试，这些都属于编码规范。

②设计规范

设计规范包括API（接口规范)、设计模式（比如面向对象的设计模式、设计原则SOLID)、架构规范(比如分布式架构规范）等。

③生产规范

生产规范指的是一套标准化的上线流程。比如软件工程师不是写完代码就行，还要做测试，测试完再上线，整个生产流程里有很多规范。

1.6整洁代码：不是写出来的，而是读出来的

代码的整洁程度代表着一个软件工程师的专业素养，不是写的人说自己的代码整洁就算整洁,而是读的人觉得整洁才算整洁。

判断你的代码整不整洁,一个最基本的标准是，读代码的人根本不用问你，只要上下读几行或者看看注释，顺着逻辑就能知道这些代码是什么意思，以及他要用的话该怎么用。

1.7代码注释：像说明书一样清晰

其实我觉得好的注释是，别人带着问题去看你这段代码和注释，看完以后问题就解决了。当我去调用这个模块或者函数时,好的注释直接摆了个例子告诉我，你这样写就好了，就像一份说明书，你去看的时候，脑海里有一个目标，然后它会非常清晰地一步一步告诉你，这样做就可以了。这就是注释应该起到的作用。

1.8编程原则：教科书没有告诉你的“为什么”

①避免重复原则

写代码的时候,如果出现雷同或相似的片段,就要想办法把它们提取出来，抽象成一段独立的代码．然后用这一段代码去解决多种问题。因为这样做既能降低程序的复杂度，又能减少维护的工作量。用一种方式解决多种问题，是避免重复原则的精髓,所以写代码写到高级阶段,其实是做数学建模。

②单一职责原则

一个类或者模块应该有且只有一个职责，简单来说就是各司其职。单一职责原则除了可以把复杂的问题简单化、模块化,从而降低问题的复杂度,让你更容易实现和驾驭,它还是一个可以让你的组件不断复用的原则。

③高内聚、低耦合原则

这是UNIX操作系统设计的经典原则,其中内聚指的是一个模块内各个元素彼此结合的紧密程度，耦合指的是不同模块之间的依赖程度。高内聚,低耦合（也叫解耦）简单来说,是让每一个模块做到独立,做到精益求精,同时把模块间的耦合降到最低，不会因为动了一个模块，而导致其他模块出问题。

④开闭原则

开闭原则具体来说是指，对修改是关闭的，对扩展（协议）是开放的，这是为了保证把稳定的东西放在内核，把易便的东西扔出去，最终保证稳定性和重用性。

1.9解决问题：别把原则当教条

毕竟我们编码的最终目的不是符合哪项原则,而是解决实际问题。程序就是一个解决问题的手段，核心问题是:这个程序真正要解决的问题是什么。

1.10全面思考：做测试比写代码难

①单元测试，一般是白盒测试

单元测试的目的就是测试这些零件是否都能正常工作，可以说，单元测试实力问题最近的地方。

②功能测试，一般是黑盒测试

一个功能是由很多个单元模块组装起来的，如果这些单元模块没有很好地配合在一起，互相矛盾,那整个功能也就不能正常实现了。因此，软件工程必须有功能测试，测一测各个模块合在一起能否正常运转。

③集成测试

从测试的角度来讲，单元测试测的是家庭，功能测试测的是社区，集成测试测的是整个城市的交互。具体到软件工程上,集成测试其实模块和模块之间或者系统和系统之间的测试。

④非功能测试

比如性能测试、安全测试、稳定性测试、健壮性测试、破坏性测试、可用性测试、灵活性测试，等等。非功能测试主要用来检查软件应用程序的非功能性方面（性能、可用性、可靠性等)，帮助降低与产品非功能性方面相关的生产风险和成本，优化产品的安装、配置、执行、管理和监控方式。

⑤回归测试

回归测试的意思是把以前做过的测试以及犯过的错误再测一遍。它的主要目的是确保代码或配置的修改、需求的增加不会影响现有的功能。通常来说，回归测试的成本是非常大的，尤其是对那些使用人肉测试方式的公司来说。所以一般来说，回归测试意味着自动化测试。

1.11程序测试：对软件工程师的基本要求

①测试要自己做，尤其不能让用户称为你的测试工程师

②除了测试基本输入以外，还要努力构想更多的边界条件

③测试接口定义的程序语意，而不是当前实现的具体行为

④对重要的模块，编写的时候就要做到基本性能测试

⑤对程序交付以后出现的问题和Bug，要构建相应的测试程序并提交代码库，保证以后回归测试可以自动运行这个测试

二：进阶通道

2.1需求分析：明确模糊不清的问题

①明确问题的边界条件。

比如金额必须要有明确的数字，才算有边界条件，否则程序就没法写。只有把边界条件明确地说清楚,定义出其中的规则和决策方式，软件工程师才能写出程序来。

②关注不可预期案例。

绝大多数人都会把时间花在可预期的事情上,而忘了关注不可预期的、可能出现故障的一些问题。比如当这个程序走到某一步，走不下去了，怎么办? 而软件工程师必须把这些环节明确出来。

2.2设计程序：学会谋篇布局

软件工程师设计程序更多需要的是谋篇布局的能力、思考总结的能力。到这个阶段，就要有一定的独立思考的能力。别人只给你一个问题，你要给出合理的科学的解决方案。

2.3高度抽象：设计需要抽象的能力

所以,从众多的实例、案例中归纳总结出通用的方法和规则,是抽象的核心思想。简单来说就是,对一个概念或一种现象包含的信息进行过滤，移除不相关的信息,只保留与某种最终目的相关的信息。

①过程抽象

所谓过程抽象,就是把要解决的问题分解为一个个小的子问题，然后用一个个独立的代码模块（如函数、类、API等)来完成,再把这些代码模块组织起来构建成一个复杂的系统。在组织的过程中，消除相似的模块，消除模块间的依赖，尽可能让每个模块都能重用到其他业务场景下。这样就完成了抽象。

②数据抽象

而所谓数据抽象，就是将复杂数据的使用和它的构造分离开来,数据结构用于定义数据的构造，数据接口用于定义数据的使用。通过隐藏数据对象的内部特征,定义数据的外部使用，大大降低系统的复杂度。

2.4原型设计

①从最难得做起

先做最难的部分，既能提早发现问题,又能节省开发时间。如果在原型设计阶段解决了最难的问题，那么后期整个项目的推进就非常顺利。当然，如果你对最难的部分做了评估后，觉得以当下的技术和人员难以攻克，那么整个项目可能就要往后放一放，不必继续浪费时间。

②原型设计的关键是接口

原型设计最根本的哲学不是实现功能，而是要注重接口。因为接口的好坏会直接决定整个项目设计的好坏。做接口设计时,要想一想每个阶段可能会调用哪些接口、每个接口需要哪些字段、怎样定义数据,等等。只有把这些问题想清楚，才能避免不确定因素对项目整体的影响。

2.5架构设计

①分而治之，理清思路

架构设计就是把需求进行抽象和分解。作为设计架构的人，首先你要知道怎样把同类型的内容抽象出来，还得知道实现目标要分成哪些步骤，以及怎么从大的步骤里切出小模块（设计模式)

②考虑异常情况和极限情况

第一，考虑系统的异常情况。我们必须假设任何环节都会出问题，都会出现异常，并基于这种假设，去做更周全的架构设计，我们需要知道每个异常出现后应该怎么解决。

第二，考虑系统的极限情况。我们做一个系统，就要提前考虑这个系统最大能承受多大的流量，在发生一些极限情况时，系统会怎么反应。

2.6技术调研：寻找最优解决方案

技术团队经常会接到一些以前没做过的需求，不太确定实现细节，这时候就需要做技术调研，看看同样或类似的需求在业内有没有被实现过，分析不同方案的优缺点，得出结论，做出决策。

①调研做得好不好，和阅读代码的能力高度相关。代码读得越快，意味着你的搜索能力越强，越能快速定位自己想要的东西。

②分析优缺点，结合场景才有效。做技术调研会涉及分析不同方案的优缺点，这时候需要注意,分析优缺点不能泛泛而谈，因为优缺点只有在场景下才成立，如果缺少场景，那么只有特点，没有优缺点。

2.7软件工程：不同的开发模式

①瀑布式开发模式。这是一种传统的软件开发模式，简单来说就是一层一层地开发。先分析需求，产生需求文档;再做概要设计，技术选型等;接着做详细设计，事无巨细地梳理流程和细节;最后编码、测试、上线。它的缺点就是慢。

②敏捷开发模式。它的意思是我在做雕像前,先由一个高手把框架开发出来，然后把后续的任务拆解成一个个小模块，拆得越碎越好,接着让每个团队（甚至每个人)负责其中一块,大家根据协议并行开发，最后拼在一起。它的本质是化繁为简，比较高效。

③班车模式。意思是我的发布每周一次（比如每周二)，如果你能赶得上就跟着一起发，如果赶不上就等下一班。这种模式看上去像是瀑布和敏捷的一种折衷方式。为了控制变更的需求,开发不要太快，也不要太慢,按一定的节奏来。

④分布式微服务开发模式。也就是把代码库、数据库全部分开，每个服务都由一个全功能的小团队（前端、后端、开发、测试、运维、产品）来负责,这样就可以把一个大部门拆分成多个小分队，让代码更容易维护和上线。团队之间也能非常方便和高效地协作。

2.8外部沟通：知道怎么“规训”业务

要告诉业务，不要把技术仅仅当做需求的解决方，只有真正的把技术当做解决问题的参与方，技术的主观能动性才能被调用起来。其次，不要直接将需求丢给技术，而是要告诉技术真正想解决的核心问题是什么。最后，我们面临的所有问题都不是单纯的技术问题,大家一起努力,才能从根本上解决问题。总之，技术只有知道如何和业务沟通，才能把需求实现好。

2.9内部协作：平衡前台团队和中后台团队

在技术团队里，我们通常把离业务近的团队叫作前台团队，把离业务远的团队叫作中后台团队。之所以出现问题，就是离业务近的同学觉得离业务远的同学做的东西都没用，离业务远的同学觉得离业务近的同学做的东西太短视。

这其实是一个长期目标和短期目标平衡的问题。

这时候，就需要大家相互理解，从后向前，中后台要有意识，主动去理解前台团队的需求；从前往后，前台团队也不能仅仅因为业务的压力，就用短期目标来要求中后台团队做不合理的事情。中后台团队要围绕着前台团队去建设，去创造价值，去解决前台的需求和痛点，甚至在前台团队还没有看到之前就预见出一些可能发生的问题,从而给前台团队提供有价值的服务，这样双方都能达到一个比较好的平衡。

2.10搭建体系：用知识树系统学习

①用好知识树。

任何知识，只在点上学是不够的,你需要在面上学，这叫系统地学。系统学习要求你去总结并归纳知识树或知识图。我们以C++为例，看一下知识树是什么样的。对于一棵树来说，“根基”是最重要的,所以，学好基础知识非常重要。

②探索知识缘由。

任何知识都是有缘由的，了解一个知识的来龙去脉和前世今生，会让你对这个知识有非常好的掌握，而不再只是靠记忆去学习。当然并不是所有的知识我们都需要了解缘由，对于一些操作性的知识，比如一些函数库,只要学会查文档就好了。

③掌握方法套路。

学习不是为了找到答案,而是为了找到方法。就像数学一样,你学的是方法,是解题思路:会用方程式和不会用方程式的人，在解题效率上不可比较。掌握高级方法的人比别人的优势有多大,学习的目的就是为了掌握更为高级的方法和解题思路。