这周我学习了《构建之法》第三章，讲述了软件工程师的成长。软件系统的绝大部分模块都是由个人开发或维护的。在软件工程的术语中，这些单个的成员叫做Individ-ual Contributor（IC）。IC在团队中的流程是怎么样的呢？以开发人员为例，流程如下。

1.通过交流、实验、快速原型等方法，理解问题、需求或任务

2.提出多种解决办法并估计工作量

3.其中包括寻找以前的解决方案，因为很多工作是重复性的

与相关角色交流解决问题的提案，决定一个可行的方案

执行，把想法变成实际中能工作的代码，同时验证方案的可行性和其他特性（例如程序的效能等）

4.和团队的其他角色合作，在测试环境中测试实现方案，修复缺陷（Bug）。如果此方案有严重的问题，那么就考虑其他方案

5.在解决方案发布出去之后，对结果负责每个人的工作质量直接影响最终软件的质量

   那么初级软件工程师成长为如下几个阶段

1. 积累软件开发相关的知识，提升技术技能（如对具体技术的掌握，动手能力）

2. 积累问题领域的知识和经验（例如：对医疗或金融行业的了解） 

3. 对通用的软件设计思想和软件工程思想的理解

4. 提升职业技能（区别于技术技能）

5. 实际成果

我个人觉得第一个阶段是最为重要的，因为技术是一切的基础，只是讲实际问题和掌握的技术相结合才能更高效地完成任务。但并不是说其他几个阶段不重要，相反，技术的提升是具有饱和度的，真正在同行中一较高下的必定取决于大量的实际经验。

同时，我还了解了软件开发的工作量和质量的衡量标准

1.项目/任务有多大？ 

说明项目的大小，一般用代码行数（Line Of Code，LOC）来表示；也可以用功能点（Function Point）来表示

2.花了多少时间？ 

可以用小时、天、月、年来表示。一组人所花费的时间可以用（人数×时间）来表示，例如某项目花费了10个人×月

3.质量如何？交付的代码中有多少缺陷？ 

4.交付有两个定义

在代码完成（Code Complete）时，交付给测试人员

在软件最终发布时，交付给顾客可以用缺陷的数量来除以项目的大小。

5.是否按时交付？ 

在团队工作中，稳定、一致的交付时间是衡量一个员工能力的重要方面

这种定量的标准对我原本对软件质量模糊的概念有个直观的评判标准，让我受益匪浅。

《构建之法》第三章学习心得