博客开封了，有段时间没有写过技术文章了，前段时间工作太忙，差点儿没有时间去反思工作。尽管搞的东西不是非常困难，可是须要耗费非常多时间去熟悉新的东西。主要是在工作中须要使用到微软开发的新框架SOLFramework。它是由微软为远洋地产量身定做的MVC框架。须要在该平台基础上开发导致了非常多兴许的麻烦。

       先来说下近期的工作情况吧，近期一段时间在工作中不是非常如意。非常多事情没有依照自己的规划进行，当中最基本的表现是这段时间没有更新文章。不管是在技术上的文章还是工作上的学习都没有及时的去思考、反思，可能是跟自己的工作环境或者工作性质有关系吧。

 一、需求变更

       需求变更麻烦大。近期一段时间最不如意的事当数工作中遇到的困难。接手了上级领导所要求的新需求。也就是需求变更。

远洋的SOA平台总共同拥有52个服务包，我们所负责的是现场销售的服务包，它主要是解决卖楼的问题。该服务包在四月份已经投入到生产环境。客户如今已经在使用中。但在使用过程中提出了新的需求。而我们呢就是新需求的维护人员。对该服务包的需求做进一步的优化。这也是程序猿最头疼的问题。开发不害怕就怕需求总做变更。需求变更是要付出代价的，当中最基本的当数浪费时间和金钱，需求变更可能会影响到整个项目的进度，当然紧接着就须要付出劳力、物力、財力，那怎样最小化的降低需求变更带来的损失以及怎样应对需求变更？这是程序开发和设计人员要考虑的问题。在网上查看了一些应对需求变更的方法，最基本的是双方面的划分，一是在项目开发前要对需求变更最好准备，二是在开发过程中需求变更的控制。

 1.1 开发前

        其一：降低需求变更。

想要较好的应对需求变更。开发前的工作是相当重要的，也就是说在开发前就应该预见性的看到会有的需求变更的地方，及早的反应解决可能的变更点。这里说的并非去规避需求的变更，事实上试图去规避需求变更本来就是错误的想法，需求变更是非常正常的问题。尽管可能会对项目的开发有影响可是它是不可避免的问题，在需求变更时往往是提出新的需求，新增新的需求，这就会导致开发时间及成本的添加，所以一定要在开发前预见性的解决需求变更点。另外须要做的是在开发前要尽量的完备需求，建议开发者或者设计人员採用原型的方法启示客户思考功能需求，让客户和BA共同思考制定需求标准。

        其二：规范化及合理化的设计。在开发前制定需求文档时一定要注意需求的完备性，所以非常重要的一点是在需求制定的标准。并且在整个开发过程中需求说明书是开发者和客户之间的重要接口，所以需求文档的制定一定要具备完整性、一致性、基线控制、历史记录等特性，在制定需求文档时一定要将文档交付给客户批阅，在客户惬意的基础上确定基线。其次是良好的结构体系，在设计软件系统时良好的结构体系可以从非常大程度上降低需求所带来的变更。所以在设计时一定要制定出符合情况的体系结构，在设计系统结构时首先要考虑的要数系统的灵活性、可扩展性、健壮性，这是一个良好的架构所必须的特性。想要设计出高可靠性的架构设计模式就是必需要使用的技术，一定要合理的使用设计模式，在系统的各模块间或者模块内部使用设计模式来控制需求变更对开发的影响。

 1.2 需求变更控制

       需求变更往往是不可避免的。需求变更的控制不仅能够在开发前，还能够在开发过程中来控制需求的变更，对需求变更的控制大致能够分为七个步骤。

       其一：变更申请。不管是做什么事情刚開始想要做都要做申请操作。客户首先要做变更申请，仅仅要有人提出变更。我们就须要他提出变更申请。

可是往往客户会在电话中提出变更的要求，这时候的需求变更应该怎样解决呢？当然不怕。客户的变更我们能够转化为文字记录吧，把变更记录下来总能够吧，这样在跟客户交流时就会有凭有据，不怕他抵赖。
       其二：技术审批。审批审什么？技术审批当然是对需求的变更是否可以在技术上实现做出评价。有时候客户提出的需求非常难再技术上解决，这时候就要及时更客户协商所需求有问题。当然大部分情况下技术还是可以满足新需求的。

       其三：工期评估。

新的需求的提出，会不会影响到整个项目的工期。须要将工期、成本、质量都要做一次量化，目的是强迫项目组清楚一个变更意味着什么。这时候对整个项目作出具体的变更工期评估，变更会不会影响到整个项目工期的延误，假设影响到了，那我么就必须权衡利弊和客户沟通对工期的影响，最后确定变更是否生效，假设产品处于着急上线的目的下，需求的变更最好是延迟在更改。
       其四：成本预估。项目需求的变更可能会涉及到新的开发者的增加，没人每天的话都必须支出对应的项目费用，所以必须对项目的成本做具体的预估。预估的目的是为了对需求的变更做进一步更具体的了解。
       其五：分析对产品质量的影响。

需求的变更会不会对原有系统的稳定性、可靠性、安全性造成影响。另外需求的变更须要做具体的測试，是否对測试质量影响较大，会不会导致系统的其它问题。
       其六：风险分析。需求的变更说大了是大事。变更意味着很多其它的功能，很多其它的功能往往意味着很多其它的工作，会面临很多其它的变数，也就是风险会很多其它。需求的变更可能会导致项目组的士气低下。引起人员的流失对项目组造成风险，所以要评估变更的风险。
       第七：拍板，定论。

重要到了拍板的时候了，最后要有人站出来说究竟需不须要做需求的变更，假设要变更一定要客户签字，让他知晓需求的变更。

二、程序编码

       开发编码问题多。

另外非常让人头疼的是在开发开发过程中。开发的程序问题百出，最基本的当数程序的代码问题，在编码过程中编码的效率不高，并且对代码的优化不够完好。

编码最基本的考虑系统的稳定性、健壮性、可扩展性。在使用不论什么对象时一定要记得对对象进行判空，空对象非常easy导致错误，另外要考虑程序的优化。尽量避免多次对数据库的訪问。最好能一次性的查询出全部数据。

最后在遇到新的问题时一定要理清程序开发的思路，对总体的需求有具体的把控，并对开发的思路有清楚的理解，切记不可盲目的开发。一定要理清开发的思路，涉及到相同的问题时一定要使用同一套逻辑，开发的模式也要使用相同的，不能够千差万别，否则会对维护造成负担。

结语

         遇到问题是好事说明自己还是非常不成熟。最基本的是需求变更和程序编码，需求变更是一件令程序猿非常苦恼的事情，困难没有出在开发新需求，而是重复的去改动原来的东西，可能会涉及到理解别人的思路，这就非常麻烦了。由于要跟着别人的编码思路走，非常麻烦。另外从開始开发至今已经做过五六个项目之多了，可是对程序的编码还有非常多地方须要精化，用最少的代码实现最多的功能。