Book01--代码整洁之道：程序员的职业素养

对自己读过的书做一些梳理，这是第一本：《代码整洁之道：程序员的职业素养》。作者从成为专业的程序员需要什么态度，需要遵循什么样的原则，需要采取什么样的行动三个方面说起。对日常工作受用较大，包括如何编码、如何和业务方沟通、怎样做会议汇报、如何高效开展工作、提高团队工作效率的准则等等，其实总结起来就是说：如何成为一名专业的技术人员，对于新手来说非常值的一看。

大致总结：

1、程序员应该具备的职业素养：

• 了解你的领域
• 坚持学习
• 刻意练习
• 合作
• 与客户、雇主保持一致

2、如何say no

• 团队精神
• 信守承诺
• 坚守原则

3、测试

• TDD测试驱动开发
• 对完成的定义
• 自动化测试的重要性

4、时间管理

• 会议的价值
• 会议上如何汇报工作事项
• 迭代回顾和功能展示

5、面对压力

• 沟通
• 依靠你的纪律原则
• 寻求帮助

 

职业素养体现在你如何解决问题，思路，步骤及反思

因为我们需要招聘的不是“经历丰富”的人，而是“有职业素养”的人。你遇到的问题可能很容易也可能很难，但我看重的并不是问题的难度，而是解决问题的方式、步骤以及反思的程度

面对重大事故，一方面需要及时挽救，将危害降到最低。另一方面需要事后复盘，内容包括：问题为何发生、下次如何避免。从中可以学习的是：解决问题的思路、步骤、后续完善及避免再次发生的措施

恢复误删数据，对很多人来说这是非常简单的任务。我更感兴趣的是怎样分析问题，找了怎样的资料，采取了怎样的步骤，此后做了哪些措施来避免这种错误再次出现。在我看来，与问题本身的难度相比，解决问题的方式、步骤以及反思的程度，才能体现出一个人的职业素养。

职业素养强调持续的沉淀。包括但不仅限于:1、编码能力 2、善于解决问题 3、了解代码背后的意义 4、对自己的代码负责

因为素养强调的并不是天赋的神秘，也不是技艺的高深，而是持续积淀的结晶：一方面，它体现了能力和素质；另一方面，它又强调了持续的积累和养成。作为职业开发人员，基本技能不够熟练，当然谈不上职业素养。但是仅仅能迅速地编写代码，却不关心代码背后的意义，不能迅速判断、解决程序运行中的各种问题，不能自信满满地为自己交付的程序承担责任，同样是与职业素养绝缘的——许多所谓的“高手”，正是缺乏职业素养的典型。

什么情况下说yes？和别人承诺时你需要做到 自己重复一遍需求，tcp三次握手的那种。先讲自己要做成个什么东西，再讲自己的实施步骤和计划，最后确认deadline

比如：什么情况下应该对业务部门说“是”，说“是”意味着什么。如果你没有想过这些问题，或者没有明确的答案，不妨看看Bob大叔是怎么说的：
（说“是”时）你对自己将会做某件事做了清晰的事实陈述，而且还明确说明了完成期限。那不是指别人，而是指你自己。你陈述的是自己会去执行的一项行动，而且，你不是“可能”去做，或是“可能做到”，而是“会”做到。

如何应对客户反复修改的需求

真正的解决办法，是约定共同认可的验收测试标准，并在开发过程中保持沟通

好代码 vs 坏代码

最好的软件开发人员都知道一个秘密：美的东西比丑的东西创建起来更廉价，也更快捷。构建、维护一个美的软件系统所花费的时间、金钱都要少于丑的系统。……美的系统是灵活、易于理解的，构建、维护它们就是一种快乐

玉：璞玉，此为动词，琢磨。
困苦的环境，可以磨练你的意志，帮助你成功。

 艰难困苦，玉汝于成

优秀的程序员需要让自己的失误率limit 0

道歉是必要的，但还不够。你不能一而再、再而三地犯相同的错误。职业经验多了之后，你的失误率应该快速减少，甚至渐近于零。失误率永远不可能等于零，但你有责任让它无限接近零。

40-20h小时工作理论

你应该计划每周工作60小时。前40小时是给雇主的，后20小时是给自己的。在这剩余的20小时里，你应该看书、练习、学习，或者做其他能提升职业能力的事情。

