可以参考：
https://blog.csdn.net/u011414200/article/list/4?t=1
https://zhuanlan.zhihu.com/p/36896480
软件工程中地一些英文缩写：https://www.cnblogs.com/vimmer/articles/2521519.html
下面笔记是进行补充。
第3章 软件工程师的成长
工程师的核心技术和扩展知识：
怎么提高技能呢？
通过不断地练习，把那些低层次地问题都解决了，变成不用经过大脑地自动操作，然后才有时间和脑力来解决高层次的问题。
断言assert：
如果你觉得某事肯定如何时，就可以用断言。使用断言可以创建更稳定、品质更好且不易出错的代码。如果你认为某事可能会发生，这时就要写代码来处理可能发生的错误情况。如：
if()
{
...
}
else
{
...
}第4章 两人和作
1.在复审前：
- 1.代码必须成功地编译，在所有要求的平台上，同时要编译Debug|Retail版本。编译要用团队规定的最严格的编译警告等级。
- 2.程序员必须测试过代码。什么叫测试过？最好的方法是在调试器中单步执行。
- 3.程序员必须提供新的代码，以及文件差异分析工具。用Windiff或VSTS自带的工具都可以。VSTS中可以通过Shelveset来支持远程代码复审。
- 4.复审者可以选择面对面的复审、独立复审或其他方式。
- 5.在面对面的复审中，一般时开发者控制流程，讲述修改的前因后果。但是复审者有权在任何时候打断叙述，提出自己的意见。
- 6.复审者必须逐一提供反馈意见。注意，复审者有权提出很多看似吹毛求疵的问题，复审者不必每一件事都要亲自调查，开发者有义务给出详尽的回答。
- 7.开发者必须负责让所有的问题都得到满足的解释或解答，或者在TFS中创建新的工作项以确保这些问题会得到处理。
- 8.对于复审的结果，双方必须达成一致的意见。（打回去/有条件地同意/放行）
2.在代码复审中还要做什么？
好的复审者不光是要注意到程序员修改了什么，还要把眼光放远，问一些这样的问题：
- “这么修改之后，有没有别的功能会受影响？”
- “项目中还有别的地方需要类似的修改么？”
- “有没有留下足够的说明，让将来维护代码时不会出现问题？”
- “对于这样的修改，有没有别的成员需要告知？”
- “导致问题的根本原因是什么？我们以后如何能自动避免这样的情况再次出现？”
有些修改看似聪明有效率，实则可能会加大以后的开发和维护的难度。
3.在代码复审后要做什么？
人不能两次踏入同一条河流，程序员不能两次犯同样的错误。在代码复审后，开发者应该把复审
过程中的记录整理出来：
- 更正明显的错误。
- 对于无法很快更正的错误，要在项目管理软件中创建Bug把它们记录下来。
- 把所有的错误记在自己的一个“我常犯的错误”表中，作为以后自我复审的第一步。
第5章 团队和流程
团队模式：
- 主治医生模式
- 明星模式
- 社区模式
- 业余剧团模式
- 秘密团队
- 特工团队
- 交响乐团模式
- 爵士乐模式
- 功能团队模式
- 官僚模式
开发流程：
- 写了再改模式（Code-and-Fix）
- 瀑布模型（Waterfall Model）
- Rational统一流程（RUP）
老板驱动地流程（Boss-Driven Process）
其他章节可以参考上面给出链接。