技术进阶的方法论-讲座记录

给大家分享一些技术进阶的方法论，我相信大家提升技术已经听过很多的方法，但这里我想给大家分享的并不是具体你应该怎么去学习技术，而是超越技术本身，我们在做技术的时候，如何构建一个正确的思维方式。这个思维方式不仅仅适用于前端开发，也适用于任何开发岗位，同时还适合于任何行业的技术从业者。

经过一些了解, 基本 80% 以上的同学换工作的原因都是：“当前公司的技术有些局限，感觉没有办法成长了，感觉没人带，感觉需要换一个公司去学习新的技术”。在这里我抛一个问题给大家，大家跳槽的时候，换工作的主要原因是否也是上面的这个原因呢？

产生这个问题的本质原因是什么的 ？我可以给大家分析一下，我相信绝大多数开发同学在工作之中会完全陷入到业务之中，认为技术是给业务服务的，只要把公司的业务做好，确保用户的体验就可以了。当然，很多公司也认为，开发同学把需求支持好就可以得到认可，晋升。 这样的一种机制会导致一个非常普遍的问题，任何的工程师，在任何公司的业务中，沉淀2-3年，都可以游刃有余的完成当前业务中的需求，同时，对公司的技术栈做到全面了解。这个时候，因为公司技术栈事相对稳定的，开发工程师就会觉得，现在的技术我已经都理解了，技术栈我也都搞清楚了，公司不能给我带来更多的技术能力提升了，我要换工作。同时，这个时候，我相信大家一定会认为，这是公司的问题，公司没有及时更新技术栈，没有组织技术培训，团队技术能力不行，没有技术高手带你…

但是这里我想告诉大家，其实，每一个技术公司都是这样，技术栈相对稳定，不会过多调整，业务也相对稳定。所以，当你打算离开公司的时候，其实这很有可能不是公司的问题，而是你自己的问题。 因为这个原因，换了一家公司，其实你可以想象一下，两三年后，你又会回到这个问题上来，在新的公司，你又熟悉了，你又觉得没有挑战了，你又要跳槽了，大家可以想一下，是不是这样的。

其实，当你在一家公司待了两三年，对公司的技术和业务了解正是深入的时候，正是可以帮助公司拿到结果的时候，你却选择了离职，从头再来，有的时候我会觉得这些候选人真的是在折腾，浪费了很多好的行业中的优质机会。

那么既然说问题不在于公司，在于我们自己，那么我们的问题在哪呢？其实也很简单，开发人员更多的把自己当成一种技术工具，去做固定的工作，而没有自己对技术的思考，和技术人员职业发展的方法论。

如果我问大家，十年后，当你体力不如年轻人的时候，在 IT 这个行业，你拿什么跟比你更优秀的年轻人拼呢？不知道大家有什么答案，我们可以交流一下。

大家看，其实很多人压根就对这个行业和自己真正长远未来的发展没有任何的计划。不过没关系，接下来，我要进入正题，把技术人的方法论分享给大家，大家把这几条做技术的方式整理好，按照这个思路来去规划工作，就一定能突破这些问题，成就更好的自己。

我把这套方法拆分成五个步骤，方便大家逐步实现：

1. 第一步： 确定技术领域

大家现在在公司做业务，我想都是去为了实现业务，但是我建议大家，在实现业务的过程中，搞清楚你所开发的产品，到底涉及什么样的行业领域，不要局限于技术，而要跳出来去了解产品，去了解产品背后的价值。这一步非常重要，因为当你了解了你所在的业务领域之后，你就可以去看同一个领域其他不同公司的类似产品了，他们的功能怎么设计？他们用到的技术是什么？他们比我们做的好的地方是什么？我们自己的优势是什么？在这个过程中，你会去有很多自己对行业技术上面的认知和思考，你也会很明确，如果你想把业务做好，技术上缺少竞争公司什么样的能力，自己该怎么学习去抹平这种差异。你看，第一步，当你不局限于一个需求，而能跳出需求从行业看待一段代码背后要解决的问题，那么你就会主动的找到要学习的点，而不是被动的在执行中学习。

说到这大家可能觉得，要做到这一点，有些难啊，也有些抽象。其实做到这一点很简单，你只要问问你自己，你是把公司的产品当作公司的产品，还是自己的产品，如果你能把公司的产品当成自己的产品来对待，那么你一定能弄清楚，你所在的业务和技术领域是什么。

2.第二步：领域大图的绘制

当你对你的领域足够了解，你就知道你要做什么样的事情了。如果你的某方面技术能力比行业差，那就要尽量抹平，如果你的技术能力比行业强，那你也要能够表述清楚。总之，这个阶段，你需要通过一张技术的图，把整个行业做的事情，和你所做的事情做一个分析对比，去在对比的过程中，其实你会发现，整个行业做的事情的一些共性，以及你和其他公司解决这类问题的各种各样方案。所以，绘制领域大图的过程，是帮助你梳理清楚，整个行业的技术方案，做横向的技术比对。

