• Feeds

  • 案例与故障的知识库

    一个团队内部经常有很多针对不同场景的设计方案,同时技术系统在历史上出现的各种问题故障可能也会在事后记录下来,但是这些记录及文档通常并没有一个好的归属,随着时间的推移就淹没在邮件的海洋中。如果知识库具备,这里简单探讨一下相关作用。

    团队中新人未经历过系统所有阶段,不能有历史的阅历。即使是老的员工,如果团队规模变大,或者是精力的原因,也不可兼顾到系统中所有的信息,因此设计案例及故障案例对一个团队共享经验及共同能力的提高都具有极大的帮助。

    看书是一种最佳的学习方式,但是在互联网工程领域,很多经验及成果并无公开的书籍及文档描述,因此很多有志于在此领域提升的新人经常会碰到困惑,如果当前不在一个成熟的互联网公司,根本没有机会来提升自己。另外一方面,即使能进入这些环境,新人也会碰到另外一些问题,公司内的牛人忙忙碌碌,已经完成的伟大作品也很少被详细介绍,新人只能在日常零星的工作中逐渐去了解全貌,很难得到一个快速成长的机会。

    这对老人也是一个启示,大家热衷于解决的新场景的问题并非最大的价值所在,新领域问题无非是根据个人经验,走了一条不那么弯的路而已。但是总结已有的典型设计加以抽象总结,形成一些系统性的设计库,或者将所有的故障及走过的弯路分门别类,形成故障库,这对于提升一个较大团队的整体能力,具有更重要的意义。

    说了知识库的需求,也许有人会顾虑知识库的技术领域差异性,技术人员对专业细分领域之外的问题不感兴趣现象比较普遍。前端的对后端的案例分析不感兴趣,数据库工程师对开发领域的问题不感兴趣。因此需要案例材料尽量跳出具体的语言细节本身。但是技术人员如果能够跳出自身的认知圈子,从更宏观的视野来讨论及分析这些问题,对于综合能力的提高具有更大的帮助,这也是走向架构师方向的一个基本要求。

    对于设计案例,理想的知识库需要有系统的分类,而且大部分新设计的功能都可以在其中找到一个对应的历史案例,虽然很少有两个系统完全一样,但是真正设计思想的区别并不会大。

    随着案例知识库的完善,案例的讨论的深入,一个团队的技术能力得到了整体提高及升华。

    团队中的为师之道

    由于团队新进来了不少刚毕业的学生,所以组织了几次负责辅导的导师讨论“为师之道”。


    对于导师来说,很容易把导师工作定位成负责答疑及分配工作的角色。做得好一点的话,好的导师给学生足够的指导,达到最初几个月相对明显的成长,让新人顺利融入团队发挥特长。但是进一步思考,孔子培养了三千弟子其中有七十二贤。如果期望团队也能培养出更多优秀人才,有哪些道可以借鉴?

    上面的疑问在交流中并没有得到明显(甚至稍占多数)的答案,但在交流中比较争议的是理想主义与实用主义的碰撞,理想主义期望新人能先发展通用能力及素质,等能力具备之后再在具体的事物中发挥作用。实用主义的核心观点是让新人能尽快下海,在“有用”的基础上再进一步向外发展更多能力。由于企业并不是教育及研究机构,因此理想方对实用方并没有原则上的反对,只是认为在不影响中期贡献的前提下,提出更适合的方案。

    周末看到古代《大学》的一段话,初步觉得可以作为为师的一个借鉴。“古之欲明明德于天下者,先治其国;欲治其国者,先齐其家;欲齐其家者,先修其身;欲修其身者,先正其心;欲正其心者,先诚其意;欲诚其意者,先致其知;致知在格物。” 如果把“明明德”理解成一个专业人员终极的追求,“致知”指透彻的了解一个事物;而“格物”指具备独立的分析能力、研究能力。则一个学生从校园走出,最先要学会做的,也应当是致知与格物。

    对应经验交流中的案例,如导师让新人分析目前的一个系统现状及优劣,并引导学生去思考进一步相关问题。它的分析的方法可以粗略的认为是“格物”,而案例分析让新人得到了一定的成长,和上文的道理是印证相通的。而“心诚”和“修身”也可以引申出很多反思,这里就不一一展开了。

    有感Google的混合研究方法

    对于一个长期在研发领域的人来说,经常需要思考研发的意义、工程与研究的关系、产品型的公司应当做何种程度的研究等问题。理想情况下,我们期望每一项研发工作都能得到组织、同事以及社区的高度认可。因此不管你处于工程领域还是研究领域,工程与研究的关系会让你不断思考甚至困扰。最近看到的Google’s hybrid Approach to research (English 中文) 一文或许会让你豁然开朗。

    研究领域的现状

    • 根据技术领域的差异,大部分产品开发可以依赖已有成熟的工程技术完成,进一步通过研究来提升产品能力的空间并不大(比如提升空间在10%以下)。
    • 互联网企业偏重产品开发能力,关注点主要在开发效率、研发流程等交付能力上。偏实用主义驱动方式,很难对相关领域的工程技术进行升华。因此研究的驱动力、研究的空间及取得成果的可能性较低。
    • 没有专门研究人员或者兼职研究人员的组织也很常见;
    • 具有研究能力的组织中,研究对产品改进及商业化应用的能力不足。
    • 具有研究能力的组织中,研究对产品改进及商业化应用的能力不足。
    • 如果研究的方向并不能立即得到商业化的应用,通常较难得到支持。比如阿里云OS项目,即使与Android之间不存在纠葛关系,其研究方向也较难得到广泛的认可。

    最近身边一个Team做了一次内部调研,有关研究的部分数据如下

    在调研中发现,71%的研究需求来自业务,而45%的研究成果会最终应用到业务中。调研的全文参见 http://e.weibo.com/2758197137/yCuvs4tjd 需要补充的是,这个调研并没有严格区分“研究”与“工程”的界限,一些非直接应用于业务的工程可能会被调研人员定义成研究。

    Google的研究模式

    1、在一个以产品为重点的团队中的先进项目,凭借其创意和新鲜感,变革前沿技术,产生新的研究成果。
    2、研究组中的项目,结果产生新的产品或服务。
    3、研究组中的项目创造出新的概念和技术,然后应用到已有的产品或服务中。
    4、工程团队和研究组之间的联合研究项目,由工程团队使用其成果。
    5、由工程团队的研究项目,转移到研究组(并最终成为上述的2、3或4)。

    成功研究的定义

    在我们看来,如果一个研究项目有学术或商业的影响(impact),更理想情况是两者兼备,那么项目是成功的。具有商业影响的研究项目显而易见是容易得到支持的,但是靠学术影响力的项目在不同的公司,或许道路就会更坎坷一些。

    Google研究的方法

    Google’s approach to research is iterative and usually involves writing production, or near-production code from day one.