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

我读《程序员的职业素养》,第1张

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

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

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

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

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

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

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

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

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

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

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

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/2090786.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-07-22
下一篇 2022-07-22

发表评论

登录后才能评论

评论列表(0条)

保存