MIUI未来有机会被重构么？
MIUI永远也不可能被重构, 但MIUI又时时刻刻被重构.
这两句话看似矛盾, 但是实际上不矛盾, 这是行外人对软件工程的误解.
因为前一个重构是题主所说的"重构", 指的是完全抛弃原有的设计和代码, 新建项目另起炉灶. 这是不可能的.
但是MIUI又时时刻刻被重构, 意思是MIUI会尝试对糟糕的代码进行修复(使其暂时可以用), 隔离(不要影响到其他模块), 进行小范围的重构(逐步进行行级, 方法级, 类级,最终到模块级),由小及大, 循序渐进, 最终把整个坏代码替换.
我举个例子, 非程序员也能听懂的例子.
你有一座商场, 这座商场一开始只有二十家店铺, 你可以管理的很好, 信息齐全, 流程完备, 职责分明, 除了品类少, 顾客的体验还是很清爽的. 商场运行的井井有条.
有一天, 你的这座商场突然火了, 二百家店铺要入驻, 但是你一共就四十间空闲的店面, 咋办?你只好提出了一个临时的解决方案, 把走廊过道厕所改小, 楼顶加盖两层, 以增加店面, 甚至还不够, 把地下停车场取消, 增加负一层店面.
这样一来, 终于是容纳了二百家商铺. 大量利润进了你的腰包. 但是问题来了:
顾客时常抱怨商场没有停车位, 厕所要排队, 走廊过道拥挤
各家店铺经常争抢走廊过道的空间
有一些店铺脏乱差, 但也无暇顾及
加盖的两层使得商场建筑岌岌可危
显然, 你的商场已经变成了屎山. 怎么办呢?你有三个选项:
- 直接推倒重盖, 盖一个更高更大更漂亮的商场. 这样就能容纳一千家店铺了.
- 统计店铺需求, 取缔脏乱差店铺, 规划走廊过道空间, 加固建筑, 增加立体停车位. 保证原有商场利润的同时, 在旁边另起一个商场, 新商场与原商场互联互通. 这样顶多能容纳五百家店铺
- 躺平摆烂, 就这呗, 能赚多少是多少.费那钱干嘛.
分析一下这三个解决方案, 你就会发现:
第一种方案未来看最好, 新盖的商场最符合需求, 比加盖的更大更漂亮, 能容纳更多店铺与客流量. 但是呢, 现金流一下就断了, 新商场能启用起码是八年后了, 中间的耗费的成本巨大. 况且, 能容纳一千家店铺, 也不一定有这么多店铺入驻呢!这种方案其实是最蠢的.
第三种方案看短期利益最好, 躺平恰烂钱, 但长期看整个商场都会垮掉.
于是你就会发现, 忽略短期收益, 选择长期收益最好的方案不适用. 选择短期收益, 忽略长期收益的也不适用. 这两者都会把你的裤衩子亏掉.
只有第二种方案, 平衡短期与长期收益, 先用低成本的手段维持住现有的利润, 再通过在旁边新建的方式保证长期发展. 这种方案最艰辛, 需要大量的调研, 设计, 实施, 既要保证屎山的运转, 也要保证新项目的成功.但是只有这种方案, 平衡短期与长期收益的方案, 才能保证整体的平稳发展. 这就是软件工程上的重构, 由小及大, 循序渐进, 平衡成本与收益.
软件工程就是平衡成本, 收益, 需求, 项目复杂度.软件工程不是在开玩笑, 成本高的要死, 需求也复杂的要死, 不是一句"重构"就能推翻重写的. 必须平衡成本, 收益, 需求, 项目复杂度, 想尽一切办法, 最终才能得到一个还算过得去的系统.
只要软件系统还能跑, 就不要重构, 这是一句玩笑话, 但也是对软件工程的敬畏.
在我看来MIUI最大的问题就是过多的听从了用户的意见, 用户不是你的产品经理, 他们提出的需求是要经过思考的, 为什么他们会提出这样的需求, 这样的需求的底层逻辑是什么, 如何平衡用户需求与项目复杂度?这才是产品经理要想的事情.
把用户的需求直接做到项目里, 然后加个开关按钮, 绝对是对项目, 对用户的不负责.
当用户想要一个杯子的时候, 他实际是想干嘛? 他不需要那个杯子, 他只是渴了而已.
