作者TonyQ (得理饶人)
看板Soft_Job
标题[心得] 线上系统再更新
时间Fri Sep 25 22:23:39 2020
刚好今天朋友聊到老系统怎麽翻新，
大家手上的系统有一天都会变老系统，
如果维护的不够，可能就会变成被讨厌的系统。
做人可以有被讨厌的勇气，系统被讨厌就会被换新。
很多人说老系统换新很难，但我觉得还是有一些方法论的。
几个我自己会处理的做法：
1. 找出最小故障单位
被称之为系统的东西通常是多元件的，每个元件有各自的职责，
所以通常不可能是一次全部都有问题。
一般来说，一个老系统首先需要的是体检，把常失火的地方找出来。
可能是一或多个。
2. 开始切出问题的边界，凡是系统一定是有 input 跟 output 。
再来，仔细读懂这一段的程式码或行为，如果没有程式码，
那就记录这一段足够的input 跟 output 确认逻辑。
3. 建立测试环境
4. 拉出隔离层(中间叠 proxy 或改成透过网路存取等)
5. 局部替换逻辑(由 proxy 导部分流量检查有无异常)。
6. 上线
7. 如果出问题，必须可还原回修改前的模式
=======
其实会难，通常是没有切对结构，
或是没找到 core issue 。
另外多数情况下未必是整个重写，通常是局部的调整可以解决问题。
有一种情况是需要向旧相容，
这种时候介面会同时支援旧的，直到确定不再呼叫。
很多人会认为写新的就不用管旧的介面，
结果上线一测东漏西漏死的乱七八糟。
总之，改老系统时，
保守的多做事多买多层保险才是先进。
改老系统的心法叫做移花接木，
强调的是模仿，与原本的功能行为越像越容易嫁接。
很多人总觉得重做功能就要东加西加，
功能连对照组都没有，当然就会越做越难。
如果是为了加新功能，所以要重写，
这其实不叫重写，这叫杠上开花。
重写是跟系统杠上，加新功能是让脑袋开花。
一般调整系统都会需要明确目的，也能结构化确认问题，
往往是非常多细碎单元的组合，而不是一次万里长征。
拍片也讲求分段拍摄再後制剪接到位，
但重写系统想要长镜头一镜到底，这是高难度技巧。
总之系统重整，单纯就是技能问题跟心态问题。
撇开耍屌、自以为是，认真的面对既有的程式跟需求。
尊重团队已经做到的事情，
想着怎麽用新的方法完成，这些才是真正的目标。
多数的失败，肇因於不尊重既有的逻辑，
贸然躁进调整，自然出事。
最可怕的是单行道的改版，
无法还原，一旦出事就大地震。
爬山要确保，写程式也得有备案。
总之，尊敬既有的程式码，与之共存，
并比既有的程式码更理解既有的程式码的目的。
这样要重写程式，很难失败。
而且减少失败次数，就是加速成功。
-----
Sent from JPTT on my Google Pixel 3 XL.
--
网页上拉近距离的帮手 实现 GMail丰富应用的功臣
数也数不清的友善使用者体验 这就是ｊａｖａｓｃｒｉｐｔ
欢迎同好到 AJAX 板一同讨论。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 223.140.46.76 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1601043823.A.4E9.html
1F：→ superpandal: 我不看做法 我看的是要我做到底合不合理 09/25 23:09
2F：→ superpandal: 基本上找人进去不给高薪 不熟业务又要叫人短时间做出 09/25 23:10
3F：→ superpandal: 来本身就不合理 09/25 23:10
4F：→ superpandal: 合理的化技术层面好解决 09/25 23:11
5F：→ superpandal: 合理的话 09/25 23:11
6F：推 x246libra: 给高薪，短时间，不熟业务，可以做出来吗？不确定楼上 09/26 02:51
7F：→ x246libra: 是薪水还是时间来判定是否合理 09/26 02:51
8F：推 ldkrsi: 老系统更新最难的不是上面觉得还能用就不要改吗 09/26 05:29
9F：→ ldkrsi: 还有就是改到一半人手被源源不绝的急件借走 09/26 05:30
10F：→ ldkrsi: 然後就变成一个更难维护的样子放在那边 09/26 05:31
你这三点讲的基本上跟是不是老系统翻修无关，而是通用的开发负面因素。
※ 编辑: TonyQ (61.231.75.160 台湾), 09/26/2020 08:45:19
11F：→ shooter555: 最可怕的是各元件之间互相依赖太深 牵一发动全身 改一 09/26 08:59
12F：→ shooter555: 个全部死 09/26 09:00
13F：→ shooter555: 然後就要排定一堆时间 来先把依赖的问题解决 再来改进 09/26 09:08
14F：→ shooter555: 其中一个元件 然後上层老板就会失去耐心 09/26 09:09
这种情况应该避免动後面的资料结构，要试着在这前提底下进行。
只要新旧结构跟行为一致，就不用担心需要大规模全换。
通常是有同时修改行为的野心才会出事。
※ 编辑: TonyQ (61.231.75.160 台湾), 09/26/2020 09:48:47
15F：推 WaterLengend: 可以请问对於这种结构性的问题，平常除了专案实战 09/26 10:00
16F：→ WaterLengend: 或开源专案能够接触之外，有其他的练习方法吗？ 09/26 10:00
开源专案接触不到这种东西, 因为如果开源专案已经足够多人用,
通常已经有自己的可靠性处理的策略, 你顶多是见习.
平常接些烂尾案对这些事情有帮助, 但抱着练功的心情就好.
不用刻意去接或以此为业~~
17F：推 nini200: 谢谢分享 09/26 11:10
※ 编辑: TonyQ (210.61.209.201 台湾), 09/26/2020 12:44:37
18F：推 WaterLengend: 了解，感谢大大。不过根据您的经验分享跟之前的经 09/26 12:54
19F：→ WaterLengend: 验比较後，感觉起来都是将问题切分明确、最小化问题 09/26 12:54
20F：→ WaterLengend: 、以及挑选风险最低的方法实行将问题解决，而不是 09/26 12:54
21F：→ WaterLengend: 动不动就要炸掉重来，把时间跟资源花在刀口上 09/26 12:54
更明确点说, 我一贯的策略是判断当下时间跟目标,
在风险能承担的上线, 贴着风险承担的边缘走, 我做事情出包的机率不低,
但我都有把握出包的时候被收在安全范围且迅速被解决.
这未必是风险最低的, 当然在论述时我会讲得比较保守是因为冒险本来就需要判断.
在正常状况之下因为我对系统可承担的风险比一般人高,
一方面多数情况下我对系统的熟悉跟经验比别人多,
另一个角度是我比较敢动结构, 跟比较能清算动结构对应的风险.
所以在多数情况下, 我的改变相对於环境仍然是属於激进跟大胆的,
但这个激进跟大胆的背後还是风险承担跟计算.
主要的问题还是所有地方都一样, 要能上得了线才是生存,
所以目标应该放在最安全的着陆, 而不是最大胆的登月计画.
※ 编辑: TonyQ (210.61.209.201 台湾), 09/26/2020 13:11:25
22F：→ superpandal: 不给高薪只是其中一个原因 09/26 13:30
23F：→ superpandal: 重申一次 在台湾好工作真的不多 09/26 13:32
24F：→ superpandal: 年薪百万 没过到一年自然没百万 多方考量意义在这 09/26 14:15
25F：→ benqm300: 对阿要你翻新，但是原本的工作还是一样要照进度完成， 09/26 18:34
26F：→ benqm300: 然後薪水不变，欢迎来到宝岛台湾。 09/26 18:34
这不就是一种工作吗？
27F：推 neo5277: 通常是没有边界，因为以前没有切得很乾净要换一个小东西 09/26 18:35
28F：→ neo5277: 就要整个全部拆了 09/26 18:35
那就要先对原本的系统进行骨干分切作业。
※ 编辑: TonyQ (223.137.36.198 台湾), 09/26/2020 19:22:42
※ 编辑: TonyQ (223.137.36.198 台湾), 09/26/2020 19:29:34
29F：推 michael0728n: 可以很快rollback就没啥大问题，最惨就浪费时间而已 09/26 23:42
30F：→ viper9709: 推分享~以为这是基本+1 09/27 00:47