Any technical argument is necessary, even if you put forward a wrong idea, but this argument should stop at technology
今天中午干完饭, 去楼道抽烟, 看到我们产品一个 29 快 30 的大小伙子在那里, 极度郁闷, 卡卡的一根接一根的在那抽烟, 遍地烟头 (估计得抽了有半包).
事情起因是因为今天我们的后台被别人搞了, 衍生出觉得 App 也不太安全, 虽然我们本身是有接口加密的. 但是加密的算法采用的是 RC4 对称加密, 所以密钥是暴露在客户端的, 在拿到我们的包之后可以通过反编译的方式, 获取到加密的密钥
iOS 端针对这个问题, 把整个网络请求的库打包成了一个静态库加载到项目里, 但是这种做法遭到了 Android 端的极力反对 (主要是 Android 端负责人的极力反对). 按照他们的说法是, 安卓把整个网络请求库打包成一个静态库不是很方便
Android 他们的意思是之前上加密他们就不是很赞同, 因为如果有人想搞我们的话, 完全不需要我们的密钥, 也不会通过反编的方式去破解我们包, 基于这一点, 他们觉得这个将整个网络请求库打包的需求成本高、收益小, 做起来很没有必要.
对于安卓说的就算上了加密, 或者他们把整个网络请求哭打包成静态库, 还是可以通过反编译或者其他方式攻击我们的服务器, 这一点我是赞同的.
但是我并不认为这样做没有意义, 对于互联网项目来说, 没有绝对的安全, 我们做的所有跟安全有关的措施, 都只是在增加别人搞我们的成本而已
安卓拒绝的理由, 产品理解起来就是: 这个需求太麻烦了, 我们 (PS: 安卓) 不想做而不是不能做
那这矛盾就出来了嘛. 产品和安卓负责人两个人在会议室吵了一整个上午. 最后安卓那边也还是不做, 给产品整郁闷了.
在绝大多数的互联网公司里, 开发和产品之间的关系都并不算友好, 开发在接到一个需求之后, 需要考虑东西有很多, 例如: 这个功能的扩展性、开发成本、 数据库怎么设计等; 但是有的时候这个需求其实只是产品在试错, 如果产品提出来的需求只是在试错, 试错的需求就需要经常改;
改可以啊, 至少也得说出来为啥改是吧! 但是有的时候产品也只是一个传话工具, 老板说要改, 为啥? 不知道!! emmmmmm…. 这个就很尴尬; 或者说, 产品就是觉得不对, 哪里不对又说不上来, emmmmmm…, 对于开发来说就是脑壳疼
碰到这种类似的问题, 我觉得不妨换个角度思考一下, 站在产品的位置上,去考虑一下这个问题. 就拿这次提到的加密强化的这个需求来讲;
这应该是一个产品应该关心的问题吗? 我个人觉得不是, 这个问题是应该在产品提出来之前就应该处理好的, 开发在发现一个漏洞的时候, 或者明知道存在这个漏洞的情况下, 应该第一时间去想办法去修补这个漏洞, 而不是等产品提出这个需求;
产品不是技术, 绝大部份产品也不会技术, 他们没有办法像开发一样去发现一些漏洞.
还有试错这个问题, 也站在产品的位置上, 去看待一下, 一个功能, 需求来源无非就是那么几种: 借鉴竞品好的想法、产品觉得不错的想法、 上面压下来的需求
不管需求的来源是哪一种, 产品怎么会知道这个功能, 是否能对项目产生一个正向的增长? 他肯定不知道啊. 所以在我看来产品的每一个需求都是在试错, 如果这个功能对项目产生了正向的增长, 那这个功能就是成功的; 反之, 这个功能对项目产生了负向的影响, 或者说这个功能没有达到产品的预期目标, 那么这个功能就需要改, 或是直接移除
在我的职业生涯里, 我碰到的所有的开发都和和产品互怼过, 无关职位、年龄和岗位, 只要他是个技术就一定会怼产品. 如果你发现一个开发还没有怼过产品, 他一定是个新人, 对业务还不了解!
作为服务端的负责人, 我鼓励我的组员对技术 (我认为 产品是不会技术的技术) 发起讨论. 可以争论, 甚至可以吵, 但是这种争论不应该掺杂个人感情, 虽然这很难.
我个人比较推崇一句话: “任何技术上的争论都是有必要的, 哪怕你提出的是一个错误的想法, 但是这个争论应该止于技术”, 这, 也是我在跟别人争论 过后和之前 最常想的一句话