快2个月没写，也是创造了新纪录啊。。。
我曾下定决心下篇文章一定要写纯技术的，不要总是吐槽。结果发现最近也没研究什么新东西，没啥好写的。。。说实话最近技术上进步不大，只是更熟练而已。《Machine Learning in Action》只看了几章。《Spring in Action》出了第四版，想重新看遍，也只是开了个头。发现一个有意思的项目Swagger，也没时间仔细研究。由于要自己写后台界面，还想研究下React，发现了一个高逼格的组件库Ant Design，结果也没坚持下来。过年期间还说看下guava的代码，也是搁浅了。不要指望假期能干什么正事。。。
so，这期间到底在干啥？年前，赶进度，年前必须上线啊汗；去三亚开年会；然后回家过年，在家过着腐败生活；年后回来，长假综合征再磨蹭几天，然后项目开工了，继续赶进度。。。时间就这么不知不觉过去了。
刚开始写blog的时候，经常一周就能写一篇。不过那时候比较闲，而且写的是纯技术文章，所以能潜心去研究。还能研究很多跟工作无关的东西，自娱自乐一下。现在么，由于有排期，有deadline，有人催，会比以前压力大一些。
更悲催的是，接投影仪时插了下hdmi线，把mbp主板烧了。。。虽然借了台旧电脑应急，但hexo的工程都放在坏掉的mbp上，没法写blog了，连个备份都没有。。。以前有linode时候还会用git备份下，看来要去搞个私有仓库了。。。
其实以上都是借口，只是懒而已。。。
半年有感
不知不觉已入职半年，老大递给我转正申请表我才反应过来。时间真的是很快。
坦白说，这半年技术上成长不多，搞的都是杂七杂八的事，毕竟是打杂工程师嘛。涨了不少见识，但都没什么深入钻研。还是以前搞hadoop、搞大数据听着更NB一点。前段时间接到某HR电话，“我们这边有个大数据相关职位，看你的简历比较符合，请问要不要考虑”，我一边嘴上客气拒绝，一边心里默默念叨：“我都好几个月没碰hadoop了。。。”
其实还是挺怀念的。纯搞技术当然不好；但搞业务太多，技术原地踏步也不是好事。
我虽然不是原地踏步，但心里还是有点虚的。。。以前是跑车，现在是买菜车。。。
离职前刷的那一点算法也快忘光了。。。
总结下，这半年真正的收获有三个。
- 对电商业务有了更多了解。也能出去忽悠几个人了。。。呆在一家电商公司，想不了解也不行。其实电商还是挺复杂的，外行人可能觉得，“不就是卖东西”，但电商可以有很多玩法。都是卖东西，摆地摊和沃尔玛能一样么。。。而如何用一个大的平台去支持这些玩法，出现新的业务模式时能直接用已有的平台实现，就是我们要考虑的问题了。如果出现一个业务就重新做一套，真的会死掉的。好在我们这里有很多阿里的人，很多经验可以照搬，阿里踩过的很多坑就不用踩了；阿里摸索了很多年才总结出的概念、架构，直接用就可以。有老司机带就是不一样啊。也要庆幸遇到了很nice的同事，帮我从一无所知到略知一二。毕竟从1到100很容易，从0到1很难。
- 对所谓的“架构”有了更多认识。加引号是因为架构这个词是很模糊的，而且很多时候有水份。“架构师”这种头衔就跟“产品经理”一样，有时候水的令人发指。应届毕业就做产品经理，are you kidding me？同理，没几年一线开发经验就号称架构师，也是醉了。我不否认有天才，只是不相信我运气这么好能碰到，而且做产品不能把希望寄托到几个天才身上。又扯远了。。。我是因为参与了一些系统从无到有的过程，又经历了后期痛苦的迭代过程，深感一个扩展性好的架构是很重要的，不然就只能各种gross hack，到最后只能推倒重来。而且我一直觉得架构分2种，技术架构和业务架构。比如说hadoop的架构，我能说出一堆，比如yarn的RM、NM之类的，这种是纯技术的，只需要从技术角度出发去设计。而且大家都差不多，不都是分布式、高可用、Master-Slave、push/pull之类的。换句话说，是有业界标准的，虽然有时业界标准不那么明确。但如果揉入业务逻辑，就会更复杂，比如设计一个商品管理平台，如何拆分各种模块，如何考虑未来业务扩展。这种架构里扩展性是非常非常重要的，因为业务是变化很快的。而且每家公司业务总是有不同的，只能借鉴不能照抄。用我老大的话说，纯技术的结构都是“伪架构”。。。如何提升架构设计能力？其实跟学棋差不多，多看些棋谱，然后自己去推演。知道好的好在哪里，坏的坏在哪里，就OK了。另外做日常需求时，多想想背后的商业逻辑，想想他们之后可能的用法，这样才能在设计时留有余地，以满足日后需求。如果能像阿尔法狗一样，遍历人类所有棋谱，那就NB了。。。话说阿尔法狗又赢了。。。
- 学会了一种积极主动的态度。这个其实是最重要的。以前在网易的时候，安安心心当一颗螺丝钉就好了。像大学里一样，有人找的时候就解决问题，没人找就自己鼓捣hadoop，跟别人接触很少，有种“山中不知岁月”的感觉。。。但现在不同了，一方面是离业务更近，而业务瞬息万变，所以节奏很快；另一方面是制度不像大公司那么完善，没有那么多流程可以遵循。所以很多事情要自己主动去推才能有进展。自己去找各种各种的人、制定计划、监控进度、调度资源。真的要有一种owner的意识，对自己的项目负责。最难的是要主动和各种人撕逼。。。这一直是我的弱项，我也就吐个槽捧个哏还可以，撕逼一般都会输。。。不过也在锻炼。这也是成长必经之路嘛。
anyway，至少还是向着好的方向前进的。
去中心化？
听了内部某个演讲有感。
我们一直在强调“去中心化”，这到底是啥意思。仔细想想，似乎就是社交+电商。就像阿里想做社交，腾讯想做电商一样，巨头们一直想把社交和电商结合起来，但种种原因都没做好。社交+电商到底应该是个什么样？似乎也没人能说清楚。简单的想想似乎就是垂直电商+社区+导购，但这样似乎又太肤浅了。
有个同事的比喻很精妙，借用一下：淘宝这种平台化电商就是“天上人间模式”，淘宝类似老鸨。。。用户想要买(zhao)东(xiao)西(jie)，必须要经过平台（大多数情况下是搜索和推荐）才能找到特定的卖(xiao)家(jie)，淘宝在这个过程中会收取费用，比如直通车什么的。其实淘宝就是靠卖流量赚钱的。这种模式下，大多数用户是没什么忠诚度的，每次想买东西时都会重新搜索一次。而且排在3页以后的卖家是没什么机会的，转化率低的可怜，卖家想提升自己的排名只能乖乖交钱。而我们要做的是“婚介所模式”，没有一个统一的平台入口，我们帮助卖家和买家认识，然后就没我们什么事了，以后你们爱怎么玩就怎么玩。。。在这个过程中我们鼓励卖家自己去推广、运营，去结识买家。我们只会在幕后推动，提供各种工具和建议，而不会直接给卖家导流量。每个卖家都是一个小小的“中心”。
为什么会这样？因为社交的一个关键就是“信任”，而信任很容易提升复购。所以我们希望卖家和买家能保持一个长期的关系。或者说，我们鼓励“口碑营销”，鼓励一种“小而美”的模式，而不是淘宝那种“大而全”。
这种方向上的差别会直接影响我们的工作。比如在淘宝里，运营（小二）的地位非常重要，说是能影响行业趋势也不为过。很多后台项目其实都是为了满足运营需求而存在的。但我们鼓励卖家自己去运营，所以做很多需求的时候还会从卖家的角度去考虑，很多工具要分成运营版/卖家版。
题外话，为什么运营这么重要：因为大家的技术同质化，产品同质化太严重了啊。如果能有颠覆性的技术（量子计算机啥的），或者颠覆性的产品形态（facebook刚出来的时候），就不用拼运营了。但在电商领域，大家的技术和产品都太相似了，只能拼谁的运营更精细了。另外据老大说，即使是淘宝，运营直接拉动的成交其实也很少的，个位数的百分比。但运营会带来长尾效应，带来很多潜在的可能性。
其实社交网络的力量非常可怕的，一旦找对爆点，流量往往会几何级数增长。所谓的病毒式营销，就是这么来的。但怎么利用这种力量，怎么和电商结合，大家都在摸索。
另外以上都是我的YY，只是个人理解，不负任何责任。。。
还是项目管理
之前提到的那个项目已经成为了我们这里经典的反面教材。。。如果有项目管理的课程必定要拿出来批判一番。。。
仔细想想还是有些东西要强调下。
- PRD评审/UC评审/TC评审，一个都不能少。这是为了保证产品/技术/测试三方的理解一致，统一思想。评审会议会增加个人的工作量，也确实很费时间，但会提升整个团队的效率。因为评审能暴露出问题，在需求阶段解决问题是成本最低的，开发完才发现问题就只能呵呵了。
- 要强硬。首先PM要强硬，坚持原则，敢于拍桌子，即使是面对leader，“你有理你怕啥的”。。。千万不要和稀泥，那是对所有人的不负责。PM还要时刻跟踪进度，确保真的进度正常，而不是成员自己说正常就算了。因为很多时候成员不了解全局，没感觉到问题在哪，没意识到风险。其次开发也要强硬，说多少天就是多少天，做不完就加人/加班，而不能因为leader的要求强行缩短工期。
- 估工作量时要给自己留有余地。真的不要那么实在。。。毕竟可能有很多种突发情况的。突然被老大叫去帮忙面试，半天就没了。。。
- 估时间时要考虑全面，不要只考虑自己开发的时间。还要考虑沟通成本、联调时间、测试时间。针对完整的功能去评估工作量，而不要只考虑主流程。
- 不要轻易给出承诺。但给出的承诺一定要实现。
项目=需求+时间+资源，这是某个同事总结的，影响项目成败最关键的3个因素，还挺有道理的。
面试の方法论
面试了一些人，总结下。
说实话工作以来也面过不少人了，但我其实不太擅长这种活。我大多会问一些确定性的问题，像是项目经验、算法、语言之类的，对就是对错就是错。一些太“虚”的问题我把握不好，关于具体业务领域的更是很少问。像是“你最有成就感的事是什么”这种问题，这辈子估计都不会问。。。所以只能负责第一面的技术面。。。
总结下套路（当然只是我的套路），特指java开发：
- 我一般会先看简历问项目经验。主要关注做过些什么，碰到过哪些问题，是怎么解决的。如果有参与了架构上的设计，做过一些抉择，为什么要做出这些选择？是否有更好的方案？这部分主要是考察学习能力/解决问题的能力/设计能力，看思路是否开阔。学习能力尤其重要。如果在项目中只是“跟随”，没有自己的思考，或者做了很多项目但一直重复相同的技术，会减分。就像大学时能用一个“图书管理系统”应付好多课程的大作业。。。但工作中肯定行不通。
- 抛出一个/几个实际问题看如何解决。具体是什么问题要看情况的。可能是工作中实际碰到的，也可能是凭空想象的，我有朋友碰到过“设计一个微博系统”这种问题。。。我一般只会问些简单的。很多时候只是算法问题披了一层皮。这种问题答错也没关系，而且很多时候也没标准答案。但必须能讲清楚思考过程和理由。更多考察的是工程经验，考察思考问题是否全面。
- 数据结构与算法。这个也是常规项目了。我最近常问的是Invert Binary Tree，因为我很期待有人能认出这个梗。。。那在我这里会加很多分。但考察算法也不一定只是纯算法，也可能是业务上的，比如负载均衡、调度算法、ML之类的。而且不同职位对算法的要求也是不同的，可能有些要求很高，有些要求熟悉特定领域的算法，看情况。
- java基础。一般就是集合、多线程之类的。深入点可能是JVM、GC。一些更基础的东西应该在笔试中就体现出来的。前提是有笔试。。。
- 框架与工具。如果你说熟悉spring，那就问spring。如果用过hibernate，那就问hibernate。如果是面试大数据相关的，一定会问hadoop/spark。反正就是挑你会的往深了挖，不在乎广度而在乎深度，当然深挖的前提是我也会。。。如果能对常用的工具很熟悉，git/maven之类的，就更好了。
- 闲聊。真的是随便问了。比如数据库、sql、redis、缓存、nginx、脚本，前端的也可以问。如果能除了工作外，自己去学各种各样的东西，会加很多分。会fan|qiang也会加分。。。
- 最后一定会问对方有什么问题要问，能解答的我都会尽量解答。但有些真的回答不了，有人问我“杭州和上海哪里工资高”，这和面试有啥关系么。。。
当然不会那么死板的。可能有些环节问得多些，有些环节问得少或不问，看情况。
技术面试最忌讳的是似乎什么都懂一些，但什么都不深入。至少我对这样的被试者印象会很差。
另外，关于简历，有篇blog讲的不错：别的程序员是怎么读你的简历的。
其实啊，面试很多时候还要看感觉。愿不愿意和面前这个人做同事？当然这里可能有个人主观因素了，这也是没办法避免的。好在搞技术的一般不会太奇葩，当然也有例外。。。我就碰到过一些装B侠，不懂装懂，乱扯一气，也只能呵呵了。。。
END
其实不一定要有个结尾的，但我是强迫症。
一些不能长篇大论，不足以单独为一节的想法/脑洞，会丢到这里。
我曾经说想做一些东西让用户发挥自己的创造力，仔细想想，有点类似UGC。
但UGC之间也是不同的。就像积木一样，有的积木表现力强（乐高），有的积木表现力差（若干年前有一款叫戴乐魔塔的积木）。想用七巧板拼一个星球大战，可能嘛？
但表现力太强就意味着不好设计，不好维护，增加系统复杂度。还是要trade off。
正好最近在做一个自助建站的项目。如果能鼓励用户分享自己的作品，并让用户基于分享的作品再次创作，就很有意思了。当然想做好也很难。
也许以后的项目都可以借鉴这种思路，鼓励用户自己去创作并分享，自己去“制定规则”。
