CMMI5-PI实践域经验之谈（软件工程如何高效开发）

本文链接：https://blog.csdn.net/qq_20466509/article/details/132369526

CMMI5-PI实践域经验之谈

引言

如果把一个普通的web应用系统拆成多个维度，可以把数据库看作二维平面，代码逻辑是数据库的投影。所以数据库的设计的好不好是一个系统的基础，决定一个系统的维护难度、业务理解的程度、系统的承载能力。所以无论是新项目还是二手项目接手的第一件事就是设计、分析数据库表，规范字段名称，这其实也是一个“吃”业务的过程，消化好了业务才能有力气干活。

数据库设计的重要性

下面是一个网盘数据库设计错误的例子：如下图所示，资源表定义为存储各个用户（机构）对资源的拥有情况；关系表是软件对资源表的关系存储表；实际业务表达的是一个资源可以被多个用户拥有，所以软件表和素材表对资源表应是一对多关系，但是设计人员却增加了中间表存储关系，使其变成多对多关系。

真实项目的ER图

以上设计有两个缺陷

资源表对软件表的关系由1对多设计成多对多，表现为开发人员对业务理解不充分，增加了代码复杂度和数据库查询压力，当无法面对亿万级流量数据时，系统将不得不重构增加搜索引擎构件重构数据查询逻辑,数据库完全可以支撑的功能却因为设计导致系统增加了巨大的额外成本。
素材表其实与软件表处在同一个业务维度，但是却没有中间表，风格不统一，后续代码维护人员容易产生困惑。处在同一个维度的业务通常是有细小的业务差距且是容易变更需求去除差异化的，实际上我们也遇到了，当底层设计不一样时我们只能选择重构或写一堆复杂的代码使业务看上去达成了，很不幸我们面对快速的迭代需求选择后者，这对后续接手维护的人来说及其不友好，至少要浪费他1亿个脑细胞。

优化建议

去除中间表，在资源表中增加关联素材表、软件表的字段，由于素材表、软件表存在很多共性的字段，比如版权、作者、创作时间等，可以将此2表合并成1个表，加一个 resouce_type字段来区分资源类型。这样大大的降低了代码复杂度，提高了开发效率。
将素材表中的resource_id字段去除，根据上面建议1增加关联字段，将相同功能的模块中的表设计一致，这样的代码的风格才能统一。

制定标准字段库，这样才不会出现错误单词，蹩脚英文，这样才能走向国际化。

前后端并行办法

我在京东数科工作的时候，我们后端是照着mock平台上面的接口开发接口的，直到进入测试阶段我才惊奇的发现已经和前端联调过了。在京东数科工作是我唯一一次感觉自己渺小的像一颗螺丝钉一样，可有可无，但确是让我我成长的最快的一份工作，在这里我见识到数字化运维，见识到了自己参与的项目被流量冲洗，看着炫酷的控制台，才感受到我是在参与制作一个产品。

经验之谈

也许很多经历丰富的工程师都明白以上开发思想，但是从思想到执行是2个完全不同的领域，执行涉及到职权划分，涉及到不同实践域的执行人员安排。

开发流程和使用工具的本质是提升沟通效率，比如关于低代码开发环境mock平台的使用，前后端对于低代码生成的增删改查套路都非常熟悉了，如果前端拘泥于没有写mock接口那就是愚蠢了，因为这相当于浪费时间在多于的工作上面。

以上开发思想及流程只能最大限度的统一风格及提高沟通效率，但也不能万无一失。如果项目负责人没有十年扎实的开发经验，在数据库设计，mock接口时还是多和工程师沟通一下吧，听取下他们的意见，可以开一个项目研讨会，这也是帮助工程师理解业务不错的机会。为了避免烂代码，一定要团队成员执行业内成熟的开发规范，并定期执行code review以提升代码质量，避免弯路。

关于code review（代码评审）的内容及执行的时机这个因项目而异，就比如我在银行参与的项目，为了保证系统安全一个jar包及开发辅助工具的使用，都需要提交申请，这也属于code review的过程。