当前位置: 首页 > 最新资讯 > 仓库管理

东南亚值得关注的5家物流创业公司。


2019-03-16  分类: 仓库管理

编者按:面对遗留的老系统,人人都很不爽,都想推倒重来。但是要如何推倒重来呢?听听余晟的看法,本文首发于他的微信公众号余晟以为(yurii-says)上个月,有个以前的同事问我:“你在的时候,为什么不把原来的系统都重做了,我们明明有实力啊”。我说:“我们也做了很多事情嘛,系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。”他说:“对,但我还是想知道,你为什么不把系统重做了呢?”于是我问:“我离职之后,后来似乎多投了不少人重做系统?结果怎么样呢?”他说:“结果,结果就是做业务要同时操作三四套系统……”就我所见,把原有系统“推倒重来”的喜好不只程序员有,使用者更有。

拿我几年前的那份工作来说,刚入职老大们就来跟我讨论系统重做的打算:需要多少人,多少钱,多长时间,能把原有系统推翻重来。毕竟大家每天都忍受切肤之痛:速度慢、经常出错、不安全、客户抱怨、架构糟糕……所以都想拿出“敢叫日月换新天”的劲头,来个干脆的彻底解决。这种心情可以理解,但在我任内“重做系统”一直没有被提上日程,整个技术团队所做的都是“改良”的工作,内容就像我上面说的:系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。这个选择我有充分把握,而且在我看来,如果断然“推倒重来”,我未必能比继任者做得更好,甚至可能更糟糕,因为“推倒重来”绝不是那么简单的事情。众所周知,软件开发的难点之一就是控制复杂度。但是在不同的领域,复杂度有不同的表现。

对于纯互联网业务,或者IT基础架构来说,其复杂度在于软件本身,架构的制定、类库的选择、编码的质量等等。对于其它IT系统——尤其是公司迅速成长,业务不断复杂化的IT系统——而言,其复杂度并不在于软件本身,安全、性能、负载的问题都套用现成的IT解决方案,真正的复杂度来自系统承载的业务本身,比如最简单的:系统里有哪些单据,各种单据承载什么信息,用在什么场景,这些单据是怎样流转的,各种单据存在怎样的约束关系,出现异常情况应当如何处理才能保证业务数据的一致性……这些问题没有准确而稳定的答案,IT再怎样努力也是白搭。对于已经能在线下规范运行的业务,或者是有经典解决方案的工作(比如财务、仓库管理),这些知识都是现成的,可以直接拿来用。但对于新兴领域、新兴业务来说,往往不存在“经典解决方案”。加上很多公司成长速度飞快,一开始并没有构筑好的IT基础(其实是业务架构基础)。典型的情况就是:业务概念混乱不清,业务逻辑层也是杂乱无章,很多系统里干脆把数据库当作业务逻辑层(这可不是说笑,因为数据库无法推脱责任了)。

结果,混乱的业务逻辑依附于糟糕的IT系统,乱上加乱最终成了一锅粥。对IT来说,已有业务的问题层出不穷,每次出问题都需要花费大量精力,寻找蛛丝马迹来“破案”;对业务来说,新增业务往往会影响到原有业务,但谁也不知道会不会影响,会如何影响。系统日渐庞大的另一面是内部日趋无序,复杂度和维护成本飞速增长,远远超过可控范围。吊诡的是,许多人的解决办法不是针对问题的根本原因,评估业务复杂度、整理业务逻辑、整理业务关系,反而认为“推倒重来”、新做一套系统就能解决。