当前位置:网站首页>「代码整洁之道-程序员的职业素养」读书笔记

「代码整洁之道-程序员的职业素养」读书笔记

2020-11-09 14:29:18 songjhh

本书虽然主标题为「代码整洁之道」,但其实内容主要讲的是:如何成为一个专业合格的程序员。所以副标题作为主标题更为合适 — 「程序员的职业素养」。

程序员作为专业技术的工种,「职业素养」是我们需要在整个职业生涯中不断最求的东西,它不仅代表你单纯的技术能力(当然优秀的技术水平是必须的),还代表着你解决问题和创造价值的能力。也就是说,个人的技术能力并不完全代表你作为程序员这个职业的价值,更重要的是你对问题思考和解决的方式、对任务的承诺、同事之间的协作等,最终能够带领团队完成一个又一个看似不可能的任务!

以下我将会根据本书的书写思路,挑选几个观点,介绍大致内容和我自己的感想,希望对本文读者有所帮助。

专业主义

"专业主义"有很深的含义,它不但象征着荣誉与骄傲,而且明确意味着责任与义务。这两者密切相关,因为从你无法负责的事情上不可能获得荣耀与骄傲。

本章节主要叙述了做一个专业工程师需要的几点要求:

  • 承担责任
  • 了解你的领域
  • 坚持学习、训练
  • 合作与辅导
  • 了解业务领域
  • 与客户保持一致
  • 谦逊

作为了一个合格的工程师,首要一点是懂得承担责任。这一点至关重要,因为这是表明你这个人是否靠谱最明显的特性。从任务是否能够按时完成,对系统上线前的测试验证,哪怕是因为你自己的错误导致的损失,都需要勇于承担责任,尽力完成自己承诺的事情,努力弥补错误。一旦被别人打上不靠谱的标签,那就很难再撕掉了。

第二点是我们需要坚持学习,由于技术的革新非常快,只有坚持学习才能不被这个行业所遗弃,同时也坚持训练,毕竟熟能生巧在各行各业都适用。

最后,除了专业技术,我们也需要也有义务去了解自己开发的模块对应的业务领域,未必需要成为该领域的专家,但还是需要花时间去了解业务的背后价值和原则,知其然知其所以然。

说不

能就是能,不能就是不能,不要说“试试看“

本章主要叙述一个专业的工程师,要用于说“不”,也要懂得如何说“不”。

一个专业人士要懂得说“不”,因为只有将问题暴露出来了,才有解决问题的机会。本章作者用了一些例子来说明,当你虽然认为项目经理分下来的任务是不可能完成的,但当你选择不对抗,导致他认为你能够按时完成,最后引发了灾难。

所以我们在平时的工作中,要懂得说“不”,要懂得拒绝,而不是一味的接受。

而“为什么不“重要吗?文中的观点是“为什么“远不如”事实“重要,对于这一点,我认为能让决策者知道为什么是再好不过了。

文中还特别强调了“试试看“的危害性,因为决策者往往会将“试试看”当作一个承诺,排入了他的项目计划中,而工程师往往想表达的只是我尽力,但什么都不保证。

这时候有个问题,项目管理者往往希望工程师能够准确的预估工作量,但是工程师预估的工作量往往是「我试试看」,实际情况可能差别很大。这里我主要有两点想法:一是作为项目管理者,需要每天实时的了解进度,调整计划,毕竟预估的工作量往往无法做到十分准确,有太多的因素会影响了;二是预估工作量,可以采取 PERT 方法,增加确信度。

说是

本章主要讲述了承诺是什么,如何给出承诺。

做出承诺,包含三个步骤:

  1. 口头上说自己将会去做。
  2. 心里认真对待做出的承诺。
  3. 真正付诸行动。

有时候我们没办法做到自己的承诺,往往是因为我们承诺了一件自己不是能完全掌控的事。

当然有时有各种原因导致我们无法兑现承诺,这很正常。但如果你希望你在同事的形象是一个靠谱的人,那么最重要的是尽快向自己承诺的对象发出警告,越快越好!!

当然,我们不应该因为承诺就放弃一些底线,打破纪律和原则往往会拖慢进度,同时也要测试过代码,保证代码整洁。

时间管理

一天的时间其实会过得非常的快,如何在这短暂的时间内尽可能高效的工作、取得尽可能多的成果是非常值得研究的事情。

会议是在日常工作中无可避免的事情,但是会议同时也会浪费大量的时间。作为会议的执行人,需要确定议程和目标,确定每个议题所花的时间以及明确的目标。

而作为会议的参与者,首先要懂得拒绝会议,避免参加没有必要的会议,因为对你时间负责的人只有你自己。

我们日常举行过最多的会议,是站会,每个人依次回答以下3个问题:

  1. 我昨天做了什么?
  2. 我今天打算做什么?
  3. 我遇到了什么问题?

每个人发言不超过1分钟,目的是减少整个站会的时间,所以要求项目负责人在会议开始前就思考好要安排的内容,而不是现场随意的想,每个人干脆利落的交代自己的工作,减少无止境的对话交流。

本书还介绍了一种时间管理方法:番茄工作法。这也是我现在正在使用的一种时间安排方法,有兴趣的小伙伴可以自行去了解一下。

预估

管理者和开发者对预估可能有不同的看法,管理者可能觉得预估就是承诺,而开发者往往预估只是猜测。但是不可否认,一个相对准确的时间预估可以让管理者做出合适的计划。

这里介绍一种预估方法:PERT,可以根据3个数字预估任务:

  • O:乐观预估,这是非常乐观的数字,表示一切异常顺利的情况下;
  • N:标称预估,这是概率最大的数字;
  • P:悲观预估,考虑到各种意外情况下的悲观数字。

那么任务的期待完成时间:u = (O + 4N + P) / 6

标准差(数字越大,表示期待完成时间越不确定):v = (P - O) / 6

比如一个任务,乐观预估需要3天,标称预估需要6.25天,悲观预估需要11天,那么通过上诉的两个公式可以得到,期待完成的时间是6.5天,标准差是1.3。

结束语

当然本书还有很多内容这里没有提到,比如如何处理压力,如何协作,编码的节奏和测试等内容。虽然随着时代的发展和本书作者所在的外国职场和国内职场的差别,有一些的内容我不尽然同意,或者觉得会难以实践。但这并不妨碍本书非常值得每一个工程师都阅读一下,相信这对你成为一个更加专业的工程师是有非常大的帮助的。

版权声明
本文为[songjhh]所创,转载请带上原文链接,感谢
https://segmentfault.com/a/1190000037771867