我读《程序员的职业素养》

前段时间入手了一本《程序员的职业素养》，谁推荐的忘记了，断断续续看完了，觉得写得还行，翻译这本书的人是公司的同事，但是从来没见过。
Bob大叔的作品，他是一名程序员，编了40多人的程序了。书的序是这样开头的， “如果你选择了这本书，那么我不妨认为你是一名软件工程师” 这句话一针见血啊，如果你不是程序员，估计也没有必要看这本书了。
“请你把这本书看成是我的错误大全，它记录了我干过的所有蠢事” 这句话挺有意思的，和马云之前谈的有点类似，他想写一下阿里巴巴犯过的种种错误，而不是阿里巴巴是如何成功的。或许，我们从过往的错误中能够学习到更多的东西吧。

书的第一章是“专业主义”，之所以这样讲，估计是Bob大叔觉得现在很多程序员不够专业吧。 “专业主义就意味着担当责任” ，这句话表示深深的认同，自己写过的代码，如果后面出了问题，这时候站出来说，这是我的责任，我啥时候搞定他。我觉得这种是值得尊敬的。

“要对自己的不完美负责。代码中难免会出现bug，但这并不意味着你不用对他们负责，没人能够写出完美的软件，但并不表示你不用对不完美负责。” 这是对于“我们要追求完美？”的答复。这时候Bob大叔对于专业人士做了个定义 “所谓的专业人士，就是对自己犯下的错误负责的人，哪怕那些错误实际上是在所难免” 。
问题：什么样的代码是有缺陷的呢？
答： 那些你没有把握的代码都是 。在日常的开发中，为了快速响应需求，我们使用了大量的第三方工具或者开源包，但是我们又对于这些缺乏了解，自然就对于代码没有十足的把握。看来要有把握，还是有必要把代码的上线信息梳理清楚。

问题：你怎么知道代码能否正常运行？
答： 很简单，测试！一遍遍地测，翻来覆去、颠来倒去的测，使出浑身解数来测试。 而我们可能没有那么多时间，这时候就需要自动化测试。“如果那套测试可以随时快速执行，那么你根本不会害怕修改任何代码”，这个在工作中确实感受到了，有时候改了东西，不敢发布，没有详细测试过，心里还是没有底，不过能够实现自动化测试，需要付出的成本也是很高的，我们是测试人员负责维护自动化持续回归的脚本，每天如果有失败的话就需要看为啥失败，需要很多时间，而大多数情况下排查发现的问题是构造基础数据出现了问题，或许，自动化也需要一种权衡吧。
“ 把持续集成看成重要的事情 ”，持续集成不应该失败，如果失败了，团队里的所有人都应该停下手里的活，看看如何让测试通过。
“ 不能铭记过去的人，注定重蹈先人的覆辙 ”，是Bob在列举每个软件开发人员必须精通的事项前引用的话。设计模式、设计原则、结构化分析、结构化设计、测试驱动开发、面向对象的设计、继续集成以及各种专业图，这些都需要啊。做程序员好不容易啊。

“ 能就是能，不能就是不能。不要说‘试试看’。 ”
“ 专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说不 ”。“ 努力没有权利说不，劳工或许也对说不有所顾忌，但是专业人士应该懂得说不 ”。
当被要求提前完成任务或者交工的时候，如果答复是“试试看”，其实以比较危险的，之前没有思考过这个问题，这本书有有完整的解释。“ 许诺尝试，就意味着承认之前自己未尽全力，承认自己还有余力可施 ”。

问题：如何识别工作中的“缺乏承诺”？
答：在谈话中识别关键字， “需要应当”、“希望但愿”、“让我们” 。
“ 如果你不尽早告诉他人可能的问题，就错失了让他们帮助你达成目标、兑现承诺的机会 ”，这一点表示深深的认同，希望得到别人的帮助，最起码也要告诉别人遇到的问题是啥吧。
“ 专业人士对自己的能力极限了如指掌，他们十分清楚自己还能保持效率加班多长时间，也非常明白要付出的代价。”，“专业人士不需要对所有的请求回答是，不过，他们应该努力需找创新的方法，尽可能的做到有求必应。当专业人士给出肯定回答时，他们使用承诺用语，以确保各方能明白无误的理解承诺内容 ”。
“ 如果感到疲劳或者心烦意乱，千万不要编码 ”，强而为之，最终只能再回头返工。相反，要找到一种方法来消除干扰，让心绪平静下来。
有时候遇到场景，死活写不出代码，Bob提供了一种方法，他自己觉得屡试不爽，“ 找一个搭档结对编程 ”。其实就我的实践来看，两个人一起写代码，应该是感觉比较不爽的事情，但是，我觉得在处理线上问题的时候，找个同事一起处理可能效果比较好。

“ 软件开发是一场马拉松，而不是短跑冲刺 ”，你无法全程一直以最快的速度冲刺来赢得比赛，只有通过保存体力和维持节奏取胜。
保持不落伍的一种方法就是为开源项目贡献代码 ，就像律师和医生参加公益活动一样。程序员用自己的时间来练习，老板的职责不包括避免你的技术落伍，也不包括为你打造一份好看的履历。
做业务的人和写程序的人都容易陷入一个陷阱，即过早进行精细化 。业务方还没有启动项目，就要精确知道最后能得到什么，开发人员还没有评估整个项目，就希望精确知道要交付什么。双方都贪求不现实的精确性，而且经常愿意花大价钱来追求这种精确。 需求是一定会变化，所以追求那种精确性是徒劳的 。
交流细节信息时间麻烦事。尤其是开发方和业务方交流关于程序细节时，更是如此。通常，双方握手言欢，以为其他人都明白自己的意思。双方以为取得了共识，然后带着截然不同的想法离开，这种事情太平常不过了。 解决这中信息不同步问题很简单，就是编写验收测试 。
关于会议，有两条真理，一个是会议室必须的，一个是会议浪费了大量的时间。 受到邀请的会议，没有必要全部参加，参加的会议太多，其实只能证明你不够专业。如果觉得会议室在浪费时间，那就应该礼貌的推出会议。

凡是不能再5分钟内解决的争论，就不能靠辩说解决 。唯一的出路，用数据说话。有些共识，一些人表现非常被动，他们同意结束争论，之后却消极对待结果，拒绝为解决问题出一份力。千万不要这么做，如果你同意了，必须拿出行动来。
编程是需要持续投入精力和注意力的智力活动 。注意力是稀缺资源，如果你用光了自己的注意力点数，必须花一个小时或者更多的时间做不需要注意力的事情，来补充它。
番茄时间是有成产率 的，你可以真正做点事情，用于应付干扰、参加会议、休息等非工作事宜的时间，则属于非番茄时间。 番茄工作法的真正好处在于，在25分钟的高效时间段里，你有底气决绝任何干扰 。

业务方觉得预估就是承诺，开发人员觉得预估就是猜测，两者相差迥异。 承诺是必须做到的，如果你承诺在特定时间完成，就必须按时完成。 专业人员不随便承诺，除非他们确切知道可以完成。
预估是非常容易出错的，所以才叫预估。控制错误的办法之一就是使用大数定律。 把大任务分成许多小任务，分开预估再加总，结果会比单独评估大任务要准确很多 。

计算机方面的技术书籍很多的，一个主题就有很多，但是书写程序员工作和人生的书却是很少。希望后面这类的书越来越多。

原文来自站长网：http://www.software8.co/wzjs/cxyyg/3529.html