2019 June 21 PageView:

《代码整洁之道 程序员的职业素养》读书笔记

第1章 专业主义

程序员的”希波克拉底誓言”

1.1 清楚你要什么

你是想做坚守“专业主义”的专业人士，还是一个混子

1.2 担当责任

你要为你的专业担当责任

1.3 不行损害之事

1.4 坚守职业道德

第2章 说”不”

能就是能，不能就是不能，不要说试试看。
专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说不。

第3章 说“是”

在工作中做出真正的承诺。你对自己将做的某件事做了清晰的事实陈述，而且还明确说明了完成期限。
做一名“严谨负责的开发人员”

之所以没成功，是因为我寄希望于别人去做这件事。
之所以没成功，是因为我不太确信是否真能完成得了。
之所以没成功，是因为有些时候我真的无能为力。

“代码必须经过测试，代码必须要有对应的测试代码。要确保代码清晰整洁，而且必须确保没有影响到系统的其他部分”
作为专业开发人员就应该遵守和捍卫这些标准。如果是专业的开发人员，就不会放弃底线。
专业人士不需要对所有请求都回答“是”。不过他们应该努力寻找创新的方法，尽可能做到有求必应。
当专业人士给出肯定回答时，他们会使用正式的承诺，以确保各方能明白无误地理解承诺的内容。

第4章 编码

要精熟掌握每项技艺，关键都是要具备”信心”和“出错感知”能力。
“不要在凌晨3点写代码”。疲劳的时候，千万不要写代码。奉献精神和职业素养，更多意义上指要遵循纪律原则，
而非成为长时间的工作狂。要确保自己已经将睡眠，健康和生活方式调整到最佳状态，这样才能做到在每天的8小时工作时间内全力以赴。

“不要在焦虑状态下写代码”

根据目标定期衡量进度，使用三个考虑到多种因素的期限：乐观预估，标称预估，悲观预估。
并且要坚决维持你的估算！不要经受不住诱惑盲目冲刺。

接受他人的帮助
如果帮助唾手可得却让自己一个人堵在那里，是很不专业的表现。

大家知道，程序员大多自负，固执，内向。

第5章 测试驱动开发

TDD三项法则
1：除非是为了使一个失败的unit test通过，否则不允许编写任何产品代码。
2：只要有一个单元测试失败了，就不要再写测试代码（无法通过编译也是失败情况）
3：只允许编写刚好能够使一个失败的unit test通过的产品代码。

第6章 练习

专业人士都需要通过专门训练提升自己的技能，无一例外。

现在我们有了更好的工具，更好的语言。可是，语句的本质并没有随着时间而改变。20世纪60年代的程序员
完全可以看懂2012年的代码。我们真正打交道的东西，40年来没有多少改变。

卡塔联系网站
http://codingdojo.org
http://katas.softwarecraftsmanshi.org
http://codekata.pragprog.com

职业程序员通常会受到一种限制，即解决问题的种类比较单一。老板通常只强调一种语言、一个平台，以及程序员的专门领域。经验不够丰富的程序员，履历和思维中都存在某种贻害无穷的盲区。经常可以看到这样的情景：程序员发现，面对行业的周期性变化造成的新局面，自己并没有做好准备。

保持不落伍的一种方法就是为开源项目贡献代码，就像律师和医生参加公益活动一样。程序员用自己的时间来练习，老板的职责不包括避免你的技术落伍，也不包括为你打造一份好看的履历。

第7章 验收测试

开发方和业务方之间需求的沟通，应该避免 过早精细化以及过晚的模糊性。
验收测试的目的在于确定需求已经完成。

相比于手动验收测试，自动化验收测试的成本更低
自动化的验收测试工具有：FitNesse，Cucumber，cuke4duke，robot framework，Selenium

验收测试应该是QA身份的人的任务，QA指Quality Assurances，也就是质量保证。
不仅仅要保证程序按预期方式运行，而且还要考虑误用例，和滥用例（misuse，abuse）

验收测试 vs 单元测试
单元测试是深入系统内部进行，调用特定类的方法；
验收测试则是在系统外部，通常是在API/UI级别进行。

几十年来，设计专家一直在教导我们，要把GUI和业务逻辑分开。
所以对产品验收测试也应该 专门针对GUI的测试 以及 真的GUI背后的API进行。

第8章 测试策略

开发小组要把“QA应该找不到任务错误”作为努力的目标。

自动化测试金字塔

