一、引子

时光如逝，2023年眨眼已经过去快六分之一了，近来跟同事和朋友聊的时候发现，有小伙伴对未来的发展方向和能力提升方式都有一些迷茫和不知所措，同时跟一些大牛们讨论过如何向上向下汇报、如何推动项目、如何成长，也随之有了一些感悟，借此机会写下来，希望能跟大家能一起探讨探讨。

二、概述

本篇文章的主题是思维变化，即讨论研发人员如何在思维上改变自己的工作和学习习惯从而提升自己的整体水平。

三、思维是什么，对我们有什么影响

思维是人类所具有的高级认识活动。按照信息论的观点，思维是对新输入信息与脑内储存知识经验进行一系列复杂的心智操作过程。分析与综合 是最基本的思维活动。以上来自百度百科哈哈:)。从“思维”两个字中，我们也可以领悟到一些东西，“思”即是思考，比较容易理解，关键在“维”字，“维”有角度、维度的意思。言归正传，对一个码农来说日常的工作就是代码开发，而思维方式会决定我们的代码水平和研发能力的提升。

思维如何影响我们呢，举个经典例子：一家大公司引进了一条肥皂生产线。这条生产线能将肥皂从原材料的加入直到包装装箱自动完成。 但是销售部门反映有的肥皂盒是空的，经理要求工程师们解决这个问题。于是成立一个以几名博士为核心、十几名研究生为骨干的团队。在耗费数十万后,工程师们在生产线上一套X光机和高分辨率监视器,当机器对X光图像进行识别后，一条机械臂会自动将空盒从生产线上拿走。 另外一家乡镇企业也遇到了同样的情况，管理生产线的小工找来一台电风扇，摆在生产线旁。装肥皂的盒子逐一在风扇前通过,只要有空盒子便会被吹离生产线，掉在箩筐里。

就从本事例上来说确实一套高科技的检测流程还不如一台电风扇，不同的思维方式导致花费的代价不同。

大家别慌，让我们再换个角度探讨一下，假设我们现在生产的装肥皂的盒子进行了改良更精美也更重了，电风扇吹不动了怎么办；假设我们另一个做罐头的生产线也需要检测罐头里是否有桃子怎么办。

再换个角度看上面的例子，有没有感觉像是我们开发一个很小的项目时，投入了大量的人力物力做了一个apm系统来保障这个小项目的线上正常运行和安排一个同学每天去线上看一眼是不是项目还在正常运行类似，那么大家觉得这个apm系统应该不应该开发？对于这个问题，我们先不着急把答案定下来，看完下面的分析我在再来讨论。

四、研发能力的评判

对于研发的能力，各厂都有自己的职级划分，这里我们举个例子吧(一家之言，大家轻拍)

入门阶段：在他人指导下能够完成比较简单的任务

编码达人：代码的质量和效率都很好，能独立完成任务

独当一面：作为核心骨干能够负责中小型项目的研发管理

技术专家：具备架构设计能力，有实现大型系统的能力

领域专家：行业的领军人物，某个头部系统或者产品的领头人

以上不同的级别对应不同的能力，而我们的成长应该包括两个方面，一个是知识，另一个是思维，两者相辅相成。有了一定的知识会改变我们的思维模式；有了一定的思维模式时，会自动去学习欠缺的知识。知识的学习已经又很多教程了，下面我们先从思维模式上聊一聊。

五、聊聊几种研发中的思维

1、框架思维

软件开发是一种知识活动，因此知识的聚集和积累是至关重要的。框架能够采用一种结构化的方式对某个特定的业务领域进行描述，也就是将这个领域相关的技术以代码、文档、模型等方式固化下来。

2、架构思维

一个系统的运行模式是怎样进行，前后端如何协作、数据如何处理、前端如何展示通用逻辑如何公共和抽象、开发调试部署的流程、功能的可扩展性、服务的稳定性设计、高并发的设计、程序的安全性设计、生态建设等等，我们可以将这些通用的设计从架构层面上进行考虑和实现，而业务开发只需关注业务的逻辑。

3、懒人思维

软件的目标，是某些工作自动化，从而让某些人可以更懒。重复的事情一定不要自己手工重复完成，侧重于自动化。思考如何把这些原来需要很麻烦的事情，自动化执行。比如使用脚手架进行项目的初始化、CI/CD减少项目运维的工作、自动化测试减少测试的工作量。

4、全局思维

任何一个岗位都有其上下游的链接。比如研发的上面有市场，下面有生产。当你写客户软件时，你得站在客户的角度看看方不方便使用、系统稳定不稳定、体验有好不友好；当你设计架构的时候，你得考虑软件工程师方不方便使用；当你设计整个开发流程时，你得考虑团队的效能。更进一步，你的这个技术方案对于公司整体技术方案的适配性怎么样，也应该考虑考虑。

5、系统性的思维

当你在写代码的时候，你很容易就认为只要你按照需求实现了指定的功能，你的代码就写完了。如果想写出真正有影响力的代码，你需要从整个系统去理解你的工作：

1).你的代码和其他人写的代码在功能上是什么关系？

