很久没有更新博客了。原因在于工作发生了变动，去新公司的第一个任务就是从无到有的开发一套亿级交易量的系统，因而开启了一段996的生活。不得不说，996对于精力的消耗真的是太大了。之后将恢复更新。下一步在技术方面将会介绍一下这两年来开发这套高并发系统的一些心得以及部分关键技术的实现原理。这一个系列主要介绍一些工作中的思考。
细细算来，我参加工作已经五年了。这个阶段的工程师经常会进入一个瓶颈期。瓶颈期最常见的表现就是：工作本身已经无法让自己继续成长。而程序员恰恰是一个渴望成长，需要成长的职业。这种客观情况与个人理想之间的矛盾让让人感觉无力。很多人也从此卡在了这个瓶颈期，再无进步。
一、工作的意义
互联网行业的一个特点就是工作强度高，单元化程度高。长期的重复劳动很容易让大家忽略一个问题，那就是：工作到底是什么？
其实在职场上，所有的工作本质上是一样的，那就是：资源交换。代码能力是资源，懂业务是资源，甚至与上级或者其他部门的关系也是资源。而工作就是上述这些资源的交换和重新分配。一个聪明人所要做的，就是使用更少的资源去换取更多的资源。
上面的说法有些抽象，我用一个例子进行具体解释。当产品向你提出业务需求时，你可能会有如下实现方案：(1)告诉他目前已经有实现好的功能，直接用；(2)生产系统支持灵活配置，无需发布即可生效；(3)业务逻辑影响小，代码稍微改一下就可以实现；(4)业务逻辑影响大，需要大改动；(5)这个需求做不了
很显然，在收获相同的收益(产品上线/KPI完成)的情况下，你所需要付出的资源按照从小到大排序依次是：(1)>(2)>(3)>(4)。而(5)则是0收益或者是负收益。因此，可以得出结论：在日常工作中，我们要做的就是努力达成(1)或者(2)，尽量避免(3)、(4)和(5)。
然而，在真实的工作中，很多程序员接到需求脑海里第一个反应是：这个功能怎么开发。而没有尝试去问自己，有没有更好更快的方案。这种默认把自己限制在(3)和(4)中的潜意识，会大大束缚你的系统设计能力，进而影响到个人成长。
不是所有的需求都必须用开发代码的方式去解决，多从系统设计层面去想问题
二、业务标准化和业务积累
程序员圈有一个很有意思的现象，那就是：虽然大部分人都是围绕着业务做开发，但是共同语言不是业务，而是基础技术方面(如语言/开源框架等)。产生这个现象的原因是：IT行业标准和积累的缺失。换句话说，一种业务没有一种统一的实现标准，每个公司都有自己独特的实现路径。当程序员跳槽时，他所能带走的只有基础知识。而与公司盈利息息相关的业务能力则留下来了。
程序员的年龄危机也跟积累的缺乏有很大的关系。之所以机械/土木等领域的工程师较少遇到年龄危机，一个重要的原因则是这些行业都已经是极度标准化。由于大家都遵循同一个标准，因此工程师在跳槽时业务能力得以保留，其业务能力随着工作年限的增加是一直在增长的。
目前在某些业务领域(例如广告推荐/系统中间件/第三方支付等)，互联网行业已经逐渐有标准化趋势了。甚至在系统架构层面，阿里提出的“大中台，小前端”也逐步得到行业内的认可(然而，在具体落体时还是同样的问题：一个司令一把号-各吹各的调)。不过业务领域的标准化还是有一段相当长的路要走。
让我们再把视线拉回到自己身上。在这样一个容易清零的行业，我们应该怎么实现最大化的业务积累呢？我有以下几个建议作为参考：
(1) 初始职业和出生点一定要选对。参加工作的前五年是业务能力提升最大的几年。而公司和工作则是影响提升速度的最大两个变量。一般来说：行业中枢公司优于分支公司，大公司优于小公司，核心部门优于边缘部门。主力开发优于辅助功能开发。而是核心与否有一个最直接的标准，那就是公司靠哪个系统活着，哪个就是核心。
(2) 不要频繁跳槽，尤其涉及到业务方向转换时一定要慎重。跳槽是对个人业务能力的一次严重伤害。涨薪固然很好，但一定要注意业务方向是否能让你得到连贯的提升；
(3) 培养自己的大局观和方法论。 在工作中，要清楚的知道自己做的事情到底对整个系统，甚至整个行业有哪些影响。影响有多大。需要哪些部门配合你完成工作。而你的工作又是对谁负责。这些问题只有在符合(1)中的岗位才有讨论意义。
上述三点都是一些主观判断，甚至有些时候带有一些运气的成分。