背景:新小程序(new-mp
)业务中,期望使用已有的小程序(old-mp
)的技术结构进行实现
(第一种做法)新建空白仓库
创建一个临时文件夹
git clone old-mp
rm -rf .git
git上创建一个空白仓库
git init
git set remote origin …
git push -set-upstream …
以上为伪代码,表示一个基于已有的旧项目,提交一个新项目
more >>背景:新小程序(new-mp
)业务中,期望使用已有的小程序(old-mp
)的技术结构进行实现
创建一个临时文件夹
git clone old-mp
rm -rf .git
git上创建一个空白仓库
git init
git set remote origin …
git push -set-upstream …
以上为伪代码,表示一个基于已有的旧项目,提交一个新项目
more >>With great power comes great responsibility
对于组件拆分的思考
我们转移给使用者多少控制权,就丧失了多少即插即用的组件复用点。
灵活度和复杂度之间的控制是一场永恒的博弈,结局终归会是面向场景的 trade-off,不同的场景控制着不同的组件设计思路。
在小程序中,微信小程序的语法亦然采用的callback方式。
为了使用顺手,我希望
1 | // cumbersome 😭 |
本文会从 code review 对流程,意义,工具,执行规范四个范畴来进行阐述
- 函数实现复杂性
- 可阅读性
- 无用的code(可减少的变量声明)
- 组件设计优化
针对某个逻辑进行debug式的review,这种情况是否属于 code review 无法界定,
理论上来讲,在做复杂模块设计的时候,会有设计文档生成,设计文档也会经过一遍审查,此时的审查就是复杂逻辑的设计。
more >>
前后端分离的工作模式下面,API交互文档亦然成为前后端沟通最佳介质。依赖文档,简化沟通,提高写作效率。
API文档应有前后端共同约定,商议。实际开发中API文档由后端同学维护,因为前端是API的消费者。提供文档的方式有很多种:
Txt,Markdown , Word
原始,文档作者手动录入,接口变动需要以来文档作者实时更新,易读性取决于作者.
文档没有集中管理方式
文档平台(公司内部文档平台)
文档集中管理,手动录入,同步不够简化,文档结构有同意约束
Swagger 文档
文档自动生成,前期会增加额外的后端同学开发工作 ,文档详细。接口变动实时同步
1 | uname -a **查询所有信息 |
1 | rpm -Uvh http://www.elrepo.org/elrepo-release-6-6.el6.elrepo.noarch.rpm |
1 | yum --disablerepo="*" --enablerepo="elrepo-kernel" list available |
1 | yum --enablerepo=elrepo-kernel install kernel-ml |
缺失模块。
1、在博客根目录(注意不是yilia根目录)执行以下命令:
npm i hexo-generator-json-content --save
2、在根目录_config.yml里添加配置:
jsonContent: meta: false pages: false posts: title: true date: true path: true text: true raw: false content: false slug: false updated: false comments: false link: false permalink: false excerpt: false categories: false tags: true