书籍-程序员职业素养

boss

一、下面列出了每个专业软件开发人员必须精通的事项。

设计模式。必须能描述GOF书中的全部24种模式，同时还要有 POSA 书中的多数模式的实战经验。
设计原则。必须了解 SOLID 原则，而且要深刻理解组件设计原则。
方法。必须理解XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计等。
实践。必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程。
工件。必须了解如何使用UML 图、DFD图、结构图、Petri 网络图、状态迁移图表、流程图和决策表。

二，Bob 大叔建议做好编码的准备工作如下

首先，代码必须能够正常工作。必须理解当前要解决的是什么问题以及该如何解决。必须确保编写的代码忠实遵循解决方案。必须管理好解决方案的每一处细节，并且使语言、平台、现有架构以及当前系统的所有问题和平共处。
代码必须能够帮你解决客户提出的问题。很多时候，客户提出的需求其实并没能真正解决他们自己的问题。这有赖于你去发现这些问题并与客户交流，以确保代码能够满足客户的真实需求。
代码必须要能和现有系统结合得天衣无缝。你的代码不能让系统变得更僵硬、更脆弱、更晦涩，必须要妥善管理好各种依赖关系。简而言之，编写代码时必须遵循稳健的工程原则
其他程序员必须能读懂你的代码。这不仅包括要写好注释这类事，还包括要精心锤炼代码，使它能够表达你的编程意图。要做到这点很不容易。事实上，这可能是程序员最难精通的一件事。
同时要平衡好所有这些关注点颇为困难。长时间维持高度集中精神是有难度的。再加上在团队或组织中工作时常会遭遇到各种问题与干扰，以及需要留意和关注的各种日常琐事。总之，编码时无可避免地会受到各种干扰。
当你无法全神贯注地编码时，所写代码就有可能出错。代码中可能会存在不少错误，也可能会存在错误的结构，模糊晦涩，令人费解，无法解决客户的实际问题。总之，最终你可能必须返工修改代码甚至重写。在心烦意乱的状态下工作，只会造成严重的浪费。
如果感到疲劳或者心烦意乱，千万不要编码。强而为之，最终只能再回头返工。相反，要找到一种方法来消除干扰，让心绪平静下来。

三，TDD 的三项法则

（1）在编好失败单元测试之前，不要编写任何产品代码。

（2）只要有一个单元测试失败了，就不要再写测试代码：无法通过编译也是一种失败情况。

（3）产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。

遵循这三项法则的话，大概30秒钟就要运行一次代码。先写好一个单元测试的一小部分代码，很快，你会发现还缺少一些类或函数，所以单元测试无法编译。因此必须编写产品代码，让这些测试能够编译成功。产品代码够用即可，然后再回头接着写单元测试代码。

四，Bob 大叔的时间管理

我每天早上5点起床，骑自行车上班，6点可以到布拉科内尔的办公室。这样，在一天的嘈杂开始之前，我有两个半小时安静的时间。
一到公司，我就拟定当天的计划。以一刻钟为单位，写下这段时间要做的事情。头3个小时安排得满满的。从9点开始，每小时都会留出15分钟的机动时间，这样我就可以处理计划外最紧急的状况，同时不干扰计划内的工作。
午饭之后的时间没有安排，因为我知道那时候工作节奏并不快，我也得静心准备下午的工作。午后这段时间难得没有任何干扰，我会安心做最重要的事情，直到突发情况出现。

这种计划也有不奏效的时候。每天早上5点起床并不容易，有时突发事件需要一整天来处理，所以打乱了我的周密计划。但大多数时候，我都可以把握住工作，看来想学习早期是很必须的。

五，站会（会议一般不超过10分钟）

我昨天干了什么？
今天需要干什么？
碰到了什么问题？

六，PERT 预估开发工时

你可以根据3个数字预估某项任务。这就是三元分析法。

O：乐观预估。这是非常乐观的数字。如果一切都异常顺利，你可以在这个时间内完成。实际上，为了保证乐观预估有意义，这个数字对应的发生概率应当小于1%，在Peter的例子中，这可能是1天。

M：标称预估。这是概率最大的数字。如果画一张柱状图，标称预估就是最高的那个。在图10-1中，标称预估是3天。

F：悲观预估。这是最糟糕的数字。它应当考虑到各种意外，比如飓风、核战争、黑洞、其他灾难等。为保证悲观预估有意义，这个数字对应的发生概率也应当小于1%。在Peter的例子中，这个数字是最右边的柱条，也就是12天。

七，预估任务做法

7.1 亮手指

