杂感

软件结构简单度受到性能的挑战时，如果软件需要持续维护，请选择牺牲性能。因为过度复杂的软件结构会带来无数的痛苦，包括莫名其妙的bug,难以添加新功能等等。

速度固然重要，方向更重要。如果软件以飞一般的速度冲向崩溃，倒还不如像乌龟那样慢慢爬向终点。

用户挑剔软件运行太慢时，唯一应该做出的妥协是：要不，我显示一个进度条？

不要吝惜把一行天书改写成几行能更清晰地表达意图的代码;也不要节省为方法/类想一个贴切的名字的时间。时间不是节省出来的，而是通过减少真正的浪费而得到的。

时常停下来想一想，真的没有更好的方案了吗？可能两个小时的思考比两个星期的编码更有用。

要尽可能地靠近需求。不要不屑于做那些简单的功能，因为真正的技术含量只在于实现需求，往其它方向寻求无异于缘木求鱼。哦，不，运行速度不算需求，如果我能接受我的软件的速度，并且我没有时间在保持结构简单性的前提下，大幅度提高性能的话，那么除了进度条外，我什么也不会提供。

测试，尽快地测试。不要等写了几千行代码之后才开始测试。修改代码后，哪怕只添加了一个语句，也要重新测试。如果你认为不会出错的地方真的不会出错的话，软件就永远不会有bug了。

保持风格，保持激情。I'm doing something useful, interesting, cool, and unique in my way.