如何反驳服务端程序员声称SELECT出来的数据直接丢给客户端的代码最好?
程序员文章站
2024-01-17 17:10:58
...
比如我觉得数据有冗余,让他精简一下,不用全部都发出来,还有希望有些数据能经过二次处理的
@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拼好了传给你吧”
呵呵呵呵
————————
正经回复:
如果放在哪会影响程序效率,你们之间是服务调用关系,这个时候如果有数据证明在服务端优化传输后能提高性能、节省成本,可以反驳——如果老板不认为省钱比快速上线重要的话你也没辙,是不?
如果对性能没影响,那么一定程度上可以理解为过早优化,这时候更多的矛盾在于你们的工作量和工资之间的比例关系,我认为这个问题需要上级来解决。
那我觉得发请求最好写中文,比如
?"给我客户的数据,谢谢"
就是这样的啊、、、、、、下一篇: php页面显示内容后延时跳转