大家围坐在桌旁。每次讨论一项任务。针对每项任务，都必须讨论这个任务涉及什么，什么因素会把它搞复杂，它应该如何实现。然后所有参与者把手埋到桌底下，根据自己的判断，伸出0〜5个手指。这时候，主持人数1一2—3,所有人都把手亮出来。如果大家伸出的手指数相同，就开始讨论下一个任务。否则，就开始讨论为什么有分歧。如此重复，直到意见统一。这里说的“统一”并不是绝对的，只要预估相近就可以。举例来说，大多数人都伸出5根手指，只有少数人伸出3根或4根手指，也算统一。但是，如果其他人都伸出4根手指，只有一个人伸出1根手指，就必须继续讨论。预估的计量单位在会议开始时就必须确定。可能是完成任务所需的天数，或者是一些有意思的单位，比如“手指数乘以3”或者“手指数的平方”。重要的是，大家必须同时亮出手来。我们不希望有人根据他人的预估改变自己的主意。

7.2 规划扑克

2002年，James Grenning写了一篇非常有启发性的论文】来描述“规划扑克”。德尔菲法的这种变体非常流行，结果很多公司都遵循它的思路，把市场推广的赠品做成规划扑克的纸牌那样2。甚至有一个网站就是planningpoker.com,依靠它，你可以在互联网上组织不在一起办公的人共同来玩规划扑克。规划扑克的玩法非常简单。向参与预估的每位成员发出不同点数的牌。如果发给每个人的牌的张数在。到5之间，那么从逻辑上说，这就是亮手指游戏。挑一个任务进行讨论。到某个时候，主持人要求每个人出一张牌。团队成员根据自己的预估选出一张牌，背面朝外，保证其他人都看不到牌的点数。然后主持人让每个人亮牌。剩下的就和亮手指一样。如果达成共识，就表示认可了预估。否则把牌收回去，继续讨论这项任务。人们已经动用了很多科学知识来为纸牌设定合理的点数，有些人甚至用到了菲波那契数列，还有人用到了无穷大符号和问号。我觉得5张点数分别为0、1、3、5、10的牌就足够了。

7.3 关联预估

关联预估(Affinity Estimation)是德尔菲法的一种特殊形式，我前几年看Lowell Lindstrom演示过。我的运气足够好，看到了不同的客户和团队使用这种方法的情形。在关联预估中，所有任务都写在卡片上，卡片上没有任何关于预估的信息。让参与预估的人围成一圈站在桌子边或是墙边，把卡片打乱铺开。大家保持静默，只是卡片按照任务所需时间的长短排序，需要时间长的放右边，短的放左边。任何时候，任何人，都可以移动任何卡片，不需要关心之前是否有人移动过。如果哪张卡片移动过超过〃次，就需要抽出来单独讨论。最终，静默的排序终止。大家开始讨论，详细了解排序意见的分歧所在，也可以通过简短的设计讨论或者手绘的线框草图来帮助取得共识。下一步是按照时间单位来给任务归类。时间单位可能是天或周或点数。按照惯例，一般选择菲波那契数列中头5个元素(1、2、3、5、8)。

7.4 三元预估

如果为单个任务做标称预估，德尔菲法是不错的办法。但是之前说过，大多数情况下需要做3种预估，才能得出概率分布。不论使用德尔菲法的哪种形式，都可以迅速得到每个任务的乐观预估值和悲观预估值。举例来说，如果选择使用规划扑克，可以要求大家根据悲观预估亮出纸牌，然后选择点数最大的那张。乐观估计也是如此，只不过是选出点数最小的那张。

八，危机中的纪律

观察自己在危机时刻中的反应，就可以了解自己的信念。如果在危机中依然遵循着你守持的纪律，就说明你确实相信那些纪律。反过来说，如果在危机中改变行为，就说明你并不真正相信常规行为中的原则。

如果在非危机时刻你会遵循测试驱动开发的纪律，但是在危机时刻你放弃了这种做法，就说明你并不真正相信TDD是有帮助的。如果在平常时候你会注意保持代码整洁，但在危机时刻你却会产出混乱的代码，就说明你并不真正相信混乱会导致速度下降。如果在危机时刻你会结对工作，但平时却不结对，就说明你相信结对工作比不结对更有效率。

选择那些你在危机时刻依然会遵循的纪律原则，并且在所有工作中都遵守这些纪律。，遵守这些纪律原则是避免陷入危机的最好途径。当困境降临时，也不要改变行为。如果你遵守的纪律原则是工作的最佳方式，那么即使是在深度危机中，也要坚决秉持这些纪律原则。