工作杂谈之说说工作中的二宗罪

       博客开封了，有段时间没有写过技术文章了，前段时间工作太忙，几乎没有时间去反思工作，虽然搞的东西不是很困难，但是需要耗费很多时间去熟悉新的东西。主要是在工作中需要使用到微软开发的新框架SOLFramework，它是由微软为远洋地产量身定做的MVC框架，需要在该平台基础上开发导致了很多后续的麻烦。

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

 一、需求变更

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

 1.1 开发前

        其一：减少需求变更。想要较好的应对需求变更，开发前的工作是相当重要的，也就是说在开发前就应该预见性的看到会有的需求变更的地方，及早的反应解决可能的变更点。这里说的并不是去规避需求的变更，其实试图去规避需求变更本来就是错误的想法，需求变更是很正常的问题，虽然可能会对项目的开发有影响但是它是不可避免的问题，在需求变更时往往是提出新的需求，新增新的需求，这就会导致开发时间及成本的增加，所以一定要在开发前预见性的解决需求变更点。另外需要做的是在开发前要尽量的完备需求，建议开发人员或者设计人员采用原型的方法启发客户思考功能需求，让客户和BA共同思考制定需求标准。
        其二：规范化及合理化的设计。在开发前制定需求文档时一定要注意需求的完备性，所以很重要的一点是在需求制定的标准。而且在整个开发过程中需求说明书是开发人员和客户之间的重要接口，所以需求文档的制定一定要具备完整性、一致性、基线控制、历史记录等特性，在制定需求文档时一定要将文档交付给客户审阅，在客户满意的基础上确定基线。其次是良好的结构体系，在设计软件系统时良好的结构体系能够从很大程度上减少需求所带来的变更，所以在设计时一定要制定出符合情况的体系结构，在设计系统结构时首先要考虑的要数系统的灵活性、可扩展性、健壮性，这是一个良好的架构所必须的特性，想要设计出高可靠性的架构设计模式就是必须要使用的技术，一定要合理的使用设计模式，在系统的各模块间或者模块内部使用设计模式来控制需求变更对开发的影响。

 1.2 需求变更控制

       需求变更往往是不可避免的，需求变更的控制不仅可以在开发前，还可以在开发过程中来控制需求的变更，对需求变更的控制大致可以分为七个步骤。
       其一：变更申请。无论是做什么事情刚开始想要做都要做申请操作，客户首先要做变更申请，只要有人提出变更，我们就需要他提出变更申请。但是往往客户会在电话中提出变更的要求，这时候的需求变更应该如何解决呢？当然不怕，客户的变更我们可以转化为文字记录吧，把变更记录下来总可以吧，这样在跟客户交流时就会有凭有据，不怕他抵赖。
       其二：技术审批。审批审什么？技术审批当然是对需求的变更是否能够在技术上实现做出评价，有时候客户提出的需求很难再技术上解决，这时候就要及时更客户协商所需求有问题，当然大部分情况下技术还是可以满足新需求的。
       其三：工期评估。新的需求的提出，会不会影响到整个项目的工期，需要将工期、成本、质量都要做一次量化，目的是强迫项目组清楚一个变更意味着什么。这时候对整个项目作出详细的变更工期评估，变更会不会影响到整个项目工期的延误，如果影响到了，那我么就必须权衡利弊和客户沟通对工期的影响，最后确定变更是否生效，如果产品处于着急上线的目的下，需求的变更最好是延迟在更改。
       其四：成本预估。项目需求的变更可能会涉及到新的开发人员的加入，没人每天的话都必须支出相应的项目费用，所以必须对项目的成本做详细的预估，预估的目的是为了对需求的变更做进一步更详细的了解。
       其五：分析对产品质量的影响。需求的变更会不会对原有系统的稳定性、可靠性、安全性造成影响，另外需求的变更需要做详细的测试，是否对测试质量影响较大，会不会导致系统的其他问题。
       其六：风险分析。需求的变更说大了是大事，变更意味着更多的功能，更多的功能往往意味着更多的工作，会面临更多的变数，也就是风险会更多。需求的变更可能会导致项目组的士气低下，引起人员的流失对项目组造成风险，所以要评估变更的风险。
       第七：拍板，定论。重要到了拍板的时候了，最后要有人站出来说到底需不需要做需求的变更，如果要变更一定要客户签字，让他知晓需求的变更。

二、程序编码

       开发编码问题多。另外很让人头疼的是在开发开发过程中，开发的程序问题百出，最主要的当数程序的代码问题，在编码过程中编码的效率不高，而且对代码的优化不够完善。编码最主要的考虑系统的稳定性、健壮性、可扩展性，在使用任何对象时一定要记得对对象进行判空，空对象很容易导致错误，另外要考虑程序的优化，尽量避免多次对数据库的访问，最好能一次性的查询出所有数据。最后在遇到新的问题时一定要理清程序开发的思路，对整体的需求有详细的把控，并对开发的思路有清楚的理解，切记不可盲目的开发，一定要理清开发的思路，涉及到同样的问题时一定要使用同一套逻辑，开发的模式也要使用同样的，不可以千差万别，否则会对维护造成负担。

结语

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