技术交流大纲
交流背景
入职一个多月,通过阅读公司的技术资料,结合自己多年的开发经验,分享一些好的,对项目有益的想法及落地方案,此外对项目的理解,提一些个人的看法,有什么不足/不对的地方,希望各位同事查漏补缺
关于调试工具
DoraemonKit
官方文档设计了两个插件,
- 一个是用来切换正式和测试环境,
- 一个是根据页面classname来跳转对于空页面(用于调试UI)
接入说明:
插件的接入主要分下面几步,
第一步: 创建一个插件Vc,用来承载插件功能,具体开发功能,用户自定义
第二步: 实例化一个插件类,实现协议DoraemonPluginProtocol
1 | // 该代理方法是点击插件按钮时会触发 |
第三步:将插件挂载到dokit的首页上
1 | [[DoraemonManager shareInstance] addPluginWithTitle:@"环境切换" icon:@"doraemon_default" desc:@"用于app内部环境切换功能" pluginName:@"KCEnvPlugin" atModule:@"业务专区"]; |
插件的目录结构如下,有兴趣的同事可以去看一下
1 | └── KCLogistics |
关于项目组件化
组件化的必要性,项目目前分为快成物流、快成司机、建龙司机、建龙物流、晋能物流、晋能司机。项目的管理主要靠创建不同的代码仓以及分支来管理代码。
我的想法是粒度大一点,类似YYKit这种,弄一个全家桶,然后内部弄一些子pod库,然后项目直接引用这个全家桶,减少一些重复基建工作。
一些前置条件
大概的步骤,按以下几步进行
- 搭建一个公司内部的私有pod源 ✅
- 项目进行梳理,拆分解耦基建组件库 ✅
- 拉分支,集成私有库,删除旧源码 ❌
- 测试,上线** ❌
线上监控
线上监控的一个思路,主要是对接bugly、钉钉、服务端。
目前我们项目里面已经接入了bugly监控,所以线上的监控也可以应用bugly提供的数据内容进行hook,然后需要服务端提供一个接口。将bugly每天产生的数据,进行一个再处理,将我们关注的数据进行一个汇总。用钉钉机器人发送到对应的群里。
### 动态化 目前的项目,还没有动态化的能力,这方面是否考虑接入RN或者其他动态化能力 如果接入的话,个人建议接入RN,今年RN底层架构有了一个大的升级,从之前的JSCore引擎升级Hermes,新引擎比老引擎通信性能有了3倍的提升,启动性能也有2倍的提升 [RN新架构介绍](https://time.geekbang.org/column/article/499434)
关于协同
工程代码书写规范
规范名称 | 说明 | 例子 |
---|---|---|
命名规范 | 大驼峰规则与小驼峰原则 | NameTextField(大驼峰), nameTextField(小驼峰) |
项目命名 | 大驼峰 | AoRiseProject |
Bundle Identifier 命名 | 反域名命名 | com.jianlongkuaicheng.driver |
类名 | 大驼峰命名。一般是:前缀 + 功能 + 类型 | KC + Login + ViewController |
VC结构分区 | 代码结构分区 | |
变量和方法 | 小驼峰 | - (void)addTrailerWithParams:(NSMutableDictionary *)params{} |
常量 | 宏:大写KC + 大驼峰 全局常量:工程前+缀全大写 |
#define KCUserAgeKey @“userAgeKey” extern const NSString KC_USER_AGE_KEY |
参数名 | 小驼峰命名 | - (instancetype)initWithFrame:(CGRect)frame myCarViewItemClickBlock:(myCarViewItemClickBlock)itemClick myCarViewSearchPlateBlock:(myCarViewSearchPlateBlock)searchPlate; |
资源文件规范 | 用途_模块名_逻辑名称 用途_模块名_颜色 用途_逻辑名称 用途_颜色 |
|
文件夹命名 | 实体文件夹,首字母要大写 | Model,View,Controller,Tool,Other,Service |
版本规范 | 采用A.B.C 三位数字命名 | |
注释规范 | ||
方法注释 | 方法外部统一用option + command + / ,方法内部统一用//注释 | |
模型注释 | ///注释 | |
分支规范 | ||
Merge规范 | 严格执行gitlab的merge request 禁止feature之间进行merge操作 merge顺序:feature->release->master->feature |
|
commit规范 | 原则:明确提交的版本/项目/改动点 [哪个项目+哪个版本?+模块?]-ADD/MOD/FIX/DELETE:desc |