2).你有没有好好测试你的代码？或者其他人是否很容易测试你的代码？

3).为了部署你的代码，线上生产环境的代码是不是需要改动？

4).新的代码会不会影响到已经运行的代码？

5).在新的功能下，你的目标用户的行为是不是你期望的？

6).你的代码有没有产生商业上的影响？

7).你的代码是否兼容老数据？兼容不同的入口场景？

6、创新思维

是指一种能够激发创造力和创新灵感的思考方式。创新思维通常包括挑战常规思维方式的能力、在问题解决中采用多种不同的角度和方法、发掘新的机会、将不同的元素或概念组合起来以创造新的东西等能力。技术的更新迭代很快、软件产品也越来越多，各行各业、时时刻刻都在有创新，别人创造出来了，我们不学习就会落后，只有保持进步和创新才能不被这个时代所抛弃。  

以上总共介绍了6种思维(如有遗漏欢迎补充)，对我们研发来说，如何通过思维上的改变来提升自己的能力呢？ 

六、能力进阶与思维改变

对于不同阶段的人，进阶的路线也是不一样的，这里我们还是以之前的职级为例，探讨一下如何通过思维的改变来完成能力的进阶，希望能给对自己的成长路线不太明朗的同学有所帮助。

1、假如你是一个加入到码农行业的同学：希望你能有“框架思维”，在稳固基础知识的同时，能够养成良好的思维习惯，做任务前能够了解何种技术可以实现你的需求，完成任务时做好总结并形成文档，反思自己做的好的地方与不好的地方，将解决过程和避坑经验进行归档，方便后来人的查阅和学习，在日益的积累中，你代码的质量和效率都得到很好的提升；

2、假如你是一个编码达人：希望你能有“系统性的思维”，工作中要不断的思考你负责的模块在整个项目中是属于哪部分，你的程序是如何运行，模块之间是如何互相调用的，项目周期的每个阶段需要做那些事情，了解你的角色以及项目负责人的角色需要做哪些事情。日常工作中要以积极的态度去推动项目的进行、遇到技术卡点问题要多从原理层面进行分析。强烈的责任心、良好业务能力、出众的技术能力是你成为项目负责人所不可或缺的因素。

3、假如你已能独当一面：希望你能在日常工作中不仅仅局限于业务的研发，在代码开发的过程中能有“架构思维”。针对需求的实现，要关注：架构设计的是否合理、性能上是否有不必要的浪费、安全漏洞是否有统一解决方案或防御、公共能力的抽象和使用是否合理、核心业务逻辑的流程是否合理、库表设计是否有空间的浪费等等；技术选型上参考以往类似实现怎么做的，是否还适用、是否要有改进、依赖哪些能力等；

4、假如你是一个技术专家：你需要有“全局思维”、“懒人思维”。你已经拥有架构能力，可以设计项目的架构，但与此同时也更需要关注系统的兼容性、数据迁移方案、可拓展性、稳定性，以及架构提供的能力是否可以让开发者不必关注底层基础能力、公共能力而只专注于业务开发；在开发流程上是否可以做到精简，减少项目上线的流程；通过自动化的检测代码安全、逻辑漏洞、文件格式化、测试等提高开发效率保证运行质量；提供的公共化能力是否有相应的文档建设、测试用例、生态能力；完善基建平台的能力，比如监控系统运行情况的apm、实时更新应用配置的配置中心、应用部署运维的平台、公司内部的管理/工具平台等等；产品的功能是否做到了人无我有、人有我优，交互和性能的体验是否做到了行业领尖，如何做到超越；这些都是我们走向行业顶尖所需要的基本能力；

5、“创新思维”具体对我们研发来说怎么理解呢？我先抛个砖：已有的事物，去研究实现的过程，叫学习或者模仿；知道一些技术或理论，去制造未出现的东西，叫创新。创新比较难，相对而言模仿比较简单，因为我们有行业的标准作为参考，比如“小程序”，自从微信有了这个产品之后，大家竞相模仿；但是相反我们会开发native的app却不一定能创新性的开发出“小程序”。不过创新其实无处不在，我举个例子，假设我们学会来使用游戏引擎Cocos，用它我们可以实现一个“小猪挖土豆”(查了下还真没有)的游戏，这个算是一种创新；如果有实力换种实现方式重新写个游戏引擎，这也是一种创新。保持一种思维习惯，说不定哪天突然灵光一闪，就走上人生巅峰了。

最后呢，我们再看下之前说的一个小项目，我们有没有必要花费大量的人力物力去建一个apm系统？这是一个开放的话题，假设的条件不同答案也不相同，但是我相信很多人已经有了自己的想法了。

七、小结：

谈思维是一件很空洞的事情 ，因为思维实在看不见，摸不清。它不像知识，知之为知之，不知为不知。经常听到人说，你说的我都懂，可我就是做不到，这就是一种思维习惯。所以思维不在于你知道还是不知道，而是一个思维惯性，思考问题的时候，多去提醒自己去往这个维度上想一想，时间久了也就成自然了。ps：如有不合适的地方，请指正～