“推倒重来”的讲究

标签: Yurii谈开发 系统重构 软件开发 | 发表时间:2015-10-10 10:23 | 作者:Yurii
出处:http://www.luanxiang.org/blog

上个月,有个以前的同事问我:“你在的时候,为什么不把原来的系统都重做了,我们明明有实力啊”。

我说:“我们也做了很多事情嘛,系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。”

他说:“对,但我还是想知道,你为什么不把系统重做了呢?”

于是我问:“我离职之后,后来似乎多投了不少人重做系统?结果怎么样呢?”

他说:“结果,结果就是做业务要同时操作三四套系统……”

就我所见,把原有系统“推倒重来”的喜好不只程序员有,使用者更有。拿我几年前的那份工作来说,刚入职老大们就来跟我讨论系统重做的打算:需要多少人,多少钱,多长时间,能把原有系统推翻重来。毕竟大家每天都忍受切肤之痛:速度慢、经常出错、不安全、客户抱怨、架构糟糕…… 所以都想拿出“敢叫日月换新天”的劲头,来个干脆的彻底解决。

这种心情可以理解,但在我任内“重做系统”一直没有被提上日程,整个技术团队所做的都是“改良”的工作,内容就像我上面说的:系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。这个选择我有充分把握,而且在我看来,如果断然“推倒重来”,我未必能比继任者做得更好,甚至可能更糟糕,因为“推倒重来”绝不是那么简单的事情。

众所周知,软件开发的难点之一就是控制复杂度。但是在不同的领域,复杂度有不同的表现。对于纯互联网业务,或者IT基础架构来说,其复杂度在于软件本身,架构的制定、类库的选择、编码的质量等等。对于其它IT系统——尤其是公司迅速成长,业务不断复杂化的IT系统——而言,其复杂度并不在于软件本身,安全、性能、负载的问题都套用现成的IT解决方案,真正的复杂度来自系统承载的业务本身,比如最简单的:系统里有哪些单据,各种单据承载什么信息,用在什么场景,这些单据是怎样流转的,各种单据存在怎样的约束关系,出现异常情况应当如何处理才能保证业务数据的一致性……这些问题没有准确而稳定的答案,IT再怎样努力也是白搭。

对于已经能在线下规范运行的业务,或者是有经典解决方案的工作(比如财务、仓库管理),这些知识都是现成的,可以直接拿来用。但对于新兴领域、新兴业务来说,往往不存在“经典解决方案”。加上很多公司成长速度飞快,一开始并没有构筑好的IT基础(其实是业务架构基础)。典型的情况就是:业务概念混乱不清,业务逻辑层也是杂乱无章,很多系统里干脆把数据库当作业务逻辑层(这可不是说笑,因为数据库无法推脱责任了)。结果,混乱的业务逻辑依附于糟糕的IT系统,乱上加乱最终成了一锅粥。对IT来说,已有业务的问题层出不穷,每次出问题都需要花费大量精力,寻找蛛丝马迹来“破案”;对业务来说,新增业务往往会影响到原有业务,但谁也不知道会不会影响,会如何影响。系统日渐庞大的另一面是内部日趋无序,复杂度和维护成本飞速增长,远远超过可控范围。

吊诡的是,许多人的解决办法不是针对问题的根本原因,评估业务复杂度、整理业务逻辑、整理业务关系,反而认为“推倒重来”、新做一套系统就能解决。持这种观点的人,通常对系统与业务的关系也有误解。

对希望“推倒重来”的人来说,系统和业务的关系,有点像车辆对人员:一辆车我开了一段时间觉得不好,就想换一辆车来开,这是很自然的。但是在信息化深入工作各个角落的今天,系统和业务的关系远不是“车辆对人员”那么疏远,而更像“心脏起搏器对人”,或者“人造骨骼与肌肉”的关系,已经如胶似漆缠在了一起,系统对业务的支持越多越广(暂时不论质量),双方纠缠得也就越紧密。更换心脏起搏器或者人造骨骼的难度,远远比换车的难度要大,所以需要慎重考虑,不能单纯因为心脏起搏器“不那么好”就轻率决定更换。对系统来说,也是如此。

如果要对基础不好的遗留系统做脱胎换骨的改造,我有几点经验可以参考:

第一,一定要有非常优秀的业务人员和开发人员。

对业务人员来说,不但要熟悉自己手头的操作,还必须明白操作背后的逻辑,并且需要超越本职工作,能从全局角度来思考自己的业务(有时甚至要让自己操作更复杂,来提高系统安全性等收益),这样才能真正把握住业务的复杂度。对开发人员来说,要能够完整理解领域知识,同时必须有高超的编程能力来应对遗留代码,敢于出手而不是畏缩不前,谨慎出手而不是贸然行动——如果原有系统开发人员的技术能力可以打30分,全新开发系统的技术要求是60分,那么要成功改造遗留系统的技术人员,往往需要有80以上的分数才能胜任。

第二,“推倒重来”往往不如“逐步改良”。