角色互换一下，我也需要专业人士提供服务，更对这些人有更强的信任度，自己为什么不能也成为这样的人呢？

 软件行业的飞速改变，意味着软件开发人员必须坚持广泛学习才不至于落伍。不写代码的架构师必然遭殃，他们很快会发现自己跟不上时代了；不学习新语言的程序员同样会遭殃，他们只能眼睁睁看着软件业一路发展，把自己抛在后面；学不会新规矩和新技术的开发人员更可怜，他们只能在日渐沦落的时候看着身边人越发优秀。
你会找那些已经不看医学期刊的医生看病吗？你会聘请那些不了解最新税法和判例的税务律师吗？雇主们干吗要聘用那些不能与时俱进的开发人员呢？

say no

专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说“不”。

我们在工作中经常会碰到说：那我试试吧。但是这是一个非常模棱两可的回答，双方对【试试】的定义不一样。同时如果你轻易的答应的话：代表着 1，你在此之前有所保留。2，你可以完成这个任务，但是压力你自己扛。

许诺“尝试”，就意味着你承认自己之前未尽全力，承认自己还有余力可施。许诺“尝试”，意味着只要你再加把劲还是可以达成目标的；而且，这也是一种表示你将再接再厉去实现目标的承诺。因此，只要你许诺自己会去“尝试”，你其实是在承诺你会确保成功。这样，压力就要由你自己来扛了。

敢于说真话，根据实际情况预估并合理表达，也是专业程序员的素养。

如果你此前并未有所保留，如果你没有新方案，如果你不会改变你的行为，如果你对自己原先的估计有充分的自信，那么，从本质上讲，承诺“尝试”就是一种不诚实的表现。你在说谎。你这么做的原因，可能是为了护住面子和避免冲突。

summary:1、遇到问题及时求助 2、有风险点及时暴露

如果你不尽早告诉他人可能的问题，就错失了让他们帮助你达成目标、兑现承诺的机会。

培养自己的出错感知能力，见得多了自己对问题的定位、解决能力也会很有提升

能够感知到错误确实非常重要。不只对“录入”是这样，对于一切事情莫不如此。具备“出错感知能力”，说明你已经能够非常迅速地获得反馈，能够更为快速地从错误中学习。

如何面对焦虑

关键所在是要学会如何关闭后台进程，或至少要能够降低其优先级，这样焦虑就不会造成持续的干扰。

如何面对中断

当然，中断无法避免，总有干扰会打断你、消耗你的时间。发生这种情况时要记住一点，也许下次也会轮到你去打断别人请求帮助。因此，礼貌地表现出乐于助人的态度才是专业的态度。

深觉需要学习自动化测试，任何一次修改，将所有的测试用例跑一遍比较是否有差别。

任何时刻，代码有任何修改，都必须运行手头有的全部测试。

适合给每一个接坑的程序员普及这种方法。论自动化测试的重要性。

拥有一套值得信赖的测试，便可完全打消对修改代码的全部恐惧。当看见糟糕的代码时，就可以放手整理。代码会变得具有可塑性，你可以放心打磨出简单而满意的结果。

先写测试用例 vs 后写测试用例 先写是进攻，深度以及捕捉错误的灵敏度更强； 后写是防守，受限于已有代码。

如果很仔细地来看，也许后写测试还可以达到较高的覆盖率。但是事后写的测试只是一种防守。而先行编写的测试则是进攻，事后编写测试的作者已经受制于已有代码，他已经知道问题是如何解决的。与采用测试先行的方式编写的测试代码比起来，后写的测试在深度和捕获错误的灵敏度方面要逊色很多。

Test drive develop.

 TDD是专业人士的选择。它是一项能够提升代码确定性、给程序员鼓励、降低代码缺陷率、优化文档和设计的原则。

Everyone should practice.

专业人士都需要通过专门训练提升自己的技能，无一例外。乐手练习音阶，球员练习绕桩，医生练习开刀和缝针，律师练习论辩，士兵练习执行任务。要想表现优异，专业人士就会选择练习。

学习是自己的事儿。

医生练习手术不需要病人付钱，球员练习绕桩（通常）不需要球迷付钱，乐手练习音阶也不需要乐迷付钱。所以老板没有义务为程序员的练习来买单。

观察者效益。所以双方都是在逐渐打磨、沟通的过程中知道自己想要什么，获取更多的信息有更多的想法也会做不同的要求了。

