应该怎么与这位同事(程序员)沟通?

2015-01-13 16:30:17 +08:00
 yuankui
事情是这样的
我和另外一个同事在做一个APP服务端,用的是spring-mvc(由于要尽快发布,因此各个模块的实现较为粗糙)
登录(验证)模块是这位同事做的,今天我简单看了一下,实现方式是要求客户端每次请求,所有的请求都带上用户名密码,然后有个入口来验证这个用户名密码(查询数据库),然后再交给后续的流程处理。
是的,这里的问题很多。我就提出了不能每次请求来都查询数据库

我:同学,你这个验证模块是每次都要查询数据吗?
同学:哦,是的,(然后他好像发现这里是有问题得了),现在写的比较简单,我后面再搞一下
我:你打算怎么搞
同学:加个缓存吧
我:那直接用session呗,session不就是一个缓存吗?
同学:手机端又不是浏览器,怎么会有session
我:手机端也可以有啊,你让客户端往http请求加个cookie就好了啊
同学:那这么说客户端就麻烦了,有些客户端就不想写,你不能强迫客户端
我:这有什么强迫的,就set cookie,调个函数就完了,有什么问题吗?
同学:算了,我还是自己写个缓存吧
我:session不就是缓存吗?你何必自己造轮子呢?而且这里面有很多问题你要考虑的
同学:呵呵,你想多了,没那么复杂的
下文略。。。。

我真的想多了吗?
其实我的目的就是劝这位同事不要重复造轮子,应该是我说话的方式不对?请问该怎么跟他沟通?
9658 次点击
所在节点    程序员
84 条回复
Havee
2015-01-13 17:34:19 +08:00
@yuankui 两个人的事,最好处理了
只需要一方去引导下氛围即可。三个人以上的氛围维护就需要制度去约束了
kisshere
2015-01-13 17:34:36 +08:00
@zhicheng 加密在服务器端生成,可逆式加密在so上面一搜一大把,这串code我可以随便暴露给任何人看,你即使能拿到加密后的code能反解它么,我可以用userid和12345的倍数(随机数)来生成密文code,服务器接收到密文后,反解它,看是否是由一个int值和一个12345倍数组成的值构成
soolby
2015-01-13 17:39:29 +08:00
@huigeer 动不动就奏请CTO,动不动就邮件抄送所有高管撕逼,这种事。。。只能呵呵了

作为成年人没有解决问题的能力吗?
turing
2015-01-13 17:39:34 +08:00
不建议用 cookie,可以尝试一下 jwt
zhicheng
2015-01-13 17:40:27 +08:00
@kisshere 可逆加密就是可以反解的。我说的是你用来加密解密的那个密码,这个密码可能开发或者运维都可以看到的。
另外注意一点,加密算法不要随便找一个就拿来用。
yuankui
2015-01-13 17:42:10 +08:00
@turing 谢谢,我了解一下!
learnshare
2015-01-13 17:47:26 +08:00
从技术上讲,这种认证方式不可以用。很多同志喜欢摆工作年限、资历,那能代表啥?

对于技术问题,最好的办法就是一堆搞技术的一起讨论,这样不至于有一个扯淡的结论。

但对于人情面子这种事,还是要顾及一下。毕竟都不是小孩子了,让人家觉得打脸的事应该偷偷摸摸干。
zhicheng
2015-01-13 17:49:39 +08:00
@kisshere 当然对于有些不是非常重要的小项目,我也会偷懒直接把认证信息存到 Cookie 或者 URL 里,不过我用的不是可逆加密算法,而是用的 HMAC 。
liaojinxing
2015-01-13 17:50:19 +08:00
参考github的api设计,https+token
jeequ
2015-01-13 17:50:47 +08:00
看完这文章,感觉你为什么会拿这么点小事来放在这里让大家讨论?

我觉着你们说话的方式,从字面上来说,感觉没有任何问题。

(同学:呵呵,你想多了,没那么复杂的)

这句话证明这位同学有足够信心能够解决缓存的问题了,更何况你们要解决就是缓存的问题吧。

对话应该是这样的:

(同学:呵呵,你想多了,没那么复杂的)

(我:不复杂啊?那行,按你的想法把缓存的问题解决了就行)


楼主是如何回答的呢?
PP
2015-01-13 17:51:53 +08:00
这类状况一般包含两个环节,一是技术取舍,二是沟通技巧。在技术方面,只要不涉及根本性问题,都可以商量着来,必要的妥协也是可以接受的。在沟通方面,您和贵同事都不大擅长,特别是在本事例中,您的责任还要大一些。具体来说,您初始提问的方式带有一定攻击性,“这个验证模块”和“你这个验证模块”的差异还是很大的,后续的一些争论也在不断的质疑对方的技术实力,把贵同事逼到了墙角,导致贵同事没有更多的选择。如果您在与同事讨论技术问题时将重心放在问题本身而不是对方身上,相信与您沟通的对象就不会有那么大的防御压力和负面反应。技术问题没人永远正确,沟通能力提升永无止境,和气一些比较好。
fising
2015-01-13 17:57:04 +08:00
看完了,觉得是楼主自己有问题。
yuankui
2015-01-13 17:59:47 +08:00
@PP
@fising
@jeequ
谢谢,我回去好好反省
lenmore
2015-01-13 18:00:51 +08:00
我觉得这位程序员做法没问题啊,以最小的代价换得性能提升,对客户端透明,这样最好了。

而且项目既然比较赶,现在突然提出这么个需求来,客户端也会有意见,你又怎么去摆平呢?
jeequ
2015-01-13 18:05:18 +08:00
@fising 你就是那位同学?
fising
2015-01-13 18:09:03 +08:00
@jeequ 哪位?
fising
2015-01-13 18:09:45 +08:00
@jeequ 哦,你怎么看出来的。。。。。
yuankui
2015-01-13 18:13:15 +08:00
@jeequ 他不是的,同事不上这种坛子的。
sumhat
2015-01-13 18:20:26 +08:00
论 spec 和 design review 的重要性。
yuankui
2015-01-13 18:23:21 +08:00
@sumhat 好多细节在最初的设计中都是涵盖不了的

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/161779

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX