2018年年度总结-工作成长
2018年年度总结-为防止过度强调自我作用,已发给部分同事看哈自介技能经验KD-RPC(2017-9月开始设计,2018-8月在项目中应用)SuperShellCpp_Serialize开发方向我涉及开发项目及难点和解决方案Blue-Eye(吃鸡)防护系统的调试游戏助手项目浏览器及配套代理开发更新系统设计虚拟货币-钱包项目基础工具建设推动源码管理工具-Git流为项目配套测试工具推动灰度测试-完善并
自介
对综合性有挑战性的任务会感到兴奋.
技能
- 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
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)