程序员三板斧-技术、业务、管理

吉利商用车

1、认知

• 程序员的核心能力是什么？
  
• 日常工作主要是开发业务需求，技术能力如何提升？
  
• 业务技能是否是程序员的核心能力，业务技能是否具备可迁移性？
  
• 随着工作经验积累和技术能力的提升，是走技术专家路线，还是做技术管理？
  

在我经历的十余年职场生涯，先后经历了职场新人、资深研发、小组技术负责人，至目前负责跨领域几十人的技术团队。在成长过程中有一些自己的思考总结，希望能够给到大家一些新的认知，帮助新人能够更加清晰化成长方向。文章中我对技术、业务、管理三个方向的思考总结，仅仅是我当前阶段下的认知，不一定完全正确，大家选择性吸收。为了说明这个问题，我想先介绍下“达克效应”。


“达克效应”被心理学家称为元认知（metacognition，即对自己认知过程的认知）。“达克效应”指出我们每个人首先会经历以下几个阶段。

• ”不知道自己不知道”，这个阶段的典型特征是，迷茫（不知道提升方向）、高估自身能力，比如在读大学期间，认为计算机相关课程没什么用，不知道未来的发展方向，上大学也只是走个过场。
  
• “知道自己不知道”，随着经验、阅历的提升，逐步认识自身的不足，明白无知多可怕。比如工作几年后，我们会遇到能力提升的瓶颈，这个时候我们会逐步认知到，计算机基础、思维认知模型、知识体系的重要性，但这些点其实是需要长期的积累。
  
• “知道自己知道”，经过长时间的打磨积累，逐步建立起知识体系，这时我们会发现，曾今我们认为高深的技术，逐渐变得清晰，对新技术学习，也逐渐变得简单，因为技术的原理其实都是相通的。
  

程序员成长过程中，会重复经历以上几个阶段。例如我们经过长期打磨积累，逐步构建技术能力，但是在成为团队Leader后，作为技术管理者需要构建新的认知体系、方法论。
2、技术

技术成长4个阶段：

• 基础：需要关注如何写出好代码，学习别人的设计思路并具备单模块的设计能力，重视规范和流程，并注重培养好的工作习惯（例如：严谨、主动、专业）。
  
• 深度：关注跨模块或者子系统的设计，有意识提升自己的架构能力，丰富自己的技术栈并注重技术深度的钻研。
  
• 广度：关注系统化的分析和解决问题，有不错的架构能力，并逐渐形成自己的方法体系。视野要开始打开，从本系统到上下游，从技术到业务，从个人到团队。
  
• 引领：技术和业务，擅长抓问题的本质，具备中长期的规划能力，能够从更远、更长期的角度分析问题并作出决策，经验可迁移。
  

雷军曾说：“我刚接触电脑就发现电脑的妙处，电脑远没有人那么复杂。如果你的程序写得好，你就可以和电脑处好关系，就可以指挥电脑干你想干的事。这个时候你是十足的主宰。每每你坐在电脑面前，你就是在你的王国里巡行，这样的日子简直就是天堂般的日子。电脑里的世界很大，编程人是活在自己想象的王国里。你可以想象到电脑里细微到每一个字节、每一个比特的东西。”
现如今计算机程序开发已经高度分工（技术领域和业务领域），有专门负责前端的前端程序员，前端领域中还会细分面向andriod、iOS、web开发等。后端分工会更细，比如负责应用开发、基础中间件开发、系统运维、数据库运维、大数据等等。下图是面向主流应用开发技术栈。


无论是前端还是后端，技术能力构建都是围绕”性能体验“、”研发效率“与”系统稳定性“这三个方向。前端的发展趋势是横向跨端的大前端体系，跨平台技术是一项基本能力。后端核心能力包含模型抽象（数据模型、领域模型）、分层思维、设计模式、设计原则、计算机基础等。
现代应用技术更新迭代速度非常快，简直是日新月异。大前端新技术、各种开发框架层出不穷。随着ServiceMesh的发展，后端技术体系也会有非常大的变化，这也是技术人员焦虑的根本原因，需要不断学习新技术。
人的精力是有限的，如何把有限的精力投入到重要事情上。对于技术提升，我的个人观点是，技术学习提升首先要聚焦，也就是要先有深度后有广度，没有深度的广度是没有意义的。对于技术的学习，我推荐链式学习法，将知识连接成锁链，环环相扣，逐步形成自己的知识体系。比如下图针对Tomcat学习，从tomcat的学习中逐步加深JVM、类加载、多线程、IO、设计模式、设计原则、性能监控及调优等领域技术深度。


3、业务认知

很多技术人员都有一个朴素的想法：“我很喜欢技术，我就想一直深入做技术，成为技术高手。至于业务和管理，还是让别人去搞定吧”。这个想法很美好，但是不符合现实。职场晋升要遵从价值原则，特别是高级别，业务能力和管理能力都是创造价值的核心能力。
为什么要懂业务？有哪些好处体现？

• 懂业务，才能更好的理解需求
  
• 懂业务，才能更好的设计技术方案
  
• 对于技术管理者，懂业务才能更好的规划技术
  

程序员在沟通交流能力上普遍比较薄弱，不愿意主动的业务沟通交流，所以我们对业务的认知主要依托于产品经理。我们合作的产品经理，并不是每一位都足够的专业，能够基于业务给出合理的解决方案。如果合作产品经理并不十分专业，技术人员单纯的按照产品设计去实现，往往要么不满足业务诉求，要么实现方案过于复杂，增加开发及维护成本。
如何才能加深对业务理解，摆脱对产品经理极度依赖，这里推荐一种方法。结合领域设计与6W模型，从业务价值目标出发，逐步聚焦抽象出业务功能，最终转换为技术可落地的业务实现方案。

• Who:  需求方、推动协调者
  
• Why:  项目目标是什么，业务价值体现
  
• What: 明确业务功能
  
• When:  随着时间推移，参与方逐渐增加
  
• Where:  明确范围，团队、系统模块
  
• hoW:  业务实现、明确产品方案
  

4、技术管理认知

如果说理解业务能创造更好的价值，那么发挥团队的作用才能创造更大的价值。对于互联网技术人来说，“带团队”是迟早都要面对的事儿。做技术和带团队，更像是职业发展的两条腿，而不是完全叉开的两条路，所以关于走技术专家路线，还是做技术管理，我的答案是先成为技术专家。
“带团队”能力要求

• 技术能力：常用技术的深度和宽度缺一不可，架构能力非常关键。否则技术方向都把握不好，技术决策也容易出问题。
  
• 业务方面：不了解业务，技术没法落地，不仅要求熟悉业务而且应该具备比较强的业务意识。
  
• 软性素质：沟通协调能力和做事靠不靠谱，聪明的人很多，但是靠谱的人很少。
  

在互联网领域，如果你服务于一家快速发展的公司，公司根本就等不到你掌握了管理技能之后再让你带团队，上级会推着你边做边学，新晋管理者，往往对管理者的职位认知不足，导致引发很多问题。这里对工程师和管理者的差异做个对比，加深大家对技术管理者的认知。


    5、结束语

人总是会高估短期的成果，却低估长期的成就，认准方向，生命不息、步履不停。别轻易给自己设限，能力不只是经历决定的，也有意识与胆量。

半毛钱

但是三个方向都全面发展不太现实，没时间也没精力