工程师忽略的隐形成本
有时候我们说,“实现这个功能,我只花了几个小时”。但是完成之后,我们发现每隔几周,我们要么在修复该功能的bug、向另一个工程师解释,要么做客服回答问题、以解释其工作原理。维护该功能总的投入时间要远远超过最初开发的几个小时。 软件开发中内化的最艰难教训之一就是额外复杂度所带来的隐形成本。有时候,复杂度在问题领域只是固有的。为了匹配乘客和司机,通过调整价格来平衡供求是一个复杂和痛苦的问题。因此,在扩大一个社区和维护社区质量的时候,把问题和答案疏通到喜欢回答和看问题的人们那里,也是如此。或者像是开发一个兼容所有设备的富文档编辑器以支持实时协作。这是固有的复杂度,我们需要根据产品做出调整以取得成功。 但是其它时候,和我们较劲的复杂度恰恰是我们自己产生的复杂度。我们用新编程语言写代码,很少人了解它,现在我们不得不维护它。或者我们增加了额外的基础架构,因为我们尝试从Hacker News看到的、热门新技术,但是它失败了,这是我们当初没有想到的。或者我们引入了一个很少人使用的功能,但是修复和bug报告就花掉了极不对称的大把时间。 额外的复杂度暴露了很多隐形成本。在开发软件时,我们所做的决定不只是决定...
