毕业后的张大胖过五关、斩六将，终于拿到了一家知名公司的Offer，并且很幸运地加入了一个明星产品项目组。这是个服务于数千家公司的企业级应用，每日同时在线用户高达几十万。相比之下，学校里做过的那些“玩具项目”顿时显得黯然失色。
几天的入职培训后，他正式进驻项目组，也很快获得了源代码的访问权限。他兴奋地将代码库同步到本地，倒上一杯咖啡，正襟危坐，准备好好“瞻仰”一下这个成功项目的内部奥秘。
俗话说，源码之前，了无秘密。但初次面对现实中的“明星产品”源码，张大胖却倒吸了一口凉气——这和他想象的优雅整洁截然不同。上千行的JSP文件、结构凌乱的Java类方法随处可见，更别提那些遍布各处的、带着历史印记的注释：
//Fix Bug #39587 : 一个组里可以有多个管理员.....
//Fix Bug #58743 : 解决在360浏览器下极速模式的显示问题
//Fix Bug #35672 : 搜索用户时需要支持汉语拼音....
//Fix Bug #58304 : 不允许两个用户同时登录手机端
......
他心中那些关于优美架构、精炼代码和经典设计模式的幻想，瞬间被眼前略显“丑陋”的现实击碎了。产品前端界面美轮美奂，谁曾想后台的Java代码竟是这般景象？一种巨大的失望，甚至是被欺骗的感觉涌上心头。
就在这时，项目经理走了过来：“大胖，给你派个小活热热身，改一个Bug。有问题就问你师傅老李，他经验丰富。”
老李很热心，花了半天时间给他讲解业务背景和技术架构，并详细交代了这个Bug的来龙去脉。之后，就得靠张大胖自己了。
独自踏上寻找Bug的旅程，他感觉像是在一片黑暗的代码丛林中穿行，每一步都小心翼翼，甚至有些战战兢兢。到处都是难以理解的逻辑“毒刺”和潜在的风险“陷阱”。历经千辛万苦，身上仿佛被划得“遍体鳞伤”之后，他终于定位到了Bug的踪影。为求稳妥，他又陪着笑脸请师傅复核，确认无误后才敢动手修改。
修改过程又是一次“炼狱”。他需要仔细扒开层层叠叠的代码，避开那些不知何时由何人定义的、含义模糊的变量，最终定位到一个奇怪的分支逻辑，加上一个判断条件，总算修复了问题。
师傅老李在代码审查时表示了赞许，随即却提出了一个让张大胖心头一紧的要求：“大胖，你看这Bug周围的代码实在太乱了，要不…你顺手重构一下？”
这要求对大胖而言无异于五雷轰顶。“师傅，您还是饶了我吧！”
老李笑了：“走，先吃饭去。”
公司的伙食不错，但大胖心里一直想着重构的事，食不知味。他小心翼翼地试探道：“师傅，咱们项目的代码质量…好像和我想象的有点差距？”
“你这算运气好的了，”老李说，“我五年前刚来时，情况更糟。”
大胖觉得不可思议，鼓起勇气说：“还能更糟？我觉得现在就已经够…够有挑战性了。要我说，最好的办法就是推倒重来。”
“我刚开始也是这么想的，”老李抿了口汤，“觉得干脆另起炉灶，重写一版得了。可新需求接踵而至，根本没时间去做。后来我下了决心，利用业余时间自己尝试重写。”
“结果怎么样？”大胖追问。
“技术上倒没遇到太大困难，但我很快发现，自己对业务的理解远远不够。”老李的表情变得严肃，“你别看咱们的代码‘烂’，但它可是在生产环境跑了多年、经受住严酷考验的代码。这些年里，系统方方面面的问题，尤其是那些深层次的隐蔽Bug，基本都暴露过，也被一一修复了。你上午看到的那些‘Fix Bug’注释，每一个背后都是前人心血和无数加班熬夜的结晶。如果从头再来，你能确保考虑到所有那些极端情况，把边边角角的细节都覆盖进去吗？”
张大胖愣住了。学校里老师总说软件的复杂性在于细节，他此刻才有了切身的体会。他也瞥过一眼Bug管理系统，里面堆积如山的记录，许多都看似微不足道甚至匪夷所思。
“每个程序员可能都有‘重写’的冲动，不愿读别人的代码，甚至‘同行相轻’，”老李接着说，“但现实往往是，自己重写一遍，未必就比现在运行良好的代码更好，甚至可能更糟。除非你有充足的时间去了解所有细节、精心规划、小心编码——但现实中，哪有这样的条件？”
大胖还是有点不服气：“难道大家都这样？没有公司真的推倒重来过？”
“有，但极少，”老李回答，“通常是因为业务发生根本性变革，或者技术栈整体转型，比如从C/S架构全面转向B/S。这也就是我为什么让你尝试重构的原因。既然我们无法‘革命’，那就脚踏实地，从当下开始，用‘革新’的方式，一点一点改善代码质量，让它朝着更好的方向演进。”
“革新，而不是革命…”张大胖若有所思地重复道。
饭后，他回到工位，心平气和地开始了他的第一次代码重构。
现实中，许多项目都面临着类似的挑战。面对庞大的遗留系统，如何平衡新功能开发与代码质量改善，是每个团队都需要思考的课题。欢迎你来云栈社区的开发者广场分享你的见解或困惑，与更多同行交流那些在“代码丛林”中摸索前行的实战经验。
发表于 前天 06:20
|
查看: 11|
回复: 0
