qq_32558347的博客

最开始是没有框架的，大家都各玩各的，同样的问题，反复多次在不同的团队解决。 后来大家发现都是同样的问题，反反复复出现，还在不停的被解决。所以提出建立一个公司级别的框架。 但是框架建立后又带来了 新的问题，框架本身要更新迭代。而框架又跑在业务应用里面，框架团队已经尚失了对框架的控制权。因为框架版本的升级要完全由业务团队决定，业务团队同意升级，才能升级。业务团队决定怎么用，就怎么用，可以完全不经过框架团队决定。 第4代框架 应该采用 thin sdk + sideCar模式。 这个thin sdk 跟框架

谈到未来应用系统的体验应该是怎么样的，我自己也做了很多总结和思考，但是回头看华为的ROADS体验是最完整，所以在这里做个记录 即实时（Real-time）、按需（On-demand）、全在线（All-online）、服务自助（DIY）和社交化（Social）。华为要启动全面云化战略，解决如何实现ROADS体验问题。 ...

当前低代码平台大火，按照Gartner的分析低代码平台已经在大规模产生价值的前夜了。但是低代码平台能做什么，不能做什么，还是有很多的误区，或者说大家对低代码的期望太高了。 首先，软件开发是一个精确工程，而人的感知或者表达并不习惯是精确的。这就是为啥低代码平台不那么好用，也不可能替换掉所有的软件开发。 另外一个不能替换的是原因是，在大企业里面。业务部门的人有自己的业务工作，他没有职责去做系统开发的工作，而IT团队，又是职业编码出身，他们又不愿意用低代码平台去开发。所以这里做组织的转型。 低代码平台擅长什

在数字化转型行业，基本上都是大型企业，甚至巨型企业，在这些企业中必然会有集团和产业的分工。集团希望统一，产业希望自主（至于这个原因，后面再做分享）。那么这个平衡点在什么地方？ 集团--保证结果 底层提供逻辑基础定标准、流程、输入、输出 再在上一层提供专业能力能力化、标准化、SaaS化 再在上一层 集团场景的能力和甚至组件 领域IT 关注过程，强调业务可控。保证定制业务过程 结合个人/领域/业务自主性活动/管理过程/结果 SaaS化、能力化、标准化 ...

在当前微服务时代，有大量的系统是独立建设的。每个系统的权限都是独立设计的。这样就导致用户在使用过程中需要申请大量的权限。而且还不知道在哪里申请什么样的权限。集中式的权限系统就呼之欲出。 集中式的权限系统应该满足一次申请，全局生效。也就是说，不要办一件事情，还要在多个系统，多次申请权限。所有系统都应该听从中央权限平台的指挥。 另外从上一节来讲，对用户最友好的应该是ABAC，基于用户属性的权限，而不是ACL和RBAC。 总结一下： 完美的权限平台应该是分成3部分 1.在应用侧由产品经理规划 这个应用

业界对权限主流的有3种 ①ACL 直接权限②RBAC 基于角色的权限 ③ABAC基于属性的权限 其中ACL 从开发者的角度来看是 最友好的，门口设置一个门禁，要想开这个门禁 直接申请 这个门禁的权限 后来发现，不只是一楼入大门的时候有个门禁，上楼还有个门禁，二楼也还有。那打个包吧。让用户申请一次就有，就可以申请到他所需要的权限。所以这时候就要 基于他的角色打一个权限包，让用户去申请。 基于角色的申请确实解决了一些问题，但是有时候角色并不好理解。特别是设计权限包的时候，是有产品经理设计的。产品经理不可

你好，世界。 作为一个十几年的码农，开篇怎么也得 搞个 Hello World吧。 作为一个标准的南方人，一直行事比较低调，也谨记谨言慎行。所以之前一直没有书写blog的习惯。这样导致我的语言和组织总结能力比较差。甚至影响到了自己的工作。 今天决定开始blog，总结和记录自己在技术上的经验。也提升自己的组织和表达能力 从今天开始 希望坚持 每天一篇 ...