[转]不要轻言升级

大致想了一下，从进入此行业开始到今天，听得最多的也许就是“升级”这两个字了。也参与或经历了一些稀里糊涂的升级、明明白白的升级、有头无尾的升级...... 在不断的升级磨练中知道了一些事情，明白了一些道理。
小小的总结了一下：

1、若非必要，不要轻言升级
很多时候，我们是用一种复杂的心态去看待前任遗留的代码的，有人自私的一面。我刚参加工作的时候，总以为别人的代码是垃圾，自己写出来的才算优美，通常是拿到代码就重构，然后一通大改，然后用勤奋来应付流言，为此吃了不少的苦头。当然得承认，经历了这些之后，对别人的、自己的代码都会有很深的认识，尤其是架构方面的。但极具讽刺意味的是，若干月或若干年之后，我重新对比阅读当时的代码，会发现自己的还不如别人的，尤其是涉及到业务方面的代码。其实原因很简单：其一是前任的代码基本上都经过了运行检验的，出错也只是BUG而已，不会涉及到业务逻辑方面的问题；其二是大部分重构的时间相对会比较紧，由不得你去列计划，忙中出错而导致业务逻辑重构不好的话，后果是严重的。而这对每个程序员来说都是一个必须经历的过程，时间长短因人而异。我也在极力尽一个厚道人的本份，对新来的人讲述自己的痛苦经历，灌输一个道理：不管前任的代码如何垃圾－－事实上的垃圾也好，假想中的垃圾也罢，若非必要，不要轻言升级。通俗点讲，只要凑合能用，就不要去招惹它。

2、升级？你准备好了吗？
各种编译器是为新软件构架准备的，而不是为升级准备的。这是我的观点。尽管这个观点遭到很多人的反驳，我依然坚信。

为什么？很多人这么问过我，而且列出了一大堆的理由，最有力的就是：编译器生产商就号称向下兼容的哦。坦率的讲，我也说不出所以然。的确他们是这样说的，而且看起来确实也是这么做的。我们给客户做项目，也动不动就说免费升级，而且作为必不可少的一条写到了方案书、标书中去了，但实际上～～，好像我还没有为此而给客户升级过:-)
来回顾一下硬件历史，从386到现在的超线程，每次我们“升级”电脑，有几个能够真正做到升级？到头来还不是一换了事？

软件系统也差不多，至少我经历过的是差不多的。也许有朋友成功过－－彻底的成功过。可惜我很不幸，从来就没有这个感觉～

当我把代码从EVC3.0向4.0向.NET 迁移的时候，是多么的踌躇满志，多么的意气风发。全然不把前任的话当一回事：“你准备好了吗？” 终于，在经历了一次又一次的类型、地址错误之后，我发现，前任比我聪明；我发现，重写比修改来得更简单；我又发现，老板根本就没有给我重写的时间；我还发现，离我被赶出公司的时间不远了；于是我开始恨微软、恨比尔盖茨、恨老板、恨客户、恨我自己当初为什么选择这一行......出来混的，哪能不挨刀，键盘鼠标一扔，睡觉去。第二天开始有人出来说，某某某整个一混子，做不出来东东，拉到，难道你说我行我就行，你说我不行我就不行啊，我自己清楚得很。工资是不指望涨了，留也好，走也罢，项目组有的是人，接手的人儿啊，“你准备好了吗？”
后来接触了其他公司的编译器，同样如此。

现在别人问我：VC6的工程升级到2003、2005怎么升？我会说：别升级，把VC6的改成动态库，或者啥也不改，就是个EXE，直接调。需要新的功能模块，再用新的编译器去写。去它的风格不统一、去它的逻辑不严谨，省时间省力气的活不干，谁爱升级谁升去，我宁愿出去晒太阳。

3、写代码为升级作准备
难道不升级、难道就躲避？当然不行。客户新需求、市场新动向，逼着我们必须正视这个问题。动态库是一个好办法，但有时候不够用。所以才有程序架构考虑、才有代码重用考虑。设计的时候，要尽量考虑扩充、升级的问题，有的人喜欢用组件，有的人喜欢用接口。不管怎样，代码重用是离程序员最近的，也是最现实的，什么封装、继承、耦合......这些专业名词俺看不懂，我只是极力建议写导出函数、公用函数、基础类的，都应该遵循一个潜规则：系统参数，尽量采用局部独立的原则，把你的函数整块拷贝出去，换个类名；或者把你的类整个拷贝出去，改动的地方不超过5处就能用的，你YES，否则就NO。曾经见过一个牛人的框架，换了三个不同的系统改几个定义都能套上去跑得很欢，真正的流水式产品，实在是高，受益匪浅啊。

其实我们平时稍微注意一下也可以做到的，只是没有养成这样的习惯而已。至于整体构架则是仁者见仁、智者见智了，这个需要不断的学习和经验积累，而且好坏也没有统一的评判。就拿看得见的来说吧，我一直不喜欢代码写得N长的程序员，这是心病，一句就能搞定的，干吗写三句？说到这里，顺便BS一下不写注释的，你以为人家都有时间去琢磨你的代码和意图啊。

4、升级项目就是新项目
别不同意。建议你按新项目来，风险、资源、进度、成本、文档都理一理，做好规划，该调配的调配，该安排的安排，该沟通的沟通，别到时候手忙脚乱的，又不是你一个人的项目，犯不着你一个人着急，要急也要大家一起急。做事情就不要这样了，自己累点，把事情都考虑好，列出可能的风险和规避对策、把你手下的人员编号再对一遍，哪个最近在泡MM、那个最近比较躁、那个在闹工资、哪个准备开溜...... 这些都直接关系到项目是否成功，还有老板的爸爸最近怎么样，二奶秘书是不是精神旺盛......这些间接关系到项目是否成功，然后的然后，就再问一下自己：必须升级吗？准备好了吗？如果你发现原来的代码50%都移植不成，奉劝你另外设计开发一个替代项目，别跟前任过不去，把他的东西改得乱七八糟的，好好保存就行了。重新开发一个，新项目哦，完成了，找老板，看看，前面的老系统也可以卖，新的你还可以卖得更贵一点，产品线也丰富了，用户群也多了，这样多好，给我加薪吧。