开发过程常见问题

需求变更，需求不清
1）  需求变更

需求变更，不可避免
解决：可以通过配置化，好的代码框架，减少调整量

2）  需求不清

非需求变更，事实上客户没有那么多需求变更，往往是没有把握好客户的真正需求导致返工。
解决：明确需求后再开发，不要猜测需求，需求是由实际业务定的，开发时是A就是A，是B就是B，不要猜测，通过沟通明确。

脚本
1）  直接在sqlserver数据库上添加表、字段、存储过程等
没有数据库结构文档，没有脚本管理。
在测试环境测试通过后，在正式环境部署程序后，频繁发生缺少脚本或存储过程错误的错误。
解决：严格遵守脚本管理规范

2）  每个人都随意修改数据库结构，包括字段、类型等。
导致不一致和数据库结构混乱。
解决：涉及数据库结构更改，统一由专人管理

代码逻辑不清晰
开发思路不清晰，要做什么要怎么做都没有清晰，正确与否靠调试。写的代码无法描述出来。

1. 逻辑缺陷不周全

　　考虑的场景少，可能只考虑一种正常的输入或流程，输入非常正常的情况才行否则出错对于异常数据的录入没有做考虑！

　　解决：要把主线流程，和各个分支都列清楚，考虑周全，逻辑要严密。要周全要逻辑严密一个最好办法就是1234步骤罗列清楚，然后做成代码（存储过程）注释。

1. 重复性代码（复制粘贴）

　　重复性代码太多，开发的时候是做复制粘贴等低级性劳动。

　　复制代码后，改动不完全，这个情况发生的错误非常高！

　　复制粘贴导致重复性代码后，后来需要调整规则或修改错误时，修改不完全，有不少地方还没有改，反反复复的出错。

　　解决：严禁复制粘贴代码，如果存在需要重用，首先考虑是否已经存在相同逻辑的方法，如果没有，则抽取成公共方法。

1. 代码没有规范，个性化代码，没有注释

　　代码太个性化，太随意，且没有注释，时间长了连自己都没有清楚代码的逻辑了，后面维护的时候一调整就出错。

　　解决：严格遵守代码规范

1. 代码结构性差，耦合性强

　　调整一个地方，涉及一大片，而调整的地方又没有评估影响的地方，导致反反复复的出错。

　　解决：减少类之间的耦合性。至于设计方法，可以自己了解设计模式等面向对象思想。

1. 缺少验证，开发完了没有自己测试

　　开发完成后或调整完一个缺陷或功能后，认为肯定不会有错，就不测试了或测试路径不够，就发布了，结果就是考虑不周全而导致错误。

1. 自己引入一些第三方技术，玩技术。如果技术程序有助于提高开发效率和系统功能，可以一起确定后引入。

　　系统开发前就已经进行技术选型，其他第三方技术不能随意引入。

1. 基础数据和数据操作功能：

　　没有做严格输入约束和校验，导致基础数据有问题，基础数据有问题，导致整个系统都存在问题，甚至无法跑起来。

1. 写脚本的时候，没有事先测试

Sql脚本存在缺陷，甚至会存在误删数据情况（灾难）

1. Sql脚本存在性能问题，复杂存储过程没有注释
2. 对用户异常操作没有考虑
3. 灵活性差，不可通过配置解决
4. 程序发布的时候忘了加上或调整配置文件参数
5. 没有按分层思想开发。

界面直接出现sql语句等，或界面的展示出现在业务逻辑层，导致重用性差，调整即出问题

1、  设计考虑不周全引起bug，解决办法需要在设计前期准确把握需求，对于不明确的需求要及时与需求人员沟通，务必把需求弄清楚，不要猜测需求。

2、  数据库设计不周，数据库设计不周全引起的bug，例如数据字典前期在其它表中保存的是数据字典里的值而不是ID，后来保存的是ID，导致后期系统出现bug，解决办法是先把数据库设计好，规范数据库，尽可能少变动数据库关系，对于需要修改数据库字段或关系的应预先考虑修改后可能引发的问题。

3、  权限部分引起的bug，权限体系部分关系比较复杂，开发人员由于不太清楚权限体系部分架构应用，导致在开发或配置时考虑不全引起bug，建议对开发和配置人员做一次权限体系部分架构应用的培训。

4、  参数过长引起的bug，在设计数据表和写存储过程时由于字符定义不够长，而在实际中传递的参数的长度大于数据库定义的长度导致产生Bug，还有就是传递的参数长度大于sql server存储过程的参数长度导致引起bug，对于参数过长问题可以在编写存储过程时考虑周全一点，对于参数长大大于sql server的参数长度可以采用多个参数取代一个参数的方法来减少bug。

管理规范

需求

ü  需求先明确。要做什么，有什么规则，有哪些功能点（粒度小），涉及哪些数据表，操作流、数据流是怎么样的；

如果需求上不清楚，马上沟通

ü  思路先理清楚，1234步骤列清楚再开发，最好作为注释到代码上，事半功倍

架构

模块化、组件化、用户控件化、粒度尽可能的小

重用性高、公共代码、减少重复代码

灵活拼装、可配置、

可扩展性