--部门开发会议讨论，对目前开发工作的问题分析和诊断，现在看还有参考价值，放在这里。
--2018/8/20
一、开发方面
1、强调面向对象的思想
面向对象的其中一个重要的思想就是数据和操作是放在一起的。在编程中的具体体现就是，对同一个数据对象的所有操作（CRUD等）都在一个类（class）中实现。这带来什么好处？
（1）很容易保持数据结构和操作的一致性。数据结构变了，类的属性就要变，所有的操作都在这个类中实现，而不是分散在系统的代码各处，调整起来自然方便。
（2）有助于避免重复开发。要开发一个新的方法、服务，开发人员拿到这个类后，自然会找有没有类似的方法，在开发工具里就可以查看类的成员方法，也能看到实现代码，方法注释，以便与评估现有的实现是否满足自己的需求，也可以找作者进一步交流。
（3）有助于避免在不同的模块重复开发相同的类。很多数据对象都是跨模块使用买的，比如薪酬模块肯定会用到组织模块中的单位这个对象。基于oo的思想，负责薪酬模块的开发人员在用到单位时，很自然的会想到这个单位是属于组织模块的，肯定在组织模块中有实现，他会直接引用过来单位这个class直接用，而不会重写一个，对单位的一些操作，也会很自然的到单位这个class的实现中去找。
具体讲，我们对相同的业务对象（数据对象）的存取操作，都集中到同一个jar包中，同一个类class中。这样系统的class会大大减少，对象关系更加调理清晰和简洁。更重要的是，能很大程度上避免重复开发，在我们人力相对紧张的情况下，尤其重要。
2、缺乏统一的插件、服务目录的管理机制
现在反映有重复开发，主要的问题是：
（1）别人开发的服务、插件我不知道
（2）别人开发的服务、插件具体功能我不了解
（3）当别人开的类似服务、插件不满足我的要求时，没有进行充分讨论设计，不能将两个人的需求融合在一块。
（4）开发服务、插件时，没有进行抽象提升，没有考虑通用性。
所以我在自己开发一次。
因此，如何统一管理插件、服务目录，如何描述插件和服务，如何将服务插件的变化及时通知到相关人非常重要。
在考虑之前，我们需要问几个问题：
（1）这个问题严重吗？可容忍吗？
（2）指定插件服务（统称资源）描述标准，资源目录，设置配置管理岗，由配置管理岗来管理这些东西是否有必要？
如果以上问题的答案都是“是”，那我们就有必要着手解决这个问题。
3、需要强化规范
现在的问题，界面风格不统一，布局不规范，交互方式各种各样；编码层级，jar包命名，各种服务组件、插件的命名五花八门，中英文结合，看不明白。
（1）命名规范
类的命名，模块的命名，jar包的命名不是非常规范，有拼写错误，有中英文混写，中文缩写看不明白，大小写不规范，缩写不规范，动名词顺序不规范，英文取词不规范，不统一）
可以通过建立字典表的方式进行统一和规范命名。可以预见，我们用的动词，名词总量不会超过50个。
（2）界面规范
目前界面不统一。
配色，字体，字号，间距，分割线，界面响应，提示信息等。
界面元素：应用头（header）、模块导航区，树形菜单，搜索栏，查询条件区，功能标题、功能标题区、数据展示区、表格标题，表格行、表格分页导航区。
配色：不同界面原色的字体颜色，底色，选中时的颜色，鼠标指向时的颜色（grid行，树节点，图标），分割线演的，只读、可编辑数据项，不可用的按钮、图标。
（3）交互规范
由于设计不充分，导致类似的功能，交互方式不一致。建议对每一类交互场景，制定交互规范，比如表格的增加行，删除行，修改行，右键菜单；分级数据的编辑、显示。数据区大小的调整，滚动条，不同类型提示信息的显示方式。
这样做有几个优点。首先，设计人员不必再考虑设计交互方式这种太过细节的东西，节省人力；当设计不足时，开发人员按照规范开发就是，不再纠结，不再作选择题；所有的功能的界面、交互方式都是统一的，降低用户的使用难度，降低培训的实施工作量，提升用户的体验（体验是一致的）。
（4）如何适应不同的分辨率
做产品，要兼容大多数的分辨率。据了解，现在客户（XX）还有 800*600的分辨率。我们要确定好系统支持的最低分辨率，以便在设计界面布局和交互方式时考虑周全。
二、业务设计和技术实现
设计要考虑各种约束，需求约束，易用性约束，可视性约束，成本约束，工期约束，技术约束（开发平台约束），设计理念的约束（简约化设计，平面化设计等等）。根据约束的重要程度、优先级，综合考虑。当发生不一致时，如何进行取舍。
1、开发对业务了解不深不透
由于沟通问题，领域知识的缺乏，开发对业务设计、原型设计领悟不深，知其然不知其所以然，不能100%贯彻业务设计的意图，“发挥失常”。
2、设计与实现之间有真空，断层
设计原型存在设计不足，比如缺内容，缺交互。开发人员拿到后，只能凭自己的认知、喜好进行开发。由于缺乏规范，就出现界面不统一，交互不统一的情况，更严重的是影响开发效率。
3、对客户需求的准确把握
比如目前实施反馈回来的易用性问题，确实是实际存在的，有其合理性，但是与目前的设计思想有冲突。
4、业务缺乏对平台实现能力的准确把握
要了解OSP平台的局限性，哪些能实现，哪些不能或者不好实现。
5、业务设计与技术协商机制
当设计意图不能实现，或者开发与设计出现冲突时，要有仲裁机制。我们要定一些仲裁的指标，比如需求满足度，易用性，平台支持，工作量，进度等。
6、评审失效
对业务设计（功能设计，原型设计，界面设计，编码实现）缺乏有效的评审，导致的问题有很多，比如不能理解设计意图，理解存在偏差，不能尽早发现问题（比如到实现时，才发现这种交互模式不可行，不满足要求，不符合普遍认知，技术不支持或者实现难度太大）。
7、沟通存在问题
现在的沟通频率，沟通方式限制的沟通的效果。
也有开发上没有及时沟通的情况。
8、业务的的职责有点混乱。
比如界面的细节，交互的细节，业务上没必要提。这个交给界面和UI设计环节来做。与技术相关性太大，影响业务设计的效率。通过制定标准，减少这方面的工作量和争执。
冲突协商：
当发生冲突时，我们需要设计一套解决冲突的机制。如果某个设计约束不会对我们的系统造成混乱，不会导致我们的程序更复杂，并且不违背常理，则是“合理”的。反过来说，如果某个设计约束，会导致以下不利发生（优先级从高到低），我们就可以说是“不合理”的：
1、导致系统功能、数据错误或混乱
2、违背大众认知，造成理解困难（需要更多的培训，需要不必要的培训）
3、不符合业务习惯
4、不满足需求（与需求不符，漏掉了需求）
5、增加系统复杂性（加大数据量，判断逻辑更多，功能数增加，功能之间的关系增多）
6、增加实现成本（需要引入新技术，需要更多的时间去实现）
7、操作复杂，降低易用性（步骤增加，数据项增加，用户需要做更多的选择）
8、界面不友好
换句直白的话，就是我们要根据以上的指标，验证一个设计是否是“合理”的。
举例：下面的设计约束，要论证其合理性。
三、测试的问题
我几乎浏览了所有的功能，从功能设置，到界面，到交互、到功能执行。这三个方面都或多或少存在问题。
1、 功能菜单名称 词不达意。有的太大（常见的xx管理，其实就是实现增删改查最基础的功能）、有的与功能不符（命名是查看，进去可以修改）、有的不统一（这里叫A，那边叫B）。
2、 界面不标准，不统一。
3、 交互方式不统一，不标准。
4、 功能还有错误。
测试的侧重点在哪里？仅限于功能性，还是界面、交互、功能性兼具？需要明确。
前提是，测试人员有能力、我们有标准和规范。
