Class彩蛋

class的文件结构,第一部分是一个MagicNumber——0xCAFEBABE。

很有意思是不是,Cafe Babe。

Wiki里面记录了这个名字的来源,很有意思,地址如下:

https://en.wikipedia.org/wiki/Java_class_file

我们过去常常去一个叫圣迈克尔巷的地方吃午饭。根据当地传说,在黑暗的过去,感恩的死者在成名前曾在那里表演。这是一个非常时髦的地方,绝对是一个感恩死亡的地方。杰瑞死后,他们甚至建起了一座佛教风格的小神龛。我们过去常去那里,我们把那地方称为死亡咖啡馆。沿着这条线的某个地方,人们注意到这是一个十六进制数。我在重写一些文件格式代码,需要几个神奇的数字:一个用于持久对象文件,一个用于类。我使用CAFEDEAD作为目标文件格式,并在“CAFE”(这似乎是一个很好的主题)之后添加了4个字符的十六进制单词,我找到了BABE并决定使用它。在那个时候,除了历史的垃圾桶之外,它似乎并不十分重要或者注定要去任何地方。因此CAFEBABE成为了类文件格式,CAFEDEAD成为了持久对象格式。但是持久对象工具消失了,随之而来的是CAFEDEAD的使用——它最终被RMI所取代。

更巧合的是,0xCAFEBABE的数值表示3405691582,我们对其所有的数字求和,得到的是43,而43正是银河系漫游指南中,宇宙终极答案42,再加一,代表着比终极更进一步(当然,这是我扯淡的)。

老外做这些东西,总是能给人带来一些意外的惊喜。

Let it Crash

“就让它崩溃”(Let it Crash),最近看到一篇文章,说的是微软的老前辈Jeff Richter在一次演讲中,说道:「别去捕获你不知道该怎么处理的exception,Let it Crash」,有人问到,那这样程序不就崩溃了吗,他解释到,没错,Let it Crash,crash is awesome。

其实我们经常遇到这样的问题,很多同事为了避免App崩溃,都会直接把代码catch住,最多再打个log,甚至直接空实现,这样的好处确实是异常被捕获了,App没有崩溃,但是这时候程序的执行逻辑可能已经错了,但是它还在苟且偷生,这些地方就是其他人很难确认问题来源的原因,原本会直接Crash的代码,在崩溃之后很容易就能找到错误的原因,但是现在这些错误都被隐藏了起来,一旦这些错误越来越多,就更难确定最初错误的原因,这也是为什么Jeff Richter会说Let it Crash的原因,出现了不能处理的exception,就应该给到调用者去处理,如果调用者也不处理,那就崩溃吧,把问题暴露出来,才能让代码更健壮,掩盖问题与解决问题,是两个完全不同的两码事。

当然,在中国化的开发下,这个观点也不能完全正确,我认为最好的做法应该是在开发阶段尽可能多的暴露异常,而在生产阶段,尽可能的屏蔽异常。

代码重构

越是资深的程序员,越是不敢轻易重构代码,年少轻狂的时候,不知道栽了多少个跟头。

为啥?

究其原因,代码重构就跟考古一样,这段代码可能从产品到开发到测试,全部都换过一轮了,谁也不知道在它那个时代,这个代码到底隐藏了什么。

所以,从代码反推业务逻辑,实际上是一件非常痛苦的事情,这也是为什么考古这么难的原因,也许现在你认为一件显而易见的物品,放到几百年后,可能被认为是天外来物一样。

重构,第一步就是要想清楚,我们重构的目的是什么,第二步,就是要梳理重构的方案,同时拿着方案向产品和测试寻求帮助,共同完善方案逻辑,而且各个角色的人从不同角度,也能发现一些潜在的问题,将风险提前暴露出来。

最后,也是最重要的,永远不要单干,产品、测试、同事都不认可不配合的重构,是没有上线的意义的,重构不仅仅是技术的事情,同样需要产品对逻辑把关,测试对质量验证,这样才能安全过渡,完成重构。

处理异常

相信大家在开发过程中,都遇到过那些写了try catch,但是catch里面什么都不做的同事。

这是一个很不好的习惯,将问题完全隐藏了起来,处理异常,通常有3种方式:

  • 转换
  • 重试
  • 记录

转换,是将异常做简单的分析并抛出,这样可以根据错误信息,了解到更详细的异常原因,方便分析,在业务中定义的错误码,就可以借助异常转换,快速定位问题。

重试是解决异常的一个非常好的方法,有时候由于各种不确定的问题,导致偶现的异常,通过重试就可以恢复,所以在一些可能的场景,可以借助重试机制来避免异常的发生。

而记录,则是在异常无法避免时,将异常的现场记录下来,方便分析。

异常处理,是编程中的一个非常重要的部分,正常的逻辑功能,可能只占我们编码量的40%,大部分情况,我们都是在处理各种异常分支,所以,重视异常吧。

中台

Supercell:听说中国有一群公司给我定义了一个词叫中台,然后花了几十亿,最后狗屁没有,还有一群写手写一些云山雾罩的文章夹杂在干货文章中间,而我们,只是想把游戏开发的容易一点而已。

中台存在的基础是什么?

中台的前提是业务有明确的功能划分,像supercell,都是开发的快节奏小游戏,类型比较相似,如果你让它做个王者荣耀,它的中台基本就没法使用了。

所以,什么东西适合做中台,什么都是适合做平台,什么东西什么都不该做,这就是领导的决策了。