技术人的年终总结

关于思想

教科书式的努力

努力很重要，这个观点从小学到高中都在强调这个。如果写作文，很多经典案例，季羡林的早起读书，邓亚萍依靠努力克服身体缺陷，贝多芬的失聪后的创作……感觉我的高中作文就是典型的鸡汤文。
下面再来一段科比的

记者问科比：“你为什么能如此成功呢？”
科比反问道：“你知道洛杉矶凌晨四点是什么样子吗？”
记者摇摇头：“不知道，那你说说洛杉矶每天早上四点钟究竟什么样儿？”
科比挠挠头，说：“满天星星，寥落的灯光，行人很少。”

后来程序员模拟了和科比的对话

程序员问科比：“你为什么能如此成功呢？”
科比反问道：“你知道洛杉矶凌晨四点是什么样子吗？”
程序员：“知道啊，那时候我还没下班”
科比: ……

你面对运气超好的杨超越。是否能和她好好聊聊努力的重要性。
你面对刘秀，你问问那场陨石是不是他自己努力得到的。
相信大家看过不少鸡汤，毒鸡汤，各种态度都有，既然都有案例，那么说明就不该讨论努力的问题。
判断合适场景，判断时机，以最少的努力达到相同的效果。这个才是值得思考的。没有合适的场景和时机，努力起来很费力的。如果没有合适的场景和时机，那么努力与否看个人。场景和时机的如何判断，推荐可以看看《易经》。

结论分析方法

如果给定一个落后的乡村作为条件，如果说这个地区癌症率高，我们就会想到是经济条件差饮食，医疗等落后导致，如果说这个地区癌症率低，我们就会想到是环境污染少导致的。
明明是同一个条件，给不一样的结果，我们就会想到不同的部分来作为诱因。我们分析自己的时候往往也是这样，从结论出发思考很简单，但是忽略很多条件，以上面的为例，饮食条件差是不好的，环境污染少是好的，那么同时作用，为何导致结论才是值得思考的。起码是一个调查，归因的过程，需要屏蔽结果来列出条件，做推演。推荐丹尼尔卡尼曼的《思考，快与慢》。

关于技术

对于技术的思考，我的感觉就是合适。
通过一些案例来聊聊。

全能工程师

我的一个朋友，说他们的研发很厉害，一个人搞定了前端和后台。我感觉一个人能干这么干，说明项目人手是肯定不够的，而且应该做出的是一个符合当前场景的代码。这里说符合当前场景，很重要。例如业务好了，tps超高，客户说界面太丑等等，那么更多专业一些的需求出来的时候，是否应该交给专业的美工，前台，后台，dba呢。全能肯定是有代价的，有点类似cap一样，是互相制约的，一定是选择削弱了部分才能达到的。这里不需要抬杠，肯定会有各方面最终都可以达到一定程度的人，例如可以使用时间积累，3年前台，3年后台，3年dba。你差不多可以和3个2.5年的组合一起比了。
一个技能达到一种层次是需要时间的消耗的，和做产品不一样。毕竟我们可以通过cv等手段来实现功能。这个东西叫做技术债务。这个借与不借，看当时的情况来选择。毕竟有一些债可能是不用还的，例如功能的废弃和重构，直接可能是新的债务。

调优

说个很有意思的事情。对方问我是不是hbase jvm堆内存给的越小，gc每次时间就越少，能满足心跳，是不是可以不用调优了。这确实是一个很有意思的问题，通过减少堆内存来减少gc的压力。讲道理，正常人都是调整gc算法，以及停顿参数，回收触发的比率等来满足心跳的，他的这个做法倒是解决了心跳的问题，至于程序还是否能正常提供服务，就得看场景了。
很多人和我说从来没做过jvm参数调优。调优是一件比较庞大的事情，业务调优，结构调优，代码调优，参数调优。能作为痛点的调优才有价值，优先调整痛点，这个思路很正确，例如本来就是db查询慢，在db上优化足够了，相比之下jvm貌似就可以减少，但是hbase的regionserver这种程序是有心跳的，gc停顿的时间必须在心跳设置范围内，否则regionserver就挂了。
调优这个事情，其实是在调整痛点，优先解决痛点的决策很正确。例如健身，你练大肌肉群，时间少见效快，相比之下练6块腹肌就没那么重要了，主要还是难练，而且没有其他大肌肉群的衬托，也很难看。

底层原理

《倭寇的踪迹 》中如影如响简直是个神技。但是里面的高手并没有自己动手，而是告诉其他人，当人的影子到那个位置就出手，不怎么会武功的人记住这个位置，打趴了一堆高手。
我想了想底层原理就是上面的如影如响的技能。如果我是想搞创新那么是必须学会的，但是如果是想应用，似乎出个操作手册，其他人满足这个手册操作就行。例如上面例子中的要记住的那个位置。
简单说，假设我不知道B+树，但是给我一个mysql的建立索引的规范，只要规范写的足够全，在索引这块，你和知道b+的很难提现出区别。
底层知识的迁移作用很强，有点类似左强定律，数据结构的变动小，组合组合就可以出现新的，知识的迁移就提现的比较重要，可以去看看我介绍底层原理的部分，都会围绕迁移，相似来的。
注
现在面试或多或少都喜欢问底层，你就算迁移不了，记下来过面试总是好的。