开发原则

更新时间： 2022-10-30T10:57:47+08:00

Work Design 系列项目作为模块化代码的实践，旨在开箱即用，易于使用。不过业务需求复杂多变，如何能做到以“不变应万变”，需要在开发的过程中分清楚界限：哪些功能是属于模块，是通用的，而哪些功能是属于主项目，是需要在主项目中override 的。

为此，我们在开发工作中提炼了一些开发原则，用于指导我们的工作。

降低学习和使用成本

经过数年的演进，软件开发的门槛越来越低。程序语言，框架，库的繁荣使得开发工作越来越简单。在设计开发库的时候，尽可能降低使用者的学习和使用成本，不仅能使得最终软件成本降低，同时降低了使用者门槛，拓大了使用者群体。

在开发中，有哪些原则能够降低使用者成本呢。

一致性是减少使用者的理解和使用成本的重要原则，系列engine，主要统一的地方：

遵循先例原则是一个法律中的基本原则，即基于现有的认知，确定解决方案。在代码库开发中，尽量遵循语言和框架的风格，遵循现有方法，基于用户已经熟悉和掌握的知识。

尽可能”Ruby Style”，避免”DSL”，DSL(领域专属语言)的潜台词是小圈子，不一定通用的规则。所以我们在使用Ruby和Rails框架的前提下，尽可能遵循ruby和rails风格的方式，会减少学习和使用成本。

对于提供的通用模块（一组方法定义），我们尽可能采用Ruby中的 include(prepend)/extend 方式去引用。如果类方法的定义中仅包含对模块的引用，则避免定义类方法，因为类方法会隐藏细节。

class User < ApplicationRecord
  acts_as_auth # bad
  include RailsAuth::User # better
end

没有万能药，一个框架和库不可能满足软件世界的所有需求。如果一个库总想着尽可能去兼容需求，则其复杂度会大幅提升，从而增加用户的使用成本。

所以在设计库的时候，需尽可能为被覆写提供渠道和便利。

作为库的使用者，则尽可能避免直接改动原框架，尤其是对于活跃开发中的库，要相信，origin库（框架）是总能被override 的，只要你对框架和语言足够熟悉。

Rails Engines里的代码可以从各个层面去override;
　* model 层：无论是include进来的module中的方法，还是重新打开类，定义同名方法即可，区别是include module引入的方法可以通过super去调用，而打开类只是被覆盖；
　* view 层：以同样的路径覆盖位于engine中的文件即可。
　* controller/routes 层：在routes定义同路径路由覆盖;

业务中的需求千变万化，如果想着满足各种需求，会额外增加很多判断。

同时如果一个库很灵活，需要的配置文件也会额外增加。

Rails作为一个庞大的应用，包含了对于构建系统来说大量实用的功能。在开发的时候，尽量避免重复造轮子。这也是对程序员的基本功的要求。

也许有些需求不足以满足，但是往往可以基于Rails框架进行扩展。

Ruby 是一门非常灵活的语言，提供了诸如打开类（Open Class）等黑魔法。这些元编程往往具有一些副作用。
所以我们应尽量避免直接改原框架，

而是基于（框架）使用回调、钩子等方案。

很多需要配置的地方，尽量考虑到配置内容可能影响的各个环节。

比如Model层一些属性会用到枚举(ENUM), 如性别包含男和女。这个配置就很适合在翻译文件中来完成。
有些配置可以基于底层的自定义，比如存储某个字段的时候，可能会需要对输入进行 truncate , truncate的大小可以基于数据库scale 文件中的字段limit值来确定。

函数式