在工作中，有一种现象叫观察者效应，或者不确定原则。每次你向业务方展示一项功能，他们就获得了比之前更多的信息，这些新信息反过来又会影响他们对整个系统的看法。

当我们在开会的时候，我们需要沟通什么？

验收测试的目的是沟通、澄清、精确化。开发方、业务方、测试方对验收测试达成共识，大家都能明白系统的行为将会是怎样。各方都应当记录这种准确的共识

对于devops来说，开发做测试最大的问题就是他知道正确输入但是却很难考虑到一些边界条件极端情况，以测试功能为主的测试是不全面的测试。测试人员更全面包括：边界条件、异常、例外等情况。

通常，业务分析员测试“正确路径”，以证明功能的业务价值；QA则测试“错误路径”、边界条件、异常、例外情况，因为QA的职责是考虑哪些部分可能出问题。

单元测试Vs验收测试。 单元测试是函数测试，验收测试是系统外部API测试。两者共同点是测试只是附属职能，重点是如实描述系统的设计、架构、行为的具体指标参数。

首先，尽管两者测试的可能是同一个对象，其机制和路径却是不同的。单元测试是深入系统内部进行，调用特定类的方法；验收测试则是在系统外部，通常是在API或者是UI级别进行。所以两者的执行路径是截然不同的。
不过，这两种测试并不重复的根本理由在于，它们的主要功能其实不是测试，测试只是它们的附属职能。单元测试和验收测试首先是文档，然后才是测试。它们的主要目的是如实描述系统的设计、结构、行为。它们当然可以验证设计、结构、行为是否达到了具体指标，但是，它们的真正价值不在测试上，而在具体指标上。

happy-path-test、corner、boundary、unhanppy-path

通常，业务人员编写针对正常路径的测试（happy-path test），而由QA编写针对极端情况（corner）、边界状态（boundary）和异常路径（unhappy-path）的测试。

对待会议的标准

所以，如果你收到会议邀请，务必确保出席会议可以给自己目前的工作带来切实且显著的成效，否则不必参与。

be response for your time

 仔细管理自己的时间是你的责任

开会汇报格式

1. 我昨天干了什么？
2. 我今天打算干什么？
3. 我遇到了什么问题？
4. 风险点是什么？

迭代计划会议

迭代计划会议用来选择在下一轮迭代中实现的开发任务。在会议召开前必须完成两项任务：评估可选择任务的开发时间，确定这些任务的业务价值。

迭代回顾和DEMO展示

这类会议在迭代的末尾召开。团队成员讨论本轮迭代中什么做得对，什么做得不对。业务方可以看到最新工作成果的demo。

注意力是稀缺资源，需要适当补充

 编程是需要持续投入精力和注意力的智力活动。注意力是稀缺的资源，它类似魔力点数。如果你用光了自己的注意力点数，必须花一个小时或更多的时间做不需要注意力的事情，来补充它。

注意力是有限的，合理分配注意力。

职业开发人员会学习安排时间，妥善使用自己的注意力点数。我们选择注意力点数充裕的时候编程，在注意力点数匮乏时做其他事情。

跟有创造性思维的人接触，你自己也会感染创造性的思维。

关于注意力，我知道的另一重点是平衡输入与输出。编程是一项创造性劳动。我发现，如果能接触到其他人的创造性思维，我的创造力也最旺盛，所以我阅读大量的科幻小说。这些作者的创造力会激发我对软件的创造力。

坑法则（The Rule of Holes）：如果你掉进了坑里，别挖。

慎重的态度和积累的经验可以帮你避免某些死胡同，但是没法完全避免所有的。所以你真正需要的是，在走入死胡同时可以迅速意识到，并有足够的勇气走回头路。这就是所谓的坑法则（The Rule of Holes）：如果你掉进了坑里，别挖。

对预估达到共识

不同的人对预估有不同的看法。业务方觉得预估就是承诺。开发方认为预估就是猜测。两者相差迥异。

大数定律：将大任务拆分成小任务，预估再共和，准确率较高。做任何事都是这样，大任务拆分成小任务，再一个个着手去做。

 预估是非常容易出错的，所以才叫预估。控制错误的办法之一是使用大数定律。该定律的意思是：把大任务分成许多小任务，分开预估再加总，结果会比单独评估大任务要准确很多。这样做之所以能提高准确度，是因为小任务的预估错误几乎可以忽略，不会对总的结果产生明显影响。

