1 专业主义
1.1 清楚你要什么
明确自己想要什么，因为专业主义不但象征着荣誉与骄傲，而且要明确责任和义务。既然你想当专业主义，就要承受它所应当的责任。而专业主义的精髓在于将公司利益视同个人利益，即你出发的角度应该是从专业的角度去看待问题，从公司的角度去获取利益。
1.2 担当责任
既然要有专业主义，你就得为你的代码而承担责任，对例行程序进行测试，毕竟专业人士写的代码，一旦发现错误，你就得为你的代码错误承担责任而不是推卸。所谓专业人士，就是能对自己犯下的错误负责的人
1.3 首先，不行损害之事
希波拉克底誓言：
对知识传授者心存感激；
为服务对象谋利益，做自己有能力做的事；
绝不利用职业便利做缺德乃至违法的事情；
严格保守秘密，即尊重个人隐私、谨护商业秘密。
1.3.1 不要破坏软件功能
没有人能写出完美的软件，但并不代表你不需要对这份不完美不负责。所以作为一个专业人士，要练习的第一件事就是“道歉”。并尽量保证下次不会再犯。失误率永远不可能等于零，但你有责任让它无限接近零。
让QA（质量保证）找不出任何问题
不能将QA作为你检测代码过程中的一步，而应该将QA作为最后一步，即如果你觉得没把握的代码，应该自行去测试解决，而不应该是让QA检查出来再反馈给你再改。虽然可能不能面面俱到，但是也要尽可能的解决。要确信代码正常运行
所以，为了确保代码能够正常运行，身为专业人士，也应该掌握一定的测试技巧，不能说我是开发而将一切都抛之脑后，即你写的每一行代码都要测试。这就要求开发人员也需要会写一些自动化单元测试，不需要精，但至少得会。
如果有些代码测试很难测试。是因为设计时就没考虑如何测试。唯一的解决办法就是设计易于测试的代码，先写测试代码再写要测的代码，这种方法也叫做测试驱动开发（Test-Driven Development, TDD）自动化QA
FitNesse的整个QA流程即是执行单元测试和验收测试。如果测试通过，说明能够发布了。当然，不能只靠简单的自动化测试来判断软件是否已经足够高质量，是否可以投入使用，还需要有个相对迅捷可靠的机制，来判断所写的代码是否可以正常的工作，并且不会干扰系统的其他部分。
1.3.2 不要破坏结构
所有软件项目的根本指导原则是，软件要易于修改。
描述如何创建灵活可维护的结构的软件设计原则和模式，专业开发人员会牢记这些原则和模式，并在开发软件时认真遵循。如果希望自己的软件灵活可变，那就应该时常改它。
想要证明软件易于修改，唯一的办法就是做些实际的修改。如果发现无法改动，说明需要改进设计，以便后续修改简单。
为什么大多数开发不敢不断修改他的代码，因为害怕改坏代码导致其他功能无法使用。因此，你需要一套覆盖了全部代码的自动化测试。
1.4 职业道德
雇主付出了金钱，你就必须付出你的时间和精力。你可以在其余的时间学习。一周有168小时，996算的话就72小时，再留56小时给睡眠，那还剩40小时呢？
当然工作就该在上班的时间内完成，不改再带回家，剩下的时间，你也该为自己的职业发展工作而努力。
1.4.1 了解你的领域
作为一名专业开发者，你需要不断扩展领域的知识面，过去产生的理念，已经过时了，但不代表着我们不需要了解它，毕竟前人留下的宝贵经验，在今天也依旧富有价值。正如桑塔亚纳的诅咒：“不能铭记过去的人，注定要重蹈覆辙。”
下面列出每个专业软件开发人员必须精通的事项：
设计模式。必须能描述GOF书中全部的24种模式，同时还有POSA书中多数模式的实战经验设计原则。必须了解SOLID原则，而且要深入理解组件设计原则方法。必须了解XP，Scrum，精益，看板，瀑布，结构化分析及结构化设计等。实践。必须掌握测试驱动开发，面向对象设计，结构化编程，持续集成和结对编程工件。必须了解如何使用UML图，DFD图，结构图，Petri网络图，状态迁移图标，流程图和决策表
1.4.2 坚持学习
软件行业的飞速改变，意味着软件开发人员必须坚持广泛学习才不至于落伍。
1.4.3 练习
练习，指的是在日常工作之余专门练习技能，以期待自我提升。常用的一个技巧是做一些简单的练习来训练自己的手指和大脑。以保证自己的习惯。
1.4.4 合作
学习的第二个最佳方法就是与人合作。尝试与他人一起编程，一起练习，一起设计，一起计划。这样可以从彼此身上学到很多懂西，而且能在更短的时间内更高质量的完成更多工作。当然独处的时间也很重要。
1.4.5 辅导
教学相长，想要迅速牢固地掌握某些事实和观念，最好的办法就是与你负责指导人交流这些内容。同样，让新人融入团队的最好办法就是和他们坐在一起，向他们传授工作要诀。专业人士会视辅导新人为己任，他们不会放任未经辅导的新手恣意妄为。
1.4.6 了解业务领域
每个专业软件开发人员都有义务了解自己开发的解决方案所对应的业务领域。开始一个新领域的项目时，你应该先读一两本该领域相关的书，要就该领域的基础架构与基本知识作为客户和用户访谈，了解他们的原则和价值理念。
1.4.7 与雇主/顾客保持一致
雇主的问题就是你的问题，你必须弄明白这些问题，并寻求最佳的解决方案。每次开发系统，都应该站在雇主的角度来思考，确保开发的功能能真正满足雇主的需要。
1.4.8 谦逊
编程是一种创造性活动，也是极其自负的行为。很多专业人士都会对自己写的代码表现的过于自信，自己风险评估出错的时候，可能会一笑了之，而对别犯错就会横加贬损。因此专业人士要要清楚自己的自负，要始终保持着谦逊的态度。
2 说“不”
尤达：能就是能，不能就是不能，不要说“试试看”。
专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说“不”。
2.1 对抗角色
面对艰难决定，直面不同角色的冲突是最好的办法。
提供太多细节，只会招致更多的微观管理
2.2 高风险时刻
最要说“不”的是那些高风险的危险时刻。越是关键时刻，“不”字就越具有价值。
2.3 要有团队精神
具备团队精神，意味着格尽职守，意味着党其他队员遭遇困境时你要援手相助。有团队精神的人会频繁与大家交流，会关心队友，会竭力做到尽职尽责。
2.4 说“是”的成本
健康的团队都会努力寻求给他人以肯定的答复。运作良好的团队的经理和开发人员会相互协商，直到达成共同认可的行动方案。
3 说“是”
3.1 承诺用语
口头上说。心里认真。付诸行动。
做出承诺，包含三个步骤：
口头上说自己将会去做心里认真对待做出的承诺真正付诸行动
3.1.1 识别“缺乏承诺”的征兆
需要、应当希望、但愿让我们3.1.2 真正的承诺听起来是这样的
我将在…之前…
3.1.3 总结
做出承诺或许听起来令人有点海派，但他能帮助程序员解决在沟通中可能发生的不少问题。
3.2 学习如何说“是”
表达自己的不确定感+坚守原则
3.3 结论
专业人士不需要对所有请求都回答“是”。不过他们应该努力寻找创新的方法，尽可能做到有求必应。当专业人士给出肯定回答时，他们会使用正式承诺，以确保各方能明白无误地理解承诺的内容。
4 编码
4.1 做好准备
代码必须能够正常工作代码必须能够帮你解决客户提出的问题代码必须要能和现有系统结合得天衣无缝其他程序员必须能读懂你的代码。在心烦意乱的状态下工作，只会造成严重的浪费。如果感到疲劳或者心烦意乱，千万不要编码，要找到一种方法来消除干扰，让心绪平静下来。
4.1.1 凌晨3点写出的代码
奉献精神和职业素养，更多意义上指要遵循纪律原则而非成为长时间工作的工作狂。要确保自己已经将睡眠，健康和生活方式调整到最佳状况，这样才能做到在每天的8小时工作时间内全力以赴。
4.1.2 焦虑时写下的代码
关键所在是要学会如何关闭自己的后台进程，或至少要能够降低其优先级，这样焦虑就不会造成持续的干扰。专业开发人员应该善于合理分配个人时间，以确保工作时间段尽可能富有成效。
4.2 流态区
流态区，即在程序员在编写代码时会进入的一种意识高度专注但思维视野却会收拢到狭窄的状态。在这种状态下，他们会感到效率极高。然而在这种状态下，为了追求所谓的速度，理性思考的能力会下降。
结对编程，两个程序员在一个计算机上共同工作。其最大的好处在于，结对中的任一方都不可能进入流态区。
4.2.1 音乐
音乐有助于你编写代码，也会消耗一部分宝贵的脑力资源，因人而异。
真实的情况是，音乐正带领他们进入流态区。
4.2.2 中断
结对是用以应对中断的一种好方法，结对搭档能够维护住中断处的上下文。
另一种方法便是TDD。失败的测试能够帮助你维护住编码进度的上下文。
礼貌地表现出乐于助人的态度才是专业的态度。
4.3 阻塞
造成阻塞的因素：睡眠，焦虑，恐惧和沮丧
解决方法：找一个搭档结对编程
创造力会激发创造力
4.4 调试
调试时间和编码时间一样昂贵，重视调试过程。
4.5 保持节奏
当碰到困难而受阻时，离开一会，给自己一点短暂的休息，能够让自己保持更好的节奏在回家的路上，你必须暂时从工作问题中脱离出来，有助于大脑以不同的但更具有创造性的方式搜球各种解决方案洗澡的时候，能让自己更加清醒，同时也能够让自己更有灵感4.6 进度延迟
管理延迟的诀窍，便是早期检测和保持透明
使用三个考虑到多种因素的期限：乐观预估，标称预估，悲观预估
不应该采用额外加班加点工作的方案，除非以下3个条件能够满足：
个人能够挤出这些时间短期加班，最多加班两周有后备预案，以防加班措施失败。
4.7 帮助
互相帮助是每个程序员的职责所在。如果有人向你伸出援手，要诚挚接受，心怀感激地帮助并诚意合作。花时间手把手地辅导年轻程序员是资深程序员的专业所在。同样的，向资深导师寻求辅导也是年轻程序员的专业职责。5 测试驱动开发
5.1 此时已有定论
TDD绝不仅仅是一种用于缩短编码周期的简单技巧。
首先声明以下几点：
此事已有定论争论已经结束GOTO是有害的TDD确实可行
5.2 TDD的三项法则
在编号失败单元测试之前，不要编写任何产品代码只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。循环不断重复：写一些测试代码，然后再写一些产品代码。
5.3 TDD的优势
确定性缺陷注入性勇气。优化后无需害怕会破坏其功能性。文档。单元测试即是文档。它们描述了系统设计的最底层设计细节设计。测试代码的一个问题是必须隔离出待测试的代码。TDD是专业人士的选择。它是一项能够提升代码确定性，给程序员鼓励，降低代码缺陷率，优化文档和设计的原则。
5.4 TDD的局限
遵循三项法则并不能担保一定会带来好处，也和写出的测试代码有关。在某些场合照三项法则去做会显得不切实际或不合适。6 练习
6.1 引子
现在的我们有了更好的工具，更好的语言。可是，语句的本质并没有随时间而改变。要想自如的弹奏，也需要练习。乐手需要反复弹奏音阶，各种练习曲，重复的节奏，直到烂熟于胸。6.2 变成柔道场
保龄球：/ArticleS.UncleBob.TheBowlingGameKata
素因子：/ArticleS.UncleBob.ThePrimeFactorsKata
6.3 自身经验的扩展
开源。保持不落伍的一种方法是为开源项目贡献代码。关于练习的职业道德。职业程序员用自己的时间来练习。7 验收测试
职业程序员会重视与团队及业务部门的沟通，确保这种沟通的准确，流畅。
7.1 需求的沟通
开发方与业务方之间最常见的沟通是关于需求的。
7.1.1 过早精细化
不确定原则。每次你向业务方展示一项功能，他们就获得了比之前更多的信息，这些信息反过来又会影响他们的对整个系统的看法预估焦虑。7.1.2 迟来的模糊性
避免过早精细化的办法就是尽可能地推迟精细化。但也会造成另外一个问题：迟来的模糊性。
专业开发人员必须确认，需求中没有任何不确定因素。
7.2 验收测试
验收测试就是在接受正式发布之前由用户执行的程序。是业务方写给业务方的。它们是正式的需求文档，描述了业务方认为系统应该如何运行。
不同团队对“完成”的定义各不相同。专业开发人员会根据自动化的验收测试来定义需求。验收测试的目的是沟通，澄清，精准化。自动化。验收测试都应当自动进行，要考虑到成本问题。不要把测试看做额外的工作。写测试是为了确定系统的各项指标符合要求。理想状态下，验收测试由业务方和QA协作编写这些测试，程序员来检查测试之间是否有冲突或矛盾。但实际上，通常会把测试交给业务分析员，QA甚至开发人员。开发人员有责任把验收测试与系统联系起来，然后让这些测试通过。身为开发人员，你的职责是协助团队开发出最棒的软件。单元测试是程序员写给程序员的，它是正式的设计文档，描述了底层结构及代码的行为。测试系统功能时，应当调用真实的API，而不是GUI。务必确保在持续集成系统中，单元测试和验收测试每天都能运行好几次。
8 测试策略
8.1 QA应该找不到任何错误
QA也是团队的一部分。QA在团队中要扮演的是需求规约定义者（specifier）和特性描述者（characterizer）
需求规约定义者：QA的任务便是和业务人员一起创建自动化验收测试，作为系统真正的需求规约文档。通常，业务人员编写针对正常路径的测试，而由QA编写针对极端情况、边界状态和异常路径的测试。特性描述者：遵循探索式测试的原则，描述系统运行中的真实情况，将之反馈给开发人员和业务人员。
8.2 自动化测试金字塔
单元测试：100%组件测试：50%继承测试：20%系统测试：10%人工探索式测试：5%9 时间管理
9.1 会议
关于会议有两条真理：
会议室必需的
会议浪费了大量的时间
如果你收到会议邀请，务必确保出席会议可以给自己目前的工作带来切实且显著的成效，否则不必参与。
如果会议让人厌烦，就离席
我们之所以愿意承担开会的高额成本，是因为有时候确实需要所有参与者坐在一起，来实现某个目标。为了合理使用与会者的时间，会议应当有清晰的议程，确定每个议题所花的时间，以及明确的目标。
开早会的时候，所有参会者站着，到场人依次回答：
我昨天干了什么？我今天打算干什么？我遇到了什么问题？
在会议召开前必须完成两项任务：评估可选择人物的开发时间，确定这些人物的业务价值。
迭代回顾和Demo展示
如果争论必须解决，就应当要求争论各方在5分钟时间内向大家摆明问题，然后大家投票。这样，整个会议花的时间不会超过15分钟。
9.2 注意力点数
编程是需要持续投入精力和注意力的智力活动。
恢复注意力点数的方法：
睡眠咖啡因注意力肌肉注意力输入和输出
9.3 时间拆分和番茄工作法
番茄工作法：设定25分钟。倒计时期间内不要让任何事情干扰你的工作。25分钟到了以后，停下手上的工作，转去处理25分钟内遇到的其他事情，之后休息5分钟。然后再把定时器设定为25分钟，开始一个新的番茄时间段。每完成4个番茄时间段时间，休息30分钟左右。
9.4 要避免的行为
专业开发人员会评估每个任务的优先级，排除个人的爱好和需要，按照真实的紧急程度来执行任务。
9.5 死胡同
专业开发人员不会执拗于不容放弃也无法绕开的主意。他们会保持开放的头脑来听取其他意见，所以即使走到尽头，他们仍然有其他选择。
9.6 泥潭
慎重的态度和积累的经验有助于避免避开泥潭，但无法彻底避开每一处泥潭。
10 预估
10.1 什么是预估
不同的人对预估有不同的看法。业务方觉得预估就是承诺。开发方认为预估就是猜测。
10.2 PERT
计划评审技术（PERT，Program Evaluation and Review Technique），即对预估的计算方法。
O：乐观预估
N：标称预估
P：悲观预估
μ：任务的期望完成时间
δ：任务的概率分布的标准差
μ =（O+4N+P）/6
δ =（P-O）/6
10.3 预估任务
德尔菲法：一组人集合起来，讨论某项任务，预估完成时间，然后重复“讨论-预估”的过程，直到意见统一。
10.4 大数定律
大数定律：把大任务分成许多小任务，分开预估再加总，结果会比单独评估大任务要准确很多
11 压力
11.1 避免压力
在压力下保持冷静的最好方式，便是规避会导致压力的处境。当无法回避时则勇敢直面压力。
遵守这些纪律原则是避免陷入危机的最好途径。
11.2 应对压力
不要惊慌失措沟通依靠你的纪律原则寻求帮助12 协作
12.1 程序员与人
专业程序员的首要职责是满足雇主的需求，让业务免于陷入困顿，让公司可以长久发展下去。
程序员之间通常很难密切合作，这就会带来一些问题：
代码个体所有协作性的代码共有权结对
12.2 小脑
有些时候，单独工作是正确的。但是一般来说，和其他人密切协作、在大部分时间段中结对工作，是最好的做法。
