编程——思维——罪与罚

现在身陷“囹圄”！
感觉自己要被逼上绝路了，细细想来，走到今天这个地步与起初写规划代码的时候有这莫大的关系。所以，今天我就总结一下编程中起初设计思维对后期的影响吧。
首先交代一下功能、起初的思维与目前的代码状况：
说起功能，确实有一些小麻烦。功能包含批发、库存调整、退货、强制调整、盘亏申请，以上操作被WEB端、APP端使用，同时也会被ERP与iSales（这是另外的两个系统）同步数据。这些操作大体逻辑是相似的，但是也有微小的差异。

起初我看到这个功能的时候，感觉这些服务可以在一起完成，即使处理上有一些微小的差异，也不是太难，针对性做出对应的处理就可以了。并且这些功能都会写成服务，通过接口被调用。既然时这样，那么我就写在一起好了，方便，并且一次性完成所有的任务，请示领导，同意后就这么写了。

现在我感觉我已经被自己玩死了，现在的代码时按照以上的想法写的，起初的时候还好维护，还算容易修改，虽然有些小麻烦。但是现在已经几近失控的边缘。首先这些业务逻辑已经被修改了三四遍了，当初的微小差异已经变成大的差异了，尤其是当草稿状态与提交转台转化的时候，需要查重、判空，然后还需要查询数据库来查出哪些记录是新增的、哪些是被删除的、哪一些又是需要被修改的，然后批量操作数据库，等等。现在感觉修改起来已经太吃力了。出现一个bug，修改完成后，原来本没有错误的代码却出现了bug，顾此失彼！这大段的程序算是快失控了。

自己挖的坑，自己埋。现在，虽然努力修改但是仍然有很多bug。现在已经深深地感觉到这么复杂庞大的代码维护修改的艰难了，也悔不该当初想的那么简单，没有考虑到后期维护修改的难处。前一段时间在博客园看到关于设计模式中的策略模式的介绍，读完之后就感觉我的这段程序太应该这么写了，这样后期维护修改起来就简单多了,虽然会使有很多相同的代码。

这一次沉痛的教训， 并且现在依久在填坑。总结起来有以下几点：
代码前期的设计不仅要考虑到写代码的时候是否便捷，同时也要为将来维护修改代码留有灵活的余地。一定要保留代码的维护性！
同事不可信。意思是不能指望同事为你写的需求文档，或者口头说的某些业务的保证（例如，一定不会出现某些情况），所以写代码的时候，自己还是要把各种异常的场景都要考虑到，即使他们没有说明或者说明了没有这样的异常（谁知道现在说没有这样的异常会不会以后又会说是有呢。）
终于知道设计模式的重要性了，估计这些模式也是前人不断挖坑又不断填坑总结出来的。作为后来这认真学习前人经验吧。

代价太沉重了！！！