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

标签: 架构 | 发表时间:2014-11-12 00:46 | 作者:Tim
出处:http://timyang.net

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的文章,欢迎页面右上方扫码关注。

Similar Posts:

相关 [系统 重构] 推荐:

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

- - Tim[后端技术]
又一次团队沙龙,这是一个每周一期的活动,探讨技术或团队一些问题. 首先,介绍一下本次讨论的背景,参与讨论的是一个多团队的部门,每个团队有不同的职责方向. 因此,大部分跨团队的各种技术或协作问题也会碰到,典型的一些场景:. 需要升级一个公共库,但是通常并没有一个职能部门来负责公共库升级事项(即使成立也可能最终成为“全国假日办”之类的机构).

HTML5重构互联网:浏览器将部分替代操作系统

- sunseesiu - cnBeta.COM
如日中天的苹果公司一直是下一代WEB语言HTML5最坚定的支持者,如今正面临新的强劲挑战者. 6月有国外媒体称,社交网站Facebook正在秘密开发基于下一代Web语言HTML5的应用项目,以摆脱苹果公司APP Store对Facebook在移动领域的束缚.

高并发场景下,百万级订单量系统的分库分表重构经历

- -
几年前我曾经服务过的一家电商公司,随着业务增长我们每天的订单量很快从30万单增长到了100万单,订单总量也突破了一亿. 根据监控,我们的每秒最高订单量已经达到了2000笔(不包括秒杀,秒杀TPS已经上万了. 秒杀我们有一套专门的解决方案,详见. 《秒杀系统设计~亿级用户》). 不过,直到此时,订单系统还是单库单表,幸好当时数据库服务器配置不错,我们的系统才能撑住这么大的压力.

代码重构

- - ITeye博客
随着程序的演化,我们有必要重新思考早先的决策,并重写部分代码. 代码需要演化;它不是静态的事物. 重写、重做和重新架构代码合起来,称为重构.    当你遇到绊脚石  ---  代码不在合适,你注意到有两样东西其实应该合并或是其他任何对你来说是"错误"的东西  -------- . 如果代码具备以下特征,你都应该考虑重构代码:.

Sunny谈重构

- - CSDN博客架构设计推荐文章
       按照软件工程大神Martin Fowler的定义, 重构就是在不改变软件现有功能的基础上,通过调整程序代码改善软件的质量、性能,使其程序的设计模式和架构更趋合理,进而提高软件的可扩展性和可维护性. 这是重构的定义,简单来说就是不改变软件的功能,优化软件设计和代码,让软件更易于扩展和维护,当然也包括易于复用.

壳系统

- Vernsu - It Talks-魏武挥的blog
经常有人被我问到“你用什么浏览器”时的答案是:傲游啦360啦,但事实上,这些都不是真正的浏览器,从技术角度讲,充其量只是在IE浏览器上加一个壳罢了. 在国外,壳浏览器是以“皮肤”的形式存在,纯属为了美化浏览器而用. 但在中国,壳浏览器成了一门生意. 奇虎的主要收入来源并非来自那个由于一场商战而赫赫有名的安全卫士,而是来自于360浏览器(它有两个版本,分别以IE和Chrome为内核).

秒杀系统

- - 开源软件 - ITeye博客
秒杀系统架构分析与实战. (反馈非常好的文章,推荐). (1)查询商品;(2)创建订单;(3)扣减库存;(4)更新订单;(5)付款;(6)卖家发货. (1)低廉价格;(2)大幅推广;(3)瞬时售空;(4)一般是定时上架;(5)时间短、瞬时并发量高;. 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是10000,秒杀系统需要面对的技术挑战有:.

代码重构总结

- - 开源软件 - ITeye博客
重构:对软件内部结构的一种调整,目的是在不改变软件之可察行为前提下,提高其理解性,降低其修改成本. 创建一个新方法,命名以它做什么来命名,而不是怎么做来命名. 如果只是简单的委托,可以将方法内联. 被子类继承的方法不能内联. 如果一个临时变量只被简单的表达式赋值一次,就可以将它内联. 将这个临时变量申明为final.

代码坏味道——重构

- - CSDN博客推荐文章
1.    Duplicated Code(重复的代码). 臭味行列中首当其冲的就是Duplicated Code. 如果你在一个以上的地点看到相同的程序结构,那么当可肯定:设法将它们合而为一,程序会变得更好. 最单纯的Duplicated Code就是[同一个class内的两个函数含有相同表达式(expression)].

【外刊IT评论网】什么是重构,什么不是重构

- - 外刊IT评论网
  有时候,会有程序员跑到我这里说他们不喜欢某个东西的设计,“我们需要给它来个全面的重构”,来纠正里面的错误.   重构(Refactoring)这个词最初由Martin Fowler 和 Kent Beck给下的定义,它是. 一种修改,使软件的内部结构更容易理解,在不改变软件的可见行为方式前提下使软件更容易变更…它是一种有节制的整理代码、使bug产生几率最小化的方法.