Mendix客户项目总结

Mendix

于 2021-04-13 13:32:02 发布

阅读量1.2k

点赞数

本文链接：https://blog.csdn.net/Mendix/article/details/115663183

版权

从2005年成立至今，Mendix一直以客户价值为导向精心打磨产品，提升客户、合作伙伴及所有参与方的使用体验。进入中国以来，我们更是以120%的态度践行这一原则。工欲善其事必先利其器，这里的“器”不仅仅在于产品本身，更在于产品背后代表的思维方式，实施合作伙伴的培养与赋能，解决方案架构，项目管理与执行，客户数字化转型的长远的计划与思考等等。只有不断地用先进的理论指导实践，并在实践中迭代成长，才能充分发挥先进生产工具的最大价值，创造多方的共赢局面。

因此，我们会建议Mendix客户针对第一期的开发项目认真地做一次Review及复盘，总结经验与不足，确保在更优化、更深入的理解的基础上去使用Mendix迭代，以期更高的价值。本篇是Mendix一个实际的客户案例的总结，希望能给未来更多的Mendix项目提供参考价值。

项目背景

这是国内某大型企业的数字化项目，由服务商实施完成，项目涉及功能复杂，APP用户数量多（~10000）；项目目前取得了很好的成果，这里我们只分析改进与提升点。

Review目标

Mendix原厂团队针对项目实施与管理方式及上线的APP进行全方位地审核与评估。

Review结果和建议

以下从项目实施方式，应用架构设计，Mendix平台使用及应用质量等方面来分享经验总结。

01. 项目实施方式

由于敏捷开发的天然价值优势，及Mendix平台原生的敏捷支持，无论是客户还是实施伙伴都首选以敏捷的方式进行应用开发。但是，敏捷只是个概念，其落地方式多样及各家的理解不同，项目往往容易进入误区。比如：

敏捷=Scrum=站会？

低代码/敏捷=没有范围，不用计划？

低代码/敏捷=需求可以随时，且不断追加？

因此我们建议：

首先，敏捷的践行方式很多，Scrum是比较流行的一种，但用Scrum方式执行敏捷也不是教条地开例会（站会，Sprint Review，Retrospective等），核心是做好Sprint计划，确保每个Sprint能产出增量的、可交付的产品。这个过程并不简单，需要产品经理，Scrum Master的团队充分协作，而且很大几率要摸索一段时间才能找到企业合适的节拍。

另外，不能简单地将Mendix低代码平台理解为一个开发工具，而且不能认为用了Mendix就等同于敏捷开发。同任何创新性技术一样，Mendix之所以适合敏捷开发方式，是因为其背后的价值观和设计思维符合敏捷的价值体系。世界上没有一蹴而就的事情，Mendix的“小步快跑”理念也不是投机思维，每一“小步”都保证完整、科学，积跬步才能至千里。

**企业把握产品价值与方向 + 服务伙伴项目管理与实施 + Mendix原厂保驾护航 = 打造企业敏捷项目最佳实践，提升数字化弹性**

02. 应用架构设计

快速应用迭代出高质量产品的前提是有优化的架构设计。敏捷开发指导原则中说“最好的架构、需求和设计出自自组织团队”，并不是说整个产品没有架构设计阶段。产品开始每个Sprint执行之前必须要有整体架构和路线图，并做好发布计划。

同时，架构设计应该考虑到弹性与可扩展性。Mendix 建议保持每个应⽤功能尽量精简，⽤⼩⽽⾼效的多个应⽤组成系统，⽽⾮将全部系统功能规划在⼀个巨型应⽤中。

我们建议利用微服务思维进行架构设计：

高内聚低耦合，把强相关的部分，总是会一起改动的部分，聚合到一起，相关性不大的部分拆开，可以参考领域模型设计思维；

粗粒度服务，从业务角度出发对服务进行封装，对外提供粗粒度的服务。

同时，使用Mendix开发复杂的应用，一样需要基于大量的业务分析，与业务充分沟通将专业业务转化为领域模型，并借助Mendix模型驱动开发理念与工具，业务与IT一起参与可视化的模型、程序逻辑、流程流和用户界面设计。

03. Mendix平台使用

Mendix低代码开发平台对开发进行高度的标准化、模块化，降低了开发门槛，大大提升了开发效率。但是这不代表开发者可以不设计，任意堆叠功能，可扩展性、性能问题、安全问题等还是需要关注的。因此，我们建议开发者还是要充分且系统地学习，按最佳实践方式使用（比如性能最佳实践），这样才能发挥Mendix平台的最大价值。

04. 应用质量

应用质量的检查也是我们Review的重点部分，Mendix客户服务部门也专门提供了相关的APP Review 服务。在这个案例里，我们在可扩展性、性能及安全性方面都有不同程度的发现，下面举几个例子。

可扩展性与性能 - 可扩展性/可伸缩性代表一种弹性，随着数据量增长，扩展性差将导致处理能力无法线性增长，造成性能差，延迟多，吞吐量低等结果。

本项目中的问题表现：

从数据库（分批）读取数据量较⼤，拥有复杂数据处理逻辑的微流运⾏缓慢；当前项目中微流里Activity数量在25个以上的微流有超过200个，有些达到400多个，复杂度很高（Mendix最佳实践建议不超过25个);
在循环中频繁写数据库（commit)；
⼀些模块中的 Entities上定义了一定数量的虚拟属性，在处理⼤量数据时可能造成性能瓶颈；
访问频繁的大数据表未添加索引；
本应⽤没有将旧数据存档的设计；
重复的微流逻辑（同模块、跨模块都有）；
微流嵌入了大量Java Action。