相信大多数人刚开始做程序员工作的时候，是从维护项目开始的。我就是这样的。维护项目也就是对项目中的功能进行逻辑修改、功能完善、新增功能等。
    然而，在一开始接手一个项目的时候，一般情况，项目的实现设计文档都不完整，甚至压根就没有，所以，项目维护是程序员最不愿意做的事情。但是，又是不得不做的事情。如果整个项目从头到尾都是自己来设计实现，一切尽在自己的掌握之中，就不会出现多个地方不协调导致的各种奇葩问题。
    从头到尾设计一个项目和实现一个项目，这种开发场景并不适用经验不足的程序员。在工作时间不久，开发经验不足的情况下，也最多只能做修修补补的工作。就算公司信任你，一下子给一个中大型项目你设计实现，你hold住吗？然而，如果面临的是维护性开发工作，你以为又真的体现不出水平吗？我想，有时候，维护项目比自己设计开发难度更大。原因在于，你需要基于已有的实现机制策略来做增量开发。否则按照自己的方式，就可能出现内部不兼容，会让代码很凌乱，甚至埋下各种bug。
    修改代码完善功能往往也是很头痛的事情。如果不是大改，只是局部单点功能的修改，一般还是容易改的。大改的话，就涉及到整体软件系统的设计框架，各种机制要非常清楚，才能完美融入进去，才能利用已有的各种机制。举个例子说，加入现有的项目中的界面通信都是自己实现的消息队列。当你需要新增界面，也需要通信的时候，你可以自己实现一个通信方法，当然也可以利用已有的消息队列。对于一个项目来说，统一的机制和风格是一个优秀项目的代表。如果你用自己的方法又实现了一个，那么一方面没有利用现有的消息队列，造成代码臃肿，另一方面，也让整个项目的逻辑变得混乱不堪。而如果要利用现有的消息队列，你需要深入全面的了解项目中的消息队列，才能真正用好。当然，这是最好的。
    你在已有的基础上升级功能，保持一致风格和实现方法，项目的可维护性可以一直延续下去，可以长期保持优良的系统逻辑结构。虽然这么做会很费劲，但是是必须做的。如果你的水平很高，你可以改进已有的机制，前提是你要对机制很清楚，否则千万不要动。对机制很清楚和你的水平高低无关，这是对于逻辑流程的了解。如果你的水平不高，那就更别想着去改现有的机制，否则只会被你毁掉。
    那么，功能修改、功能完善和功能升级该如何做好？
    我就从上到下的顺序来简单说说吧。上指的是整体机制，下指的是具体的功能点实现。从上到下也就是从整体到具体的过程。
    对于整体机制，我们如何做修改、完善和升级呢？如果你想到整体机制的改动，说明你雄心壮志不少。然而，一定不要冲动。整体机制是一个软件的核心，整体机制可以是基础功能的机制，也可以是业务功能的整体机制。说白点，就是软件的框架。听到框架一词，你可能会感觉很高大上的样子，实际上也就是整体机制。整体机制是牵一发而动全身的。如果要改动任何一点点，你都必须非常的谨慎。当你了解很清楚每一个细节的时候，那么你可以放心修改了。如果发现框架有漏洞，而且无法在现有机制中规避，那么你就需要重构框架了。
    对于框架的改动，一般都没有人随便敢这么做。重构代价太大，用一个全新的架构来替换，不用管现有的框架了，相当于重新基于现有的框架模式实现一个新的框架，公司一般都不允许，很耗时间。而且，这个重构需要相当能力的人去做。就我工作所知的，还没有见过真正完全重构公司项目的。而我在接手一个项目的时候，因为那个项目比较简单，我也不是去重构他的项目，而是全新开发一个完整功能的项目。毕竟去研究别人怎么想，比自己相办法实现来的更难。如果遇到一个奇葩的实现方法，说不定你都绕不出来。当然，如果是一个优秀的项目，有成熟的框架，也用不着你去重构了。
    那么你要做的就是，完善框架的某些模块。模块需要和框架配合，整体模块的设计实际上与框架也是保持一致了的，所以你也不能随便动模块的结构。所谓的模块就是一组具体的功能组的机制的实现。如果这个模块设计不合理，和框架融合的很不好，你可以重新设计实现这个模块，与框架完美融合。前提是，你还是要非常熟悉框架。所以，虽然相对于重构框架来说难度低些，但是也不是随便能够动的了的。
    那么我们能够做什么呢？我们经常维护代码是在做什么呢？
    我们维护项目代码主要做的就是修改bug和新增功能。框架和模块重构难，一般不会随便去重构的。我们只要维持现有的机制能够正常运作就好了。往往我们需要维护的就是因为bug一大堆。究其原因，就是在实现的时候没有考虑到位。如果有新的功能点需要增加，那么我们就需要在现有的机制中增加模块。这里的模块说的是一个功能需要做的相关的东西，并不是指一个组件什么的。你明白这个意思就好，不要咬文嚼字。
    而不管是修复bug还是新增功能，都是需要了解现有的框架的机制的。除非是新增那种不需要依赖框架的功能模块。所以，维护性开发是我们最不愿意做的。维护性开发需要花大量的时间阅读已有代码，当然我们也可以从中学习到优秀的地方，比如良好的代码风格，一些机制的实现等。而独立开发则主要是自己设计和实现，是发挥自己最大水平的时候。所以说，独立开发可以让你大干一场，而维护性开发则更多是学习。如果你没有什么经验，那么维护性开发对你是非常好的。不要抱怨维护性开发很麻烦之类的。维护性开发是提高你开发水平一个高效的途径。
    对于现有的功能的修改完善和升级，是维护性开发最常做的。不管是依赖现有框架还是独立实现功能点，你不可忽略的是业务逻辑。业务逻辑是你开发的核心。前面说的框架熟悉是实现基础，而在此基础上，我们需要明确我们的业务逻辑。我们的修改、完善升级都必须保证业务逻辑的正确。改动后如果业务逻辑发生错误，那将是致命的错误。业务逻辑指的是功能流程和业务流程。功能流程只要是使用的方法，业务流程影响的是最终的使用效果。我就拿C++技术网开通会员这个功能来举例。
    原先的实现：在用户中心里，用户可以点击按钮自助开通会员。自助开通会员需要有C币，否则就无法自助开通。无法自助开通则会提示用户主动转账到支付宝133********（大熊）这个账号，并带上网站的用户名。这个基本实现，完成了基本的业务逻辑。有不少人已经通过这个方式开通了会员。但是问题是，支付宝的这个手机号有3个账户，用户在支付的时候，经常需要确认哪一个是收款的账户。其实都是可以的，不过最常用是首选，否则转账到其他账户，不能及时提醒，也就不能及时开通会员。为此，提供了一个QQ联系方式，让用户主动联系。
    这个业务实现可以运作了，只是不方便，给用户带来了障碍。毕竟需要输入支付宝账户，还要确定常用的子账户，然后再在转账的时候带上用户名。如果转到其他账户了，那就需要用户主动加QQ提醒开通会员了。
    因为C++技术网目前并不是商业化网站，主推公益技术普及，所以没有申请各种支付接口，也没有资金去申请使用。为了改善这个支付业务功能，我加入了QQ支付、微信支付和支付宝支付的面额为10元、20元、30元、40元和50元的支付二维码。这样让支付方式更多样，满足各种情况的支付。假如一个用户只有微信有钱，那么支付宝支付不是让人挺为难的。所以，之前的考虑并不全面，也给用户开通会员带来很多麻烦。那么此次加入维护码，似乎可以非常方便快捷的让用户开通会员了吧。毕竟扫一下，支付，就搞定了。不同的金额都一目了然，不同的支付方式也一并呈现，只要对准不同的二维码，就可以搞定了。是不是万事大吉了呢？错！！
    这个改动，并没有真正的解决问题。关键在于急匆匆的就实现了，并没有认真去思考整个业务流程。没有抓住关键点，只是知道扫码支付方便。事后才发现，二维码支付陷入了一个困境！因为二维码支付只能简单的支付，用户在支付的时候没有办法附带额外的信息。因为我们开通会员是线上自助开通自助支付的，开通会员支付的途径和网站没有直接关系。如果是线下，都是面对面的确认，然而线上就没有沟通的途径了。我们是可以收到支付款，然而，这个支付款对应的是哪个用户呢？不知道用户名，如何开通会员呢？结果，就只能提供QQ，让用户再通过QQ发送用户名，我们还要确认QQ提供的用户名和支付是一致的，才能开通会员。如此一来，不就更加麻烦了吗！之前虽然转账有点不方便，但是只要账号输入对了，转账的时候可以附带用户名，在收到转账之后，我们就可以看到用户名，就可以分分钟开通会员，体验更好。然而使用二维码支付之后，支付是方便了，然而开通会员却变得麻烦，而且这个体验是非常差的。
    所以，如果能找到一个方案，将支付和可靠传递用户名结合起来，避开选择账户转账，避开用户输入账户名导致出错，而且可以在转账的时候传递用户名，那么就可以在快捷支付和快捷开通会员中得到权衡。那么解决办法就是：提供一个收款账户的二维码，扫一下就可以定位到收款用户，避免输入错误和确认账户。然后启动转账，在转账时可以附带用户名。此时可以避开验证用户名和支付的一致问题。我想，这也是在两次不足之后，通过再次分析业务逻辑而想到的最好的解决办法。
    所以说，维护性开发必须充分了解已有的代码的框架机制、业务逻辑，找出最基本的流程，然后加以分析和优化。如果经验不足，一定要画出流程图来辅助。框架机制是基础而重要的，也是很有难度的。然而业务逻辑，只需要花足够的时间认真分析，找出核心流程，找出需要优化的部分，然而分析利弊，进而找到一个最完美的实现方案。最后就是写代码去实现。而新增功能开发，也是需要充分的去调查框架机制和业务流程，然后在此基础上做出一个完美的方案并实现。