[原文链接]http://blog.fexnotes.com/2016/02/08/mylife-2015zongjie/
写这篇blog的时候特地看了下今年年初写的2015年初总结，想看看去年总结的时候我都在思考些什么。请原谅我还活在农历的时间里，这也是我经常把年终放到大年三十晚上写的原因。所以我在这里说的今年是2015，去年是2014。在整理这篇总结的时候我也在想要怎么组织这些内容，才不会落入年终总结八股文模式(我所谓年终总结八股文模式就是：关于工作，关于生活，关于新年愿望这样的陈述方式), 所以我把要写的内容都总结成了一个标题的形式。客官且看：
从开发到Owner
我觉得今年的关于工作这块最大的角色改变就是我从一个业务打杂开发转变为了一个业务(商家后台)的Owner。这得益于团队对整个业务进行了划分。每个产品线都有对应的Owner，这样团队在具体某个业务上对外和对内都有一个具体的负责人。这个角色的改变怎样影响了我的工作内容。下面我从下面三个方面说说这个转变的过程。
开发和Owner的区别
记得刚入职那会，Leader说希望我能独立的take起一块业务，Owner一个业务线。其实现在想想我当时理解的take就相当于是一个项目负责人。然而经历了一年的业务开发之后，当我真正的在负责一个业务的时候发现并非如此。整个上半年我作为一个开发或者一个项目负责人其实思考的最多的还是处于怎么让这个功能更好的开发出来，怎么让这个项目能够按着预期的排期顺利的上线这样一个状态，这个也是现在很多开发同学最常在做的事情。然而当你在真正负责一个业务线的时候情况其实是这样的。 首先，你要对你负责的业务整体上很熟悉，比如你要知道每个功能(即便这个功能或页面不是你开发的)对应的业务场景是怎样(如，店铺街这个东西是干嘛的，对应的内容展示在哪里，商家设置了这个功能有什么作用)。若业务整体上很庞大，是否考虑对每小部分业务进行责任人的划分，这个道理与对多个业务线进行划分责任人是一样的。
其次，你要负责业务的整体调度工作。因为每次有了新的需求过来，PM都会先找到你说“某某某我这边有一个需求blablabla...需要FE支持下”。然后你要根据这个项目进行一个初步的判断谁比较适合来做这个需求，然后让谁去参加评审(当然如果是大项目的话还是需要一起参与评审的)。一开始我的做法是我去参加评审然后回来根据需求情况安排一个合适的同学跟进开发，但这样存在一个问题就是参加评审的和最后开发的不是同一个人，这样沟通成本就比较大。在安排后同学跟进后你可能还需要对需求的技术实现方案进行讨论，然后对项目的进度进行跟踪，和同学一起保证项目顺利上线。
再者，作为一个Owner你可能需要关注下业务开展过程中一些障碍，有哪些影响了大家开发效率，比如是否有一套比较方便的开发组件提供给大家使用，比如团队开发文档是否齐全，一个业务项目或者技术项目是否有相应的文档辅助大家理解。比如开发环境是否恶劣，技术栈是否过时需要更新，用什么技术栈去更新等。比如协同开发，大家代码的规范性和可维护性要怎么保证。
再再者，你需要对业务的对接人熟悉，因为在大部分的公司对业务肯定是有职能划分的，那么对接你业务的RD，QA， OP有哪些，你要很熟悉。这样在项目的推进工作中就会顺利很多。而这当中你需要一些沟通和处理事情的技巧。
最后，你可能还需要对你业务的上线和部署情况有一定的了解。你负责的业务的上线过程是怎样的，部署在哪个机房，部署的架构是怎样的，比如请求先经过了哪些流量接入机器转发后再落到你的业务机器，是否加了流控，nginx部署在哪几台机器上面，配置是怎样，日志要怎么查看，怎么知道线上的服务是否稳定。RD同学的代码部署是怎样的。这些都要了解，这样在上线大项目和对线上问题进行排查时候才能做到心里有数。
然而这些东西我之前作为一个开发其实都是很少去关注的，我想这就是角色改变对我的意义吧。
如何Owner一个业务线
这个问题有一个很直接的办法就是：主动思考，发现问题，解决问题。想想其实上面列举的这些场景是经常会遇到的。在当你刚刚接手一个业务的时候，你需要抓住尽可能多的机会去接触和学些这方面的知识。一个业务线肯定是或多或少存在一些问题的，那么在发现这些问题后，你要怎么解决，然后这个解决的过程中其实你就学到了很多，更好的做法是带着新同学也参与进来，这样大家都能通过解决问题去学习。具体实际的例子，之前我们商家后台业务太多，但是都在一个svn模块进行开发，这样会导致代码库庞大并且难以维护，这个发现的存在的问题，那么怎么解决，我们采取了拆分子模块的方式，但是对用户来说其实是要做到透明的，具体来说就是之前一个域名对应一个svn模块, 现在要做成一个域名对应多个svn模块的形式。这个过程中除了要进行业务技术架构的升级，协调QA资源对整体项目进行整体的测试，最后要对线上环境进行修改，比如nginx，这个时候就是机会你首先要知道nginx部署在哪里，并且要学习和读懂线上nginx配置，然后找到要修改的地方，并做好修改的方案，这个时候你需要对接OP同学，找他们沟通(邮件，工单或者IM形式)后，再做升级，事后还可以进行总结和分享帮助大家进步。所以整个就是发现问题解决问题过程，在这当中你即要把问题分析清楚，又要提供解决方案，还要跟其他团队的同学合作，这处处都是学习的机会。
是否应该改版你负责的业务
为什么要提这个话题，其实跟商家后台最近一次改版的经历有关。如果没有记错从我入职到现在商家后台应该改版过3次了。升级过3此UI，其中有一次升级了技术方案。而最近一次升级代号为4.0，在UI和CSS技术方案上进行了升级。但其实这个过程挺周折的，整个4.0的改版其实是我们团队推动的，下面说说整个过程： - 在评审UI设计稿的阶段中PM和UI设计同学对界面的改版细节进行了多次PK，PM更多的从产品角度，UI同学更多的是从视觉角度，大家都觉得自己更懂用户(这里不讨论对错，在这种大改版中有分歧我觉得很正常) - 整个商家后台4.0改版耗费精力巨大，开发周期巨长。因为大家在为了不影响新需求正常进行的情况下参与改版 - 上线前进行了再对页面的实际效果进行了一次内部评审，上线后从收集到的1000+反馈来说，虽然整体上是好评的，但是吐槽者也不在少数。于是又导致了一次内部的争论。 - 最终在4.0的基础上又进行了一次产品方面的梳理后，再优化了一版4.1上线，才让整个改版工作结束。
可以看到整个改版成本巨大，让我事后不得不重新认识改版这个事情。我们为什么要改版，改版有哪些好处？这两个问题的答案是，目前商家后台存在很多视觉和排版的问题，这个是肯定的，那么改版的好处在于我们统一了设计规范，对这套设计规范进行了CSS组件层面的建模后，之后的开发对设计和FE来说都是很轻松的事情。那么到底需不需要我们改版？经历过这次改版后我觉得应该慎重的考虑清楚。虽然总的来说改版肯定要比不改版能带来一些好处(如果连这点都保证不了，那还改毛)。只是我们得想清楚改版带来的对开发和设计的益处是否会伤及用户(不伤及用户那答案就一目了然了)，或者说伤的底线是多深才值得改？这必须得有个方法来权衡，刚好那天看到了微信公众号覃超帝国兴亡史的四篇介绍FaceBook公司Growth Hacking文化的文章，其中中篇讲到了为什么FaceBook这么多年主页为什么一直没有大的改版(其实)的原因，相反还讲到了作为中国FB的人人网又是怎样对待改版这个事情的。看完后深以为然，不得不服，推荐大家也看看~所以对于改版这件事情得有科学的统计对比方法才能知道正确的答案。
我所理解的导师
在今年对于我来说还有一个很重要角色就是所谓的导师，在这个事情上我其实一直遵循的是这三个步骤：
培养独立完成项目的能力
这个很好理解，因为公司或者团队招你进来，能独立干活这个是基本的要求。也是你能在团队的立足之本，这个需要信任对团队的开发环境和技术栈使用到的技术进行学习和掌握，这样才能基本胜任开发的工作。所以我在新同学刚来的时候一定会首先说这一点，然后希望说要在多久之内达到能独立开评审，开发，联调，测试，上线。这样达到完整的跟完一个项目的能力。在这第一步骤历练的过程中，其实也是对新同学技术和工作习惯的一个很好的检验过程。
强调工作习惯的重要性
如果说第一步骤是历练新同学技术硬实力的过程，那么第二步就是成长新同学工作软实力的阶段。虽说我工作经历不多，但从开会，联调&测试的沟通中，发邮件的内容和语句的组织，还有在做一个需求或者技术项目的习惯中可以很容易看出一个新同学的工作习惯是否优秀。工作习惯这种东西其实比第一步骤更让人一劳永逸，因为一个好的工作习惯到哪个团队和公司都适用，都让人觉得这个同学很靠谱，而技术却会因团队而各异。那要怎么去养成这些工作习惯呢？我觉得最快的办法就是找一个榜样，观摩学习他处理事情的方式和方法。这一点我觉得我很幸运我有遇到@Alien(已改名：阿烈叔，哈哈)这个导师，当然我希望我作为导师能做到这一点(具体要养成什么样的好习惯，大家有兴趣可以投简历呀)。当然在发现新人各种工作习惯问题应该及时指出并且帮助其解决。
努力成为有价值的工程师
其实就是希望新同学能找到自己的兴趣点和学习方法，然后学以致用能自己做一些东西出来，而不是一直只停留在做业务的水平和境界上。作为导师应该多给他们创造一些这样的机会让他们能接触到各种各样的技术，如，通过技术项目等方式。帮助他们去发现自己的兴趣，并且帮助他们在相应的方向上学习的更深入一些。我觉得只有这样才能保持自己作为工程师的价值，无论你去到哪个公司哪个团队都是一个靠谱的有价值的工程师。
以上为个人的几点拙见，更系统的实践经验，可以阅读@Alien的这篇文章，很值得细细研读~
怎样的团队才是好团队
年末月度沟通会上，@lusir提了一个问题说什么样的团队才是好团队。我后来也想了想这个问题。记得去年总结的时候我对我们团队给了很高的赞美，虽然现在也是，哈哈。但是这期间我现在想起来团队还是有一段非常迷茫的时期的。主要迷茫在哪里呢？直到听到@Alien说到这样的一句话你所在的团队是被行业所推动还是被业务在推动。为此我当时还发了一条微博来强调了下这句话，我觉得这句话完整的应该是这样你所在的团队是被行业所推动还是被业务在推动,还是说你们团队有自己主见和目标。当时我突然想明白了我们团队缺少什么东西。缺少了规划，没有一个明确团队规划和核心价值取向。注意到前面两个被推动，说到团队是被行业在推动，我们知道前端圈子本身就是比较躁动的圈子，各种观点吵来吵去，各种技术喷来喷去，今天有人说这个技术过时了，明天有人说那个框架好。你所在的团队是否随波逐流，疲于奔命似得折腾。还是说你所在团队根本就来不及理会这些，因为手里的头的活都忙不过来，被业务在驱动呢？直到后来@wille把团队的四大方向最终确立我觉得这个时候我们团队有完整了起来。这样才发现团队其实还可以做很多的事情，又有了新的活力和奋斗目标。所以我觉得好团队需要具备的一个条件是：有团队规划和核心价值观。当然除了团队规划，团队成员也很重要，关于团队成员这快，年中的时候CoolShell的@左耳朵耗子(以下简称@耗子)和支付宝的@玉伯两位讨论的相当精彩，两位撰文阐述自己的观点。当然看到最后其实你会举得他们的观点其实是殊途同归的。@耗子说的团队当然是人人都想要的，@玉伯说的土方法其实@耗子的理想扎根现实的做法而已。所以关于团队成员这方面我就不多说了，所以基于现实，一个好团队的成员应该还是要形成梯队的形式(都是精英目前还不现实啊)，具体大家可以详细去看看这两位的观点。最后一个好团队还是需要凝聚力的，这一点毋庸置疑的。那具体怎么增加团队凝聚力呢？比如首先你需要在组建团队的时候尽量保持团队的年龄相仿(具体一点可以为大家都处于未婚状态或者没有女朋友状态，这样才能经常一起加个班不是。哈哈)，然后团队需要有线下的集体活动，包括：技术分享，一起吃饭，一起打球，一起逗比这类的事情。线上是同事，线下是朋友这样的团队才能有更好的凝聚力。
所以总结下就是好团队需要： 明确的团队目标，梯队式成员，非凡的凝聚力。
新年愿望
写了这么多，终于到新年的目标了。废话就不多说了，先review下去年的目标： - 阅读量在30-50本左右, 类别不限。(这个我今年有信心)。
Done! 其实主要是上半年看的，下半年主要用kindle在看Blog。
学习一门新的泛型的语言(初定swift | python)。
Failed! 虽然这一年有接触Python 和 PHP。但是远没有达到随心所欲的水平和状态。
每月至少更新两篇(万一实现了呢)。
Failed! 想不到还是没有实现呢~ 只写了8篇blog。 但把Blog又改版了一次，终于现在把写Blog的兴趣提起来了。
研究某特定的方向（暂定选择器, webapp, native)。
Done! 今年主动研究了React生态圈还有ES6。
锻炼身体：羽毛球 or 游泳。
Done! 这个还是主要靠羽毛球，后来跑步了一段时间，但是冬天了就暂停了(主要是气温和霾的原因)。
参加一次迷笛或其他音乐节/eason演唱会。
Done! 去了一次工体看了@逼哥的演唱会。现场还是挺赞的。
所以你看梦想和现实总是存在着差异不是? 虽然没有全部完成还是比去年要好一些，马云说梦想还是要有的，万一实现了呢，所以我又立下了几个新年愿望： - 阅读40+本书，不限类别 - 每月2篇blog，我就不信我做不到 - 研究某特定的方向(暂定：mvvm & nodejs) - 独立开发一个App Ideal已想好 - 拿下驾照, 这个应该比较简单 - 减肥到65kg以内，不知可否
总体来说2015这一年还挺好，2016继续努力~