作者回复: #1. 我知道的,RESTful API用的多些。我对这方面的不熟,希望留言区有人可以帮着回答。
#2. 其实,短期内我们很难做到“铁打的营盘,流水的兵”。软件开发还算是一项复杂的活动,很多时候,也会体现出是“流水的营盘,铁打的将”的现象。优秀的程序员,还是要想办法留住的。有研究表明,替换一个工程师,需要花费平均6到9个月的薪水,甚至是1.5到2年的薪水。如果我们把替换成本变成现有工程师的薪水涨幅,也许事情就简单了很多。
代码没人敢动,一个很重要的原因,就是没有回归测试或者回归测试不完备,我们搞不清修改代码带来的后果。JDK运行在几十亿台设备上,每天都做很多修改。之所以能够做这么大量的修改,除了规范、文档、评审之外,还有大量的回归测试案例。代码修改提交之前,要把相关的回归测试跑一遍。一旦修改带来了兼容性问题,回归测试就会检测出来,工程师就会知道修改带来的影响,会重新考量修改方案。
另外,要用好现代的工具,不能停留在手种刀割的时代。很多工具都是开源软件,搭建起来,形成习惯就可好了。比如,bug管理工具(bug systems), 版本控制工具(git,mercurial),这些工具都会留有历史信息,用好了可以更好地理解代码和变更。不使用这些工具,好多有价值的东西,极小一部分留在工程师的脑子里,人走了,价值也就随着走了;大部分都会被岁月冲散。JDK的开发过程中,我经常需要找找十多年前历史信息,看看当初为什么那样设计,要解决的到底是什么问题,变更起来影响可以有多坏。
作者回复: 搜了一下,是《金字塔原理:麦肯锡40年经典培训教材》吗?你的阅读面很广啊! 嗯,有机会我也要买来看看。作为一名老旧式的五道口技校经管的学生, 推荐大家多读读经济管理的书籍,对产品设计很有帮助的,大部分的设计思想都逃脱不了经济管理的原理范畴。
作者回复: 这两种都是很好的方法。 第一个方案的一个小缺点是如果用户传入参数,内部整理在个别的情况下没有办法自动处理,不过大部分情况下都没有问题。第二种理论上没什么问题,就是对规范和用户的要求都有一点点高,需要规范标注;仔细阅读规范;并且遵守时间顺序。😣,编码的难处就在于要反复地妥协和平衡。
作者回复: 嗯,估计你使用小屏幕阅读的。代码的显示在小屏幕上,的确是个问题。
这个Signature类设计的最大问题,就来源于update()这个方法。 因为签名数据可能很大很大,这种情况下,需要分批传入数据,使用update()方法。 当然,还有更好的解决办法。
作者回复: MESE的原则是划分到事实为止。用到代码上,划分到有现成方法可以用为止。如果有吞咽这个方法,划到吞咽就够了。
作者回复: 这样适合处理小数据,如果签名数据很大,比如文件,图像,sign方法需要占用的内存太多,占用时间太长(data参数)。verify方法怎么传要签名的数据呢?