构建之法第三章学习小记
0.写在前面
看了《构建之法》这本书，更多的注重实际，和我们在课堂的学到的东西完全不同，更多的是职场上的事。书中的每个问题都能引发我的深思，这些问题都是我在校园中根本发现不到的，瞬间感觉到一只“井底之蛙”的失落，又有发现新大陆的快感。就随便写篇博客记录一下吧。
1.引子
- 首先先看一个问题：
以前我觉得，公司中的大佬级别和刚进去的菜鸟程序员的行为会有天差地别的差距。但是事实上他们每天做的事情都是一样的：“每天在电脑前敲敲打打，有时候查邮件……”。这根本就看不出什么区别嘛
- 那么问题来了：高级程序员到底强在何处？为什么做同样的事情，他们却可以拿到更高的工资？
- 当初我对这个问题的答案是：高级工程师的代码能力更强，能在很短的时间内完成任务。
2.如何衡量个人能力？
- 举一个足球运动员的例子：
- 爱看球的我们知道，职业足球队对足球运动员有很高的要求：
体能、技术、意识、斗志。
- 当然，上面的都是个人能力。除此之外，懂得团队配合也是很重要的“个人能力”。
阵型、配合、临产应变。
软件开发团队和球队一样，不单单有团队流程，也有个人流程。把每个人的工作有序的组织起来，就是团队的流程。有序不是指直接安排好的，这个有序是建立在大家的讨论上，消除矛盾、经过协商得到的“有序”。
- 那么对于运动员来说，每场比赛结束后都有得分统计，上场时间等一些可视化的数据。但是在一次软件开发以后，并没有明显的数据来衡量一个人的实力。那么，如何来衡量一位工程师的能力呢？
- 我对这个问题回答是：代码量与完成任务的时间与质量（返工次数）。
- 带着自己的答案继续看下去，发现自己遗漏了重要的一点：稳定！完成任务速度用时少是好事，但是完成时间的标准方差也是衡量一个程序员的重要因素。
现在有三个任务：1，2，3，程序员A完成这三个任务用时分别为：1，9，11、程序员B完成这三个任务用时分别为：7，8，9。从总用时来看程序员A的平均用时比B的少一天，似乎是A稍稍优秀一点，但是从标准方差的角度看，显然B会A的交付时间会稳定的多。
- 在实际的工作中，稳定、一致的交付时间是衡量一个员工能力的重要方面。
- 一个成熟的软件工程师往往可以降低自己的标准房差。如果你能长时间稳定而按时交付自己的任务，不管是同事还是客户都会对你更有信心，更愿意与你合作！
3. 团队对个人的期望（TSP）
大多数工程师都在团队的环境下工作，怎么才算是一个合格的、优秀的队员呢？
- 交流：及时发现问题并解决。
- 说带做到：按时、稳定的交付任务
- 接受多重角色，并按要求完成任务
- 全身心的投入团队的工作中
- 按照团队的流程来工作，不要过分的专注与个人流程。
- 充分的准备每次组会讨论
4. 技能的反面
相信小时候大家都玩魔方吧，刚刚开始玩的时候我们都可以按照口诀迅速的把魔方还原。这时“精通玩魔方”就算是我们的一个“技能”了。那么技能是用来干什么的呢？或者说技能的反面是什么？
巴克斯顿说，技能的反面是“problem solving”——解决问题。
- 我们来看一个例子
一个IT专业的大学生来面试，简历上写着“精通visual studio C#编程”。于是面试官叫他用他最精通的IDE写一段程序。其实这就是一个解决问题的过程。
