2018-2019-1 20189215 《构建之法》第三章学习总结

第3章 软件工程师的成长

教材学习内容总结

1. 软件工程的术语中，单个的成员叫作Individual Contributor(IC)。

2. 软件开发流程不光指团队的流程，还包括我的开发流程，由于软件团队是由我的组成的，我的在团队中有独立的流程

3. IC在团队中的流程

   • 经过交流、实验、快速原型等方法，理解问题、需求或任务
   • 提出多种解决办法并估计工做量（其中包括寻找之前的解决方案，由于有不少工做是重复性的）
   • 与相关角色交流解决问题的提案，决定一个可行的方案
   • 执行，想法变成代码
   • 合做，测试实现方案，修复BUG
   • 发布解决方案后，对结果负责

4. 初级软件工程师的成长

   A. 积累软件开发知识、技术技能
   B. 积累问题领域的知识、经验
   C. 对通用的软件设计思想和软件工程思想的理解
   D. 提高职业技能
   E. 实际成果

5. PSP认为的软件开发的工做量和质量衡量方法

   1.任务 / 项目的大小（代码行数或者功能点）
   2.花费时间（人数 × 时间）
   3.质量 （bug的数量 / 代码行数 或者 re-work返工）
   4.是否按时交付（在团队工做中，稳定、一致的交付时间是衡量一个员工能力的重要方面）

6. 与PSP（我的软件流程）相对应的是TSP（Team Software Process）团队软件流程。TSP对团队成员的要求：

   交流：和其余成员有效地交流不管小仍是大的问题
   说到作到（好比按时交付）
   接受团队赋予的角色并按角色要求工做
   全力投入团队的工做
   按照团队流程的要求工做
   准备：开会讨论以前、开始一个新功能以前、开始一个新项目以前，都要作好准备工做
   理性地工做

7. 软件工程师的思想误区(重点！！！)

   分析麻痹

   一种极端状况，想要弄清楚全部细节、全部依赖关系以后再动手，分析太多以至于没法起步前进。

   不分主次，想解决全部依赖问题

   过于积极，想立刻动手修复全部主要和次要的依赖问题，而后就能够“完美地”达成最初设定的目标，而不是根据现有条件找到一个“足够好”的方案。

   过早优化

   一个工程师在写程序的时候，常常容易在某一个局部问题上陷进去，花大量时间对其进行优化，而无视这个模块对全局的重要性，甚至还不知道这个“全局”是怎样的。这个毛病就被概括为“过早的优化是一切罪恶的根源”。

   过早扩大化 / 泛化

   过早地想要扩展软件的功能、范围和支持的平台等。

8. 如何提升技能
   经过不断的练习，把那些低层次的问题都解决了，变成不用通过大脑的自动操做，而后才有时间和脑力来解决较高层次的问题。

感觉

本章《软件工程师的成长》给了我很大的触动，经过本章我了解到了我的在团队中所发挥的做用、在团队中的工做、在团队中也是一个独立的个体等等。特别是软件工程师的思想误区，不少都比较符合我曾经的一些想法，陷入了思想误区以后，就没法踏踏实实地先根据当前的条件，找到一个“足够好”的问题解决方案，再进行改进，这样就会影响到团队的开发工做。
关于书本P59第2题的案例，小飞在坚持本身的想法，并说服了同事，可是在开发的过程当中他意识到本身方法的缺陷，我以为这应该是属于不分主次的状况，由于他想的是完美地代称目标，而不是先找到一个“足够好”的方案。我认为在实践中，要意识到这些思想误区，当陷入进去的时候，更够自我提醒或者团队其余成员的提醒来保证团队开发的进度。

学习进度条

	章节数（新增/累积）	博客量（新增/累积）
目标	共17章	共17篇
2018.10.23	1/1	1/1
2018.11.01	1/2	1/2
2018.11.10	1/3	1/3

计划在本学期读完。

参考资料

• 《构建之法》（第三版）