• Feeds

  • 当谈系统重构时,我们谈什么

    weibo team

    又一次团队沙龙,这是一个每周一期的活动,探讨技术或团队一些问题。

    首先,介绍一下本次讨论的背景,参与讨论的是一个多团队的部门,每个团队有不同的职责方向。因此,大部分跨团队的各种技术或协作问题也会碰到,典型的一些场景:

    • 需要升级一个公共库,但是通常并没有一个职能部门来负责公共库升级事项(即使成立也可能最终成为“全国假日办”之类的机构)。
    • 或者是当你负责一个被依赖的模块,当你需要升级时候,发现不少使用方对老版本的feature依赖比较严重,而他们没有精力(或兴趣)迎合升级做大的修改。
    • 团队多了之后,缺少全局的依赖管理,调用之间可能会出现循环依赖的情况(还有间接的循环依赖更复杂)
    • 引入新的第三方库,可能有些团队觉得方便就直接引入了,但又造成了内部使用方法不统一的问题。如果部署在相同的节点,还会对别的模块带来污染的问题。
    • 部分相似的功能大家重复开发,比如一些开关降级工具、发号器等。另外一个层面,A team在开关降级方面新开发了一些实用的feature,但是B team也用不上
    • 从team leader的角度,首要关心的问题是项目的进度及交付目标。因此软件结构的合理性、代码的优雅性以及系统的可扩展性等层面,可能出现优先级未得到保证的情况。“等忙过这一阵,一定要好好重构”,但由于拖延症,长期得不到实现。

    在正式展开讨论之前,介绍一下《人件》原书第三版(感谢华章)中的一个黑衣团队章节。说的是一公司,软件在客户那里出现了很多问题。但由于开发工程师是一群非常有个性也聪明的人,从来不认为自己的代码有问题。因此解决这个问题,公司引入了一群非常有才能的测试工程师,为了更加有个性,他们开始都穿上黑色的衣服,系统一旦有BUG他们就可怕地笑起来,他们的测试根本不是在支持开发人员,而是乐于将软件与工程师放到一种不是测试而是折磨的工序下面;他们还经常聚在一起研究出十分可怕的测试策略,他们一些变态的想法与测试方法让开发工程师望而生畏,欲哭无泪。由于这样一个机制,软件工程师在交付之前自己会进行各种极端的健壮性及正确性判断,最终这个团体逐渐形成自已的个性,也发展了一种渴望并期待发现产品缺陷的哲学。这个机制在不断有人离开的情况下仍然在团队内完好保存。

    但是在重构这个问题,如上面几点所说,团队找不到一种类似凯文·凯利《失控》中描述的机制,不健康的问题第一时间得到了处理。这个可能也是在不少公司同样存在。因此一些主要提出的方案观点如下。

    体检及手术式

    由于上面提到的各种问题,技术体系的健康遭到侵蚀,各个团队还承担各自业务压力,大家的人力资源宽裕程度也不一,因此第一种观点对这些不能及时消除的隐患的存在表示理解,也能意识彻底解决问题的复杂性,但隐患也不能长期不理,因此提出跨团队巡检队定期检查的思路,并将发现的问题列举出来,在约定的时间内完全解决。

    这个做法的逻辑有点类似生活在帝都的IT民工们,在糟糕的雾霾环境下承担着工作的重压,身体健康状况自然不好保证,但也无力改变现状,因此只好通过每年体检来发现身体大的隐患,并尽早排除。

    改变导向式

    这种观点的出发点是人都有惰性,即使有合理的重构理由,在系统还可以勉强运作的前提下,人是没有充足动力去做改变。即使这时候有人跳出来大声疾呼,也不能得到充分的支持与理解,造成了一种机制上的潜在障碍,让健康问题不能第一时间得到解决。

    《人件》第34章标题就是改变成为可能,其中提到,因为人们都不喜欢改变,而你想促成改变的发生,所以你就站在了人性的对立面,自然你就会受到他人的挑战。

    “People hate change…
    and that’s because people hate change…
    I want to be sure that you get my point.
    People really hate change.
    They really, really do.”
    – Steve McMenamin, The Atlantic Systems Guild, 1996

    为了避免这个情况出现,团队需要实行一种“改变为先”的共识 — 只要有人提出一种新的升级(新版本、框架、工具等),团队其他成员原则上不可以提出反对意见。尤其在公共工具库方面,倾向采用在框架配置层面强制升级,再让所有成员被动升级的做法。

    satir_change_model
    《人件》中有关改变的观点则引用萨提亚模型(Satir model),其主要观点是,改变需要至少经过4个阶段,其中的3、4阶段如果没有经历,改变不可能真正落地。因此对于软件开发这样一个以人为本的实践活动,充分意识到混乱也是新事务出现以后的一个必经之路,但混乱不是终点站,有很多团队在做改变时候,从3直接又回去2了。

    多数派决策式

    这种观点的出发点是大的系统、背后大的团队以及成员的关注点及诉求点的多元性。比如

    张三:关注点在存储的成本及效率,由于精力原因,对于公共组件库采用跟随策略,并期望最小的参与成本。
    李四:喜欢尝试新框架,如果团队引入了某个公共的开源框架,对社区每个小的升级迭代充满兴趣,希望将每个版本即时引入到公共库中,并希望所有团队调整自己的代码,跟随及时升级。

    在认可团队多元化价值观的前提下,这个问题不能简单总结成采用某种“稳健型”或者“积极参与型”的思路来决策。但为了团队重构的机制能够存在并运作,可以由各团队选出一名技术代表,每周来讨论一次公共的技术重构事项,并按照多数派的意见进行执行。

    当然上面只是部分主要观点,由于本次讨论各方参与激烈,本文章不做结论,欢迎大家留言介绍你们团队在系统重构方面的做法及机制,希望能从中找到类似上文《人件》或《失控》中描述方法类似效果。

    对微博平台技术沙龙感兴趣的朋友,可以在微博关注话题 #平台技术沙龙# 或微信搜索公众号“WeiboArch”(a.k.a 微博平台架构)来参与。

    如想及时阅读Tim Yang的文章,可通过页面右上方扫码订阅最新更新。

    « | »

    3 Comments  »

    1. pass by the road

      吊打 team leader

    2. pass by the road

      责任是谁的? 工期能不能完成? 为什么要这么做? 既然能跑不就ok了?

    3. 计划也在负责的团队中每周开展一次技术沙龙,想了关于沙龙的开展,主要如何组织和讨论/分享哪些知识点?

    Leave a Comment