※ 引述《eori (浮光掠影)》之铭言：
: 进来公司一个多月，被指派说要去修改一个系统。 该系统已经用了10年以上，文件寥寥
: 可数，代码改得乱七八糟，注解只有几行。我这个职位两年内换了五个人，其他同事只知
: 道大概，问细节就说去看code。老板一直认为这个系统很简单，搞不懂为什么没人懂。请
: 问大家有没有相似经验，后来又是怎么解决，可以给我当作参考，谢谢。
这种情形大概不会少遇到，除了自己公司开发的换了很多手的以外，也有那种外包给别的
公司做后来没有再继续维护后就放在那摆烂的系统。接到这种案子心情真的是会蛮差的，
去问别人都会叫你去看Code，去年我也接到几个(公司维护摆烂说他不会，事实上他可能
真的不会，因为他上次跟流程人员说 Win10 不相容 .Net Framework 没办法安装，搞到
流程来找我求助...这又是另一个故事了)
总之接到这种案子怎么办？
我的经验是：
1. 先判断是不是你非做不可？
别人都可以不做，都可以说不会，那为什么我就必须会必须做？每个人职位不同都有
自己该做的工作，你本来的工作做不完，被推一个坑，延误到你自己的时程，谁会帮
你？如果修不好还要被呛被酸，有够倒楣。如果是别人随便推到你身上而不是必要的
那你先把自己的事做完再来看要不要帮忙，建议是不要节外生枝，说很忙没空，之后
再说就好。去年我就是这样呛维护的，本来就他的事，我身上三个开发案还叫我去帮
他看，他自己在那跟客户吹牛他什么都会，还在try-catch里写递回这种东西我哪敢
碰。
2. 如果非做不可：
如果老板已经发下命令要你做，先争取时间。第一这个东西本来不是我写的，你要我
研究一定要时间(不管是要维护还是直接重作)；第二你现在要我做这个，那我本来的
专案进度怎么办？我没办法兼顾，看是你要协调别人来帮我还是先暂停其他案子，不
然我没办法做。
再来实作方面，Trace Code一定是必要的，但帮助可能不大。举我的例子来说，去年
我得到PM同意暂停手上案子后，去协助维护改以前的工具，跟你一样文档没有注解没
有。结果维护真的是来乱的，跟我讲说看 Code 就会了什么也不讲。我问他你说看
Code就会，那表示Code的逻辑是对的囉？Code是对的为什么要改？他说将来Data
Source的格式可能会变更，我说喔那会变成什么样子？他说不知道。我问他那你要我
改哪？这个工具是干嘛的我都不知道，你说现在可以正常运行而且运行结果是对的，
那改什么？你说将来会改但改成什么样不知道，那你要我怎么改？然后这件事就不了
了之了。
事实上同样的情况也适用在你碰到的情形上，我建议你在看Code前先了解一下这个系
统到底是干嘛的，问题点在哪(没有想改善的点那是要改什么？)把你需要处理的业务
逻辑都整理清楚。我们工程师是为了解决某个特定问题而去写程式写系统，而不是写
好系统来看我们能达到什么解决什么问题，这样有点本末倒置，很可能一开始问题根
本不存在反而多花很多功夫。现在老板要你改，表示他觉得这个系统有问题，那就是
Code本身可能就有问题。如果你什么都不清楚，光从有问题的逻辑中就能推敲出正确
的逻辑应该是怎样，那老板该换你当了。当你看到你觉得很奇怪的Code时，你根本无
法确定前人为什么这样写？到底是有特殊要求还是单纯写错，或者是当时的需求已不
适用于现在，你也会不知道从何改起。
随着时间过去，中间又经手过很多人修改，系统一定越来越庞大也越来越难改，如果
你能搞清楚这个系统到底是要干嘛的，问题点在哪，改善后要达到怎样的效果，逻辑
和数据该怎么流动而终于要开始改了的时候，再来依照你Trace Code的结果决定是要
重作还是修改前人的Code。一般而言如果我判断重作大概几周至一个月内能做完的话
我就会直接重作了，反正有争取到时间；要是系统实在过于庞大非短期单人能完成，
那你只好硬著头皮去改以前的Code。要是你能了解这个系统的业务逻辑，那应该也有
助你找到比较可能出错的地方。不过原则上来讲还是建议跟老板提看看要不要发包或
开新专案专门重作这个系统，毕竟一个系统搞到大家都敬而远之，也代表他的维护成
本是相当高昂的，是不是还要这样继续下去，还是应该另外再做一个，这其实是可以
讨论的。
当然如果够油条，这些事其实能让你杀很多时间，就像我前公司的维护一样哈。