注：这本书跟我之前看过的另一本书 断舍离 ——《代码整洁之道》读书笔记 是同一个作者，即 Robert C·Martin。
第1章 专业主义
1、承担责任
- 将公司利益视同个人利益。
- 没有对例行程序进行测试就交付软件是不负责任的。例如把自己没有全盘检查过的代码发送过去，想等QA找出bug再反馈回来。
2、代码易于修改和时常修改
如果你希望自己的软件灵活可变，那就应该时常修改它！这完全与大多数人对软件的理解相反。他们认为对上线运行的软件不断地做修改是危险的。错！让软件保持固定不变才是危险的！如果一直不重构代码，等到最后不得不重构时，你就会发现代码已经“僵化了”。
他们对待代码，就如同雕塑家对待泥巴那样，要对它进行不断的变形与塑造。
3、与时俱进
① 与时俱进自己领域的知识
你会找那些已经不看医学期刊的医生看病吗？你会聘请那些不了解最新税法和判例的税务律师吗？雇主们干吗要聘用那些不能与时俱进的开发人员呢？
② 与时俱进其他（业务）领域的知识
开始一个新领域的项目时，应当读一两本该领域相关的书，要就该领域的基础架构与基本知识作客户和用户访谈，还应当花时间和业内专家交流，了解他们的原则与价值观念。
4、换位思考
每次开发系统，都应该站在雇主的角度来思考，确保开发的功能真正能满足雇主的需要。
5、等等
下面即娓娓道来。
第2章 说“不”
1、敢于说”不“，而不是”试试看“
Frank大发雷霆，整栋大楼都能听到他的咆哮声，久久不散。于是Bill和我们的系统分析师Jalil过来问我们，什么时候才能让系统稳定下来。我说：“4周。”他们吓坏了，转而一脸决绝地说：“不行，在周五之前必须让系统跑起来！”
……
但是 Bill 和 Jalil 也很顽固：“不行，一定要在周五前。你们至少也该试一试吧？”我们的组长于是说：“好吧，我们试试看吧。”
……
专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说“不”。
最要说“不”的是那些高风险的关键时刻。越是关键时刻，“不”字就越具价值。
现实中，程序员的话语权还是很低的，尤其是在乙方公司，大多还是依着客户。
2、有时候开发比客户还操心交付
客户永远不会像你那么在乎尽管客户一再声明交付日期很重要，尽管他们对此表现得似乎非常迫切，但他们永远不会像你那样在乎应用程序的按时交付。那天下午，我宣告应用程序开发完毕，把最终构建版本通过电邮发给所有相关人员，主管们（嘘！）、经理们，一干人等。“搞定了！我给你们带来V1.0版啦！感谢上帝，我称颂您的美名。”我点了“发送”按钮，仰靠在椅子上，开始自鸣得意地笑着想象大家会如何把我抬到肩上，冠我以“史上最伟大的开发人员”的美名，列队走过第42大街……至少，我的形象将会出现在他们的各种广告上，对吧？有意思的是，他们似乎对此不以为意。事实上，我有点捉摸不透他们在想些什么。我没听到任何反响。一丁点儿也没有。原来，猩猩卖场的那些家伙已经热切地把精力转移到下一件事儿上了。
因为程序员仅仅只专注在开发上，天天脑子里想的都是按时交付的压力，而这只是客户操心的事中的一件（微不足道的）事。
3、压缩开发的时间有时只是为了给未来可能提出的新需求留 buffer
一而再地推后项目截止日期。给到开发人员的截止期限往往只有几天，他们为此要飞速拼命地赶工。（顺便说一下，这也是开发人员最容易犯的错，但这已是家常便饭，谁又会在乎呢，对吧？）既然他们已经这么高效了，为什么又跟他们说可以将日期延后呢？占便宜啊！就是这样，在你已加班20小时把一切差不多都弄好时，他们又多给了你几天时间，然后又再加一周时间，好提出新的需求……就仿佛是驴和胡萝卜的关系，只是，你的待遇连驴子都还不如呢。
在经济全球化时代，企业唯利是图，为提升股价而采用裁员、员工过劳和外包等方法，我遇到的这种缩减开发成本的手段，已经消解了高质量程序的存在价值和时宜了。只要一不小心，我们这些开发人员就可能会被要求、被指示或是被欺骗去花一半的时间写出两倍数量的代码。
压榨的恶性循环。
第3章 说“是”
1、识别缺乏承诺
以下示例中包含的几个用词和短语，会透露“缺乏承诺”的蛛丝马迹，要注意搜寻。
需要/应当：“我们要把这活做完。”、“我需要减肥。”、“有人应当负责去推动这件事。“
希望/但愿：“希望明天我能完成这个任务。”、“希望改天我们能再见面。”、“但愿我有时间做这件事。”、“但愿电脑能快点。”
让我们（而不是“让我”）：“让我们回头再见。”、“让我们把这事做完。”
有些人只是习惯了说说，千万别当真。
2、识别真正的承诺
略
3、承诺后如果后悔，一定记得及时预警
如果你承诺要解决某个你认为可以解决的 bug，但随后发现解决起来要远比自己预想的棘手，你可以发出预警信号。这样一来，项目组还可以做些研究，决定是否采取一些行动（结对工作、挖掘可能的解决方案、进行头脑风暴）来达成目标，或者调整优先级，安排你先去修复其他简单些的 bug。在此，有一点相当重要：如果你不尽早告诉他人可能的问题，就错失了让他们帮助你达成目标、兑现承诺的机会。
第4章 编码
1、注意力
注意力是稀缺的资源，它类似魔力点数。
（1）编程需要注意力
当你无法全神贯注地编码时，所写代码就有可能出错。
如果感到疲劳或者心烦意乱，千万不要编码。强而为之，最终只能再回头返工。（我最糟糕的代码，是在凌晨3点写出来的。）相反，要找到一种方法来消除干扰，让心绪平静下来。
（2）注意力是怎么消耗的？
- 集中注意力做事
- 忧虑和分心
（3）注意力如何补充？
- 睡眠
- 适量的咖啡因
注意：咖啡因也会给你的注意力添乱。太多咖啡因会把你的注意力偏转到奇怪的方向。太浓的咖啡会搞得你一整天都沉溺于不重要的事情。
- 做不需要注意力的事情，这样注意力点数可以缓慢恢复。漫步一段长路，与朋友聊天，看看窗外；沉思、反省，听播客或者翻翻杂志。等等。
- 冥想
- 肌肉注意力有助于改善心智注意力（甚至提升心智注意力的上限）。例如搏击、太极、瑜伽之类体力锻炼；体力活动如骑车；手工活如做木工活、制作模型、清理花园。
本人是 adhd（注意缺陷障碍）轻度患者，所以对这块有研究，也尝试用一些办法治疗自己。感兴趣的同好可以看这本书更多的了解：《分心不是我的错》
2、流态区
（1）警惕流态区
有些程序员将之称为“流态区”。不管用什么名字，你可能都不陌生，甚至有过这种体验。这是程序员在编写代码时会进入的一种意识高度专注但思维视野却会收拢到狭窄的状态。在这种状态下，他们会感到效率极高；在这种状态中，他们会感到“绝无错误”。
一些曾经进入这种状态但终又从中摆脱出来的人给出了一点儿忠告：避免进入流态区。这种意识状态并非真的极为高效，也绝非毫无错误。这其实只是一种“浅层冥想”状态，在这种状态下，为了追求所谓的速度，理性思考的能力会下降。在流态区写代码可能会快些，但是后面你将不得不更多地回头重新审视这些代码。
（2）常见的进入流态区的行为
- 我过去习惯放着唱片，边听音乐边写代码，那时我以为这样有助于集中注意力。但是我错了。
- 粗暴相对的回应方式通常都是因为流态区所致。被他人从流态区中拉出来，或者当你正努力进入流态区却被其他人干扰时，你可能都会十分生气。
（3）怎么走出流态区？
- 现在，当我感觉自己将要滑入流态区时，就会走开几分钟。我会通过回复几封邮件或者翻看几条推特来换换脑筋。如果时间已近中午，我会停下来去吃午饭。如果我正和一个团队一起工作，则会去找一个结对编程的搭档。结对编程最大的一个好处在于，结对中的任一方都不可能进入流态区。流态区是一种与世隔绝的状态，而结对则要求持续密切地进行沟通。
- 结对是用以应对中断的一种好方法。当你接答电话或回答其他同事的问题时，结对搭档能够维护住中断处的上下文。等到你重新回去和结对搭档一起工作时，他能够很快地帮你恢复被打断前的思维。
- TDD。失败的测试能帮你维护住编码进度的上下文。当处理完中断重新回去时，你很清楚下一步任务便是让这个失败的测试通过。
3、创造力
- 平衡输入与输出。编程是一项创造性劳动。我发现，如果能接触到其他人的创造性思维，我的创造力也最旺盛，所以我阅读大量的科幻小说。这些作者的创造力会激发我对软件的创造力。
伟大的艺术家和伟大的工程师有一点是相通的，那就是都有表达自己的欲望。
- 我曾在下班开车回家的路上，解决了许多问题。开车会占用大量与创造性无关的脑力资源。你必须让眼睛、双手和大脑专注于开车，因此，你必须暂时从工作问题中脱离出来。而从问题中暂时脱离出来，十分有助于大脑以不同的但更具创造性的方式搜求各种解决方案。
- 我也曾经在洗澡时解决了大量问题。也许是清晨的水流能够将我彻底唤醒，使我可以深入盘点昨晚睡觉时大脑中浮现的所有解决方案。
第5章 测试驱动开发（TDD）
1、什么是 TDD
“测试驱动开发”（TDD）自在行业中首次亮相，至今已经有十余年了。它最早是极限编程（XP）运动的一部分，但此后已经被 Scrum 和几乎所有其他敏捷方法所采纳。即使是非敏捷的团队也在实践 TDD。
TDD 的基本原则：
- （1）在编好失败单元测试之前，不要编写任何产品代码。
- （2）只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况。
- （3）产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。
遵循这三项法则的话，大概30秒钟就要运行一次代码。
2、TDD 好处
- 单凭测试全部通过，我便敢冒可能的风险发布代码。
- 拥有一套值得信赖的测试，便可完全打消对修改代码的全部恐惧。
- 单元测试即是文档。它们描述了系统设计的最底层设计细节。
- 测试代码的一个问题是必须隔离出待测试的代码。如果一个函数调用了其他函数，单独测试它通常会比较困难。为了编写测试，你必须找出将这个函数和其他函数解耦的办法。换言之，测试先行的需要，会迫使你去考虑什么是好的设计。
第6章 练习
1、练习的重要性
如果有两个习武者在搏斗，每个人都必须能够迅速识别出对方的意图，并且在百分之一秒内正确应对。在搏斗时，你不可能有充足的时间来研究架势，思考如何应对。这时候，你只能依靠身体的反应。实际上，真正做出反应的是你的身体，大脑是在更高级的层面上思考。在每分钟进行许多次编码/ 测试的状态下，你身上的肌肉记忆了要敲哪个键。意识中较基础的部分识别情景，在百分之一秒的时间内做出合适的反应，大脑则可以放心思考更高层次的问题。无论是搏斗还是编程，速度都来源于练习。
练习的时候你是赚不到钱的，但是练习之后，你会获得回报，而且是丰厚的回报。
2、一个人的练习 —— 卡塔
在武术里，卡塔是一套设计好的、用来模拟搏斗一方的招式。目标则是要逐步把整套招式练习到纯熟。习武者努力训练自己的身体来熟悉每一招，把它们连贯成流畅的套路。训练有素的卡塔看起来相当漂亮。漂亮还是其次，**练习卡塔并不是为了舞台表演。训练意识和身体是为了真正搏斗时能够正确应对。它的目的在于，在需要的时候，可以凭借本能完美出招。**与之类似，编程卡塔也是一整套敲击键盘和鼠标的动作，用来模拟编程问题的解决过程。练习者不是在解决真正的问题，因为你已经知道了解决方案。相反，你是在练习解决这个问题所需要的动作和决策。编程卡塔的最终目标，也是逐步练习以达到纯熟。
3、两个人的练习 —— 瓦萨
我学习忍术（jujitsu）时，在练习场上会花很多时间用于两个人练习瓦萨（wasa）。瓦萨基本可以说是两个人的卡塔。其中的招式需要精确地记忆，反复演练。一个人负责攻，另一个人负责守。攻守双方互换时，各种动作要一而再、再而三地重复。程序员可以用一种叫“乒乓”的游戏来进行类似的练习：两个人选择一个卡塔，或者一个简单问题，一个人写单元测试，另一个人写程序通过单元测试，然后交换角色。 如果选择标准的卡塔，结果就是两人都去练习，点评对方敲键盘和挪鼠标的技巧和对卡塔的记忆准确性。不过，如果选择解决一个新的问题，游戏会更有意思一些。写单元测试的程序员会极力控制解决问题的方式，他也有足够的空间来施加限制：如果程序员选择实现一个排序算法，写测试的人可以很容易地限制速度和内存，给同伴施压。 这样整个游戏就非常考验人……也可以说是非常有趣。
4、贡献开源项目
略
第8章 测试策略
1、自动化测试金字塔
（1）单元测试
单元测试由开发人员编写。
单元测试是可行的，而且可以做到接近100%的覆盖率。通常而言，这个数字应该保持在90%以上。
（2）组件测试
组件测试由QA和业务人员编写，开发人员提供辅助。
组件测试差不多可以覆盖系统的一半。它们更主要测试的是成功路径的情况，以及一些明显的极端情况、边界状态和可选路径。
大多数的异常路径是由单元测试来覆盖测试的。在组件测试层次，对异常路径进行测试并无意义。
（3）集成测试
这些测试只对那些组件很多的较大型系统才有意义。
集成测试一般由系统架构师或主设计师来编写。
集成测试是编排性（choreography）测试。它们并不会测试业务规则，而是主要测试组件装配在一起时是否协调。
在这个层次上，也许已经可以进行性能测试和吞吐率测试了。
注：
1、集成测试多使用与组件测试同样的语言和环境来编写
2、一般不会作为持续集成的一部分，因为集成测试的运行时间通常都比较长。
（4）系统测试
系统测试由系统架构师和技术负责人来编写。
这些测试是针对整个集成完毕的系统来运行的自动化测试，是最终的集成测试。它们不会直接测试业务规则，而是测试系统是否已正确组装完毕，以及系统各个组成部件之间是否能正确交互。
在这个层次的测试集中，应该包含吞吐率测试和性能测试。
（5）人工探索式测试
这是需要人工介入、敲击键盘、盯牢屏幕的测试。为了达到这个目的，需要人类智慧的介入，需要使用人类的创新能力，对系统进行深入研究和探索。预先编写测试计划反而会削弱这类测试的效果。
有一些团队可能会安排专人来进行探索式测试。也有一些团队可能只会安排一两天的“抓虫”活动，让尽可能多的人参与其中，其中也许会包括管理人员、秘书、程序员、测试人员和技术写作人员，大家一哄而上，看是否会让系统崩溃。
第7章 验收测试
注：这里我把 第7章 跟第8章 顺序颠倒了下，因为根据项目流程阶段划分，验收测试是在最后的。
1、什么是验收测试
有人认为，验收测试就是在接受正式发布之前由用户执行的程序，也有人认为它是 QA 测试。在本章，我们把验收测试定义为业务方与开发方合作编写的测试，其目的在于确定需求已经完成。
我司也是， 我们的
UAT（User Acceptance Testing 用户验收测试）环境是提供给我们 QA 和客户测的。
完成意味着所有的代码都写完了，所有的测试都通过了，QA和需求方已经认可。这，才是完成。
2、验收测试跟普通测试的区别
验收测试则是在系统外部，通常是在API或者是UI级别进行。
要把GUI和业务逻辑分开。
而普通测试应当尽可能地减少 GUI 测试。 GUI 很容易变化，所以这类测试是不稳定的。 GUI 测试越多，维护它们的难度就越大。
第9章 时间管理
1、会议
（1）需要避免的会议
- 浪费时间的会议
- 发泄情绪的会议
- 一面之词，让大家站队的会议
主要就是浪费时间，其他都是浪费时间的子情况。
受到邀请的会议没有必要全部参加。参加的会议太多，其实只能证明你不够专业。
（2）怎样避免会议
1、如果会议让人厌烦，就离席。再说一次，仔细管理自己的时间是你的。
离席要优雅。
2、领导的最重要责任之一，就是帮你从某些会议脱身。好的领导一定会主动维护你拒绝出席的决定，因为他和你一样关心你的时间。
（3）如何开好会议
在敏捷开发的武器库中，这大概是难度最大的会议了。如果做得不好，可能浪费大量的时间。
1、迭代计划会议
迭代计划会议用来选择在下一轮迭代中实现的开发任务。
在会议召开前必须完成两项任务：评估可选择任务的开发时间，确定这些任务的业务价值。如果组织得足够好，验收/组件测试也应当在会议召开前完成，或者至少要有概略方案。会议的节奏应该足够快，简明扼要地讨论各个候选任务，然后决定是选择还是放弃。会议在每个任务上所花的时间应该限制在 5 到 10 分钟。如果需要更详细的讨论，则应当另选时间，挑出团队中的一部分人专门进行。
凭我的经验，在每轮迭代中，这类会议所花的时间不应当超过 5%。如果一周（ 40 小时）为一个迭代周期，这类会议时间应当限制在 2 小时内。
2、解决会议的争论
如果观点无法在短时间（5～30分钟）里达成一致，就永远无法达成一致。
Kent Beck曾告诉我一个深刻的道理：“凡是不能在5分钟内解决的争论，都不能靠辩论解决。”。
方法一：用数据说话。
主观得不到支持，那就只能客观说话了。
方法二：要求争论各方在 5 分钟时间内向大家摆明问题，然后大家投票。
注意：有人会表现得非常被动。他们同意结束争论，之后却消极对待结果，拒绝为解决问题出一份力。他们会安慰自己说：“既然其他人想要这么办，就这么办吧。”这可能是非专业的行为中最糟糕的了。千万千万不要这样做。如果你同意了，就必须拿出行动来。
2、立会（standup）
敏捷开发的武器库中包含“立会”：在开会时，所有参会者都必须站着。到场的人依次回答以下 3 个问题：（1）我昨天干了什么？（2）我今天打算干什么？（3）我遇到了什么问题？这就是全部会议内容。每个问题的回答时间不应当超过 20 秒，所以每个人的发言不超过 1 分钟。即便是 10 个人的小组，开一次这种会议的时间也不会超过 10 分钟。
立会是我们公司每天都要做的，确实不错，即倒逼自己梳理，也能促进沟通知晓进度。
3、番茄钟
一天中你有几个番茄时间段？不错的情况下你可以有12～14个番茄时间段。
差不多 6-7 个小时。如果一天能高效这么久，已经不错了。
4、坑 与 泥潭
所有软件开发者都要遇到死胡同。比如你做了决定，选择了走不通的技术道路。你对这个决定越是坚持，浪费的时间就越多。如果你认为这关系到自己的专业信誉，就永远也走不出来。这就是所谓的坑法则（The Rule of Holes）：如果你掉进了坑里，别挖。
比死胡同更糟的是泥潭。泥潭会减慢你的速度，但不会让你彻底停下来。在泥潭中继续前进的危害是不易察觉的。
我觉得防止掉进坑和泥潭的办法是，运用番茄钟，及时中断自己，然后养成时不时停下来审视反省思考的习惯。
第10章 预估
不能兑现的承诺也是一种欺骗，只不过比明目张胆的欺骗好一点。
1、先评估，避免过早精细化
做业务的人和写程序的人都容易陷入一个陷阱，即过早进行精细化。需求是一定会变化的，所以追求那种精确性是徒劳的。
需求变化的一种原因：在工作中，有一种现象叫
观察者效应，或者不确定原则。每次你向业务方展示一项功能，他们就获得了比之前更多的信息，这些新信息反过来又会影响他们对整个系统的看法。
专业开发人员知道，评估可以而且必须基于不那么精确的需求，这些评估只是评估而已。为强调这点，职业开发人员通常会在评估中使用误差棒。
专业开发人员直到着手开发的前一刻才会把需求具体化。
2、评估方法论
（1）三元分析法
你可以根据3个数字预估某项任务。这就是三元分析法。
- O：
乐观预估。这是非常乐观的数字。如果一切都异常顺利，你可以在这个时间内完成。实际上，为了保证乐观预估有意义，这个数字对应的发生概率应当小于1%。 - N：
标称预估。这是概率最大的数字。如果画一张柱状图，标称预估就是最高的那个。 - P：
悲观预估。这是最糟糕的数字。它应当考虑到各种意外，比如飓风、核战争、黑洞、其他灾难等。为保证悲观预估有意义，这个数字对应的发生概率也应当小于1%。
有了以上三个预估，我们可以像下面这样描述概率分布： μ=(O+4N+P)/6
（2）德尔菲法
20世纪70年代，Barry Boehm向我们介绍了称为“德尔菲法”（wideband delphi）的估量方法
办法非常简单。一组人集合起来，讨论某项任务，预估完成时间，然后重复“讨论－预估”的过程，直到意见统一。
例如亮手指方法：亮手指大家围坐在桌旁。每次讨论一项任务。针对每项任务，都必须讨论这个任务涉及什么，什么因素会把它搞复杂，它应该如何实现。然后所有参与者把手埋到桌底下，根据自己的判断，伸出 0 ～ 5 个手指。这时候，主持人数 1－ 2－ 3，所有人都把手亮出来。如果大家伸出的手指数相同，就开始讨论下一个任务。否则，就开始讨论为什么有分歧。如此重复，直到意见统一。
（2）大数定律
该定律的意思是：把大任务分成许多小任务，分开预估再加总，结果会比单独评估大任务要准确很多。这样做之所以能提高准确度，是因为小任务的预估错误几乎可以忽略，不会对总的结果产生明显影响。
第11章 压力
1、有压力也要坚守纪律原则
如果在非危机时刻你会遵循测试驱动开发的纪律，但是在危机时刻你放弃了这种做法，就说明你并不真正相信TDD是有帮助的。如果在平常时候你会注意保持代码整洁，但在危机时刻你却会产出混乱的代码，就说明你并不真正相信混乱会导致速度下降。如果在危机时刻你会结对工作，但平时却不结对，就说明你相信结对工作比不结对更有效率。
当困境降临时，也不要改变行为。如果你遵守的纪律原则是工作的最佳方式，那么即使是在深度危机中，也要坚决秉持这些纪律原则。
第12章 协作
1、与业务同舟共济
专业程序员最糟糕的表现是两耳不闻窗外事，只顾一头将自己埋在技术堆里，甚至连公司业务火烧眉毛行将崩溃了也不闻不问。你的工作职责就是要让业务免于陷入困顿，让公司可以长久发展下去。因此，专业程序员会花时间去理解业务。他们会和用户讨论他们正在使用的软件，会和销售人员与市场人员讨论所遭遇的问题，会和经理们沟通，明确团队的短期目标和长期目标。简而言之，他们会将注意力放在与业务同舟共济上。
2、结对编程
略
3、团队伙伴互相帮助
要清楚团队伙伴的状态。如果有人看起来遇到了麻烦，就应该向他提供帮助。帮助别人所带来的显著影响一定会让你感到相当惊讶。给他人提供帮助并非说明你比人家聪明很多，而是因为你带来了一个新的视角，对于解决问题起到了显著的催化作用。
如果有人向你伸出援手，要诚挚接受，心怀感激地接受帮助并诚意合作。不要死命护住自己的地盘拒绝别人的帮助。不要因为自己进度压力很大，就推开伸来的援手。如同要以乐于助人为荣一样，也要以乐于接受别人的帮助为荣。
第13章 团队与项目
1、最好的团队是
有凝聚力的团队通常有大约12名成员。最多的可以有20人，最少可以只有3个人，但是12个人是最好的。这个团队应该配有程序员、测试人员和分析师，同时还要有一名项目经理。
2、围绕团队还是围绕项目重要
团队比项目更难构建。
团队和项目，何者为先银行和保险公司试图围绕项目来构建团队。这是一种愚蠢的做法。按照这种做法，团队永远都不可能形成凝聚力。每个人都只在项目中的过客，只有一部分时间是在为项目工作，因此他们永远都学不会如何默契配合。专业的开发组织会把项目分配给已形成凝聚力的团队，而不会围绕着项目来组建团队。一个有凝聚力的团队能够同时承接多个项目，根据成员各自的意愿、技能和能力来分配工作，会顺利完成项目。
第14章 辅导、学徒期与技艺
1、作者倡导学徒制
问题在于，在大多数情况下几乎没有技术层面的督导！在大多数公司中，根本就不存在技术督导这一回事。程序员的水平是否能够提升和最终是否能够得到职位晋升，全视乎程序员自己的表现。我们今天的做法和我所提倡的理想化的学徒制程序，这两者之间的主要差异在于技术方面的传授、培训、督导和检查。观念上最大的差别在于，专业主义价值观和技术敏锐度需要进行不断的传授、培育、滋养和文火慢炖，直至其完全渗入文化当中。我们当前的做法之所以传承无力，主要是因为其中缺失了资深人士辅导新人向其传授技艺的环节。
附录 工具
1、问题跟踪（issue tracking）
问题跟踪目前我使用的是 Pivotal Tracker。
我司用的是 gitlab 自带的。功能不是特别强大，但是够用。
2、组件测试工具
FitNesse是我个人偏爱的组件测试工具。
3、UML/MDA
UML/MDA 在20世纪90年代早期，我满怀希望地相信CASE工具行业将会彻底改变软件开发人员的工作方式。在那个冲动的年代，展望未来，我满以为到现在这个时候，每个人都应该已经在更高的抽象层次上用图形语言编程，而文本语言编程的时代应该已经一去不复返了。我太幼稚了。不但这个梦想没有实现，连朝这个方向所做的每一次努力都不幸失败了。不是缺乏工具和系统来展示这种方法的潜能，只是，这些工具都不理想，很少有人愿意用。在这个梦想中，软件开发人员将可抛弃基于文本编程的琐碎细节，采用一种更为高级的图形语言来编写系统。事实上，只要这个梦想成真，也许根本就不再需要程序员了。架构师能够通过UML图形创建整个系统。工程师们，那帮人数众多、冷酷、对非编程人士的困境缺乏同情的家伙，只需把这些图形转换成可执行代码就可以了。这伟大梦想就是“模型驱动架构”（MDA Model-Driven Architecture）。不幸的是，这个伟大的梦想有那么一点微小的瑕疵。MDA假设代码是问题之所在。但事实上，代码并不是问题。代码从来都不是问题。细节才是问题。
统一建模语言（UML Unified Modeling Language ）
MDA 运动旨在能够通过以图形代替代码来消除大量的细节。目前看来这种希望十分渺茫。事实表明，代码中并没有特别多的细节能够通过图形来消除。而且，图形自身也包含许多额外细节。图形有自己的语法、句法、规则和约束。最终，细节上的差异互相抵消了 ，并没有产生什么实质性的作用。MDA 的希望是，能够证明图形是在比代码更高的一个抽象层次上，就像 Java 是在比汇编语言更高的一个抽象层次上一样。但是这个希望再次落空了。即使是在最理想的情况下，这两者之间在抽象层次上的差别也是微乎其微的。