Pengfei-xue.GitHub.io

programming your life!

Home ~/

View My GitHub Profile

  • 架构即未来 - 关系 思维 和 商业案例

    业务主管的问题

    • 技术负责人至少被更换过一次么
    • 技术团队中不同的人分给了业务主管同样的解释,但是他仍然不相信?
    • 因为技术主管已经在学习阅读财务报表了,作为业务主管,是否用尽可能多的时间去了解技术?
    • 业务主管是否懂得,应该如何去询问项目日期是否积极和可以实现?
    • 业务主管是否在产品开发生命周期刚开始的时候,行办法弄清楚如何度量成功?

    业务主管的问题

    • 技术团队是否可以对项目的关键日期提供早期反馈?
    • 反馈一直不正确?
    • 业务在生产或者产品的时间表中反复遇到同样的问题吗?
    • 技术团队成员用什么指标来衡量其工作对业务的意义?
    • 技术方案的选择是基于商业利益还是技术优点?
    • 技术团队是否了解是什么在驱动业务?竞争者是谁?他们的业务是否会成功?
    • 技术团队是否理解业务所面临的挑战,风险,障碍和策略?
    • 技术领导可以阅读和理解资产负债表,现金流和损益表?

    技术高管理解赚钱的业务手段,收入的驱动力,目前的财务现实,竞争格局和当年的财务目标非常关键。 只有具备这种知识和能力的CTO才能够制定出合理的技术战略来实现企业的目标。

  • 架构即未来 - 管理秘籍

    以明智和合乎道德的手段来完成任务。

    即使最好的经理也承认自己需要不断地提高,而能够意识到提高的唯一办法就是度量。

    在整个职业生涯中,我们从来没有看到过一个项目在计划的第一次迭代中就完全按照最初的设想去执行。

    杰夫 斯玛特的书籍,招聘方法 (who: a method of hiring)

    照顾花园也意味着把在某个位置上表现得不太好的人,放到能发挥其作用的地方。然而,如果你发现自己不止 一次地调动某个员工,很可能你是在避免适当的除草行动。虽然你必须遵守公司淘汰员工的相关要求,但是想 办法尽快淘汰妨碍大家实现目标的人极为重要。越早淘汰表现差的人,就能越快找到合适的替代者,让团队向前 发展。

    在考虑如何度量生产效率的时候,真正的诀窍是把它至少分成两个部分。第一部分讨论工程团队是否用尽可能多 的时间来解决工程相关的任务。比如工程师一年的可用工作时间175个工作日,分子就是从这个分母中除去花在 相关时间上的时间,比如构建环境无法使用,测试环境无法工作,工具或者编译代码环境出问题,缺少源代码 或者文档等。如果你还没有开始度量这些破坏因素,那么你可能会惊讶地发现工作日的有效使用率只有60-70%。 第二部分是毒狼每隔工作日的产出。不度量就无法提高

    好的管理者实际上会亲自上手,帮助团队完成目标。

    项目管理用5%的时间制定详细的计划,用95%的时间做好应付突发时间的准备。在适当的时间聚焦取得结果, 而不是生搬硬套原定的方案。

  • 谈谈后端业务系统的微服务化改造 文章摘要

    谈谈后端业务系统的微服务化改造

    问题

    业务系统是任何一个用户产品的必须组成,充当着一个门面的角色,用户的输入就是这个系统需要维护的,数据 存取是整个系统的核心。例如,广告业务系统的输入是广告主的投放约束、定向条件,微博业务系统的输入是短 文字、图片等。

    在应用发展初期或者规模不大的情况下,有非常简单的实现方案,LNMP、JSP、PyWeb都是你能随口说出来的词, 如果用某种架构方式来描述,那就可以称做单体模式(Monolithic,Martin Flower大神所提出的,后面还会介绍), 而这些技术都是单体模式的成熟解决方案,它们可以使你工作在“应用层”的最顶端,各种中间件、框架能让你 省心地干好业务,开发人员可以通过“模块化”的手段来管理业务系统的复杂度,使他们之间解耦、复用。 简单来说,这个单体就是如下这种层次划分。

    表示层       前端(HTML+CSS+JS)                        
      |             |
    逻辑层     业务系统(PHP、Java、Python是常用的语言)         
      |             |                               
    数据层      数据库(MySQL)    
    

    看起来很简单,对吧。诚然,业务系统在这里面还需要做很多,比如缓存、SQL优化、数据分区、系统安全工作, 当然还有对于代码的维护和重构。这种工作方式可以很好的工作几年、甚至十年,但是如果业务发展非常快,在 系统复杂度、业务规模、参与人数、代码腐化程度都不断上升的情况下,你会发现整个项目正陷于泥潭,PM/RD/QA/OP经常抱怨:

    "改个小功能,怎么要拉这么多模块?"
    
    "拉模块也就罢了,改的地方多,编译太慢了。"
    
    "慢也就算了,关键不知道怎么改,这代码太丑陋了,算了,为了满足PM的排期需要,凑合来吧。"
    
    "凑合来了,QA发现bug,返工再返工,延期再延期。"
    
    "上线了,oh my god,报case了,性能有问题,原来是依赖的模块访问数据库用了for循环select。"
    

    透过现象看本质,我总结了来看就这三点问题:

    1、业务逻辑复杂耦合,开发维护成本高。 2、交付效率和质量低。 3、非功能需求不达标。

    非功能需求指标特指性能、可用性、可扩展性等方面,代码的腐化和缺少维护、重构,以及没有代码洁癖的人 污染下,必然导致性能逐渐下降,甚至出现不同资源竞争的短板效应,造成整个系统crash,同时一个大怪物 的伸缩性较差,不能随意横向扩展某个细分功能点。

    Design is there to enable you to keep changing the software easily in the long term!

    业务系统中模块化实践,随着软件规模的变大,很容易绕过障碍而使得不同模块耦合、依赖关系复杂,这种纪律 性很难保证,从而削弱模块化的结构、降低了团队的生产力(敏捷开发和持续交付越来越难做,部署起来太庞大 了大家的开发士气不高,而且痛苦),很快的这个模块就会变成一个大杂烩。

    服务化

    服务是独立开发,独立测试,独立发布,独立部署,独立运维的,某个细分团队负责整个生命周期管理,这就 是”康威定律(Conway’s law)”的通俗解释,官方解释是“一个组织的设计成果,其结构往往对应于这个组 织中的沟通结构”,服务的规划不就是多人、跨团队协作的沟通模式嘛。好处在于摒弃原来的火车模型(所有模 块一起发布部署),拥抱独立快跑,这也更好的支持了敏捷和持续集成的方法实践。同时去除了牵一发而动全 身的问题,单一职责的来进行修改需求或者重构一个点,开发和构建方便,不影响整个产品的功能,一个bug 不会crash掉整个产品,针对不同的类型,区分计算密集型还是I/O密集型,区分业务上更好使用关系型还是 NoSQL,区分2/8原则、即80%经常修改的服务独立出来自成一家,区分短板功能、针对瓶颈可以做水平扩展、 避免资源竞争,甚至可以区分技术栈、突破语言限制。

  • 架构即未来 - 领导力

    定义

    影响一个组织或者个人达成某个特定目标的行为的力量。

    核心点

    自知之明 以身作则 不刚愎自用 努力完成使命 留意和同情组织的需要 及时决策 给团队授权 和股东利益保持一致

    在较好的工作环境和文化环境中,员工要比一般的环境产出更高。糟糕的文化掠夺生产率,在这种 有毒的环境里,员工们聚在饮水机周围闲扯最近老板的恶性,或者抱怨老板是怎么滥用其职权的。

    从行为角度来说,你应该表现给你的团队看,已所不欲,勿施于人。好的领导不会滥用职权,他们不 认为自己的职位允许他们拥有某种特权(比如自己的代码不用被review,自己不遵守代码规范等)。

    能干的经理和领导完成使命,伟大的领导和经理则是通过营造文化氛围,使员工感受到赏识和尊重, 诚实而及时地处理绩效相关的反馈。及时地把绩效结果反馈给员工,承认即使是一流的员工也需要 了解他们短暂不良表现的反馈。

    好的领导会确保那些产生最多价值的人得到最好的奖赏,确保那些表现远在一般人之上的人能够 得到应有的休假。

    团队希望你能作出适当的判断,并快速解决主要的问题。领导总是被放在显微镜下仔细观察,毫无疑问很多细节 背会抓住或者看到,会做一些自己都会后悔的事情。我们希望被抓到或者看到的事情,是你前一个晚上工作太 辛苦,结果白天在办公桌前打盹,或者是从办公室跑到车里,去办一些因为工作的太晚无法完成的个人事情。

    你想让大家做什么,那么就教导什么,你教导什么,你的标准就是什么。

    最有成效的领导往往通过理念来影响其组织,把团队利益置于个人利益之上,为团队及其成员提供智能激发, 为团队成员的福利和职业发展展现出诚实和个人化的关怀。

    愿景 使命 目标

    我们以生动的描述和明确的信念告诉要去的人如何检验他们的任务是否成功。

    一个愿景应该符合下面这些标砖: - 对理想未来的生动描述 - 为股东创造价值很重要 - 可度量 - 激动人心 - 结合信仰的因素 - 大致不变,但可根据需要修改 - 容易记忆

    使命的描述应该符合下面这些: - 对当前现状的和行动的描述 - 有目的感 - 可度量 - 一个大方向或一条通往愿景的道路

    最好的目标是通过SMART来制定的: - specified 具体 - measurable 可度量 - achievable 可达成 - relative 相关性 - time 时限性

  • 架构即未来 - 组织的设置

    rasci 工具

    完全负责人 responsible 决策批准人 accountable 提供资源人 supportive 提供数据或者资源人 consulted 需要了解相关情况人 informed

    一个任务会有一个 R 和 一个 A,多人负责一个项目等于没有人负责。

    组织设置

    团队规模

    团队规模下限为6人,上限为15人。当团队内出现沟通不畅,生产率低下,士气低落时都是团队规模太大 的信号。团队规模过小,需要注意业务合作伙伴,微观管理的经理,过度劳累的成员,团队可能无法及时 交付,或者被合作放抱怨需要更多的交付。

    拆分团队,必须要考虑一些事情,比如谁出任新的经理,每个团队成员的参与度有多高,于业务负责人的关系 怎么处理?首先要根据代码和工作来聚焦,最佳方案时根据故障域来拆分团队和代码,通过隔离服务来限制故障 所带来的影响。

    我们团队目前出现的情况是,过度劳累,有好些同学私底下再问目前的状况什么时候能结束,太累了。另外一方面, 需求方还在不停地抱怨,什么时候他们提的需求可以上线。

    职能型团队

    在一个采用瀑布型开发方法的职能型组织中,研发的责任显然落在工程团队上。因为软件工程师都向工程部门的 负责人汇报,质量保证工程师均向质量保证部门的负责人汇报,所以非常容易制定,发布,遵循和执行标准。

    职能型或者直线型结构的问题包括缺乏单一的项目负责人和跨职能部门的沟通效果不佳。项目很少只发生在一个 职能部门内。大多数软件研发项目,特别时通过网络交付的服务,总是需要不同技能的人来共同完成任务。

    在职能型组织中,跨部门沟通出奇难。例如,软件工程师想告诉质量保证工程师,必须进行某个测试以验证功能 是否正常。为此,软件工程师很可能要浪费宝贵的时间,在质量保证的管理层级中上下求索,知道找到负责的测试 同学。工程师可能会依赖现有的设计规范文档,通过流程来传递这些信息。可以想象,研发和测试之间,写一个 20页长的测试规范比面对面对话要带来多少额外的负担。

    另外一个挑战是,团队之间的冲突。这个团队没有能按时完成任务和那个团队交付的产品存在错误,这些都是那些按照 职能型结构组织起来的团队在合作时经常听到的抱怨。工程师们想要有归属感和被同伴接受,其他不同的人(测试工程师, 产品经理,甚至运维)经常被当作圈外人士,而不被信任,甚至有时候被成为公开的敌对目标。

    好处是同质性,责任简单清晰,有标准可议。不利的地方包括没有单一的责任人和沟通不顺畅。

    目前,我们遇到了类似的问题,虽然,有纵向的团队在一起做事,但是太过临时,相当于是把职能型团队微观化了。 团队成员之间交流少,开发流程更接近瀑布模式。

    矩阵式团队

    一个人汇报给多个经理,而这些经理并不能理解每个人的任务优先级。

    之前一直想往矩阵式团队靠,现在看来问题确实挺多,仔细想想向多人汇报就觉得够头疼的了。目前的状况看起来, 我们的团队组织形式是强职能型的矩阵式开发合作团队

    敏捷型组织

    聚焦团队搭建,最好的构架,需求和设计源于自组织的团队。它不是以角色为基础,而是专注于满足客户的需求。 每个敏捷团队都拥有一个用户服务,并且包括了需要的所有技能。(包括了,研发,测试,运维,产品等)

    改善冲突,授权和组织边界来实现创造力的提升。团队按照服务组织起来,自主管理并让人员跨越职能部门,结果是 大幅度地降低了情感性冲突。团队成员共享一个目标,不再需要争辩谁来负责或谁应该负责某个任务。每个人要对其 提供的高质量,高可用性并能满足商业目标的服务负责。

    劣势是,为了按照计划的方式正常发挥作用,团队需要按照构架设计中面向用户的服务重新组织。如果高质量的 功能和高可用性的服务来度量,当敏捷型结构的团队在代码质量和责任上出现重叠的时候,团队将无法自治,会 导致较低的创新力。

    希望目前的小团队可以继续在一起工作,成立第一个敏捷型的团队。