朱皮特的博客 自由的飞翔

重构-客户端开发整理服务端项目的感想

2018-12-06
朱皮特
阅读量:

背景

我们在2011年的时候开始搭建端游反外挂系统,整个项目在2013年完成。服务端开发是从隔壁组借来的,项目完成之后有一个人在维护。我本人是负责客户端开发的,对服务端的开发一窍不通,从那之后主要负责线上的外挂打击运维,写写脚本,回答一下运营MM的问题,有时会解决一些游戏反馈来的BUG。

时间一晃就过去了好多年,这中间我们开始转战移动应用安全领域,对这个系统也没怎么太关注,倒是后端维护人员换了几个人,经手的人基本上对这个系统的评价都不高,甚至是负面的。

2018年底,因为要接入一款新型游戏进行反外挂对抗,但是由于游戏模式不一样,所以打击的策略也不一样,需要对系统进行升级。时间也比较紧迫,新游戏上线那段时间基本上对抗得很激烈,但是也异常被动。客户端层面虽然这么多年没在关注Windows下的反外挂策略,但是运营下来,确实能够在很短的时间把这段差距补上来。

但是单靠客户端一方也不行,后端的很多功能逻辑已经失效,很多功能用不起来,新策略也无法实现,整体运营下来很是吃力。整体下来,身心疲惫,很有一种失落感,并夹杂着有力使不出的感觉,我总结下来是很失败的,这不是我希望的结果。

所以在后端人员又一次变动时,我把后端这块接了过来,准备整改!鉴于我个人对整个业务相当熟悉,加上后端新人的积极主动,我们推进的速度很快。大约花费了一个季度,后端项目已经有了很大改善,到现在,我也更有信心来运营这套反外挂系统了。

因为我个人也参与了部分的实施,所以有一些体会,就写了下来,分享给大家。

目标

降本增效

现状

文档混乱

从内网上下载下来的文档经过很多人手,合起来多达几十份文档,很多新的老的重复的搅合在一起,而该有的文档却没有,大大增加接手成本和维护成本。

分支使用不当

打了多个分支,但是从来不合并,导致的问题是:线上有很多游戏,不同游戏各自有一套,随着时间发展,代码差异越来越大,维护成本越来越高。

部署困难

需要手动敲很多命令,文件传来传去,部署一个包需要花费大半天时间。

调试困难

有问题只能靠日志排查,效率极低,有时一个简单的问题却要发给数天甚至数周来解决,验证影响方案策略的实施和迭代。

后来在跑一个项目时记录了下耗时:

  • 运行起来需要12s左右
  • 调试运行跑起来需要一分半钟

试问这样的时间怎么能快速解决问题呢?

具象目标

  • 一键部署
  • 代码统一
  • 快速迭代
  • 本地调试

准备工作

以下是我自身具备的技术条件:

  • 一直从事客户端的开发工作,主要使用的编程语言是C++,对代码优化和重构有着深刻的认识。
  • 有过少量的Android开发经验,因此可以写点简单的Java代码。
  • 毕竟不是后端开发,对后台的开发流程一窍不通。
  • 痛恶于Linux环境下的命令行的工作模式。
  • 鉴于上述原因,Git零使用经验,一直使用SVN。
  • 后端开发框架零基础。
  • 前端开发零基础。

鉴于以上的条件,想要上来就动手整理服务端项目不太现实,先要考虑如何开始,怎么开始。

我有两个生活上的感悟:

  • 工欲善其事必先利其器
  • 整理术

工欲善其事必先利其器,这个绝对是真理。曾经有过钓鱼的切身体会,如果没有把渔具准备好,钓鱼时就会完全不在状态,各种不顺手,进而导致心境不佳,最终一无所获。

也了解过很多关于整理方面的知识,对整理术有了一点认识:借助整理可以理清思绪,降低大脑的意识负担,最终做到:

  • 神清气爽
  • 心聪目明
  • 心境平和

