enter image description here

前段时间入手了一本《程序员的职业素养》,谁推荐的忘记了,断断续续看完了,觉得写得还行,翻译这本书的人是公司的同事,但是从来没见过。

本书是Bob大叔的作品,他是一名程序员,编了40多年的程序了。书的序是这样开头的,“如果你选择了这本书,那么我不妨认为你是一名软件工程师”这句话一针见血啊,如果你不是程序员,估计也没有必要看这本书了。

“请你把这本书看成是我的错误大全,它记录了我干过的所有蠢事”这句话挺有意思的,和马云之前谈的有点类似,他想写一下阿里巴巴犯过的种种错误,而不是阿里巴巴是如何成功的。或许,我们从过往的错误中能够学习到更多的东西吧。

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

“要对自己的不完美负责。代码中难免会出现bug,但这并不意味着你不用对他们负责,没人能够写出完美的软件,但并不表示你不用对不完美负责。”这是对于“我们要追求完美?”的答复。这时候Bob大叔对于专业人士做了个定义“所谓的专业人士,就是对自己犯下的错误负责的人,哪怕那些错误实际上是在所难免的”。

问题:什么样的代码是有缺陷的呢?

答:那些你没有把握的代码都是。在日常的开发中,为了快速响应需求,我们使用了大量的第三方工具或者开源包,但是我们又对于这些缺乏了解,自然就对于代码没有十足的把握。看来要有把握,还是有必要把代码的上线信息梳理清楚。

问题:你怎么知道代码能否正常运行?

答:很简单,测试!一遍遍地测,翻来覆去、颠来倒去的测,使出浑身解数来测试。 而我们可能没有那么多时间,这时候就需要自动化测试。“如果那套测试可以随时快速执行,那么你根本不会害怕修改任何代码”,这个在工作中确实感受到了,有时候改了东西,不敢发布,没有详细测试过,心里还是没有底,不过能够实现自动化测试,需要付出的成本也是很高的,我们是测试人员负责维护自动化持续回归的脚本,每天如果有失败的话就需要看为啥失败,需要很多时间,而大多数情况下排查发现的问题是构造基础数据出现了问题,或许,自动化也需要一种权衡吧。

“把持续集成看成重要的事情”,持续集成不应该失败,如果失败了,团队里的所有人都应该停下手里的活,看看如何让测试通过。

“不能铭记过去的人,注定重蹈先人的覆辙”,是Bob在列举每个软件开发人员必须精通的事项前引用的话。设计模式、设计原则、结构化分析、结构化设计、测试驱动开发、面向对象的设计、持续集成以及各种专业图,这些都需要啊。做程序员好不容易啊。

“能就是能,不能就是不能。不要说‘试试看’。”

“专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说不”“不努力没有权利说不,劳工或许也对说不有所顾忌,但是专业人士应该懂得说不”

当被要求提前完成任务或者交工的时候,如果答复是“试试看”,其实以比较危险的,之前没有思考过这个问题,这本书有有完整的解释。“许诺尝试,就意味着承认之前自己未尽全力,承认自己还有余力可施”

问题:如何识别工作中的“缺乏承诺”?

答:在谈话中识别关键字,“需要应当”、“希望但愿”、“让我们”

“如果你不尽早告诉他人可能的问题,就错失了让他们帮助你达成目标、兑现承诺的机会”,这一点表示深深的认同,希望得到别人的帮助,最起码也要告诉别人遇到的问题是啥吧。

“专业人士对自己的能力极限了如指掌,他们十分清楚自己还能保持效率加班多长时间,也非常明白要付出的代价。”,“专业人士不需要对所有的请求回答是,不过,他们应该努力寻找创新的方法,尽可能的做到有求必应。当专业人士给出肯定回答时,他们使用承诺用语,以确保各方能明白无误的理解承诺内容”

“如果感到疲劳或者心烦意乱,千万不要编码”,强而为之,最终只能再回头返工。相反,要找到一种方法来消除干扰,让心绪平静下来。

有时候遇到场景,死活写不出代码,Bob提供了一种方法,他自己觉得屡试不爽,“找一个搭档结对编程”。其实就我的实践来看,两个人一起写代码,应该是感觉比较不爽的事情,但是,我觉得在处理线上问题的时候,找个同事一起处理可能效果比较好。

“软件开发是一场马拉松,而不是短跑冲刺”,你无法全程一直以最快的速度冲刺来赢得比赛,只有通过保存体力和维持节奏取胜。

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

做业务的人和写程序的人都容易陷入一个陷阱,即过早进行精细化。业务方还没有启动项目,就要精确知道最后能得到什么,开发人员还没有评估整个项目,就希望精确知道要交付什么。双方都贪求不现实的精确性,而且经常愿意花大价钱来追求这种精确。需求是一定会变化,所以追求那种精确性是徒劳的

交流细节信息是件麻烦事。尤其是开发方和业务方交流关于程序细节时,更是如此。通常,双方握手言欢,以为其他人都明白自己的意思。双方以为取得了共识,然后带着截然不同的想法离开,这种事情太平常不过了。解决这种信息不同步问题很简单,就是编写验收测试

关于会议,有两条真理,一个是会议是必须的,一个是会议浪费了大量的时间。受到邀请的会议,没有必要全部参加,参加的会议太多,其实只能证明你不够专业。如果觉得会议是在浪费时间,那就应该礼貌的退出会议。

凡是不能再5分钟内解决的争论,就不能靠辩说解决。唯一的出路,用数据说话。有些共识,一些人表现非常被动,他们同意结束争论,之后却消极对待结果,拒绝为解决问题出一份力。千万不要这么做,如果你同意了,必须拿出行动来。

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

番茄时间是有成率的,你可以真正做点事情,用于应付干扰、参加会议、休息等非工作事宜的时间,则属于非番茄时间。番茄工作法的真正好处在于,在25分钟的高效时间段里,你有底气拒绝任何干扰

业务方觉得预估就是承诺,开发人员觉得预估就是猜测,两者相差迥异。承诺是必须做到的,如果你承诺在特定时间完成,就必须按时完成。专业人员不随便承诺,除非他们确切知道可以完成。

预估是非常容易出错的,所以才叫预估。控制错误的办法之一就是使用大数定律。把大任务分成许多小任务,分开预估再加总,结果会比单独评估大任务要准确很多

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

本文作者: iamzhongyong
原文地址: http://blog.csdn.net/iamzhongyong/article/details/9297499