3. 第三部，构建技术体系

当你有了领域大图后，其实你对整个行业的技术痛点，就能有非常直观的体感，也就是说，你会知道行业真正的技术需求是什么。当你知道了行业通用的需求是什么的时候，往往解决这个问题，不能靠一个方面的突破，而是需要一个体系去解决这样的大问题。我这么讲可能很抽象，我给大家举个例子。

比如说 React 框架产生的过程一定是： 1. 确定技术领域（前端工程化） 2. 领域大图（各个框架的横向对比，找到问题） 3. 创建 虚拟DOM，响应式编程这个体系来解决问题。

能构建出这个体系其实是非常难的，也是我们技术从业者很难克服的一个瓶颈，因为大多数人只会局部的思考解决问题，思维的高度很难达到这个程度。但是，当你持续的去训练自己做事情的方式的时候，不断问自己，我的技术领域是什么，我的领域通用问题是什么，这类问题怎么去体系化解决。我相信你一定能找到这个体系化的解决方案。

我举个自己的例子：我再做很多Node的中间层应用，我知道中间层这个领域很多人都在做，那么我就会去看整个行业，中间层的问题是什么，解决问题的方案是什么。我会发现，中间层部署运维会占用前端工程师大量的开发时间，降低效率。那么如何降低运维成本，发布成本就是行业的问题。如何通用的解决这个问题，你可以使用Serverless这样的方案去解决这个问题，那么Serverless这套方案，就是你要构建的体系。这个体系不仅让你解决了自己的问题，也让你解决了整个行业的问题。

我想讲到这大家有一点懂了，做技术绝不是只实现功能，一定要有方向，知道自己要做的远远超出需求的完成。而在一个公司，如果你自己能把一个体系做出来，相信没有个五年是不可能的，如果你有体系化的思考，五年内完全可以在一家公司耐住寂寞，深耕下去。

讲到这，大家能尝试说说，如果让你从行业的角度，构建自己的技术体系，你会怎么构建呢？

4. 第四部：技术攻坚

当我们有了体系这个大目标，那么实现这个目标就会有非常多的技术挑战，就需要我们做很多的技术攻坚，所以你看，到了这一步，当你自己有了自己的体系后，技术的提升其实完全不需要靠别人，你自己就知道你自己缺什么，要去学什么，就会高速的发展。我们暂且不论体系最终是否搭建成功，但在这个过程中，你一定会快速的得到技术成长的。如果体系足够大，技术攻坚，后面又会发展到团队技术攻坚，那么你就要带团队一起攻坚，过程中，你需要学习带队的方法，排兵的技巧，等等一系列管理的方法。很多时候，很多Leader觉得，带队无非就是把需求分分工，实际上这个太局限了。Leader的作用在于构建体系，创立技术的大方向和目标，而人则是帮你实现目标的核心工具。好的Leader能够让团队上下一心，一起快速成长，而差点Leader只会写排期表。我也建议大家，当你有了自己的技术体系的思考后，再尝试带人，没有这套思考能力，你下面的同学就会和我之前的面试同学一样，2年就跑掉了。

5. 第五部：构建生态

当你的体系构建完成了，其实你已经站在行业的技术制高点上通过技术驱动行业的发展了，但这还不是最高的境界，其实你要思考的是如何形成自己技术的行业生态，你可以把它理解成开源，让它越做越大，越做越好，形成自己的一个发展闭环。如果你能够把这个生态做好，实际上你已经驾驭了一个npm，git这样的生态系统了，你可以想象下，这基本就是技术的巅峰了。

回头来看这五个步骤，我们来想想，不借助其他人，是不是自己就能从现在这么做，尝试思考呢？仔细想想，这个过程真的不需要你的公司很伟大，你的Leader很牛，你只要自己耐下心来做，有方向性的做就可以了。这就是我们说的方法论，不依赖于外部，可以让我们做的很好，也是今天我想跟大家分享的内容。

总结:

确定技术领域 -> 领域大图的绘制 -> 构建技术体系 -> 技术攻坚 -> 构建生态

之前，你可能以一个程序员的角度以需求衡量你的能力，今天开始，希望大家能以这五步中，你做到了哪一步来衡量自己。在工作中，进行不断的尝试，我相信大家不管在哪，都一定能取得很大的成功，不仅是IT领域，你仔细想想，这个方法是不是适用于其他领域呢？

如果面向工资编程 我没见过这样致富的程序员

如果为了工资去做好事情 可以活得不错 但不会很好 做技术还是要有机制的技术追求的

初入职场 选leader比赚多少重要的多

职场并不关心你是不是应届生

我认为理论大于实践, 经验谁都能有,理论可不是

学习没有捷径 慢慢学 比较快

往精英圈里混 没错的

未来可能是开发工程师和底层工程师