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

Posted 2021-01-19 jsjliyang

第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

计划在本学期读完。

参考资料

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