有过这两方面的心得体会,于是想在这个项目上加以实践运用。工欲善其事必先利其器,这个其实就是搭环境;而整理其实在技术角度来讲就是重构

搭环境

首先弄清楚后端开发需要的流程,逐步弄清楚发现:服务器开发并不是像客户端开发那样上来就可以建个工程开始搞,必须先把公司的服务端开发流程弄清楚,我在这个上面浪费了不下两周时间,门槛真的很高啊。

最浪费时间的莫过于申请一大堆的权限:

  • SSH权限
  • VPN权限
  • ROOT权限
  • 数据库权限
  • 其他各类服务性工具的申请

后端的开发框架当时调研了很久,一直在Django和SpringBoot之间犹豫不决。之所以犹豫是考虑到以下原因:

  • Django使用Python语言,自己对Python的熟练度较高。
  • SpringBoot使用Java,自己对Java掌握较弱。
  • Java代码写起来太啰嗦,Python则很简短高效,而且Python属于动态脚本,可能迭代速度会更快。

后来最终采用的SpringBoot,事后我总结了下使用SpringBoot的好处:

  • 老项目采用的是SpringMVC,因此迁移SpringBoot是有优势的,如果迁移到Django,那只能重写了。
  • Java虽说不是动态脚本,但是少了动态语言的毛病:静态时不出错,运行时可能会出错。
  • Java生态好,要找的问题基本上都能在网上搜到。
  • SpringBoot的部署很方便,打个包扔到tomcat里就能跑。

开发工具

除了IDEA没有二选。

热身

周末花时间把SpringBoot开发的完整流程走了一遍,至少知道怎么去用,但是经验性的东西是不可能在短时间内获取的,只能用到的时候再去摸索了。

重构细节

项目工程迁移到IDEA

之前老的项目是用的eclipse,但是这个工具真的很难用,必须迁移过来,好在IDEA对eclipse的支持做的很好,迁移过来后花点时间配置整理,先能跑起来。

分支规范

必须一个统一的分支dev上开发,其他所有平台的不同代码合并到一起,以后只维护一份代码。

文档规范

通过markdown模式编写简单清晰的说明文档,包含以下方面:

  • 权限申请
  • 模块说明
  • 部署说明
  • 调试说明

设计开发文档使用Word。

迁移至SpringBoot

因为老的项目是SpringMVC,用的很多的库也很老,直接升级到最新的SpringBoot有点困难,花费了不少时间做配置。

优化运行时间

重构完成后运行时间和调试运行时间缩减到一致的六、七秒。

代码重构

把重复性的代码用基类封装管理,细节不再细述。

热部署

双屏开发,右边一边改代码,左边就能看到效果了,开发效率大大提高。

一键部署工具

一键部署到服务器上。

改进效果

因为涉及到业务层面的效果,属于公司机密,所以效果展示就不贴了,仅作内部分享。

感想

  • IDEA是最好的开发工具,没有之一。
  • Java是个很棒的语言,开发效率比C++高很多倍。当然也确实啰嗦,好在能在很短的时间内完成(很多代码也能自动化生成),不是它的痛点。
  • 在IDEA中进行Java开发,爽的一塌糊涂,总之是痛快!
  • 后端的开发流程上比较繁琐,需要组织协调的东西较多,可能习惯就好了吧。
  • 后端对整个业务的支撑起到了很重要的作用,对业务的推进和运营效率的提高有很大的帮助。
  • 有些东西确实是简单改改就可以扔上去的,没那么复杂。
  • 遇到问题解决问题,快速迭代,很快就能把系统迭代完善,不要等指示。
  • 双端思维更能全面理解系统,更容易推进项目。
  • 对业务熟悉程度决定了系统的最终实现效果,技术只是达成的工具。
  • 跟着业务走,进步的更快。
  • 很多技术形式也是跟着业务的发展而衍生的,如:大数据,数据挖掘,规则系统,机器学习……
  • 问题其实就是试炼,一次次对抗,一次次升级。
  • 尽可能高地去思考,尽可能勤奋地去实施。

Comments

Content