
3.3
修剪模块
|
63
第四,内部的实现应该是尽可能高性能的。通常,对性能的衡量能反映出
事物的运转是否正常,因为如果某个东西慢到被认为不可靠,那么使用者
也会难以忍受。但是在我们所期望拥有的特性中,性能下降到了第四位。
性能被看作是一种特性,并且我们应该把简单性和可读性看得比性能更重
要些。不过也有一些例外,在这些情况下性能是最重要的,甚至可以牺牲
一点接口的质量和代码的可读性来换取高性能。但即使在这样的情况下,
至少也要尽量为相关代码多写一点注释,以便使用者明白为什么必须这样
写代码。
编写简单的代码和提供整洁的接口能带来灵活性,但是在满足使用者的需
求方面,灵活性毫无作用。试图预测使用者的需求往往会增加代码规模和
复杂性,还会浪费时间,对于改善使用者的体验几乎没什么用。
3.3
修剪模块
与现代
Web
开发类似,到这里模块设计还没有真正完成。本节我们将探讨
一些主题,帮助你思考组件的生命周期,以及如何设计和构建组件,以便
组件开发完成之后,不会给我们带来太多麻烦。
3.3.1
对错误的处理、缓解、检测和解决
进行软件开发时,总是要花时间排查看似不可能找到的微小
bug
的根源。
花了很多时间之后,你会发现这些
bug
是由我们认为理所当然的程序状态
出现了微小差异而引起的。这个小小的差异在程序的逻辑流中逐渐被放大,
最后变成不得不一查到底的大问题。
我们无法完全阻止这种情况发生,因为总是会有意想不到的
bug
出现。比如,