所谓“逐步改良”,指的是大家先通过讨论确认未来系统的设计蓝图,然后需要开发用于过渡的接口层。于是,新开发的模块一定要严格按照新的规范开发(这也就是我说的“理清各模块职责、API通讯机制的建立、内部分层的整理”),同时通过过渡的接口层与原有系统对接,原有的模块则在理清业务逻辑的情况下,按需切出合适的接口,逐部分在测试通过的情况下进行迁移。最终新的系统是像拼图一样慢慢拼出来到最后一天才成型的,而不是平底盖楼造起来的。在这个过程中,最关键的是找到合适的切入点,搭建出合适的接口或者接口层。这些工作就像盖房子的脚手架,哪怕之后不会用到,中途也不能省略,还必须仔细对待。当然,这是一个考验人的工作——我曾经遇到过数据库事务里跨库连表的查询,这个糟糕的设计严重阻碍了单数据库实例拆分成多实例的进展,回想起来真是如噩梦一般。

如果你对改造遗留系统有自己的见解,或者在这个过程中有什么有意思的经历,欢迎留言给我。

最后推荐一本有意思的书。其实不管是软件开发还是社会变革,对于不喜欢的现状,大家往往喜欢来个“干脆”、“彻底”的解决方案,但真正成功的往往不是这些方案。在第二次世界大战结束时,世界上到底发生了哪些事情,遇到了哪些问题,又是怎样重建社会秩序的呢?广西师大《理想国》丛书第9册 《零年:1945现代世界诞生的时刻》,用翔实的文笔全面记录了“终战”之后的情景,许多画面相信会让读者大吃一惊——很多时候“文明”堪称被打回原形,“零年”这个名字可谓名副其实。

相关 [Yurii谈开发 系统重构 软件开发 ] 推荐:

TokuMX使用小计

- - 乱象,印迹
最近因为工作的缘故,接触了 TokuMX,尝试下来感觉不错,值得介绍给大家. 事情的起因是要解决MongoDB的问题. 系统中需要保存程序输出的运行信息,这类信息比程序语言的log更高级,比明确的操作日志更低级,却是某些时候发现问题的关键证据,所以必须保存下来. 因为其格式不规范,又需要方便检索,综合下来文档型NoSQL的MongoDB是比较好的选择.

公开表扬,私下批评?

- - 乱象,印迹
很多初上管理岗位的人都听过这样一条教诲:“公开表扬,私下批评”. 而且,很多有管理经验的人也是这么做的. 理由很简单:公开表扬能给人鼓励,催人继续,私下批评给人留了面子,减少副作用. 但是,它真的是一条应当时刻遵守的行为规则吗. 不妨看两个例子:某人表现不好,主管与他谈话之后有了一点改进的苗头,应该鼓励,所以主管公开表扬,结果其它人明明做了更大贡献,却没有得到表扬;某人搞砸了工作,造成整个团队加班为他收尾,然而主管只是私下批评,让其它人觉得不公平,主管有意袒护.

“推倒重来”的讲究

- - 乱象,印迹
上个月,有个以前的同事问我:“你在的时候,为什么不把原来的系统都重做了,我们明明有实力啊”. 我说:“我们也做了很多事情嘛,系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理. 他说:“对,但我还是想知道,你为什么不把系统重做了呢. 于是我问:“我离职之后,后来似乎多投了不少人重做系统.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从Excel到微服务

- - 乱象,印迹
Excel很老,Excel很土,Excel一点也不sexy;微服务新,微服务很潮门,微服务很高大上. 那么,Excel和微服务有什么关系. 上个月看了篇文章,The Unbunlding of Excel. 作者认为,对于初创公司(尤其是非“纯IT”初创公司)来说,Excel几乎包办各种工作. 想做轻量级的CRM,可用Excel.

软件开发的核心

- - 博客园_知识库
  「我们一直这样做开发,时间做久了,便忘了当初的本意.   有关软件系统开发,我们谈些什么.   我们谈过程,编码规范、开发流程、同行评审、结对编程、持续集成,从瀑布到敏捷再到极限编程.   我们谈架构,企业级、J2EE、容器化、SOA(面向服务架构)、Microservices(微服务化).   我们谈规模,大容量、高并发、大数据.

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

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

软件开发的“三重门”

- - 酷壳 - CoolShell.cn
自从上次写了“ 程序员技术练级攻略” 以来,就觉得似乎还有很多东西没有谈到,但当时没有继续思考了. 而春节前有人问我,是做底层技术,还是做业务. 这问题让我思考了很多,不由自主地回顾了一 下我这十多年的软件开发经历,并顺着整理分类了一下自己解决过的若干问题,还发散想了很多,经过了一个春节假期的发酵,产生了下面这篇文章.

软件开发模型综述

- - CSDN博客推荐文章
                     软件开发模型概述. 最早出现的软件开发模型是1970年W·Royce提出的瀑布模型. 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架. 软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段.

软件开发的人文关怀

- - 极客公园-GeekPark
我是极客公园黑板报认证值日生. [核心提示]软件可以没有活力,而软件开发却不能没有活力;程序可以像机器一样,程序员却不能像机器一样. 要改变这种状态,就应当增添更多的人文关怀,把开发人员当成活生生的人,而不是视为程序或者工具. 编辑注记:本文来自余晟的博客 乱象,印记. 作者从自己的经验出发,提出了一些给软件开发人员提供人文关怀的可行措施.