想要成为软件开发中的王者，需要明白的 21 条准则

程序员| 2017-08-15

本文笔者收集了 21 条有关软件开发的准则和技巧：这些观点可能互相矛盾，但仔细品味也会发现其不同点，可以对软件开发者有一定的启发。记住，它们并不是真理，只是观点而已。

软件开发者的工作不是“写代码”，而是解决业务问题，“采用的新框架”常常不能解决业务问题。
我们与人一起工作，只是有时候写代码而已，所以人际关系是这份工作的重要组成部分。
软件开发人员也是人，他们和所有人一样都会受到认知偏差的影响。可以读读关于认知偏差、FAE（fundamental attribution error，基本归因错误）、特别是Kahneman 的书。
每一个新框架的出现，是因为前端开发者面临的问题我们没有理想的解决方案。每一个成功的新框架都有其创新之处，所以得想想“这个框架/库如何改变我的工作”这个问题。
软件开发者不“只是写代码”，而是参与开发过程。所以如果公司在使用敏捷（Agile），你必须对其认真对待，最起码也要对其保有尊重。
代码评审（Code review）是软件开发过程的重要组成部分。对代码评审有所疏忽就不能成为优秀的软件开发人员。
作为软件开发者，我们对自己部署的代码要负责。我们也负有道德上的责任，不要做不道德的事。
用户也是人。我们的产品和我们的失败都可能直接影响他们的生活，对你行为的后果要三思。
人与人并不相同，人们的思维方式也不同：有时候我们认为困难的东西从商业人士角度看来可能很容易。这是我们必须解决而不是逃避的矛盾。
对截止时间（deadline）负责。如果在截止时间前完成不了，你必须重新沟通新的截止时间。
任务有两种复杂性：内部和外部复杂性。内部复杂性不可避免，因为这是任务本身；外部复杂性来自重新架构系统过程中异常决定的后果。要格外注意外部复杂性超过内部复杂性的情况。
如果开发者在写代码或架构系统时选择容易而不是好的解决办法，他欠下的技术债迟早有一天是要还的。
“别人”写的代码几乎总是无法理解或着写得很差，但并不总是因为代码真的写得不好。有时候这些“别人”就是过去的我们。
有时候在不改变代码的情况下也能解决问题。
勇于改变需要改变的，接受那些无法改变的，用智慧来分辨其中差异。
有时候对开发人员来说不重要的事情却有极高的商业价值。商业是一个好的角度，不要逃避它。
很少有公司关心你的个人成长。如果公司对你目前的水平不满意，他们一开始就不会聘用你。
会议或者聚会的价值在于在场的人，其次是交谈内容。
面试都是双向的，不仅是公司在考察你，也是你考察公司。
我们选择这份职业是因为我们对其很感兴趣，但付我们薪水是因为我们创造了价值。了解一下公司的成本和利润，看看自己属于哪一个。
作为自由职业者，花钱请你是因为客户不具备这些技能：客户不会告诉你你代码哪里不好、也不会指出其中错误，客户用自己的方式提出这些意见。