《这就是软件工程师》读书笔记

选择平台：去面向未来、技术驱动的公司
**计算机和互联网的发展太快，如果要选择，一定要选择走在未来航道上的快速发展的公司。**因为高速成长的公司需要人才，它需要解决的问题也是新的，你会跟着公司一起去解决这些问题，你的能力会越来越强。**要选择技术驱动，以技术文化为主导的公司。**职业生涯的初期，把自己的基础打好，培养起扎实的编程能力和良好的职业素养。

认识自己：找到适合自己的路线
一个人要想认识自己，就得看清自己的特长、兴趣、热情等。

**特长：**找到你DNA中比别人强的东西，拿你的DNA和别人竞争。你要找到自己可以干成的事，找到别人找你请教的事。找到特长后，扬长避短就好。

**兴趣：**如果你没找到自己的特长，就找自己有兴趣的东西。什么叫兴趣？兴趣是再难再累都不会放弃的事，不怕困难，痴迷其中。

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

**勤奋：**如果你前三者都没有，你还能做的事就是勤奋勤奋注定会让你成为一个比较劳累的人，也是很有可能被淘汰的人。随着你的年纪越来越大，你的勤奋也会变得越来越不值钱。因为年轻人会比你更勤奋，比你斗志更强，比你要钱更少。勤奋虽然不值钱，但是只要你勤奋，至少能够自食其力。

知识都是死的，只要不怕困难总有一天会懂的。最可怕的是畏难，为自己找借口。

编码规范：不要逆着规范做事
为什么要有规范：为了提高效率。一家公司有很多软件工程师，以及日益增长的代码库，如果大家遵循同一套规范，你只需要花很少的时间就看懂，这对提升团队效率的影响是巨大的。作为新人，你在编码之前先熟悉这些规范，开发时严格遵守就好了，没必要逆着规范做事。

公司差异：即使没有规范，也得自我要求
要么花时间在写代码上，把代码质量提上去，要么花时间在后期修理上，靠运维去修补代码质量差的问题。

整洁代码：不是写出来的，而是读出来的
整洁代码不是写出来的，而是读出来的。不是写的人说自己的代码整洁就算整洁，而是读的人觉得整洁才算整洁。整洁代码的核心在于，你心里要装着将来要阅读这段代码的人，从方便阅读的角度去布局、设计。

代码注释：像说明书一样清晰
注释可以为读者提供足够的信息，让读者知道什么时候，怎么样使用这个类（方法），以及正确使用这个类（方法）的注意事项，而不是只是说明这个类（方法）是什么。

编码原则：教科书没有告诉你的”为什么”
避免重复原则：既能降低程序的复杂度，又能减少维护的工作量。
单一职责原则：指的是一个类或者模块应该有且只有一个职责，简单来说就是各司其职，可以把复杂的问题简单化、模块化，从而降低问题的复杂度。
高内聚、低耦合原则：内聚指的是一个模块内各个元素彼此结合的紧密程度，耦合指的是不同模块之间的依赖程度。高内聚，低耦合（也叫解耦）简单来说，是让每一个模块做到独立，做到精益求精，同时把模块间的耦合度降到最低，不会因为动了一个模块，而导致其他模块出现问题。
开闭原则：对修改是关闭的，对扩展（协议）是开放的。因为同一个事情、同一个原因改变的东西放在一起，把会因不同原因改变的东西扔到外面去，最终保证稳定性和重用性。
这些原则看上去或许不难理解，要用好却不那么容易。你可以先了解这些原则，不必急着马上使用，先在工作、学习中观察和总结别人的设计，再回过头来看看这些原则，然后适度地去实现。

解决问题：别把原则当教条
编码的原则很多，但有一些原则，不必拿它当教条，毕竟编码的最终目的不是符合哪项原则，而是解决实际问题。程序就是一个解决问题的手段，核心问题是：这个程序真正要解决的问题是什么。

全面思考：做测试比写代码难
一般来说，程序测试包括单元测试、功能测试、集成测试、非功能测试、回归测试等。

