优秀程序员的 30 种思维--技术执念篇

技术执念

不迷信权威

一句话解读：hack 一切

权威是用来挑战的。挑战带来创新。 在开发的领域里，这样的例子比比皆是。

没有 linux 对 windows 的挑战，就没有风靡世界，性能优秀，成本低廉的服务器操作系统；

没有 bitcoin 对法币的挑战，就没有去中心化的，神圣不可侵犯的私人财产，就没有高效的跨境转账系统，就没有洪都拉斯和萨尔瓦多对美元霸权的挑战；

没有 android 对 ios 的挑战，就没有现在不到千元的智能机。（注：这里的 ios 是泛指闭源的手机操作系统）

保持好奇心

一句话解读：求知若渴，虚心若愚

优秀的程序员总是用好奇心不断探索各种可能性。

以前有个大学生通过优酷上记者采访周鸿祎的视频拨打电话的按键音，解析音频信号，还原了周鸿祎的手机号码。 后来这个人收到了很多企业的橄榄枝，不过他选择了自己创业，创立的企业也在 2021 年冲刺科创板。

现在的新技术，新概念层出不穷，日新月异，保持好奇心，并把好奇心转换成求知欲，可以让你在职业生涯上拥有别人没有的先发优势。

开源精神

一句话解读：分享与协作

如果开源社区的影响力越来越大，很多的影响时间的软件也诞生在开源社区。比如：服务器操作系统领域，开源的 Linux 占据了 80%以上的市场份额；数据库领域有广为人知的 MySQL，MongoDB，Redis 等等；应用中间件领域有大名鼎鼎的 Nginx；调度框架有 kubernetes 和 openstack；AI 领域有 tensorflow；而和我们生活息息相关的应用有 chrome，firrefox 浏览器 ，压缩软件 7-zip ，android 安卓操作系统等

我们的生活几乎离不开开源软件。说开源软件改变世界，一点都不夸张。 而在 30 年前，还是闭源软件的世界。

之所以开源社区能在短短几十年蓬勃发展，和开源精神鼓励分享，倡导协作分不开。

开源精神是程序员的执念，没有工资，无私奉献自己的时间和才华，和大家一起完成一个有意义的事情，影响世界的软件，这是一件多么酷的事情。 有开源精神的程序员，应该更受企业的青睐，因为他对编程是真的热爱，对于协作和分享的理解更深，和分享和协作精神也是众多互联网工程师需要的品质。

标准化

一句话解读：以标准化为荣，以特殊化为耻

特殊化其中有一个表现是会写很多的 if.我认为放任特殊化，是一种偷懒的做法，商务没有搞定好客户，产品没有理解好需求，研发没有做好逻辑的抽象。

特殊化的逻辑有时是避免不了的，但是过多的特殊化逻辑会带来维护问题。比如代码越来越冗长，维护性差，测试人员要写更多的测试用例，产品运营人员要记住更多的配置，慢慢这些代码和逻辑会变成所有人的负担。

标准化是研发的一个理想和追求，但是又不是一个人的事情，特别是在 To B 的公司里，很多时候会有一些特殊化的需求，这时候怎么办呢？ 我觉得需要所有人思考：

1. 对于创始人和管理团队，想想公司的业务边界是什么，在业务上要有所取舍，不能什么都要

2. 对于商务，对于客户的要求是否要无条件答应呢，是否有其它的方式可以实现，是否可以先用标准化，满足不了再分期迭代

3. 对于产品，在产品交互上，是否就要想好未来的扩展性需求，在产品上做好兼容

4. 对于开发，是否可以多做抽象，少写 if-else, 多做配置，少做硬编码

清晰原则

一句话解读：文档和代码尽量写得清晰，容易理解，可维护

网上有个段子说： 程序员最不喜欢事情有两件，1 是写文档，2 是别人不写文档。

能把文档和代码写得可读性好，别人很容易读懂，我想也是判断一个程序员是否优秀的标准吧。

可读性差的文档/代码，不仅让需要协作的人读起来痛苦，不知所云，甚至产生误解， 还让自己在后期浪费很多时间去回顾当初想要表达的意思。

所以平时的话，我们会建议研发人员养成以下的习惯：

• 理解产品需求，并翻译成代码设计，整理出流程图，时序图， UML 图，架构图等

• 规划好代码实现的设计模式，包，模块和函数，对于无法直观理解的代码，需要添加必要的注释

• 将文档也纳入版本管理

另外关于怎么写文档，可以参考一篇文章怎么才能写好技术文档?这是我的全部经验^[1]

关于怎么画好架构图，可以参考下面的文章画一手好的架构图是码农进阶的开始^[2]

不存侥幸心理

一句话解读：问题往往出现在你认为最不可能出现的地方，不能想当然

有一种心理学效应叫“墨菲定律”，讲的是“如果事情有变坏的可能，不管这种可能性有多小，它总会发生。”。

而我笃信在开发领域也是适用的。 比如我经常遇到这样的情况：

case 1： code review 时，认为某段代码比较简单不用审查，结果上线就是那段代码出问题

case 2： 测试时认为某个功能之前已经测过好几遍了， 不需要再测了。 结果第二天出问题的地方就是没有测到的功能。

case 3: 做一些变更的时候，执行脚本时，脚本很简单，认为没有必要校验，结果执行的时候把所有用户数据都改错了，造成了生产事故

以上的情况都是真实出现的，而且出现不止一次，并非我自己凭空构想。

怎么避免或者减少上面的情况呢， 通常我们给研发人员的建议是： 不要想当然，严格按照流程走，不要漏步骤，不要偷懒。 另外就是群策群力，大家坐在一起，评估和讨论，也可以减少考虑不周全的情况。

参考资料

[1]

怎么才能写好技术文档?这是我的全部经验: https://mp.weixin.qq.com/s/FXjzItLWZRW7N3TDrEfgWg

[2]

画一手好的架构图是码农进阶的开始: https://juejin.cn/post/7062662600437268493