
76
|
第
4
章
内部构造
件还有
notify
功能,用于处理邮件的发送。更进一步地扩展这个想法,或
许
subscribers.notify
的大部分工作可以通过另一个名为
emails
的服务组
件完成,这个服务组件负责正确地配置邮件发送的功能,也有将可能的邮
件转换为单纯的
console.log
语句的功能,这样在调试期间就可以快速访问
邮件内容了。
一旦原型阶段结束,清晰地定义层(
layer
)对设计出高效且可维护的应用
程序就至关重要。层可以由遵循我们所使用的框架的约定的组件构成,也
可以是自定义的,就像前面讨论的服务层那样。通过使用层以及使用函数
参数而非作用域来传递上下文,我们可以将几个正交的组件放在一起来引
入水平伸缩,而不会让它们碰触彼此的关注点。
4.2
重构复杂代码
代码是不断发展的,我们的代码最终不可避免会发展成大型项目,变得不
那么容易维护。后面的几节会在架构层面谈一谈关于降低复杂性的实践,
本节将重点讨论如何降低应用程序中已经很复杂的那部分代码的复杂性。
4.2.1
多用变量,少写“巧妙”的代码
复杂的代码明显比它原本应该有的长度要短,这一点通常具有欺骗性。一
个可能需要
5~10
行短代码表达的逻辑,通常只需要一两行巧妙的代码
(
clever code
)就可以表述。而这一两行巧妙代码的问题在于,只有在我们
第一次写完这些代码时或者花费了可观的时间进行分析后,对其意图才有
清晰的认识,不然就需要花时间与精力去弄清楚。
阅读复杂代码时可以发现的一个潜在问题是,它们用的变量很少。在编程