2016/05/19 第584期

使用功能开关而不引入technical debt

文中的办法不错:建立俩branch,一个加功能开关,另一个删除;先merge加功能开关的那个branch,上线代码;过了一段时间,确认可以删功能开关了,就merge第二个branch。

使用feature flags(功能开关)最终会在代码里留下一堆if .. else,上线功能大半年后早已忘记功能开关这回事,即使记得也懒得去删、或者没把握删除后会不会引入bug。文中的办法好处在于,加功能开关的时候,已经熟悉部分代码,删除的时候很有信心,顺手删除,为以后节省时间。

深入浅出Postgres内存管理

其实讲得还不算深入,但对大部分人来说了解这么多就足够了。了解一下常用数据库的运作原理以及如何配参数优化性能是很有用的,可以省却很多花里胡哨难以维护的“性能优化”的应用程序的代码。

以前做过一个项目,本来要在应用程序代码里加入缓存的机制(用memcached之类的),做好了写一堆恶心的cache invalidation的代码的心理准备,即将为公司花掉很多钱(工程师时间乘以时薪)。后来benchmark了一下,发现啥cache都不用,直接依赖postgres自己的buffer management效果就很好了,因为workload很predictable。快糙猛的解决方案:)

失败是成功之母

在某个计算平台取得巨大成功的,很难把成功复制到下一个计算平台。反倒是在上一个主流计算平台失败了后,才能重头开始、抛弃旧思维、创造性地思考下一个计算平台的事情。举了微软、苹果、亚马逊为例

微软:PC成功,手机失败;Apple:PC失败,手机成功,手表半死不活;Amazon:手机失败,Echo(智能家电?)成功。当然现在说Apple Watch失败或Amazon Echo成功,都还太早。

文中对比了鼎盛时期的Apple推出智能手表与微软在极盛时期的90年代推出Windows CE,看上去两家公司都占尽了下一个计算平台的先机。微软用桌面操作系统的思维做手机操作系统,Apple Watch看上去也是智能手机的简化版。

配置文件的出错信息必须准确易懂

广泛使用的软件工具(尤其服务器类的)或多或少有配置文件,有独特的语法。在配置文件中引入错误很不好排查;软件工具作者们很多都没在出错信息上花心思,要嘛没有出错信息、要嘛模棱两可。

公司里真的需要那么多员工吗

所谓10x engineer(以一当十?),只是他们有10x的机遇、有10x的自由发挥创造的机会;如果公司处处提防他们、不给他们机会、让他们束手束脚、大材小用,人浮于事的情况就会出现。

"A talented person with no opportunity produces 1x results. A talented person with 10x opportunity produces 10x results."