
152
|
第
6
章
开发的方法论与哲学
件、视图控制器和
API
之中,而不是大部分先放在服务器端处理,然后在
客户端代码结构中单独的物理位置处理。这种集中化对于团队中希望更好
地了解应用程序流程的新人来说很关键,因为不然的话他们就得一直琢磨
视图组件和控制器以确定发生了什么。对于首次涉足代码库中未知领域的
人而言,这是一个令人生畏的任务。
我们的代码的其他任何功能可能也有此种情况,因为如果应用程序中的每
一层都有明确定义,就很容易理解算法是如何从一层流转到另一层的,但
是如果将业务逻辑与应用程序代码的其余部分隔离开,得到的好处最大。
还有一种方法是使用像
Redux
或
MobX
这样的状态管理解决方案,将所有
状态与应用程序的其余部分隔离。不管选用何种方法,其核心不变,即始
终尽可能明确地将应用程序中的视图渲染部分与业务逻辑部分隔离。
6.6
开发与生产的平等性
我们已经声明了明确定义构建过程和部署过程的重要性。与此类似,我们
拥有不同的应用程序环境,比如开发、生产、预发布、特性分支(
feature
branch
)、
SaaS
与内部部署环境等。这些环境根据定义来区分,最终我们会
在不同的环境中使用不同的特性,无论它们是调试工具、产品特性还是性
能优化。
每当合并特定环境的特性标识或逻辑时,都需要注意这些变化带来的差异。
是否可以加强依赖环境的逻辑使得引入的差异最小?是否应该将新引入的
逻辑分支隔离到一个单独的模块中,以便尽可能多地处理这种差异的各个
方面?我们为特定环境开发特性时所启用的标识是否会在无意间将
bug
引
入到其他启用了不同标识集的环境? ...