目录
第三章-软件工程师的成长
3.1个人能力的衡量与发展
1.一些定义
软件工程：包括开发、运营、维护软件的过程中的很多技术、做法、习惯和思想。
软件开发流程：软件工程把这些相关的技术和过程统一到一个体系中。目的是为了提高软件开发、运营、维护的效率，以及提升用户满意度、软件可靠性和可维护性。
2.IC在团队中的流程
- 通过交流、实验、快速原型等方法，理解问题、需求或任务
- 提出多种解决方法并估计工作量（其中包括寻找以前的解决方案，因为工作重复性）
- 与相关角色交流解决问题的提案，决定一个可行的方案
- 执行，把想法变成实际中能工作的代码，同时验证方案的可行性和其他特性（如程序效能等）
- 和团队的其他角色合作，在测试环境中测试实现方案，修复缺陷，如果此方案有严重的问题，那么就考虑其他方案
- 在解决方案发布出去之后，对结果负责
3.初级软件工程师的成长
- 积累软件开发知识，提升技术技能（目前貌似对c/c++比较熟悉，希望之后对python有更深入的学习和应用）
- 积累问题领域的知识和经验
- 对通用的软件设计思想和软件工程的理解（听说这个是玄学）
- 提升职业技能
- 实际效果
4.软件开发的工作量和质量的衡量
- 项目/任务大小（代码行数，功能点）
- 时间长短（人数*时间）
- 质量（交付代码缺陷：交付的定义是在代码完成时，交付给测试人员；在软件最终发布时，交付给顾客）
- 是否按时交付？
5.团队对个人的期望
PSP对应的TSP对团队成员也有一些要求：
1.交流。
2.说到做到。
3.接受团队安排的角色并且按角色要求工作。
4.全力投入团队的活动。
5.按照团队流程的要求工作。
6.准备。
7.理性地工作。
6.软件工程师的思维误区
软件有自己的特性和规律，模块之间有复杂的依赖关系，不可见性和易变性，使得软件的依赖关系很难定义清楚，导致软件不易得到及时的维护和修复。
7.分析麻痹
一种极端情况就是想要弄清所有细节和依赖关系之后再开动，心理上过于悲观，不想修复问题，出了问题都依赖在相关问题上。就是畏手畏脚...
8.不分主次，想解决所有依赖问题
和上面的分析麻痹所存在的心理问题恰恰相反，这是心理太过于积极，最后忘了自己的最终方向。
9.过早优化
软件有很大可塑性，如果在一个局部的问题陷入然后花费大量的时间对其优化，忽略了局部的模块对全局的影响。
10.过早扩大化/泛化
一劳永逸不可取……
11.画扇面-调侃目标和远景
就是过于追求很大的东西然后最后啥也没做好...连最初的小目标都没弄好......
3.3软件工程师的职业发展
很多人的态度：
1.临时的寄托或工作
2.工作
3.职业（在工作基础上，如果有足够的职业道德和职业规划，那么可以说工作就是一个职业）
4.投身的事业
5.理想的呼唤
专和精的关系
全栈和行为艺术者。
3.3.1 职业发展-考级之路
考试考证...
3.3.2 职业成长-Steve McConnell版本
入门 Introductory
熟练 Competency
带头人 Leadership
大师 Mastery
3.3.3 职业成长-大公司版本
以微软公司为例：
入门->独立->小组领导->团队领导->整个机构的牛人，甚至工业界
3.3.4 职业成长-自我评估
以做CURD数据库系统为例…
3.4技能的反面
问题有三个层次，从低到高呈金字塔状，依次为低层次问题（变成自动操作，舒适区，精通）、中间层次的问题（脑力解决，学习区）、高层次问题（无暇顾及，恐慌区）
840
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
