※ 引述《eori (浮光掠影)》之铭言：
: 进来公司一个多月，被指派说要去修改一个系统。 该系统已经用了10年以上，文件寥寥
: 可数，代码改得乱七八糟，注解只有几行。我这个职位两年内换了五个人，其他同事只知
: 道大概，问细节就说去看code。老板一直认为这个系统很简单，搞不懂为什么没人懂。请
: 问大家有没有相似经验，后来又是怎么解决，可以给我当作参考，谢谢。
上面那一篇是精神面正解 我这边说一下操作面好了
第一阶段
前几天code大概看看就好 先看coding style分成几类 然后cloc一下
先报告这个系统约XX万行 程式里面有YY种风格混在一起
(先展现这系统确实不好处理)
第二阶段
先管大架构 简单的报告这个系统分成几个子系统 如果可以的话......
没文件也没注解的话命名又鸟的话 这边开始就要奋斗了
先对子系统写一些简单的测试 最低限度的测试就好 边界或特殊状况都不管
(因为有写东西 总行数有变多)
做一些简单重构让程式码好读 还有写好注解
因为一般老人最爱SOP 写一份文件应该是上面会比较喜欢
不过写不写看还是看老板要求 如果要写的话 注解跟文件尽量一样
(这样有两个好处 1. 后面的人不能直接抄你的注解转文件 2.方便改)
第三阶段
在大概知道架构后处理容易产生bug或难以debug的地方 这部份很吃经验
好比 a. 解开A include B / B include C / C include A环状
b. 改掉些白目的写法 像是把很多事情压成一行
c. 把一些奇奇怪怪写法改成正常的写法
d. 整理coding style
这边要告报做了多少事就靠diff 尽量维持每周处理差不多的量
好比改得多就不要去动coding style 改得少就找一天刷coding style之类的
第四阶段
正式增修和改写程式本体还有维护它