2018年年度总结-工作成长
2018年年度总结-为防止过度强调自我作用,已发给老板和工作相关一些同事哈
- 自介
- 技能
- 经验
- KD-RPC(2017-9月开始设计,2018-8月在项目中应用)
- SuperShell
- Cpp_Serialize
- 开发方向
- 我涉及开发项目及难点和解决方案
- Blue-Eye(吃鸡)防护系统的调试
- 游戏助手项目
- 浏览器及配套代理开发
- 更新系统设计
- 虚拟货币-钱包项目
- 基础工具建设
- 推动源码管理工具-Git流
- 为项目配套测试工具
- 推动灰度测试-完善并把关测试流程
- Java-Mock:测试服务失败的情况
- 为兼容数百币站-监控爬虫
- 团队方向
- 带人
- 推动项目的项目方向的两例
- 我最近业余时间
- 总结与未来
- 方向
- 技能
- Git流
- 异常
- 错误捕获
- 跨细分领域来寻找解决方案
- Mock与测试
- 大数据与速度瓶颈
- 前端的学习和后端的学习
- 印象深刻的几件事
- 流程建设
- 成员成长
- 不足
- 未来
自介
对综合性有挑战性的任务会感到兴奋.
技能
- C,C++,汇编(3年+)
- Java(最近半年一直在用)前端栈(H5,JS,CSS)
最近半年一直在用它们做项目为公司.
经验
对调试器（mini debugger,公司的反蓝盾保护-调试器内核级增强方案),编译器(SuperShell),格式设计(KD-RPC,差量更新项目),序列化(KD-RPC,Cpp_Serialize)有一定经验。
KD-RPC(2017-9月开始设计,2018-8月在项目中应用)
支持同步异步调用.支持64bit和32bit(格式兼容)互通信.
在公司项目中得到稳定应用在数千台客户端.
https://github.com/dalerkd/KD_RPC
SuperShell
即时C语言编译器.以最少的代码实现无限的功能.
https://github.com/dalerkd/SuperShell
Cpp_Serialize
相对于 Google Protocol Buffers 来说,能够对C++容器进行序列化。
https://github.com/dalerkd/Cpp_Serialize
开发方向
我涉及开发项目及难点和解决方案
Blue-Eye(吃鸡)防护系统的调试
- 涉及技术
驱动开发,内核调试,native调试,Hook等 - 承担任务
赋能:使普通的调试器具有内核级调试器的能力.
游戏助手项目
- 承担任务
硬件信息获取 - 遇到问题
兼容多种系统(Win10,8,7,64bit/32bit) - 解决策略
- 使用统一的WMI方案替代旧的注册表读取信息方式.
- 开发依赖检测工具
因为兼容问题比较普遍:该携带哪些版本dll也不明确.
所以开发了:PE文件格式依赖分析工具.对exe,dll依赖关系进行动态分析.找出不具有的问题.
https://github.com/dalerkd/PE_Format_Checker
制作的这款工具推给同事使用,评价不错哈 - 使用了其他成熟产品的dll方案
浏览器及配套代理开发
- 涉及技术
类,重构,日志 - 承担任务
前期预研,代理服务的开发及配置功能.浏览器编译开发. - 任务
- 前期 A同学负责通信接口,B同学负责代理模块.我负责:编写其他模块和整合代理模块以及使用通信接口.
此外,因为早期项目:深陷崩溃困境,我为系统增加了: - 崩溃捕获系统
- 中期
AB同学的业务都交付给我这边.我负责整个项目的开发和管理.
除了完成业务需求外,我根据需求和项目进展增加了: - 重写更新系统
- 完善日志机制
- 引入异常管理
而不是使用返回值.(掉过坑) - 引入符号管理
解决遇到BUG,找不到符号的尴尬. - 跨系统支持
- 后期
推动到Chromium内核后.
和B同学完成搭建环境初步修改后,我为浏览器增加动态首页功能.
更新系统设计
- 旧版不足
- 严重排错障碍
通信依赖系统API,导致错误码根本无法说明其真实原因.(坑不少次) - 无事务系统
- 配置表达弱
- 项目拟合的情况
由于以上问题,故领导支持"升级更新程序".我主动把该项目接过来,因为我被它坑太多次,希望把它搞好,搭一个好的方便再次升级的架构. - 新版特点
- 解决依赖地狱
最大限度去除依赖,及增加互斥机制等.
解决自更新问题. - 针对下载模块诊断错误困难:重写下载模块
- 增加事务更新设计(真有用)
确保更新的稳定性. - 按项目需求增加两种文件模式
- 压缩文件
- 设计了差量更新
解决补丁体积过大的问题.最小可达1kb.
引出了C++容器序列化问题,所以自己在探索一种解决方案:
https://github.com/dalerkd/Cpp_Serialize - 针对表达力不足
使用JSON格式设计新的格式 - …
虚拟货币-钱包项目
独立开发
- 初期涉及技术
前端栈:)
Vue,electron,H5,CSS,JavaScript
基础工具建设
推动源码管理工具-Git流
在界面开发项目中.
同事还在使用:
- 每个版本复制一个目录(几个G)
- 直接在上一个版本上进行覆盖开发
要A版本,需要注释调B版本的信息
这无法满足项目快速开发的需求.我在详细查阅Git流资料后,
向项目参与者A,B两位同学,演示Git流方案.答疑解问.鼓励大家学几条常用指令.
最终推动Git流方案成功.
我们使用的极简Git流为:master发行版本,dev是开发,每个功能从dev上拉future分支.
为项目配套测试工具
- 无日志之痛
遇到BUG时,不能随时监控其日志.
为其增加日志开关. - 测试
对于测试整个项目是黑盒,所以为测试同学能尽快发现潜在BUG和减轻其测试压力(同时也减轻了开发被打断的情况)。
开发了配置和调试工具的开发,随着项目功能的增加,为测试同学开发的测试功能也逐步增强,截止目前为其提供: - 更新类
- 周期调试
- 服务器选择
- 灰度控制
- 登录配置
- 服务器配置
- 杂项
- 心跳频率控制
- 日志控制
- 遍历服务
- 代理项
- 自定义代理
- 差量更新
- 补丁及测试
- 补丁及测试
我认为下一步开发方向是自动测试.
当功能稳定后,回归测试的压力很大,所以自动测试-固定测试可以有.
推动灰度测试-完善并把关测试流程
- 一同事将没有做任何测试的版本发布到线上…
暴露出了测试流程不完善的情况. - 解决方案:灰度更新
看腾讯团队的更新设计灵感:
使用:交叉灰度.
解决了以下问题: - 无法测试线上正式服务
- 无法在本地测试功能
Java-Mock:测试服务失败的情况
Mock就是制造假数据，服务器不可能为我们提供任何的数据。
测试同学面临无法测试错误处理的情况。
我为什么老是为测试同学设计工具？
因为他们测不了的情况,会在用户电脑上爆炸.而且有先例.
学了Java和Vue做了一套程序:
功能:
提供界面配置,任何种类的http请求.及其返回数据.
如图:
为兼容数百币站-监控爬虫
依然是测试同学这边压力很大,每天监控数百站点,需要对其进行代码兼容性测试,
因为我们的项目是做浏览器.
用JS写了爬虫,只做两件事,遍历站点,截图(方便排查页面是否错乱),并采集控制台的错误信息(JavaScript错误).
测试同学看到工具后,眼里在发光:)
团队方向
带人
带过一名小伙伴F。其掌握界面开发技能。我和他协作的过程中教授 调试技能，以及编程技能。
推动项目的项目方向的两例
无论是新手还是有一定经验的人，发现在方案时决策时，有一定沟通惰性。面对一些技术方向上抉择的问题，没有及时将更有效的方案推送到领导层，认为领导推荐的方案，难以改变。缺乏能动性。
- 在确认F同学方案可行的情况,推动qt成为设计界面,替换团队不熟悉的duilib。
- 内核升级双路线:补丁还是内核升级?
因领导提出或许可以试试X路线,但其实开发人员均知Y路线才是根本之道.
群体比较消极,认为领导的想法无法改变(其实是领导并不了解Y路线)
我在确认开发人员确实均推荐Y路线后,号召大家做出迅速分工做出Demo.然后力陈其事,并将担忧的点,最后此事通过同事分工做出的Demo向领导展示Y路线而解决.
我最近业余时间
- 设计自己的编译器
- 学习尤克里里
- 给自己充电
总结与未来
方向
本年度基本完成从逆向岗向开发岗转换的过程.
我对此转换很满意,符合做带来更大价值的事的自我期望.
此前,我认为逆向的价值来源于开发.
后端向,服务器向也是我的原定目标.通过参与职业培训,也得到了相当给力的提升.
技能
Git流
技能上 开始使用完整的Git流(之前只是在用Git管理而已)，享受此过程带来的益处.
异常
使用异常而不是返回值来表达错误,随着项目规模的扩大,异常的优点越来越吸引人.
项目中发生了一些true,false之外的状态,而遭遇BUG的情况.
在更深入学习思考关于异常的意义和场景后,开始在项目中更多在合适的场景上使用异常.
错误捕获
dump技术和dump分析,以及由此引发的符号管理,依赖分析工具的设计.
错误处理,事务操作.
规范化的日志处理,及后备方案.
跨细分领域来寻找解决方案
如:
- 事务更新思路来源于SQL数据库事务操作
- JSON存储格式 来源于对前端栈的学习
- …
Mock与测试
测试的意义深入我心,开始实践更全面测试项目的方案.
为测试推出了:
- 控制调试工具
- Java Mock 工具
计划推出的:自动测试工具.(基于控制调试工具,提供:测试用例)
大数据与速度瓶颈
服务器速度限制,推送问题等.
前端的学习和后端的学习
对以下内容有更多的理解:
- 数据库
- 模块化
- 色彩设计
印象深刻的几件事
流程建设
成员成长
我所在是家小型公司.
我观察了周围新手的成长流程发现:
-
无人带
出于成本考虑,招聘的人员新手居多.
往往是一人一项目,两人一项目.很多团队是自力更生状态. -
疲于业务,总结提升意识不强
重复类型的BUG.没有建立完善够用的测试流程. -
跨团队时,新技术新流程其实推广很慢
团队部分老员工对新技术接受度不高.怎么解决?(值得思考)
eg:长连接替代轮询- 使用替代方案
- 针对其依据给出测试结果
不足
未来
现在有数个个人的业余设计涉及到编译器.希望能掌握它的基础设计.
人工智能是我垂涎之地,所以希望为此的学习时间分配更多.
2018年11月28日星期三 12:48