你希望你面对的医生怎样处理棘手的事情，你就应该成为这样的程序员。态度稳定、坚守自己的职业素养、信守承诺、尽力做好。

想象一下灵魂出窍后的体验：你看见自己躺在一张手术台上，一位外科医生给你做开胸手术。医生竭力挽救你的性命，但是时间有限，也就是说，他的一举一动都与病人生死攸关——你命悬一线。
你期望医生的表现如何？你希望他冷静、井井有条吗？你希望他清楚准确地吩咐助手吗？你希望他严格遵循当初训练时的做法坚守手术规程吗？
还是想让他汗流浃背、咒骂之声不断？想让他乱扔手术器械、把东西摔得哐当响吗？想让他满腹怨气责怪管理人员设定的不现实的手术时间，一直嚷嚷时间不够用吗？你期望他表现得像一名专业人士，还是像我们常见的某些开发人员的那种做派？
即使有压力，专业开发人员也会冷静果断。尽管压力不断增大，他仍然会坚守所受的训练和纪律，他知道这些是他赖以战胜由最后期限和承诺所带来的压力感的最好方法。

坚持秉持自己的开发原则：包括但不限于代码整洁、tdd、结对编程等等。

当困境降临时，也不要改变行为。如果你遵守的纪律原则是工作的最佳方式，那么即使是在深度危机中，也要坚决秉持这些纪律原则。

 应对压力的最好解决方式

1. 不要惊慌失措。
2. 保持你的原则。
3. 沟通
4. 求助

为什么喜欢做程序员，可以理解为对代码输出的可确定性的那种掌控感。可预见性的结果给我带来的稳定感。

 我们并非是因为喜欢和其他人在一起工作才选择做程序员的。我们都认为人际关系难以应付而且毫无规律。编程用的机器则整洁，行为也可预见。如果可以一个人待在房间里数个小时沉浸在一些真正有趣的问题上，那将会是最开心的时光。

理解业务，对各方沟通。don‘t be a api boy。

专业程序员会花时间去理解业务。他们会和用户讨论他们正在使用的软件，会和销售人员与市场人员讨论所遭遇的问题，会和经理们沟通，明确团队的短期目标和长期目标。

合理看待被人对自己代码的修改，这是一种学习方式。

专业开发人员是不会阻止别人修改代码的。他们不会在代码上构造所有权的藩篱，而是尽可能多地互相合作。他们通过合作来达到学习的目的。

有效的学习方法是向高手请教而不是从零开始。

专业人士结对工作，还因为这是分享知识的最好途径。专业人士并不会仅凭一己之力从零开始创建知识，而是通过互相结对来学习系统的不同部分和业务。他们明白，尽管每位团队成员都有自己的位置，但是在紧要关头，每位团队成员也要能够接替其他人的位置。

太真实了，每次run出来自己想要的结果or debug到问题所在，都觉得自己牛逼哄哄的，世界上最聪明非我莫属，整个世界的奥妙都被我掌握！

我又录入了其他几个类似的简单程序，它们都能够如我的预期正确运行。那时我简直感觉整个宇宙在握！

总结出来学习了两种方法。一、课本书籍，自我摸索；二、观察高手，向高手请教。

之所以告诉大家这两个故事，是因为它们描述了截然不同的两种辅导，这两种辅导都不是通常字面意义上的“辅导”。在第一个案例中，我通过一本精心编写的手册向作者学习。在第二个案例中，我通过观察他人工作来学习，尽管他们对我视若不见。在这两个案例中，我所获得的知识虽然基础但是意义深远。

信息化时代下，原来我们一点都离不开程序员和软件噢。

我们的文明运行在软件之上。是软件在传送和操纵我们日常生活中无处不在的信息，是软件在控制我们的汽车引擎、变速箱和刹车，是软件在维护我们的银行账户、发送账单和接收付款，是软件在帮我们洗衣服，是软件在告诉我们时间，是软件在电视上显示图片，是软件在发送短消息和拨通电话，是软件在我们疲劳时为我们带来娱乐。软件无处不在。

有必要：导师制+结对编程

 建立一种包含学徒期、实习期和长期指引的机制已是迫在眉睫。

summary for tools

 我使用git来管控源代码，使用Tracker来管理问题，使用Jenkins来进行持续构建，使用IntelliJ作为集成开发环境，使用XUnit来做单元测试，使用FitNesse来做组件测试。