@kvkboy 低代码平台前面 @matrix67 有提到，可以参考一下 https://v2ex.com/t/681272
我之前的问题 https://www.v2ex.com/t/639230，也有很多朋友回复推荐相关产品。

@laminux29
1. 界面的问题，前端模块是需要不断开发的，UI 设计还是不能缺少，算是可拖拽系统的持续扩展吧，美工的创造性不可取代，当然不是只有 draw.io 一个前端样式的。
2. 逻辑层的模块是业务解耦的，如果需要过滤一部分输入数据，是否可以扩展开发相应的算法或者策略的逻辑模块，再拖拽到系统上？
3. 同 2，逻辑模块是可以扩展的，根据具体业务需要，如果是大并发情况，缓存，分流，流数据处理等操作是否可以抽象成逻辑层的可复用模块？

我也不知道可行性的，我想象不到所有场景。逻辑层的可拖拽还是个空白，我现在是想当然了

@Mark24 我也找过一些拖拽的系统，确实前端拖拽很方便，但是逻辑拖拽和数据拖拽就不好办了，如你所说第 3 条所所，注入代码是不行的，这部分代码也需要可以拖拽，让设计者拖拽一块逻辑绑定到前端组件上才完成的可拖拽。确实逻辑可拖拽太抽象了，是否有可能，把程序员一个字符一个字符的敲代码来表达业务逻辑的过程，改成拖拽逻辑模块，这个抽象的过程是否可行，是否有意义（提高效率），我也不是很确定的……

@miv 确实我忽略了数据处理的难度，这里我想当然了，不过现在拍脑袋先想一想，看这样是否可行：
将数据处理的流程抽象成逻辑模块的拼接，处理完数据再绑到前端，就是说前端绑定的逻辑模块使设计者自己通过更细化的逻辑模块拼凑的，换句话说，拖拽者拖拽的使逻辑，好比程序员敲代码，换了一种形式，改成拖拽逻辑模块了，最粗粒度的拖拽是，这是订单模块，这是支付模块；最新粒度的模块是打回原形，程序员敲代码了。

看到标题有同感，好奇会有什么解决方案，我点进来看评论，没有寻找到好的办法。

有提到 API 文档工具的，这类工具是前端向后端要接口的时候比较好用，好像没有解决楼主所描述情况的痛点。

系统不断开发到了后期，后端开发人员不清楚自己写的接口用在哪些具体的前端模块 /功能点上。

对于 web 项目 F12 是可以，不过是整个页面的调用，没有对应到页面具体模块 /功能，而且移动端页面也不好调试找接口，F12 感觉也不尽人意，总会有好办法的感觉。

借楼再问：是否有什么工具能让后端开发者从界面模块 /功能直接查到后端接口调用情况？

总结、反馈

总结：
1. 抽象、解耦、分层、细化；
2. graphql ；
3. 数据库的设计方面；
4. 参数动态调整，不写死；
5. 重构；
6. 设计模式

------------------------------------
反馈：
1. 问过‘有经验的’同事，也简单一提说分层，是个方向，但是自己还是没明白，再继续查查了；
2. 有简单查了一下 graphql，目前不明觉厉状态……
3. 设计模式看了这个： https://www.cnblogs.com/susanws/p/5510229.html，较之前多了些理解吧；


------------------------------------

ps：刚完成一个项目，领导让我们复盘，总结一下怎么才能不出现干一年 bug 一堆的问题，就从自身想了一下，代码大部分是我写的，功能明确，就开始写接口，需要什么数据就从哪里获取数据，一个个接口写下来，功能也实现了，没有什么解耦啊的概念，到后期就是无尽的 bug 模式，肯定是自己哪里做的不够，需要提高才是，就这里来问一下，想必有前辈、老司机、同道中人会指点迷津，也许我面临的问题不是一两句能说明白的，仙人指路也可以，我去查查看，结合代码说明可能更清楚吧，那么届时留个博客地址什么的，我们去观瞻~

pps: 需求变更可以控制，但是不可避免，怎么控制的技巧还在这里之前，这里先讨论需求确认变化之后我能做什么，所以这里是讨教怎么写代码或者设计代码、架构什么的，才能在需求变更后更灵活的实现，眼下我想先提高自己这方面的能力吧。

ppps: 总结是我目前状态和能力能理解的各位的表达，也许有老司机的表达我现在还体会不到，没事，以后会来挖坟啃的。反馈是看到各位的意见和建议，立即行动起来的反馈，希望能有建设性和可执行的意见哦。

就给前端提供接口，一般业务，多个后端程序员，我写的多一些。我的感受是需求怎么实现都可以，各有各的写法，高明的，菜鸟的，需求不变都可以交差，感觉差别在后期需求不断变化之后，就有差距了，高手们总有些针对这方面总结的一般而言的经验之谈吧，怎样的架构可以降低需求变更成本？以不变应万变（理想情况？），或者不能抽象到一般情况，劳烦举例一二说明里面的门道也是好的。或者有同感的分享经历，没杀过猪也见过猪跑了，也能增加几分阅历。在下洗耳恭听，望各位不吝赐教。

@chenwl 赞同， APP 是社交的一方面，不是全部。

@wizardforcel 是的，社交是多方面的，社交 APP 只能满足一方面的需求吧，不放弃其他方式的社交。

@Greenly 哦哦，是的，这里要补充一点，亲密度可以不醒目的显示出数字，可以用颜色啊声音等，感性的度量，来衡量好友是否可以看到更隐私的信息，发布信息的时候也是，用颜色表示要发布的信息是否要更隐秘，更贴近心情，而不是数字

@kaktos 这个确实是耳目一新的一片世界呢

@alex321 还没有上升到这个高度的感受，只是从自己的使用过程中细细体会，发现让自己更舒服的需求。

@techmoe 不求大发展吧，能满足一部分人的需求，提高某类 app 的使用舒适度，也算进步，希望自己手机的 APP 用的顺心如意一些。

@yeluozhiqiu1981 最开始的地图是10X10的，但是玩家反馈太大了，打好几枪都打不到，这样上手难度确实有点高，所以改成了6X6

排名是要加的，现在想到的排名有这些：
1. 经验
2. 金币
3. 最佳战绩
4. 平均战绩
5. 战斗次数
6. 飞行距离
……

@yeluozhiqiu1981 不错，总共有可能的机头位置只有24个，每次被敌机击落的几率是1/36（我会说我被电脑击落过么……）其实细研究下去，可以总结出几套战术思路，就是最开始几枪的落点和分布，怎样才能更有效的排除错误位置和朝向，这样就能更快速的打中机头。

另外刚修复了个说明手册指令：
?h
欢迎提修改意见：P

http://justkids-splendone.c9.io/topic/3/%E8%AF%B4%E6%98%8E%E6%89%8B%E5%86%8C-%E9%A3%9E%E6%9C%BA-v1-0

@yeluozhiqiu1981 哦~~~！！~~！！高大上的工具啊

@openroc 其实是自己写的的H5页面作为图形页面的？相当于点了一个图文信息，打开一个微信内置的web浏览器里看图形。
嗯嗯，这个可行的，但是需要更多的资源，用到图形和声音的要素，以后会做一个的，先以txt这种简单方式把想要实现的功能流程实现出来

@yeluozhiqiu1981 恭喜你打下敌机！

PS:这里原来可以回复图片啊！我还费劲地改头像发订阅号的二维码……

@adubi 我搭的论坛挂了……数据库好像找不到原来的数据了，我的说明手册贴没啦 T T