早些年，还不能靠道具/DLC 后续收费的时候，实况足球、FIFA 这些年货游戏，就靠「就算功能做出来，也下个甚至下下个发行版本再上」，来整钱。

@mars2023 #18
@zy0829 #22
二维码能推开，前提是腾讯、阿里两家已经垄断了。NFC 领域，都不用有垄断公司，就是住建部或者交通部能有点实权，早就全国一卡通了。

微软在劝粉转黑的道路上，正在狂奔。

双向看不上就没必要继续搞了。当然这说的是干活，对于工作来说，可以当混子，可以趁机搞自己的兴趣（注意如果搞出来的话，产权是归公司的），可以直接走，可以找到工作再走，取决于你自己。

不签字你是爷，签了字你是孙子。

用 IE2.0 —— Chrome ，替代 IE3.0 Edge ，这个行为应该叫什么。

简历写不写都无所谓。要是签了合同的话，面试的时候一定要说清楚。没签过合同的话，面试说不说就无所谓了。如果不挑刺的话，一个月就跑只会认为你商家公司坑。要是挑刺的话，一个月以上的空档期，也是有影响的。

@zhch602 #72 你有看楼主的描述吗。

这里面绝大部分的回复，压根就是看了个标题就开始回复。甚至就是标题都没仔细看，标题已经点名了，这不是让开发去熟悉业务，是让开发兼岗或者直接转岗去当客服。

不闭门造车，不是让你走向另一个极端去先当客服。程序的业务，也是个技术活，要做什么、什么能做、什么不能做、哪些先做、哪些后做，这都是要有一定能力才能做的。这是产品经理或者产品负责人的事，开发要想熟悉业务，首先要找的是他们。如果开发越过产品负责人去直面客户，熟悉到的业务大概率是「苹果掉了之后该往天上飞」这种正常情况下应该被过滤掉的业务。

另一个事实是，回复里面相当一部分人，是打心眼里瞧不起开发和产品，表面上说着熟悉业务，背地里想得是「只要给客户当好孙子，敲代码的开发，和决定做成什么的产品，就都是他的孙子」

核心开发要是上一线直面客户，就俩结果，要么客户上来就被开发气跑了，要么开发无脑接了一堆客户的要求最后项目、开发、以及客户那边的对接人全部跑了。就算光看人事安排这一点，把开发直接敢到客户那里之后，产品经理就被架空了，同时这个领导自己连开发加业务也都不会去管，架空别人但自己又不接，这是重大的人事问题。你这领导，纯沙雕无疑。


@NoobNoob030 #1
@helllkz #2
@Corrots #3
@fmumu #4
@James2099 #5
@xxxyy2y #6
@godloveplay #7
@stinkytofu #9
@opengps #11
业务跟客户的原始需求，是两码事。

@flynnlemon #120 年轻人，购买力的标杆从来都是生活必需品，以前是粮价，现在是房价。

@fish3125 #19 这个选项，貌似是移到 Office 自己的选项里面了：Office——选项——保存，第一个复选框。

当然本质上，网络不好的情况下，就算是没丢数据，频繁的处理合并冲突也是超级烦人的事。所以如果没有多人/多终端编辑的需要的话，还是要关闭 Office + Onedrive 的在线编辑。以前是在 Onedrive 设置上关闭的，现在不知道在哪里关闭了， 狗日的 Win11 Onedrive 设置上没有这一项目。

@lisxour #9
@Infinite2K #13

Office 是先本地暂存（不是全文档，是“修改部分”）到 Office 上载中心，然后再上传，网络问题只会影响上传，不会影响本地暂存。OneNote 具体机制不了解，但大体上也是先本地保存再跟服务器同步，因为网络不好的时候，它会发生同步冲突，然后让你自己去选择保存哪一项目。这种分布式同步问题，想保持一致性没啥难度。当它丢数据的时候，往往就是用户选择丢数据，比如说 OneNote 选择了服务器版本，比如说 Office 在冲突的时候不仔细看直接确认了“清楚本地暂存”，比如没等上传完毕就强退甚至禁用 Office 上载中心。

跟微软连线不稳定的时候，开启自动保存会相当难受。但是只要你别做骚操作，两周之内是不会丢东西的。

@pandazhong123 #72 如果是面向传统前端的标准 URL ，或者 RESTful ，或者是公开接口，那么应当是 book-detail 。URL 在部分场景（比如 Windows IIS 当服务器），是不区分大小写的。下划线则是在部分字体或者 UI 下，容易看不见。如果仅面向当前项目的前端，那就看团队习惯，对于全 Java 系开发来说，bookDetail 更舒适。

@lambdaq #65 会跟新增 「 user 」 的 「 delete 」 冲突。

关于 RESTful API 如何表示领域行为方法，这个我也是抄别人的，就直接贴链接了。
原文（也是翻译老外的）链接： https://mp.weixin.qq.com/s/251ql2WhDi-InUgVtIQ6_Q
我看的是转发： https://blog.didispace.com/use-ddd-design-rest-api/
请注意，这也是违反 RESTful 的，需要有全局约定才能这么做。他并不存在冲突，因为 PUT /resources/{id}/action 是专有的 URI （原本的 PUT 因为是修改指定资源，其 URL 形式必定是 PUT /resources-level1/{id}/resources-level2/{id}的形式。）

关于 REST 的参考： https://restfulapi.net/resource-naming/

关于单复数的部分，需要纠正，REST 接口，资源必须定义成复数，因为单数名词有特殊含义，他是定义可选的前置分组的。当然，这是个认为约定，不是强制规定。如果约定好，全部单数也不是问题。

再纠正一下 14 楼的回复。「如果是一般动作，那就是 POST /user/{id}/%动词%，比如 POST /user/{id}/disable 。」是错误的。应改为「如果是一般动作，那就是 PUT /users/{id}/%动词%，比如 PUT /users/{id}/disable 。」因为这个动作，是对当前资源的修改，不是新增资源。

@theqiang #28 按下 SHIFT+ENTER 换行，结果直接提交回复了，下面一楼才是完整回复。但是好多人好像只看到我这个半回复，没看下面的完整回复。

@hidemyself #29
DELETE /user?phone=xxx 跟「根据用户手机号查询用户列表」，是一样的套路。

@george2077 #44 /user/add /user/delete 并不符合 RESTful API 的设计原则。RESTful API 的基准原则就是，URL 仅表示资源路径故只能是名词或者等效于名词的东西，GET/POST/PUT/PATCH/DELETE 这几个 method 才能表示动作。所以只能是 POST /user ，DELETE/user 。（单复数我忘了，好像应该是复数形式。）如果你用/user/add ，最经典的问题就是 @Pastsong #27 提到的 /user/{id}冲突。但他的 /user:add 这样也不对。

严格 RESTful API 有一个经典缺点，就是 GET/POST/PUT/PATCH/DELETE 动作不够，无法表示其他方法。当你采用领域模型来设计接口的时候，这个确定会更突出，因为领域模型在增删该查之外会有大量的其他行为方法。这个在后面单独说。

@lambdaq #50 根据 ID 批量删除：DELETE /user?id=xx,xx,xx 。根据条件（批量）删除：DELETE /user?condition=xxx