「技术人生」第2篇：学会分析事物的本质

技术一号位不是岗位，更多的是技术人员在公司中做事的一种心态，这个系列的文章适合所有想要对日常工作“知其然更知其所以然”的技术人，借助理论工具的指引，结合自己的实践经历，悟到自己的收获，从而加速成长的过程。大道理千千万万，有缘者得之真谛践于其行而非流于其表。

未来一段时间，阿里巴巴中间件公众号会持续发布系列文章，欢迎关注。

往期技术一号位方法论系列文章：

「技术人生」专题第1篇：什么是技术一号位？

背景

ALIWARE

生活中每时每刻都在发生着各种各样的事情，有些与己相关，有些看似毫无瓜葛，不论事情大小，总需要分出一部分精力，或多或少，对事情进行处理解决。在处理这些事情的过程中，在和某些人接触时，总能感觉到他们对事物的认知要更深刻，更全面，听其言如同醍醐灌顶，观其行胜读十年书。这样的人解决问题往往一针见血，事半功倍；而在和另外一些人沟通时，则可能会感到对方对某个事情的认知其实流于表面，解决问题往往抓不住重点，做的很辛苦却多是无用功。那么究竟是什么造成了两种人对事物认知的差异？是否有什么途径或者方式能够消除这种差异？

作为技术研发人员，总面临着各种各样的需求，总会有前人不断强调技术的复用，强调代码的重构，可是往往是倒排的截止日期逼迫研发更快上线临时需求，造成线上拣不干净的满地鸡毛，同时留下一身还不完的技术债务。为什么面对一定会变的业务需求，研发人员似乎永远跟不上需求变化的节奏？很多时候大家本能的会怪罪产品经理没有想清楚，那么有没有人思考过，和我们每天配合的产品经理或者运营人员，究竟是什么东西没想清楚，从而导致了我们研发同学自己不断地返工？他们没想清楚的事情，我们是不是从来就没想过？这些事情，我们该不该想，能不能想清楚，有没有好处？研发人员需要掌握什么技能来应对永远都在变化的业务需求？

作为系统架构师，在面对复杂业务系统时，开局往往操作猛如虎，三年规划五年演进，可是经过若干年的建设，往往只是遗留下众多见招拆招的祖传代码，新的需求需要在旧的业务逻辑的缝隙里面找“解法”，一线开发人员不仅要避开“牵一发动全身”的各种弯弯绕绕，可能连架构本身也已经变得模糊不清了，更不用提架构的演进。这一切都会逐步失控下去直到某一天达到临界点再来一次推翻式的重构，让混乱重新回到原点，开始新一轮的技术债务周期，当然，系统一定是 2.0 或者 3.0了（目前还没见过 4.0 的系统）。可是当年说好的架构可扩展性呢，说好的抽象程度高呢？架构本身究竟和业务有什么关系，架构的演进又和业务的发展有什么关系，如何才能让架构师打破“架构设计和演进过程被现实反复打脸”的魔咒？

作为研发团队 leader，带着自己的人做需求交付，一边忍住亲自下场写代码的冲动不得不做着项目管理的事情，一边又可能被下面的人怀疑技术能力；各种倒排的截止日期仿佛一条条排着队催债的红线，眼看着这些红线圈着自己团队的黑着眼圈的兄弟，在一个又一个的坑里面像炮灰一样摸爬滚打，而自己只能像一个大号的外包资源经理一样对这种局面在实际行动上束手无策，在思想上除了觉得要不断加人之外感觉无力回天。如何才能让团队成员在做业务的过程中不再是资源一样被消耗而是像资产一样自我增值？如何才能利用对业务发展趋势的预测打破规律提前布局，在战略上掌握主动性，从而在战役上既能先于对手做出稳定的产品，又能有足够的时间打磨产品从而提升用户的使用体验？

不同角色的技术人，不论在工作还是在生活中，面临的这一系列老生常谈的问题时，或许都希望能有一抹就灵的万金油，打一发银弹出去，就能够留下广为业内传唱的人月神话。可是在现有的生产力条件下，技术人员既没有万金油，更不存在银弹，而且人月神话永远都是神话。所有的事情，所有的问题，想要被解决，都要回到最初的原点：这件事情的本质是什么？也就是说，我们日常工作中的事情的起点不是使用什么工具解决问题，而是先认清这件事情 —— 认清一件事情的本质，是所有后续行动的前提和基础。做业务需求分析也好，做架构设计画架构图也罢，计算机语言和技术栈的选择以及相关整体解决方案的构建是一方面，而“基于对业务本质的理解进行的业务建模并结合业务发展持续演进”是极其重要的、却往往被忽视的另外一个方面。

日常工作中，很多研发人员往往把注意力集中在各种计算机语言及其技术栈上，大家会花时间翻看各种技术书籍，探究各种技术方案背后的原理，然后通过业务实践提升个人技术能力