防止257性能隐患和功能遗漏的对策思考

 

一、防止性能隐患的对策思考：

 

1、对于看上去就明显有性能隐患的功能，要坚定不移的拆分界面，千万不要犹豫，我们多次证明后面处理很棘手。

 

2、希望产品经理和产品设计人员、开发Leader一起工作，决策每个业务表或业务抽取数据来源在1000亿客户业务规模下的数据量、决策每个列表常用的查询条件和排序字段，这样开发Leader就能提前设计冗余字段、历史数据表、索引、任务调度抽取数据或统计数据。这个事情相当关键，需要产品设计人员推动。

 

3、能用基表的就不要用VIEW。咱们许多开发人员还无法很好平衡简化SQL和SQL性能，所以先满足性能，用基表处理。如果你开发的这个模块中使用了一个很大的VIEW，那么你要坚决花费一定工作量改用基表，也不要得过且过的继续完成功能，否则后患还得在后期做返工修改。

 

4、增加新表、新字段的时候要非常慎重，防止业务满足存储，但写SQL复杂，SQL性能低。

 

5、千万不要共用表结构，慎重慎重

 

6、为了SQL简单编写，为了SQL性能，需要冗余表或字段就冗余

 

7、慎重审视提炼出来的所谓的公共功能，这很可能是代码复杂代码不稳定代码被不断修改的隐患。

 

二、防止功能遗漏的对策思考：

 

1、测试、设计、开发同业务场景视角、同统一标准

 

测试人员和产品设计人员同视角业务场景、同分析方法，尽量多的共用设计说明。这就需要测试人员给设计人员提要求，把测试人员现在分析测试场景、设计测试用例的文档要求融入到现在的设计文档中，做到尽量多的共用。设计、开发、测试三者在过程中各有各道理导致不断开会协商不断返工修正浪费，其根源就在于三方没有一致标准。此举就是为了消除这个问题。此次做设计文档，千万别再重复犯这个错误。测试部门经理得把这件事推动撮合起来。

 

2、设计部部门给全体人先讲清业务需求和流程，时时讲，反复讲。

 

设计部门最好组织全体设计人员、开发人员、测试人员，把业务需求和业务流程讲通，反复讲2-3次，一次根本不起作用。很多人不了解业务，所以也不容易理解代码。

 

3、开发人员学习核心复杂模块、明确学习产物、宣讲/考核/指导

 

设计人员先圈定此番修改工作量大的或者修改复杂的模块。然后开发部门去组织这些模块的学习。开发部门责任到人，每个模块哪几个人一组来快速进行学习产物沉淀。一个组人不要多，2人或3人即可。学习产物有现有模块的实现思路、关键表结构/关键字段/关键VIEW关联关系/关键SP实现思路。

 

4、交叉影响点的搜索

 

我们还屡次遇见这样的问题，也是我们容易疏忽的点，是我们经常返工的点，这些点需要开发部门或设计部门提前找到

 

1〉 一个功能有多入口。这个怎么找出来？找到这个很重要，否则我们修改一处而遗漏更多处。

 

2〉 一个VB函数、JS函数、ASPX页面被多处调用，这个怎么找出来？被跨系统调用的，徐刚那里有清单，上次我给过大家一个。

 

3〉 一个VIEW，很可能被多处调用。如果你要修改这个VIEW，要搜索这个VIEW的全部点，这样才不至于遗漏。

 

4〉 咱们有些表是业务不共用，但过去为了偷懒就事实上共用一张表了，然后用关键字段来判断区分，这类表的关键字段在代码中的判断调用处，需要提前搜索出来，并判断是什么功能。这为咱们不遗漏设计、不遗漏开发、测试也好找关联影响点。

 

5〉 咱们影响点交叉复杂的，也有一部份是被系统开启权限判断、该用户数据权限判断，业务运行参数判断来交叉的。这些代码开发部门根据代码关键字来找到这些代码，判断是什么功能。这为咱们不遗漏设计、不遗漏开发、测试也好找关联影响点。

 

三、防止问题滞后的对策思考：

 

1、提前锁定各模块设计、开发、测试责任人，同一个组的设计、开发、测试坐在一个工位间

 

提前锁定各模块设计、开发、测试责任人，这样可以大家非常有责任的有明确目标的学习自己负责的模块、代码实现

 

不在一个工位会潜移默化产生许多问题，所以坐在一个工位间相当重要。

 

2、部门经理每天早晚询问部门各个成员

 

我们在过往经历中常常会遇到目标清楚、方法清楚，但一做就和之前大家讨论的不一样，经常需要经常重申我们要解决的问题是什么、关键问题是什么、目标是什么、手段是什么。不反复重申，我们就老在自己浪费自己时间、反复绕弯或返工。

 

另外，设计部门经理、开发部门经理、测试部门经理需要每天早上、晚上两次询问每个部门成员的工作进展、目前出现的问题、是否和计划滞后、滞后的原因是什么。及时发现，及时一起分析问题查找问题、给出问题解决方案。这样，部门经理就不会脱离项目。

 

部门经理参加周五PMO项目例会，需要成为标准。