十几年老码农，讲讲互联网、软件行业的那些事儿。欢迎关注同名公众号：“屋顶的闪闪星光”
刚开始学Java时，在main函数中调用了一个有200多行代码的test方法，一个师兄告诉我，你得根据他们的职责提取出方法来。慢慢地，类、变量、switch等一个个的概念去学，每多懂一个概念，写的代码功能就复杂了一些。
后来又学了网络中的7层模型、多线程、异步操作文件等，有一次操作系统老师讲课时跟我们说，学软件本质就是在学习一个个的概念、模型，然后练习如何应用它们去解决问题。那时我还年轻，虽然觉得有道理，但没有很深的感受，现在回想起来，这个老师对计算机的理解层次很高了。
毕业工作几年之后，我掌握的概念和模型越来越多，设计模式、各种中间件、高并发应对方案等等，慢慢地对老师那句话也感触越来越深，原来这些年学习软件的基本思路一直没有变化。就是在学习理解一个个的概念，然后把现实中的问题往上面一套，就把问题解决了。
再后来，我做架构师，关注领域划分、能力抽象、并基于软件分工的基础之上排兵布阵。然后又开始带团队，开始做技术规划，从业务问题、关键指标，到运营策略、产品能力、技术支撑、人员划分、RoadMap，甚至人员招聘。
一步步地学习、成长、应用，最终发现，所有的一切，都是套路。
现在把一份简历摆在我面前，让我判断质量的话，抛开面试时经常关注的候选人项目经历、专业基础知识等这些表象，我一直在关注，并且想通过交谈挖掘出来的其实是以下两点：
1、他有没有学到足够多的套路，比如，计算机领域的常见基础模型、做技术方案的几个要素、项目风险控制的几个关键点等等。
2、他有没有得到机会，可以通过应用这些套路来解决足够复杂的实际问题。
我看过大几百份各种各样的面试官从专业角度对候选人的评价：基础是否扎实、思考问题是否全面、异常逻辑是否会考虑到、有没有架构意识、解决问题时有没有系统性的手段等等。这些评价的背后其实都是上面这两点。
为什么大厂的人都很受欢迎？就是因为上面这两点中，不管是复杂的业务问题，还是与大量优秀的人共事从而开阔自己在套路上的视野，在大厂中特别容易获得。
我们进一步再提炼一下，在软件工程这种应用理解套路、解决现实问题的工程领域内，一个人要把专业素质提升到专家级别，一要靠掌握足够多的套路，二要靠碰到过足够多的问题。
讲完道理，再举两个例子。
比如，软件工程师在动手写代码之前被要求做一个技术方案。
如果没有学习过技术方案的套路，面对这样的一件事可能无从着手，要么觉得写无可写，要么觉得东西太多无从着手。而学习过套路的人，可能甚至不需要思考，就可以从目标问题、业务场景、需求价值、调用链路、数据模型、稳定性防控、资金安全、异常流处理等等这些方面选择出来一部分对当前业务需求比较重要的模块，拼装出来一个完整的技术方案。
再举个例子，业务侧的需求提到一个研发团队来，研发团队的TL需要拍板接不接这个需求。
如果没有做过TL的人，可能陷入两难：接吧，团队负荷已经满了，再接兄弟们要造反了；不接吧，业务方讲得头头是道、天花乱坠。
这里的核心问题是什么呢？作为技术团队的TL，需要掌握一个判断业务需求的价值和优先级，以及工作分配机制和评估团队工作吞吐量的套路。你的规则是明示所有需求方的，他们的需求也要能够量化出来价值，并事后追溯，这样大家就很容易讲清楚了。
以上两个例子中，是这些套路有多么高深么？非也，主要还是看一个人有没有接触过，有没有机会多用这些套路来处理过问题。
说到这里，针对第二个例子中的团队管理，我多讲几句，因为很多人比较关心管理。常见的言论，如，做技术如何，做管理如何；技术年轻时搞搞，岁数大了要转管理等。
我一直强调专业能力更多靠个人奋斗，而管理更多是组织赋予的，除少数天生缺陷的人之外，一个人能不能当管理者，不是取决于自己够不够努力，而取决于组织是否需要这样的职位，以及他是否符合组织的选拔标准。
那组织的选拔标准是什么呢？信任！管理工作很难量化，事情靠下面做，管理者负责资源分配，而资源分配创造的价值占比是很低的。我们可以看到，有的人业绩不行，但位子坐得稳甚至还能晋升，有的人能力强，但几上几下。
大家不要用个人能力衡量一个人的管理工作，他既然呆在那个位子上，一定是上面认为他行，如果我们认为他不行，那是因为我们跟他上面的标准不一样。
以上，是关于“管理”的套路。
最后再讲讲实操过程中可能存在的一些误区。套路和问题并不是经历得越多越好，更重要的是一定要在一个主线上，具备连贯性。
这里拿我个人经历举个例子。
在我个人能力成长期，曾经有一个主管跟我说过，你现在这个阶段不要再去做那些从0到1的事情了，那会让你把精力都陷入在一个又一个熟悉新业务上，那样看起来是在不断学习，实际上都是简单地叠加，没法从量变到质变，还空耗了时间。
后来，他安排我去了一个已经度过了从0到1阶段，正在快速成长的业务团队，呆了三年，完整经历了业务从1做到100的过程。每一次业务量级的上升，业务逻辑的升级，都会进行一次系统重构，我不停地在架构扩展性、对未来的预判、有限的资源、技术难点等几个事情中钻研、权衡，被业务逼着取得一个又一个地突破。
终于，我达到了自己一直梦想中的专家级，那是一种什么样的状态呢？我有信心，在一个领域内，任何难题摆在我面前，我都会心里不慌，给出解决方案，或者思路。核心原因在于，我已经在处理大量复杂问题的压力之下，将这个领域内几乎所有的套路都见识、应用了一遍。
以上，“绝对”适用于软件工程领域，“应该”适用于绝大部分应用基础理论解决现实问题的工程领域，“并不”适用于基础领域前沿的无人区问题。
