@qiayue 请问这个是啥 App

楼主还是太年轻，可视化编程早就出现了（看看 http://coolshell.cn/articles/11094.html ）。国内大一点的 ERP 厂商基本上都有一套通过拖放业务组件生成业务代码的工具。印象中几年前普元的 EOS 有一套完全可视化编程的工具，就连 if 这种流程也是通过拖放组件来完成的。。。如果用在稍有点规模的项目上，这开发效率可想而知是有多酸爽啊。。。我用鼠标拖个组件并且配置（连接）各种参数的时间，估计够我敲百来行代码了。所以你去实际体验下这些可视化编程工具，就知道为什么不普及了。

function A() { console.log.apply(console, [].slice.call(arguments)) }

1. 远程 sshd 改完配置重启了吗？
2. 本地私钥是这个 /Users/fourstring/.ssh/hexo 对吗？

@adv007 换成声音就是分答或者值乎呗

哈哈，回到大学 BBS 的既视感

好吧，看到楼主的 ID ，请忽略楼上的疑问

看到黄海均的头像，你们是「职人社」的？

国内的暂时没找到，国外的有这些：
- https://www.bitrise.io
- https://greenhouseci.com

@dahvlh 几年前就在那了

一点小挫折而已，算不上悲惨，放正心态最重要。 3 就不要选择了，你是嫌在研究生阶段被老板压榨得还不够吗？可以暂时选择 4 或者趁这段时间好好提升一下自己的技术能力，等答辩后直接找社招吧。当年我们一个同学和老板处得不好（听说），答辩直接不让参加，阿里巴巴的 offer 也黄了。然而这也不算啥。

- 既然选择了结构化的数据传输方式，当然就是按照业务逻辑来建模数据。只要符合业务逻辑语义，数据嵌套多少层都没有问题；
- 如果产品目前只有一个端，由前端驱动 API 设计并没什么问题。道理很简单，由需求方驱动，合作会更容易进行。人家要什么你就提供什么，这样前后端集成起来就快了。如果后续还有其他端需要接入，可以提供新的统一 API ，也可以继续给每个端提供独立的 API （还是由各个端驱动）；你可能觉得这样就不那么通用了，然而过早设计通常并没有什么卵用，特别是在快速迭代的项目，几个月后接口可能都面目全非了；预留一定的灵活性就可以了，毕竟产品快速上线才是第一要务；
- API 不应该和后端资源（特别是数据库）紧耦合。 API 对于后端来说就是一个 View ，对于相同的资源，后端应该可以为不同的端提供不同的 View （ API ）。「因为数据太多，需要插入很多表，如何保证数据一致性？」这个问题和 API 设计完全没有关系，恰恰说明你设计 API 的思路还是「面向数据库」，你应该恨不得把所有 API 都设计成数据库的 CRUD 吧。然而你最终提供的 API 不应该和数据库结构（知识）有半毛钱关系，要不以后调整数据库表结构了、要分库分表了、要换数据库了、甚至不用数据库了，该怎么办？改 API 吗？
- 把你提供的 API 当作产品一样对待，你就知道该怎么做。满足用户（ API 调用方）需求、用户用得爽的，才是好产品；
- 楼主表面上提了个技术问题，实际上是对对方「想要主导开发，而且比我要受到老板信任」感到不爽。抱怨无用，多互相沟通、多互相学习、自我提升才是正道。

@ragnaroks 怎么无法提交文件，用 multipart/form-data 啊

要的话肯定不开啊，怎么可能给这种敏感信息

这个坑。。。 mark 一下

因为一直插着循环数很少以为是正确姿势然而健康度一言不合就报警幸亏买了 Apple Care 于是免费更换了电池的人飘过。

你用的 MIT 协议，其他人是可以随意修改甚至出售的。

和楼主一样的原因断交了一个月，没法补，看来还是有不少人躺坑了