写在工作一年之际

火绒正在保护您的电脑,已保护365天

去年的11月1号进入这家公司,到现在已经整整一年了,也从一个到处闯祸的实习生成长到可以独立负责一些任务的新手了,如果要对过去一年做个评价的话,not bad
没有什么比困难更能考验一个人,过去的一年里,做过的比较困难的任务,有三个

第二个月,第一次独立负责

image.png

现在回想起来,也是噩梦般的经历,我大概做了这些

• elastic search,之前只是听说过这个框架但是完全不知道是做什么用的,项目结束之后已经灵活使用了(之后又研究了一些高级特性,比如function score)
• redis 也是第一次使用,当时没有引入基于redis的分布式锁框架,就用setnx来做加锁,项目完成后特地找了点资料研究了一下,对它内部的实现也有了点了解(redis的实现真的是就算只是一个bit都要想办法去优化)
• protobuf 同样第一次使用,刚开始很害怕,写了一个之后才明白并不复杂(至少使用的时候不复杂)
• 多线程设计 当时要做的东西类似于在线ktv,有一个待唱列表,每个人都能操作,主持人有更高级的权限.对于当时的我来说,挑战很大,多亏大佬们的讲解.自己也是一点一点领悟修改,写出了一版不完美但是能跑.想一下当时自己傻傻的埋头苦写不知道去问,还让大佬们主动来指点我,真是羞愧万分
• 接口设计 接口需要哪些参数? 有些数据是不是后端自己就能获取? 前端传递的数据是否可信? 如果要返回的数据,有一部分是逻辑相关的,是不是要把他们封装到一起? 对敏感数据用get还是post? 这些是我那段时间学到的,这块是前端大佬们一点一点把我教会了,十分感激.

最后在两周延期后有惊无险的上线了,这次做的并不好,之后一次还坑了大佬一次,唉,羞愧.
之后也想过重构,忙了七八天,大佬给的评价是"你这是重写,不是重构", 为此特地找了几本重构相关的书,最后意识到我那确实是重写了,哈哈

第六-七个月,负责独立的模块

这次是做两个模块,好友聊天和随机匹配,匹配之前老项目里有类似的,自我感觉难度不是很大

• 允许抄,但是要根据自身场景做变化,不能死搬硬套
  当时我就是死搬硬套,也没去思考下两边有没有什么区别,被leader狠狠的批了一顿,这次是真的活该哈哈哈,下去之后仔细研究了一下修改之后确实看着更自然也更好做了

• 技术是为业务服务的,写的再好效率再高,不能满足业务也是白搭
  写匹配的时候,考虑过多个方案,有几个可以说是为了效率不顾一切吧哈哈,每次都被毙掉,最后leader说了一些话,大致意思就是上面这些,也就是从那时候开始自己才真正有这个意识,做设计的时候也会仔细思考一下这块

• 代码中要考虑到极端情况
  "如果redis挂掉一段时间你这块会怎么处理?","那就挂掉喽".嗯,不出意外又被diss了.第一次听说要考虑基础服务挂掉代码如何继续运行时,我的第一反应是基础服务都挂掉了,那就都挂了呗,后面自己仔细想想才体会到它的真正含义,基础服务挂掉并没有想象的那么罕见,如果是核心逻辑,确实要考虑到这些情况.

• 不要过早优化
  当时刚刚看了几本代码优化方面的书籍,迫不及待的试试手(这些书上是提了不要过早优化的),写完之后才意识到有些优化确实做得太早了,徒劳无功.
  在整体逻辑尚未成型时所做的优化,一般来说时负优化.前期整体结构还不固定,业务随时可能变动,现有的逻辑也不一定正确,在这种基础上做的优化往往是徒劳无功.后面改起来反而更麻烦.但是并不是说不做优化,通用逻辑封装这些还是可以做的

• 要尝试理解用户,从用户的角度去做业务
  做到好友聊天这块时,有这个场景,用户选择挂断,这里可能有并发问题,可能另外一个用户提前点击了结束,那么请问这个操作能报错吗? 当然不能,从用户的角度看,我不想聊了,想结束都结束不了? 这是不能接受的.
  最后附上leader当时说的几句话,个人认为很有意义,如果业务出现了异常情况,按照解决方式从好到坏排列分为 1. 后端能解决 2. 用户能解决 3. 卡死

