DigitalC

数渠产品线 - 定制化基础组件、业务组件 DigitalC

🔗 快速体验

在线演示:https://digitalc.vercel.app

npm 地址: https://www.npmjs.org/digitalc/

简介

每个研发团队都会有自己的工具库、UI 组件库、脚手架与构建工具,来提高效能和实现能力复用。如何在繁杂的业务中寻找共性，提供通用产品解决方案，并且满足不同项目的业务差异；如何将设计经验，业务代码提炼为指南，帮助使用者正确使用组件，并在项目之间实现能力复用，如何提高效能快速落地和交付，如何减少前端与设计的沟通、降低验收成本提高全局协作效率，已经成为亟待解决的问题。

除此之外，从设计角度看每个产品也会有自己专属的设计规范/设计语言/设计体系，设计师通常会整理出一份设计侧的 UI 组件库，并制定一套 Design Token 用于与其他设计及前端沟通交流和设计与研发之间的联动,以满足国际业务多样性。整体维度是 “从抽象到具体”的总分关系，达成对数渠产品各维度都有具体的指导，能保证长期使用避免重复返工的同时，也便于囊括后续的迭代内容。这些用文档来传阅并不方便且不具备交互性，所以就需要一个好看好用的站点,来详细的展示各种规范和组件的实际效果,并且能给后续类似场景实现能力复用,这是本项目的初衷。

🌈 设计指南

用户体验团队将部门内部多年设计经验提炼总结,为领域内的专业设计指南，提供的行业设计解决方案。包含:

价值观
色彩
字体
动效
图标
布局
暗黑模式

资源

为了实现需求与设计\开发之间的高效协同，团队展示了丰富且可复用的产品组件资源：

✨ Usage

npm i  digitalc

import { Button } from 'digitalc';

export default () => <Button>点击</Button>;

如何贡献

非常欢迎您的贡献！提交您的 Issue 或者提交 Pull Request。

Pull Request
Fork 代码!
创建自己的分支: git checkout -b feat/xxxx
提交你的修改: git commit -a 'feat(project): describe'
推送您的分支: git push origin feat/xxxx
提交 pull request

🖥 Development

Install dependencies,

$ npm i
or
$ yarn

Start the dev server,

$ npm start

Build documentation,

$ npm run docs:build

Run test,

$ npm test

Build library via father,

$ npm run build

最后,将 dist 发布到 npm(digitalc),将 docs-dist(站点文档) 部署到服务器对应的目录就好了.

如果想免费挂载到公网，可以用 https://vercel.com。

❤️ 致谢

感谢所有为 digitalc 项目,贡献力量的 2022 新同学们~

开发注意

约定式路由。

src 目录下面的第一层目录就会被当成顶部导航栏的项目名，第二层目录以后则是在左侧的目录体现。

  * 代码提交使用了eslint验证,确保无错误提示再进行提交;
  * 业务代码和css样式,尽量保证在兼容多个浏览器的前提下实现效果(如IE10\11);
  * 新功能需求: 在接口无法提供的时候,可先用 Mock 模拟数据;接口服务：rap2
    新功能需求: 使用字体图标,不建议使用图片图标;
    新功能需求: 相同功能已经有依赖的三方或技术选型，不应该再引入新的类库。若确实有新的或更好的方案,可以组织评审讨论后补充或替换;
  * 后面我们的分支模型develop的代码，都是已经经过联调，都调通，功能都没有问题的代码,
    实现的功能 通过走查后 MR到 feature,直接 push 到核心分支的权限已经被关闭. (开发新功能的分支也应该从develop拉取);
  * 业务实现的代码: 至少经过一个同学的Code Review走查通过方可提交,走查方式为 GitLab 的 Merge Request 流程;
    同时: 理解别人写代码的风格和方式取长补短，找出别人代码与规范违背的地方，督促自己有则改之无则加勉;
  * 规避常见安全问题:见最下方[常见漏洞]补充文档;


  业务功能完成实现为前提下:
  * 代码逻辑杂糅，存在很多常函数，很多业务逻辑放在一个函数内，逻辑没有拆散。
      * 推荐做法：单个函数，代码行数不超过120行，单个文件行数不超过500行
  * 业务逻辑重点函数没有逻辑注释
      * 推荐做法：文件头部增加全局注释，函数头部有具体的方法注释
  * 方法名称随意，无法区分函数功能
      * 推荐做法：事件响应以on开头，通用函数封装到单独的文件中
        onChange={this.handleCardChange}
        handleButtonClick
        handleNextStep
        handleDialogClose
  * 存在大量hardcode代码
      * 推荐做法：将常量数字及常量字符串封装为枚举类型
      * 常量提成配置项

  * @ 指向 src 目录，如 @/components。 建议代码中都使用 @/ 开头引用组件
    ~ 在 less 或者 sass中 指向 node_modules 目录

代码质量

* 异常处理
    * 逻辑上的边界条件，对逻辑异常需要在整个业务代码最开始地方处理，发生异常直接return，异常包括例如: 为空、错误、异常等
* 命名规范,
    * 不强求, 但是基本的问题要杜绝, 例如: hardcode, 变量后加数字, 名字不恰当、太通用等
* 技术规范
    * 遵守域内研发框架
* 写小函数
    * 例如: 单个函数建议不要超过120行
* UI层事件响应的逻辑处理抽象
    * 通过 async/await 简化交互层代码逻辑
* 代码注释
    * 在主要业务流程的函数顶部，写清楚业务执行逻辑及各个分支场景
* 使用解构
    * 替代联系的“.”运算
* 代码走查
    * 单次MR不超过500行代码

Commit type 提交前缀说明

  真实 Commit 描述，能说明白即可，字数不用太多

  remove: unused  code
  feat: 新特性
  fix: 缺陷修复xxx
  docs: 文档相关
  style: 样式修改、错别字修改、格式化等
  refactor: 重构
  perf: 性能提升
  test: 增加测试
  chore: 业务无关修改，如：发版、构建工具链修改等
  scope: 可选，作用域标识，指明你需改的代码所属作用域

当你在审查其他人的代码时，你应该关注什么？

不管你是通过像 Upsource 这样的工具还是同事的讲解来审查代码，有一些东西是比较容易评判的。比如：
  ● 格式 ：空格和换行在哪里？他们使用的是 tab 还是空格？大括号怎么布局？
  ● 风格 ：变量/参数声明为 final ？方法变量是在使用时再定义，还是在方法开始的地方定义？
  ● 命名 ：字段、常量、变量、参数、类的命名遵循标准吗？名称有过于简短或通用？
  ● 代码场景覆盖 ：这段代码有没有考虑到请求失败的情况\兼容性问题有没有测，性能的防抖和节流做的怎么样？
  ● 可读性和可维护性: 是否过于冗余\能否复用和拆分更简约?