如何反驳服务端程序员声称SELECT出来的数据直接丢给客户端的代码最好？
程序员文章站
2022-06-04 13:45:15
...
比如我觉得数据有冗余，让他精简一下，不用全部都发出来，还有希望有些数据能经过二次处理的
@vczh 的方法是无效的，因为首先产品狗根本管不着服务器端传什么数据，需求变更只会传达到前端，所以这个程序员的做法是以不变应万变，他把数据库直接暴露给你了，所以除非需求要修改数据库，他都完全不用修改任何代码，而如果需要修改数据库，他的修改也非常简单。
这种情况，正确的反驳方式是用海量的请求对服务器端发起DoS攻击，令其不得不缩减传输数据大小和增加缓存来改善性能。
如果你的DoS也不能让对方失去响应，或者你们根本没有这么大的流量，那么说明他的设计就是合理的。那这个问题就只是两个程序员工作量分配的问题了，这事儿应该找你的上级去反映。
任何设计原则其背后一定有其原因，抛开场景谈原则的架构师都是十足的骗子——Ivony。 设计接口时的确有不要太精确地配合前端的需求的动机，为了接口有一定的一般性。只返回前端需要的字段，那么前端增加显示内容就要变更接口；把信息按前端需求格式化好，那么前端变更呈现方式就要变更接口。
当然，接口最小化可以节省服务器带宽，可以为扩展和schema变更留出空间，可以防止前端依赖内部实现细节，这都需要取舍。
此其一。
你今天要求他接口最小化，明天需求变更，你又去找他增加返回数据，你多么被动。
他今天坚持返回所有数据，明天服务器压力太大，他找你商量哪些数据可以砍掉，他多么被动。
此其二。
谁干活，谁说了算，谁为自己的决定负责。你最多尽到提醒义务。他以后发现自己决定错误，想精简接口，你又没有增加工作量，你基本上连利益相关者都算不上。
此其三。 来，服务器端程序员来说话了
这事我们真要具体情况具体分析
1、那个服务器端程序员工作的时候爽不爽，例如我现在很不爽，不是特别要紧的话，我就直接SELECT * 给你了，有冗余的或者需要二次计算的，你自己在客户端去搞，这事关情绪，当然也显得特别的不够Nice~~但是讲Nice的话，是不是有人对服务器端不够Nice呢？
2、这个API有多个客户端或多处在调用，为了照顾通用性，确实直接SELECT出来给你最好，并把结果在服务器端做个缓存，这样一来大家都能调用，由客户端做二次处理。例如你只需要其中3个字段，但其他人却需要5个字段，这个时候你说如何取舍呢？当然我可以把包含5个字段的结果全部缓存起来，当你来调用的时候我二次处理只给你返回3个，但，这个又会涉及到我爽不爽的问题了（其实我是真心觉得没什么必要，无关情绪）……
把一些非核心的计算交给广大人民群众手中的客户端去做，我觉得特别美啊~~ 让产品狗给他上几个需求变更 你就按照他的设计逻辑，让他把口令也这么传到前端，然后在前端判断是否登录成功。 这根本就不是个技术问题。你让人家多干活，人家自然是要反抗滴。说什么都是借口罢了。你要是给人家付加班费，估计就好说多了。 服务端，客户端都做。
所以呢，个人经验是，找上级或者找产品都没意义。关键是你先理解对方为什么要这么做。如果是你，你会不会这样做。双方理解是最关键的。别占着你认为你是对的这条路子一直走。没用的。。。人家的思路毫无疑问也是对的
我做客户端的时候是每次都让服务端尽可能的把数据给我，然后我来分析。除非不好弄，协调一下，对方也会响应。你帮他，他就会帮你。。
所谓开发，也是和人打交道，除非都是一个人开发，那是另一回事。
上面说的比较虚，来点实际点的。
给多数据有什么好处呢？
1.服务端开发肯定方便很多，加字段减字段而已
2.认识的你就要，不认识的你就不要。暂时不需要的也丢弃掉。以后扩展，服务端不用动，只需要你调整就行。否则，两边一起改。这个开发成本不是1+1=2.是1+1>2的。
前面同学说：
DoS攻击的说法，不好意思，没用。多一个字节少一个字节在DoS下没明显的区别。人家DoS的目的是拖垮你，如果没做DoS防御。这个借口什么都不吐，光http的头就能弄死你。
简单可依赖。。
除了一种情况。移动端~~~~移动端区别是非常大的。。流量就是钱。 你可以说：“得了，你不用开发了，直接让我把SQL拼好了传给你吧”
呵呵呵呵
————————
正经回复：
如果放在哪会影响程序效率，你们之间是服务调用关系，这个时候如果有数据证明在服务端优化传输后能提高性能、节省成本，可以反驳——如果老板不认为省钱比快速上线重要的话你也没辙，是不？
如果对性能没影响，那么一定程度上可以理解为过早优化，这时候更多的矛盾在于你们的工作量和工资之间的比例关系，我认为这个问题需要上级来解决。
回复内容：
这对他来说的确是最省事最简洁最有效率的做法，看不出你的胜算在哪，，，@vczh 的方法是无效的，因为首先产品狗根本管不着服务器端传什么数据，需求变更只会传达到前端，所以这个程序员的做法是以不变应万变，他把数据库直接暴露给你了，所以除非需求要修改数据库，他都完全不用修改任何代码，而如果需要修改数据库，他的修改也非常简单。
这种情况，正确的反驳方式是用海量的请求对服务器端发起DoS攻击，令其不得不缩减传输数据大小和增加缓存来改善性能。
如果你的DoS也不能让对方失去响应，或者你们根本没有这么大的流量，那么说明他的设计就是合理的。那这个问题就只是两个程序员工作量分配的问题了，这事儿应该找你的上级去反映。
任何设计原则其背后一定有其原因，抛开场景谈原则的架构师都是十足的骗子——Ivony。 设计接口时的确有不要太精确地配合前端的需求的动机，为了接口有一定的一般性。只返回前端需要的字段，那么前端增加显示内容就要变更接口；把信息按前端需求格式化好，那么前端变更呈现方式就要变更接口。
当然，接口最小化可以节省服务器带宽，可以为扩展和schema变更留出空间，可以防止前端依赖内部实现细节，这都需要取舍。
此其一。
你今天要求他接口最小化，明天需求变更，你又去找他增加返回数据，你多么被动。
他今天坚持返回所有数据，明天服务器压力太大，他找你商量哪些数据可以砍掉，他多么被动。
此其二。
谁干活，谁说了算，谁为自己的决定负责。你最多尽到提醒义务。他以后发现自己决定错误，想精简接口，你又没有增加工作量，你基本上连利益相关者都算不上。
此其三。 来，服务器端程序员来说话了
这事我们真要具体情况具体分析
1、那个服务器端程序员工作的时候爽不爽，例如我现在很不爽，不是特别要紧的话，我就直接SELECT * 给你了，有冗余的或者需要二次计算的，你自己在客户端去搞，这事关情绪，当然也显得特别的不够Nice~~但是讲Nice的话，是不是有人对服务器端不够Nice呢？
2、这个API有多个客户端或多处在调用，为了照顾通用性，确实直接SELECT出来给你最好，并把结果在服务器端做个缓存，这样一来大家都能调用，由客户端做二次处理。例如你只需要其中3个字段，但其他人却需要5个字段，这个时候你说如何取舍呢？当然我可以把包含5个字段的结果全部缓存起来，当你来调用的时候我二次处理只给你返回3个，但，这个又会涉及到我爽不爽的问题了（其实我是真心觉得没什么必要，无关情绪）……
把一些非核心的计算交给广大人民群众手中的客户端去做，我觉得特别美啊~~ 让产品狗给他上几个需求变更 你就按照他的设计逻辑，让他把口令也这么传到前端，然后在前端判断是否登录成功。 这根本就不是个技术问题。你让人家多干活，人家自然是要反抗滴。说什么都是借口罢了。你要是给人家付加班费，估计就好说多了。 服务端，客户端都做。
所以呢，个人经验是，找上级或者找产品都没意义。关键是你先理解对方为什么要这么做。如果是你，你会不会这样做。双方理解是最关键的。别占着你认为你是对的这条路子一直走。没用的。。。人家的思路毫无疑问也是对的
我做客户端的时候是每次都让服务端尽可能的把数据给我，然后我来分析。除非不好弄，协调一下，对方也会响应。你帮他，他就会帮你。。
所谓开发，也是和人打交道，除非都是一个人开发，那是另一回事。
上面说的比较虚，来点实际点的。
给多数据有什么好处呢？
1.服务端开发肯定方便很多，加字段减字段而已
2.认识的你就要，不认识的你就不要。暂时不需要的也丢弃掉。以后扩展，服务端不用动，只需要你调整就行。否则，两边一起改。这个开发成本不是1+1=2.是1+1>2的。
前面同学说：
DoS攻击的说法，不好意思，没用。多一个字节少一个字节在DoS下没明显的区别。人家DoS的目的是拖垮你，如果没做DoS防御。这个借口什么都不吐，光http的头就能弄死你。
简单可依赖。。
除了一种情况。移动端~~~~移动端区别是非常大的。。流量就是钱。 你可以说：“得了，你不用开发了，直接让我把SQL拼好了传给你吧”
呵呵呵呵
————————
正经回复：
如果放在哪会影响程序效率，你们之间是服务调用关系，这个时候如果有数据证明在服务端优化传输后能提高性能、节省成本，可以反驳——如果老板不认为省钱比快速上线重要的话你也没辙，是不？
如果对性能没影响，那么一定程度上可以理解为过早优化，这时候更多的矛盾在于你们的工作量和工资之间的比例关系，我认为这个问题需要上级来解决。
那我觉得发请求最好写中文，比如
?"给我客户的数据，谢谢"
就是这样的啊、、、、、、