2016/10/17 第731期

10 种 Over-Engineering 的错误

在做产品的过程中,没经验的工程师们(或编程学校刚出来的)往往 Under-Engineering,而有一些经验的半吊子工程师们则往往 Over-Engineering,常常想太多了,把问题复杂化。

这个 GitHub repo 里的 Java 代码很具有代表性,用来讽刺现实世界中的“企业级”代码,咋看之下这些代码符合各种软件工程的最佳实践,具有接近100%的 test coverage,但实际上就是一坨过度复杂的狗屎。

替换 MongoDB 存储引擎的那几个不眠夜

他们将 MongoDB 的存储引擎从 MMAPv1 换成 WiredTiger,当 WiredTiger 缓存用满后,MongoDB 变得无响应;花了几个不眠夜换回 MMAPv1,数据恢复就用了36小时。

这是“边开飞机边换引擎”的失败案例:)抛开吐槽 MongoDB 的种种不是,他们在 production 上对数据库进行这么关键的操作确实准备不充分,灾难恢复也没做好。本文最后他们自己也总结了经验教训,另一篇来自 Parse 前系统工程师的博文针对此次事件也做了很好的评价,也推荐读一下。

永远投资你的教育

这里的教育并非单指在学校里拿学位的那种教育,而是自发地投入时间、投入金钱去大量阅读、终身学习,这能让你做更好的决策、见识到更多的机会,你自己的教育是唯一可以终身投资且终身受益的东西。

有的人读4年很好的大学,毕业后每天、每年都没再进步了;有的人没怎么读过大学,但每天、每年都在进步。10年、20年后来看,读好大学的可能人生的巅峰就发生在读大学的那一刹那,只有在那时才是同龄人中的佼佼者,以后就不是了。人生还很长,必须不断进步啊。

“If a man empties his purse into his head no one can take it away from him. An investment in knowledge always pays the best interest.” — Benjamin Franklin

如何决定该做哪个产品功能

公司里每个人都有各种好的产品 idea,先做哪个好?文中给出了一个方法:用电子表格把各种产品 idea 列出来,从三个方面打分 Demand、Impact、Effort。最优先做的功能应该是需求高、影响力大、工程上容易做的。

这个电子表格给出了这种方法的使用范例。

On Writing Product Specs

公司发展到上百人后,给产品增加新功能以前写好 product specs 是很有必要的,因为上线一个产品功能都要不同部门一堆人协同工作,文档是唯一有效的、scalable的沟通方式。

本文讨论了为什么要写 product specs、以及怎么写,还给出了 product spec 的范例