测试模式 测试主体 负责人 测试目的 覆盖率
人工探索式测试 滥用例，误用例测试 项目负责人，测试人员：尽可能多的，各类人参与测试 在验证预期行为之后，探索系统预期之外的行为 5%
系统测试 GUI 系统架构师/技术负责人，测试目的：测试系统是否正确组装完毕，且系统间的交互是否符合预期 不是要确保正确的系统行为，而是要确保正确的系统构造。一般使用和UI集成测试使用同样的语言和环境 10%
集成测试 API 系统架构师/主设计师，测试目的：实际是装配测试，确认组件之间是否正确连接，彼此间通信是否畅通 使用适当的模拟/测试辅助技术与其他组件解耦，此阶段可以进行性能测试和吞吐率测试 20%
组件测试 API QA/业务人员，测试目的：因为系统的组建封装了业务规则，所以对组件的测试就是对业务规则的验收测试 组件间可能存在耦合关系，测试单一组件时，可能需要模拟/测试辅助技术，解开与系统其他组件间的耦合 50%
单元测试 XUnit 开发人员，测试目的：在最低层次上定义系统。 单元测试将作为持续集成的一部分来运行，用以确保程序员的代码意图没有遭到破坏 100%

(开发人员应该遵从TDD模式，先编写测试，再编写产品代码)

第9章 时间管理

关于会议，有两条真理

1：会议是必需的，

2：会议浪费了大量的时间。

参加的会议太多，其实只能证明你不够专业。你应该理智的使用时间，对会议必须谨慎的选择。

领导的最重要责任之一，就是帮你从某些会议脱身。好的领导一定会主动维护你拒绝出席的决定，因为他和你一样关心你的时间。

这些年来，我学到了一条简单的规则：“如果会议让人厌烦，就果断离席”

每个会议都应该关注 议程，会议时间和目标，如果会议偏离议程/议题，则应该指出。

站立会应该回答以下3个问题
1：我昨天干了什么
2：我今天打算干什么
3：我遇到了什么问题
每个问题的回答时间不应当超过20秒，每个人的发言不超过1分钟。

敏捷开发 迭代计划会议 和 迭代回顾及DEMO展示技巧参看P106-P107

Kent Beck曾告诉我一个深刻的道理:“凡是不能在5分钟内解决的争论，都不能靠辩论解决。”
争论之所以要花这么多时间，是因为各方都拿不出足够有力的证据。所以这类争论依据的不是事实，而是信念。

注意力点数
如果自己察觉自己的注意力点数耗尽，就像游戏里的魔耗尽，要根据自己的恢复方式回魔，而后再投入到工作中，特别是编码工作

所有的软件开发者都要遇到死胡同。比如选择了走不通的技术道路。
作为一个专业开发人员，就应该有足够的勇气走回头路，承认决策失误。
这就是所谓的坑法则（The Rule of Holes):如果你掉进了坑里，别挖。

专业的开发人员相比于死胡同，应该更关注/恐惧泥潭。
因为在泥潭中，你仍然可以看到前进的道路，而且看起来总是比走回头路更短（虽然实际不是这样）。

第10章 预估

预估的实质：预估不是个定数，预估的结果是一种概率分布。
比如预估任务需要多久完成，结果可能是这样
第2天能完成的概率是10%
第3天能完成的概率是50%
第4天能完成的概率是20%
第5天能完成的概率是10%
第6天能完成的概率是5%
所以说6天内能完成的概率是95%
cleancode_predict

预估任务的 乐观预估，标称预估，悲观预估时间可采用德尔菲法
比如 亮手指，规划扑克，关联预估，三元预估等

大数定律
把大任务分成许多小任务，分开预估再加总，结果会比单独预估大任务要准确。

第11章 压力

专业开发人员应该避免对没有把握能够达到的最后期限做出承诺。
如果是业务人员对客户做出了不切实际的承诺，专业开发人员应该尽力主动帮助业务方找到方法来兑现这些承诺，但是一定不能接受这些承诺。要明白，如果承诺无法兑现，责任应该由承诺的人承担。

快速前进确保最后期限的方法，便是保持整洁。专业人士不会为了快点前进而乱来。他们明白“快而脏”是自相矛盾的说法，脏乱只会导致缓慢。
让系统，代码和设计尽可能整洁，就可以避免压力。这并非是说我们要花无穷无尽的时间去清理代码，而只是说不要容忍混乱。
混乱会降低速度，导致工期延误，承诺失信。因此，要尽力保持输出成果整洁干净。

危机中的纪律
观察自己在危机时刻中的反应，就可以了解自己的信念。如果在危机中依然遵循着你守持的纪律，就说明你确实相信那些纪律。反之，则说明你没认可那些纪律。
比如TDD，保持代码设计整洁，结对工作等纪律，要刻在骨子里，变成原则，而不是压力情况下，这些原则全抛弃了。

