变量
函数
分支
循环
辅助一些基本的数据类型

脚本语言就这么些东西，唯一的不同的就是语言语法在现在看来很奇葩： 比如说 bash

我觉得 bash 脚本这种东西一行可以写完的就用 bash， 写不完的尽量用 Python 之类的现代化语言

个人简单使用那写一个 rsync 脚本就可以了

团队使用用 CI 工具持续集成

@caoyouming 随机数和加密算法一样，最好不要用自制的，使用全球公开并且认可的算法

@reus 需求就没有稳定这一说，只能说有个大方向， 具体细节还是要在开发者不断改的

@caoyouming 还真有人使用自制的随机数生成器？

@reus
这个东西不是我定义好前端就能实现， 产品就能满意的， 一个复杂的流程必须要和前端还有产品沟通，做演示，提意见，一系列操作之后，你原来定义好的接口可能就面目全非了

所有人，包括产品经理都是在项目进行中不断学习，不断深入理解需求的，你提前把接口都定义的前置条件就是：

1. 所有人都对需求有 100%的理解
2. 后端定义的接口前端一定可以使用而不需要考虑前端使用的复杂度

但是上述的条件都是不成立的
第一点我已经说过了
第二点后端要考虑前端人员的技术水平以及项目进度。有时候前端觉得这个接口不符合他的使用习惯或者是难以使用， 后端应该尽可能的提供帮助来解决问题。


按照你的说法， 需求不变的情况下，前端因为其他问题需要后端改接口是不能的。因为后端接口只依赖于需求，不依赖于前端。
但现实情况是：
1. js 很垃圾， 后端可以简单实现的功能 js 要写一堆，依赖一大堆
2. 开发人员水平参差不齐，有些后端认为很简单的实现对于和你对接前端来说很困难

我们要做的就是接受这种现实，不是说吐槽后端不行或者是前端不行，而是说大家作为一个团队要及时沟通和相互帮助来完成我们的项目。

@reus
1. 依赖注入不能帮你解决依赖过多的问题
2. 前端不止需要知道接口会 doX， 他还需要知道有那些额外的参数来触发额外的钩子，埋点
3. 代码职责太多的表现就是在参数中有许多 flag

@reus
只有非常简单接口可以这么做

如果这个接口有前置接口依赖，那我是不会提前定义的， 我会和前端实时沟通并更新接口

@reus
对于用户端的接口来说， 需求就是 doX 并发送短信

对于后台管理端的接口来说， 需求就是 doX


要理清楚需求，哪怕现在用户端和管理端的接口需求一样， 也必须分开， 因为这些都是可以预期的二者会往不同的方向发展

@reus
那安卓用户要推送消息并且同步记录到数据分析平台怎么实现？
你这个接口的职责有多少？
依赖关系有多复杂？
单一职责原则忘记了？

@Chingim 字段名称和我说的数据库结构是两回事

数据库结构是你的表结构是怎么设计的

如果把表结构对于的实体类直接返回给前端， 那么前端拿到的数据会有很多冗余，并且嵌套层级非常深


我一般的做法就是按照 UI 图单独定义一个 Response 类，返回一个扁平的对象，这样做的好处
1. 网络传输的数据少
2. 客户端只依赖于 Response， 不依赖于我的数据库结构
3. 前端写起来简单一点

@reus 代码生成了解一下， 本来把数据库的结构暴露给前端就是一个很 sb 的事情

@reus 那用户端的和后台管理的对于 事务 X 的定义是一样的吗？

接口：

/api/doX


前端用户执行之后需要发送短信通知


后台管理执行之后不需要


一个接口如何实现这两个功能？

@Chingim 套一个 DTO 的事情

@reus 不好意思， 我们多端还真是多个接口的， 我们只需要保证核心的领域逻辑不变， 适配任何端都是可以的。

至于你说的 web 和页面耦合， 我这套接口就是给 web 页面做的， 只要由这种需求，那么我也会把 xxx 前 返回给前端， 因为类似小程序你要改 UI 还需要重新发布。

@reus 就一句话 多个接口怎么保证事务？
后端把 post 拆分为 post1 post2 post3， 前端怎么做事务？

uniqid ([ string $prefix = "" [, bool $more_entropy = false ]] ) : string
获取一个带前缀、基于当前时间微秒数的唯一 ID。

uniqid 本来就是基于时间戳的， 所以你说的

打算时间戳+截取几个 uniqid 字符

不成立