一年,开发核心逻辑

135da41db13cfbf6.png

要做一个游戏,开发时间一周.时间很紧,游戏的主流程是我做来做的,很累.万幸的是按时完成了.

• 不要固执己见,要听取别人的意见
  因为之前不了解游戏角色的当前血量设计,加上时间紧(只能说是当时的托词),没有听取前端同事的意见,做到后面果不其然出了问题,最终还是改成了他提的那种设计,这次教训很惨重,大概浪费了半天时间,如果当时能够仔细的询问一下,思考一下,可能节省出更多时间,做一些其他地方的优化.(这里大概也有些沟通方面的问题吧,与君共勉)
• 不能容忍重复代码,要懂得抽离通用逻辑,分离变化与不变
  这点是这次自己做的比较好的,还是上面的血量设计,一共改了两次设计,得益于前期封装的很好,每次更改设计改动的代码不超过100行.想一下如果当时偷懒没做封装,业务逻辑又这么复杂,肯定不能按时上线了
• 写代码纠结是好事
  有这个场景,要把map中所有的值自增,为了这个纠结了半个小时写了一个性能和可读性都还行的设计,时间是很紧,但这不是理由,作为一个程序员,如果没有对优雅代码的追求,那和咸鱼有什么两样
• 对于核心流程要考虑要任何可能的情况
  参见上面的代码中要考虑到极端情况,有一个场景,玩家死亡时会可能会掉落一些物品,如果氪金了就不会掉了,因为前端要显示,所以在死亡时就要计算好会掉什么,如果玩家确认重生了才会扣除(氪金当然就不扣了),可能掉落的物品肯定用redis来存了,当时就考虑到如果用户死亡后,确认放弃前.发生了一些异常情况导致扣除失败,这种情况是不能报错的,如果报错用户就无法继续游戏了,这个情况是不能接受的,所以对这块做了处理,不管能不能扣除成功都确保用户可以重生.之后查看线上日志发现确实派上用场了,这点算是这次比较得意的设计了,嘻嘻.

这一年我学到了什么

1. 一定一定一定要跟产品确认所有不确定的细节
这里不是黑产品,产品想做的和程序员想出来的很可能有很大偏差,如果不做确认和可能出现以下两种情况

1. 本来很简单的东西程序理解的太复杂,导致做了很多无用功
2. 本来很复杂的东西程序理解的太简单,导致代码不可能,最坏的情况就是重写

另外程序主动跟产品确认需求还有一个最大的优点,对于这个需求,程序已经有自己的理解,并很可能有初步的实现方案了,而产品可能还不确定自己想做什么,这样就很有可能将一个很复杂的需求简化

2. 学习一项新技术时,没有什么是比官方文档更可靠地
花的时间去钻研官方文档,比漫无目的的看博客好很多.

3. 要懂得请教别人,个人的思维是有局限的,别人往往能发现自己的逻辑漏洞
举个例子,对于一个需求,自己想了一下有了大概的设计,觉得是可行的, 这个时候请教一下同事,将自己的设计复述一下,如果对方能理解并且没有发现问题,那这个设计就不会有大的纰漏.可以说是起到及时止损的作用.(PS.请教时一定要有礼貌和足够的尊重,大家都很忙,没人有义务去帮你的)

4. 做业务时可以'拿来主义',但是事后要去研究一下
如果一直都是拿来主义,不去自己死磕研究一下,技术不会有任何进步,就真的变成了日常搬砖了

5. 终身学习真的不只是说说,要抽出时间来学习新知识
工作时间越长越能感觉到自己的不足,各个方面的知识都欠缺的很多,要每天抽出些时间去读,去学,去使用.业务是做不完的,如何抽时间就见仁见智了.

6. 运动! 运动! 运动!
每天运动一下,保证三天至少跑步一次. 运动很重要,并不只是因为健康,运动可以极大的缓解压力,补充意志力.每天不用动的话,心态真的会爆炸的.

7. 要明白自己真正想要什么要对未来保持憧憬
搞技术是枯燥的,就算对技术再痴迷,也是会有困倦的时候,这时候你需要明白自己真正想要什么,它一定是和技术无关,而是和人生相关的.如果不是想到她,我可能真的无法坚持下来.

结语

终于把这篇总结写完了,也算是给自己一个交代,与诸君共勉.