据说今天（2016-10-24）是程序员的节日？不过没啥过节的气氛嘛，大家还是该干啥干啥。
懒得想题目了，随便借用一下。题目这种东西嘛，不是很重要，反正是无主题随意吐槽。
不过1024是开篇的日子，等写完估计是十一月了。。。
PM小课堂？
最近在持续跟进一些项目，每天都是鸡飞狗跳的，搞的自己心力交瘁。。。过程中发现了各种槽点，不吐不快。我的观点未必是对的，只是总结下自己的想法。
首先明确项目中的几个角色：需求方，就是使唤你干活的人，上至CEO下至运营都可能是需求方；产品，通称PD（似乎这是阿里系的叫法），负责细化需求，把控产品走向，通俗点说就是写PRD的人；技术，根据PRD出技术方案并实现，一般每个项目会有一个技术方面的负责人，通称PM，负责推进整个项目的进度。注意这里的PM指的是“项目管理”，而不是“产品经理”。其他角色还有交互、视觉、测试、运维之类的，暂时按下不表，因为他们一般不是专职针对某个项目，不会背相应的KPI，而只是给项目“打工”。
简单点来看，项目的进行过程就是需求方 vs PD vs PM的三方角力。
PM一般是开发来做，因为能比较好的把控全局。如果让一个非技术的人来做PM，可能会比较惨，容易被人忽悠。。。PM不需要了解所有的技术细节，但至少要知道大概，整体的技术方案都需要他来把控。
PM的工作职责是啥？如果说的官方一点：把控开发进度/及时处理风险/和各方沟通/保证按时交付之类的。但这都是正确的废话，真实答案就是——啥都要干，PM的工作没有边界，只要是跟项目相关的，可能影响进度的，都需要你去搞定。要会编码，会催进度，更要会撕逼。于是我的日常大概是这样的：
“你这边进度怎么样啊，有没有啥问题”
“这里体验不好，修改下”
“这个数据还没好？我去找相关的人，明天给你搞好”
“这个改造的方案，我们一起找XX看下”
“用户说有bug？你在哪里我去看下”
每天跑来跑去，找各种各样的人，解决各种奇奇怪怪的杂事。任何问题都会找到我，用户有问题我要解答，其他系统接入我要去对接，视觉进度慢我要去催，联调有问题也要我想办法。。。很难有整块的时间去写代码，往往要等到下班了，没人找我了，才能写自己的代码。要不怎么说每天都是鸡飞狗跳呢。。。
为啥会这样？因为如果项目延期/失败了，锅一定是PM的，这个逃不掉。需求方都是大老爷，当然不能背锅；至于PD，要看项目的不同，有些项目中PD主导的比较多，也有些项目中PD就是个打工的，帮你写文档而已，所以PD可能背锅也可能不背；视觉/交互/测试也没有背锅的理由，人家只是帮忙的；只有PM的锅，是绝对逃不掉的。
所以PM确实要去操心各种琐碎的事情，因为这是PM的职责。我作为项目对外对内的唯一接口人，对外要保证各种问题/bug/需求得到及时处理，就算不能立刻搞好也要有个回复，给出时间点，有点类似运维。。。对内要保证成员工作进度，不至于block，解决他们的任何问题，保证技术上整个流程是通的。很多时候我要先有技术方案，然后告诉他们如何去做。如果技术方案不通，我要负责找各种人，想出可行的方案。
如果说项目是一艘航行的船，一般来说PD就像船长，要负责船在驶向正确的方向；而PM就像大副/管家，要负责船上的人往同一个方向划水，才能形成合力。不至于有的人向左有的人向右，船就只能原地打转。如果你身兼PD&PM，那就呵呵了，只能自求多福。
而且不得不说，很多人都是不催就不会动的，完全没有自己是项目中一员的自觉，一副事不关己的态度。就好像船已经漏水，你拼命往岸边划，船上其他人却在一边吃瓜一边围观，间或给你叫个好加个游。。。
更悲催的是，往往你手上不会只有一个项目，而是多个项目并行。。。如何协调，如何排期，这就是考验你智商/情商的时刻了。这比研究hadoop难多了好嘛。
既然已经是PM了，职责已经逃不掉了，能不能让自己更舒服些呢？我胡乱总结了下：
- 善用制度和工具。根据项目的不同，适当使用评审/周会/文档/jira/wiki等方法，但千万不要生搬硬套，要根据项目的特点。人越多的项目越需要各种制度的约束，如果只是几个人的小项目，制度反而会带来额外的负担。一般来说，定期的周会/周报就能解决很多问题了，要让大家养成定期总结、定期review的习惯，提需求/提问题/吐槽都尽量集中到周会上，而不要随时随地提，搞的很烦。
- 善用工具保证开发质量。其实这条和上一条差不多的，但是专门针对开发而言。比如单元测试、代码静态检查、code review、持续集成、完善的发布系统、遵循统一的git分支模型等，反正尽量不要出现低级bug。曾经有同学代码编译不过都敢提交，也是醉了；还有同学合并分支时，把另一个分支上的修改全部抛弃了。。。出现一些业务逻辑上的bug可以忍，这种低级bug不能忍。同样也是要根据项目的情况去选用的。其实这里有个悖论，就是“NB的个人 vs 完善的制度”。如果团队能力足够强，可能不需要额外的措施去保证质量。据说amazon里各种系统/制度非常完善，就是因为它里面新人开发很多？总之要自己权衡。
- 规划好自己的时间。因为会有各种各样的人“打上门来”，如果碰到问题立刻就去解决，很快就会疲于奔命。可以了解下四象限法，合理安排各个事情的优先级。我现在啊，就有点像是一个MQ，你有问题过来了，我会先ack一下，确认收到，然后消息暂存，但不保证什么时候去消费。。。现在就是一个异步处理，处理完成去调你的callback。。。另外，现在也越来越离不开便签之类的东西了，事情太多太杂，只凭脑子根本记不住。
- 拒绝二手需求，从我做起。啥叫二手需求？老板和PD说，我要A；PD和我说，老板要A、A+、AAA、∀、Å、Д。。。看着好像都是A，但已经偏离原始需求很多了，就是蜗牛跟天牛的区别。所以啊，千万别傻乎乎的直接开始编码了，要真正的坐下来和需求方聊下，看下真实的需求是什么样的。“这是老板要的”似乎就是尚方宝剑，也是一些PD的护身符，似乎这句话一说所有人都只能乖乖听话。。。但很可能只是拿着鸡毛当令箭罢了。
- 拒绝一句话需求。其实是拒绝所有模糊的需求。有运营跟我说，“这个页面我们要改下，突出商品属性”，然后就问我什么时候改好。我tm怎么知道你要怎么突出啊？字体加粗？改背景色？大图？多图？倒是说清楚啊。对于这种需求，只能拜拜了您呐。另外一种常见的需求就是“和XXX一样就可以了”，这tm也是个坑。以前电商很火热的时候，各个小公司都想做自己的电商网站。一问需求，“和淘宝一样就可以了”。。。
- 拒绝“伪需求”。其实很多需求都是需求方一拍脑袋就提出来的，三分钟热度而已。我见过很多，“这里帮我改一下吧，不改要死了啊”/“想想办法，必须要上的啊”/“不就这里加个图片么”，更有甚者甚至语带威胁，不改就如何如何。当初需求评审/视觉评审的时候怎么不说？我废了很多口舌去解释，他们翻来覆去就是那句话“要改，不改不行”。结果呢，放置一段时间再问，“那就下期再改吧”/“那就当bug修复吧”/“不改也可以”。。。
- 别怕闹事，该吵就要吵。PM是要代表项目组去和各方PK的，摩擦在所难免，尤其是涉及到和其他组的一些利益分割时。这种情况下，独善其身是不可能的，怎么办，只能硬着头皮上了啊。有句话怎么说的，“没事别找事，有事别怕事”。关键时刻要敢于邮件@所有人，拉更多的人进来一起撕，最后总会有个结果的。不过就像我之前说的，大多数人负责，就等于是没人负责。对项目整体而言未必是好事。
- Keep Calm。PM可能会碰到很多让人气愤的事，你有时会忍不住想说去年买了个表，尤其是有些人一副居高临下的态度找到你，“老子怎么说你就怎么做我才是大爷”时。要么放置play，要么就只能撕起来了。但吵架只是一种态度而已，真为这种事生气就很傻了。NBA里的教练为啥会冲过去找裁判理论然后吃T？难道他真的生气？其实有很大的表演成分在里面，给裁判施加压力而已，表明态度“我很生气你丫判罚尺度注意点这tm是我主场”。PM同理，所以好的PM都是很腹黑的么。。。
- 明确自己的边界。知道哪些是自己的系统该做的，哪些是应该交给其他外部系统的；哪些是现在该做的，哪些可以留到下期。不能所有的需求不加思索就吞下。是否会破坏系统已有的结构？是否有特殊的业务逻辑在里面？
- 不要高估别人的下限，敬nc而远之。和这种人辩论一定会输，因为他们听不进去你说的任何话，只会翻来覆去讲自己的道理，复读机一样，任何摆事实讲证据的逻辑都是无效的。但是他们又会崇拜“权威”，甚至可以说是跪舔。。。所以不得不撕的话，一定要拉上他们老大。。。
PM是个挺锻炼人的活，你会见到形形色色的人，碰到各种各样的事。
最大的收获是，我以为我情商已经够低了，没想到有人比我还低，顿时觉得生活又充满了希望啊。。。
50th & 100000
写这篇文字的时候，突然意识到这是我的第50篇blog。于是写了段程序统计下字数（只计算汉字），正好是10w字多一点，算上这篇估计有11w了吧。能坚持下来敲这么多文字，还是有点开心的。
其实写blog的初衷很简单，我希望把工作相关的事情都沉淀下来，回头看自己过去几年的时候，不至于觉得虚度光阴。而且一些技术点记录下来，也方便自己以后查找。
大多数文章，都是以前在网易的时候写的，很多是纯技术向的。那时候工作内容比较“单一”，安心研究hadoop就好了，顺带着各种大数据技术都了解了下，真的是两耳不闻窗外事。在网易的几年最大的收获是培养了一种技术上的“素养”或者说“习惯”、“思维方式”，这种感觉很难说的清。离职后，各种杂事多了起来，更新频率大大降低，而且各种吐槽也多了起来，越来越不正经。。。不过至少开阔了眼界，了解了各种业务上的东西。
偶然的机会，google到自己以前的文章，突然有点伤感。以前俺还是个严肃的人啊，写各种技术文章，厚着脸皮说质量还算可以吧。。。也能帮到一些人。但最近越来越有玩票的感觉，其实有点怕。。。技术这种东西呢，不进则退。如果不能在某个领域深耕，那个人价值在哪里？在不同的业务逻辑上一遍遍重复着同样的技术？那还有啥意思啊。最近面试了几个工作7、8年的人就是这种情况，毫无悬念的挂掉了。。。
旁边搜索的同学在研究ES，我也很口水啊。身不能至心向往之。
如何从繁杂的日常事务中抽身去研究一些东西，真是一个很难的问题，精力终究有限。而且我所说的研究不是那种跑个docker，搭个kafka就好像自己掌握了宇宙真理一样，然后到处吹逼，这些人没听说过奈何姓万的故事么？研究一门技术/工具/系统，最重要的是掌握原理，其次是使用场景、可能遇到的问题，能深入到代码最好。有些同学天天git push/git pull就号称“熟练使用git”，分支怎么合并都不知道好意思么。。。
而且仅凭个人兴趣的研究和公司层面所支持的研究，能达到的高度是完全不同的。就像我如果业余去研究下Lucene，也能大概了解原理，说不定还能看看源码，但应用起来肯定还是一堆坑，跟搜索那边天天搞这玩意的同学根本没法比。又比如hadoop，如果不是有一线的运维经验，很多坑你根本想象不到。坑这种东西，不是看代码能看出来的。
不过反过来想想，“业务”和“技术”根本不是对立的，二者应该是相互驱动的。良性的循环是业务需求催动技术水平的提升，技术的提升又反过来给业务更多想象空间，这种循环的典型就是bigdata；恶性的循环就是业务半死不活，技术毫无成长。如何进入良性循环才是每个人都要思考的。
当然有人说可以纯搞技术，不沾任何业务逻辑，比如DBA、比如运维、比如各种中间件。如果能有这种外部环境，公司能提供一个良好的氛围/待遇/考核制度，我举双手双脚赞成，其实我tm也想这样。。。如果可以安心搞研究还照样发薪水，每天的工作就是往开源社区提交feature/patch，公司鼓励你成为contributor/committer，根据你对社区的贡献设定KPI，我可能立刻就会跑过去投简历。。。但就我看到的公司而言，大都是业务驱动的。哪个部门手里有业务，哪个部门就有发言权，就更强势，其他部门负责支撑性的工作，也负责背锅。。。这跟公司的“基因”真的关系很大，是业务导向还是技术导向。
而且就算某些公司能提供这种环境，这种赔本赚吆喝的事又能持续多久呢？毕竟公司是要赚钱才能活下来的，有多少公司愿意养着一个不产生收益，纯研究性质的部门？就算养了这样一个部门，这个部门的待遇和其他部门是一样的么？前段时间有个知乎帖子也讨论过这个问题。
好像扯远了。。。本来是在说个人成长。但个人成长这个问题真的很复杂，我上面发了这么多牢骚，其实也没有答案，只能不断摸索吧。
anyway，至少我还没有停止思考。
但行好事，莫问略问前程。
又是校招季
赵忠祥老师：春天秋天到了，万物复苏了，这是个校招的季节。。。
前段时间校招如火如荼，各种改卷子、面试，曾经一天之内电面了7个同学，稍微总结下感想。
总的印象就是：好的很难招，跟大公司抢人是很难的；差一点的呢，老大又不愿意招。。。导致成果寥寥。不过这不是我要说的重点，我只是总结下笔试、面试的感想。
校招么，当然不会很看重项目经验，毕竟都是刚毕业。最看重的是基础，各种基础知识必须要扎实，算法/数据结构/java之类的，如果能有工程经验更好；其次是学习态度，是否积极主动，是否有探究精神，是否能快速的学会新知识，这是判断新人潜力的重要标准。扎实的基础+积极的态度，即使面对陌生的环境和工作也能很快适应，这样的新人才值得培养。
对于笔试，只要尽自己所能就可以了。有题目答不出是正常的，笔试题最大的目的是区分不同的档次，所以题目都会很有层次。如果你所有题都能答出来反而是有问题的。。。但答不出来最好也写写想法，关键是要有自己的思考。对于有些交白卷就夹个简历上来的同学，我也只能呵呵了。。。
面试也是一样的道理，注重基础。注意自己简历上的每一个字，都必须是真实可信的，面试官不一定会从哪里开始问。如果有什么虚假/夸大的经历/项目被发现，一般直接gg了。
有些同学啊，面试时总是喜欢扯各种业务逻辑，把实习时参与的一些系统的整个业务给我描述了一遍，但其实我根本不关心。。。我关心的是你在这个系统里扮演什么角色，做了什么事情，用了什么技术，碰到什么问题。如果能讲清楚技术细节，为什么用这些技术，就更好了。
其实，社招时很多人也有这个毛病，描述一大堆业务逻辑。确实业务很庞大很复杂，但毛线用都没，问起技术实现和细节还是一无所知。我只能认为那是心虚的表现了。。。
可能跟我个人有关吧，我更关注对技术本身的理解和实践，抛开那一堆业务逻辑。
还有些同学总是举着一块挡箭牌，或者叫遮羞布，“我是做算法的”。因为是做算法的，所以可以不会java/没用过多线程/不会spring/没听说过maven/不会git/工程经验0。我说搞算法的hadoop/spark总应该知道吧，要不咱们聊聊mapreduce？回答是：不知道，只会用Caffe。。。研究机器学习/深度学习/神经网络固然高大上，但一些基础的开发知识还是要知道的吧。“算法”和“工程”从来都不是对立的，不知道为什么很多人觉得只能取其一。
社招中也有这种情况，只不过挡箭牌变成了“我是做业务开发的”，所以不了解分布式/大数据/高并发/Linux/运维是可以的。确实有些人经手的系统比较简单，这些技术也用不到，但你要去学习啊，要能看到远方啊，看到系统规模变大会发生哪些问题，瓶颈在哪里。有句话说的好，“兜揣2块钱，心怀500万”，我觉得这种心态用在学习技术上正合适，虽然夸张了些。。。
另外还见过一些同学，各种项目经验，还有自己创业好几次的，甚至都融到天使轮，但问起基础来还是一团糟。就像我之前说的，校招不会太看中你的经验，关键还是基础，简历上的项目经验/实习经历再光鲜又有何用。
最后一个感想：面试也是挺累的。。。不比写代码简单多少。。。
KPI？
起因是看了zhihu一个帖子。
因为最近面试比较多，往往会涉及到一个给面试者定级别的问题。当然我给的级别不是最终的，仅供参考，最终结果还是老大说了算，只是用于评估面试者一个大概的能力范围。那如何区分不同的级别呢？其实我的标准很简单：
- 1档：需要被告诉做什么事，并且指导怎么做。
- 2档：告诉做什么事就可以，不用什么指导，最多code review下。
- 3档：能独立维护一个系统，自己去优化并对接需求。
- 4档：能从无到有做一个系统出来，担任项目PM。并且能做些工作之外的事，扩展技术深度和广度。
- 5档：能自己找到需求，从无到有做活一块业务。在某些技术领域能有深耕。
当然这是个很粗略的分类，再高的级别我也应该碰不到了。。。关键字：独立、从无到有。
各个级别之间也不是泾渭分明的，边界不是特别清晰，也不是像打怪一样必须要一级一级上升。每个级别，除了有技术上的要求，更重要的是对各种“软实力”的要求，比如沟通/协调/组织/眼界。相对而言，技术水平的提升是最容易的，“软实力”的提升才是最难的，要看自身情况。
那个帖子里有句话说的很好：“很多中国教育的方式让人过度注重 technical，比较有可能忽略了其它领域”。
评级和KPI一直是个比较敏感的话题，也被人诟病很多，确实这种制度在执行时有很多问题，搞得大家怨声载道。。。不过我感觉这不能怪制度本身，就像minzhu一样。。。印度和美国都是minzhu，为啥印度的minzhu一直被人骂，美国的就一直被夸？制度是死的，执行制度的是人，是人就可能有偏差，可能有漏洞，有猫腻。
对于大公司而言，貌似还真的少不了KPI，因为没有更好的管理方式。大公司追求的已经不是快速扩张了，而是平稳发展。KPI就像是给马套上缰绳，确实平稳了，容易驾驭了，但也失去了冲劲和野性，从赛马变成了拉车的马。总之是把双刃剑，是否用/怎么用，都要视实际情况而定。
不过KPI制定的合不合理，执行的又如何，是否会被某些人滥用，就是另一回事了。
最糟糕的情况就是：做的越多，错的越多，导致大家都畏首畏尾，小心翼翼的维持现状。
关于升级再提一句，其实升级是个很玄学的事情，很多时候也要看运气，没人能告诉你怎么做。大多是挑战一些难度很大的事，不成功则成仁。。。就算这件事难度上达到了级别，但做不成也不算，不会有所谓的“苦劳”。
杂七杂八的研究
在 2016 年学 JavaScript 是一种什么样的体验？：前端领域吐槽的集大成者。印象深刻的是一些评论：“jquery: 你大爷永远是你大爷”，“前端现在是面向issues编程”。。。
对二手前端而言嘛，纯粹是吃瓜看戏。如果一定要我在js框架中站队，我当然会选react，其次是vue，最次是angular。
URL的发展历史：域名、协议和端口：科普考古文，以前也研究过DNS，觉得挺好玩。
Tomcat 7 Class Loader HOW-TO：起因是一个同学问我怎么看java程序启动后加载了哪些jar，我说ps -ef看java进程的classpath参数，后来发现这招对tomcat完全不灵。。。
多形态MVC式Web架构的分类：MVC已经是一个有些混乱的概念了，别纠结概念，能解决问题就好。
Patreon：一个好玩的网站，可以让各种创意工作者得到捐助。我只知道vue的作者在上面募捐。
前端时间研究ML时，看了斯坦福的公开课，顺便也整理下常见的在线教育平台。对我来说，选择平台最重要的因素是看视频时能不能加速。。。比如2倍速播放。毕竟视频太长，很浪费时间，对于一些熟悉的领域，即使2x语速也完全能理解。