单元测试：一般是白盒测试，单元测试是离问题最近的地方，离问题越近，解决问题的成本越低。
功能测试：一般是黑盒测试，一个功能是由很多个单元模块组装起来的，如果这些单元模块没有很好地配合在一起，相互矛盾，那整个功能也就不能正常实现了。功能测试并不关系具体实现是什么，而是把软件当成一个黑盒（不知道里面是什么）来进行测试。
集成测试：集成测试其实是模块和模块之间或者系统和系统之间的测试，比如“订单”模块和“支付”模块之间的测试。集成测试的难点有两个，一个是怎么把众多系统组织搭建起来，另一个是怎么定位测试过程中遇到的问题。
非功能测试：非功能测试主要用来检查软件应用程序的非功能性方面（性能、可用性、可靠性等），帮助降低与产品非功能性方面相关的生产风险和成本，优化产品的安装、配置、执行、管理和监控方式。
回归测试：把之前做过的测试以及犯过的错误再测一遍，确保代码或配置的修改、需求的增加不会影响现有的功能。
程序测试：对软件工程师的基本要求
测试要自己做，不能让用户成为你测试工程师。
除了测试基本输入以外，还要努力构想更多的边界条件。
测试接口定义的程序语意，而不是当前实现的具体行为。
对重要模块，编写的时候就要做到基本性能测试。
对程序交付以后出现的问题和bug，要构建响应的测试程序并提交代码库，保证以后回归测试可以自动运行这个测试。
执行任务：从改bug开始
不要小看改bug，你只有学会在海量的数据里找到bug，学会修补，避免出错，才能知道代码在真实环境里是怎么运行的，才能找到一名软件工程师的工作体感。

定位bug：像侦探一样发现问题
模拟bug场景：想象一些怎样的代码才会实现bug导致的现象，然后顺着这个思路去找。
二分法：先把代码一分为二，判断bug可能在前面一半还是后面一半，然后再分，再分，不断缩小范围。
调试工具：针对某些bug使用调试辅助工具。比如IDE里的单步跟踪、多线程调试工具、性能调试工具、内存检测工具等。
极限测试：用足够多的测试机，设置不同的极限条件进行测试，观察测试结果有什么规律。
修复bug：务必小心谨慎
正式修复前，要梳理整体设计、理解代码，保证你的操作不会影响到其他部分，不然很容易制造新的bug。

拆分任务：动手工作前，先做任务分解
当你碰到一个大的任务，有时甚至是难以完成的任务时，先去拆解，拆分成子任务，然后聚焦于每个子任务怎么完成和实现。将大目标拆分成小目标，大任务拆解成小任务，是软件工程师非常重要的工作能力。

阅读代码：重要的不是写代码，而是读代码
在阅读别人的代码的时候，有几类代码值得重点关注

被反复使用的代码：如果你读了很多代码，发现不同项目都在调用用一个函数，就要重点研究，看看它好在哪里——大家都在用的东西往往是标杆。

穿越时间的代码：如果一段代码用了10年、15年都没被淘汰，说明它的设计思想很棒。建议你关注这类代码的演进过程，尤其是它最旧的版本，最旧的版本往往反映了最核心的设计思想。

好调试的代码：调试代码也是观察、学习、长经验的过程，如果这些代码你调起来非常顺手，大概率是因为写代码的人为你准备好了基础工具。这时候你就要抓紧机会学习，看别人是怎么在早期搭建这些工具的，为以后自己写代码积累经验。

找到捷径：通读牛人代码
牛人的代码会非常清晰、明确、易用，自带使用说明。
牛人写的代码会非常高效。
牛人代码的通用型很高，可扩展。
牛人的代码都是自带风格的。
追本溯源：多读文档，多读书
代码告诉你怎么做，文档告诉你为什么。书和文档是人对人说的话，代码是人对机器说的话。所以，如果你想知道人为什么要这么写，你就应该去看书，看文档。如果你想知道让机器干了什么，那你应该看代码。

重在过程：学习牛人的方法，别抄答案
跟高手学习是提升自己的捷径，但不意味着高手做一件事，你就照着抄。问题总会变，技术也在变，但优秀的解题思路不变。

在高手帮你review代码的过程中学习。接受批评，重点关注他指出了哪些问题，以及下次如何改进。
跟高手一起解决难题。在遇到难题的时候，高手才会把最好的水平拿出来。
潜移默化：和优秀的人一起工作
要想方设法和公司里非常优秀的同事一起工作，长此以往，别人身上解决问题的方法和能力，会潜移默化地成为你的一部分。

亦师亦友：和身边的人搭档学
软件工程师有些时候是单枪匹马去战斗，难免有自己发现不了的问题，也会有陷入迷茫、难以抉择的时刻，如果你身边有一个值得信懒的伙伴，作为胖过这帮你指出问题、理清思路，就能免去很多烦恼。你也可以通过同样的方式帮助对方，两个人搭档学，双方都能有进步。