写给天天被无聊业务需求追着跑的你~
程序员经常说的那句话是什么来着？我其实不怕忙，就怕忙的没意义、没成长~
所以，很多人最怕的就是那种：需求点贼琐粹，时间还贼紧，关键架构还都是现成的，贼没有挑战，几乎是那种纯写代码的，还左一个右一个提过来的需求~ (组里人手少，想推都推不掉~)
我相信这个感觉，应该算是不少朋友的困境，特别是工作前一两年的朋友。
作为老一辈无产阶级程序员，我觉得有必要和年轻一代的小火鸡们交流一下心得
。最近我也被一个需求恶心坏了，文章都更新不及时了
，需求进度好不容易赶上去点，抽空来理理心路历程~
1天天业务代码怎么办
有的同学总是向往中间件、框架代码的研发。这其实没有问题，因为相对比而言，中间件和框架，需要的技术深度和知识把控程度，都要比业务代码要求更高。
就比如，上篇文章中提到的RocketMQ主从复制的锁优化，将多重重量级锁下保障线程安全的问题，简化为buffer切换+写buffer两个CAS。
如果是业务代码里遇到类似的场景，我们在开发的时候，会计较这么细么？
大概率是不会的。为啥？个人理解，是因为业务代码中涉及的更耗时的逻辑多的是，一个接口调用，甚至是一个缓存存取，就要比这个锁的影响大的多，我们更愿意用个并行的方式，让更短的耗时短板，来掩盖这个很小的性能损耗~
人都是有惰性的~，有些行为是潜意识的，不知不觉就这样做了~
为什么RocketMQ非要把多个重量级锁优化为2个CAS锁呢，是因为对于RocketMQ的业务场景和作用，这个"小小"的性能损耗，会对系统的吞吐量产生很大的影响~ 换句话说：这也是没办法，被逼的~
所以，当我们意识到这个事情的时候，框架代码好像更香一些了，但还会认为业务代码一点价值都没有么？
只要我们够仔细，就会发现一大堆的点，可能都有更优的写法，小到ArrayList和LinkedList的类型选择，大到锁的优化、同步块的减少和消除、并行资源的控制、线程池的优化、JVM友好的代码模式等等~
所以，当我们去写一段业务代码的时候，可以这样问问自己： 我的这段代码，会不会被后面接手的人骂！ 我的这个优化和注释，会不会给后面接手的人上一课!
2拿什么去拯救你，我的职级
工作为了啥？升职、加薪、迎娶白富美、当上CEO呗，还能是啥！
自私点的说，我们大部分人工作，都是目的性很强的，没有那么多人是为了热爱，起码我不是，如果正好有兄弟是，那我真心服气。
刚看了《功勋》，凡是得了共和国勋章的前辈，都是因为热爱、专注，这是一种常人难以企及的高度，不得不服~
那么，说回我们普通人，同样是坐在一起写代码的一群人，怎么能做到比别人容易升职呢？
阿里有句土话，叫"以结果为导向"，细细想来，创造这个话的人应该是很厉害的，虽然这个行事准则在阿里内部越来越严重的被演化为吹牛逼，但不得不说，对于个人成长，是重要的。
那么，怎么以结果为导向呢？经常做需求的我们知道，一般小的需求，基本都是一两个星期就完事了，但是大的需求，动则几个月，多则按季度来算。
小需求其实很难做出什么结果的，主要还是看大需求。
就按3个月的周期来算，这样的项目一年才能做4个，还不一定经常有，所以，如果遇到这种以月为单位的项目，并对这个项目所需要的技术和所能获取的知识有了一定把握的时候，一定要问问自己： 我做完这个项目，能不能总结一篇文章发到公司的技术公号!(打个比方~)
如果可以那最好，如果不行，那就不要在这个项目上浪费太多的精力，能复用的，能拆解的，能抛锅的 你懂的~ ，尽可能缩短投入，去做更有意义的，比如技术驱动的需求。
3总结
曾子曰：“吾日三省吾身：为人谋而不忠乎？与朋友交而不信乎？传不习乎？”
这里，我们也要效仿一下古人了：
当抬手写一段代码时，问自己：这么写，后面的同事会怎么评价我？ 当我们起手做一个项目，问自己：这么做，自己的投入产出是怎样？
另外，从别处看到的一个方法也非常好，分享给大家：一学、二练、三讲。最终落到讲上的原因是，当你可以给别人把一个知识讲清楚时，说明你掌握的要远比这个知识要多的多了。
推荐阅读
高并发垂直优化系列：
高并发整体可用性系列：
腾讯云开发者