依靠你的纪律原则
在危机/压力时刻，不要惊慌失措地茫然四顾另寻依靠，而要从容不迫，专心致志地依靠你自己的纪律原则，这将帮你更快地走出困境。
如果你遵循TDD，那么这时写的测试甚至要比平时多。
如果你笃行无情的重构，这时就要更多的进行重构。
如果你相信要保持函数尽量小，这时就要让函数变得更小。
战胜压力煎熬的唯一方法，便是依靠那些你以及知道切实有效的东西，也就是你平时遵守的纪律。

第12章 协作

我们并非是因为喜欢和其他人在一起工作才选择做程序员的。我们都认为人际关系难以应付而且毫无规律。编程用的机器则整洁，行为也可预见。
如果可以一个人待在房间里数个小时沉浸在一些真正有趣的问题上，那将会是最开心的时光。
虽然这么说有点以偏概全，但是整个群体的平均状况还是朝我所描述的方法发展。

专业开发人员应该结对工作，因为结对工作是分享知识最好途径，是复查代码最好的方式。

团队之前代码不应该筑起高墙，应该打破各种代码隔断，由整个团队共同拥有全部代码。

第13章 团队与项目

有凝聚力的团队确实有些神奇之处。他们能够一起创造奇迹。
有凝聚力的团队通常有大约12名成员。由12个人组成的理想团队，人员配备情况是这样的：7名程序员、2名测试人员、2名分析师和1名项目经理。

形成团队需要时间。团队成员需要首先建立关系。他们需要学习如何互相协作，需要了解彼此的癖好、强项、弱项，最终，才能凝聚成团队。

团队和项目，何者为先？
试图围绕项目来构建团队是一种愚蠢的做法。按照这种做法，团队永远都不可能形成凝聚力。
专业的开发组织会把项目分配给已形成凝聚力的团队，而不会围绕着项目来组建团队。一个有凝聚力的团队能够同时承接多个项目，根据成员各自的意愿、技能和能力来分配工作，会顺利完成项目。

团队比项目更难构建。因此，组建稳健的团队，让团队在一个又一个项目中整体移动共同工作是较好的做法。并且，团队也可以同时承接多个项目。在组建团队时，要给予团队充足的时间，让他们形成凝聚力，一直共同工作，成为不断交付项目的强大引擎。

每个团队都有自己的速度。团队的速度是指在一定时间内团队内完成的任务量。
有些团队用每周点数来衡量自己的速度，点数是一个抽象的概念，细粒度的度量单位
比如每个团队每周的速度为 40点，如果一个任务总点数是120点，那么如果把此任务分配给这个团队，就可以预估要花三周时间才能完成。

第14章 辅导，学徒期与记忆

程序员应该和医生一样，毕业后到独当一面，应该有一个过渡时期
比如医生从 毕业生 到 实习医生 到 住院实习期
程序员也应该是从 毕业生 到 学徒/实习生 到 熟练工 到 大师
熟练工应该作为学徒的导师，向学徒传授TDD，重构，估算等各类必备技艺
学徒期至少应持续一年。期满之时，如果熟练工愿意接受学徒上升到他们这个层次，就把学徒推荐给大师们。
大师们则通过面谈和水平检测，对学徒们进行考核校验。如果能够取得大师们的认可，那么学徒便可晋升为熟练工。

现实情况是大多数时候，学徒在公司都没有得到技术层面的督导。程序员的水平能否提升以及职位能不能晋升，全在于自己的表现。
实际上这时不对的，在学徒的培养阶段，专业主义价值观和技术敏锐度需要进行不断的传授，培育，滋养和文火慢炖，直至其完全渗入文化当中。
在一个技术导向公司，应该把上述 学徒的培养 融入到企业文化当中，而不是依赖于个别领导或核心人员的推动。

技艺是工匠所持有的精神状态，技艺的模因（meme）中包含价值观，原则，技术，态度和正见。
应该让技艺的模因像传染病/传销一样，让这种精神病毒感染到所有观察到的人，落地生根。
所谓近朱者赤近墨者黑，任何人应该能识别出哪些病毒是良性的，哪些是恶性的，应该主动去接近拥有良性病毒的大师/匠人，远离那些拥有恶性病毒的人。

学校能够传授的是计算机编程理论。但是学校并不会也无法传授作为一名编程匠者所需掌握的原则，实践和技能。这些东西只有经由师徒个体间多年的细心督导和辅导才能获得。
软件行业中像我们这样的一批人必须要面对这一事实，即指引下一代软件开发人员成熟起来的重任无法寄希望于大学教育，现在这个重任已经落到了我们肩上。
建立一种包含学徒期，实习期和长期指引的机制已是迫在眉睫。

All content is licensed under CC BY-NC-SA

Built with Jekyll and 3-Jekyll theme • Hosted on Github

Table of Contents