【读书笔记】程序员的职业素养

写在最前

读书笔记只是对于读到的部分内容的想法看法写下来，与全书内容不无关系也没有全部的联系。想要知道全书在讲些什么，最好还是自己去翻阅原书。

关于想读这本书

想读这本书是因为，自己属于一众普通程序员中的最普通的一员。人一普通，就只能是学习并遵循一些前人给予的好的建议，以此来规范自己的行为。读这本书希望先让自己在抛开技术本身，对待一个技术类的工作的时候，有一套合格的工作素养。当然，这有一些舍本逐末。毕竟，技术到位了，很多职业素养就不是必须的。读此书，也权当是培养职业化完成工作（不一定是技术工作）的意识与能力吧。

专业意味着担责

犯错无可避免

初看起来，专业和负责似乎是两个不相干的词，尽管都是正面的词汇。可是，在bug总是在所难免，事故偶尔就会发生的程序与技术工作中，一个专业的工作人员（程序员）不是避免犯错误，而是能对事故负责。不少职业化“教材”向初入职场的人介绍的职场文化，永远都是强调拒绝放错误。要知道，任何千辛万苦建立的信任度，只要一次错误就会被毁灭。

而程序员写出错误的代码，或仅仅是不合规范的代码都是常有的事，在大厂，提交的代码鲜少是一次即过的，辛苦修改程度不亚于发表论文。即使在新厂小厂，看似不需要严格的代码审查，后果是事故往往是线上生产事故。

所以负责是专业的表现之一。

不行损坏之事

虽然写出有问题的代码无法避免，但是在代码做交付之前，应该保证这一段代码是可以正常运行的，过得了测试的关的。不应该把没有测试的代码进行交付。大多数程序员都知道这个基本要求，但是一旦在频繁的修改问题代码或者解决事故的时候，容易因为疲倦而懈怠。

这也是为什么要推行测试驱动开发。写代码之前先做好测试代码的编写，无论工程代码进行什么样的修改，写出的代码都是可以经过代码变异测试的。

只有当代码过得了自己的关的时候，才进行交付。这是专业的表现，也是负责的工程师的表现。事实上，很多专业的工程师，代码都是在交付的时候基本已经完成该有的业务逻辑的测试，几乎不需要测试工程师再做一遍。否则很多初创公司在技术层面就已经失败了。在业务逻辑之外，性能问题及代码规范问题，随着产品升级及技术升级，慢慢积累经验，去避免错误。但无论如何，专业的程序员随时都提醒自己不行损坏之事。

随时给代码做必要的修改

代码重构是常发生的事情，不要等到发起重构项目的时候，再对代码进行重构，更不要仅仅在每一次新增feature或者bug fix的时候顺便做重构。这会使得重构只是为了当前的问题，而忽略了设计本身的问题。

当然，有一种说法是，代码只需要做当下的工作，不要为未来做过多的设计。两者似乎是矛盾的，权衡的方法没有一套基本原则，只能是依靠工程师的工作经验以及对业务的理解与业务未来规划的了解。

无论如何，对于自己维护的项目，应该知道自己的代码一定在编写之初有哪些可能的缺陷或漏洞。尽管已经做出交付，仍然建议每一次都可以做一些必要的修改，不要懒惰搁置。相信每一次的修改对软件本身、对自己技术水平，都是一种提高。