前言

这个礼拜似乎是写了一礼拜的业务代码，没遇到什么太恶心的坑，就是理解业务逻辑费了点功夫。下个礼拜似乎又要开始撸组件撸网页了，现在想想感觉还是写写业务比较舒服，没事可以怼怼产品，给前端找找bug，写完还可以慢慢测；撸组件就比较无聊了，容易出大锅，而且还得求着人家用，用出问题还会被怼。。。不过好处大概就是以后跳槽面试的时候不容易被问死吧。。。

知识&技巧

常用@see和@link注释

写代码的时候经常会遇到一些需要枚举的类型，比如“活动类型”、“数据来源”这类的。但是一般来讲我们不会直接用enum类型，因为这些数据一般都是以整数的形式存储在数据表里面，因此用整型去存储、转移会更加方便。所以一般我们都是直接声明成一个整型，然后用另外一个类去存储这个类型的值，比如:

1
2

//需要引用的地方
int xxxType;

1
2
3
4
5
6

//该类型的值
public interface XxxType {
    int type1 = 1;
    int type2 = 2;
    int type3 = 3;
}

这样搞没啥问题，但是比较讨厌的就是，当另外一个人看到xxxType这个字段时，他可不知道这玩意的值是XxxType去记录的，他甚至有可能去用YyyType的类型去给xxxType赋值。这就说不清楚了。

因此一个比较简单的方法就是把注释写清楚了，而相比普通的注释，java的文档注释就比较好用了。这里面有一个@see的注释，非常适合这种场景：

1
2
3
4

/**
* @see the.package.of.XxxType
*/
int xxxType;

也可以使用{@link}注释，达到类似的效果:

1
2
3
4

/**
* {@link the.package.of.XxxType}
*/
int xxxType;

这样无论谁在给这个字段赋值时，都非常清楚的知道该赋什么值了。这一点jdk做的就非常好，要向他学习。。。

前言

好快啊，又是一周的轮回，本来打算把本周遇到的问题展开一个一个总结的，但是奈何踩的坑是在有点多，展开来根本没时间搞，索性就搞了这个类似周报的东西。希望从这一周开始，每一周都能坚持下来喽。

由于跟给老大看的周报不同，这个是给俺自己看的，所以成果啥的就不表了，主要表一表自己写的bug跟领悟。就记一些大实话吧，”写者有罪，闻者足戒“。

知识&技巧

while循环的控制逻辑写在循环体内

这句话是同事跟我讲的，领会了下他的意思，大概是，下面的写法二要比写法一好:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

//Method1
while (!shouldBreak1() && !shouldBreak2()) {
    //Do sth
}

//Method1
while (true) {
    if (shouldBreak1()) {
        break;
    }
    if (shouldBreak2()) {
        break;
    }
    //Do sth
}

方法一看似简单清晰，一行代码就完成了控制逻辑，但是这样其实有弊端:

1. 调试麻烦，如果条件越来越多，容易混淆出错的到底是哪一行
2. 打日志不方便，这很显然
3. 逻辑一致性较差，有的控制逻辑可以写在开头，可有的控制逻辑就无法写在开头了，这时候不如都直接写在代码体里，保证一致性。

当然，复杂逻辑适合方法二这么搞，但是辩证的看，如果逻辑比较简单，用方法一也无可厚非嘛。

不要对数据表的记录进行物理删除

前言

前一段时间在做代码性能比较的时候用到了jmh这个工具，原本以为拥有了这个方便的工具就能hold住java微基准测试这个命题。但是事实上，用着用着就发现自己的理解还非常不深入，有很多在测试的时候难以解释的现象。于是查阅了相关资料，才发现这里面的水比我想象要深，趁着记忆还热乎，赶紧记录一下。

动态编译VS静态编译

java作为一种动态编译语言与c/c++这种静态编译语言有本质的不同。静态编译语言是在编译时就已经对代码做好了编译优化(比如C/C++在编译时指定-O1 -O2 -O3参数)，得到的程序能够直接被计算机忠实地执行。而java这种动态编译语言在编译时几乎不会做什么优化，而是等到运行在虚拟机中时，动态的进行优化。

动态优化有好处有坏处，好处就在于他可以根据程序实时的运行状况，忽略掉那些事实上没有被执行的代码的影响，最大化的优化那些被多次执行的代码（这也是jvm有“预热”这一说法的原因）；但是，缺点也在于，随着程序的运行，程序运行的环境会发生变化，如果继续保留之前动态优化的代码则会无法起作用甚至可能会出现错误，此时就需要卸载之前做的优化，这就是“动态反优化（Dynamic Deoptimization）”。

显然，我们并不希望jvm经常进行动态反优化，但是其实正常情况下，相比于程序逻辑的执行时间，这点反优化造成影响还是微不足道的。相比于他带来的问题，我们往往更加享受他带来的便利，因此大部分情况我们也无需太在意这些细节。但是当我们分析问题的粒度逐渐变小时、尤其是在做微基准测试时，就需要做到对这类问题心中有数了，否则就可能贻笑大方。

诡异的问题

说的可能有点玄乎，举一个简单的例子，比如下面这样一段微基准测试代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

package com.pinduoduo.tusenpo.test;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.OptionsBuilder;

import java.util.concurrent.TimeUnit;

@BenchmarkMode(Mode.Throughput)
@Warmup(iterations = 5, time = 200, timeUnit = TimeUnit.MILLISECONDS)
@Measurement(iterations = 5, time = 200, timeUnit = TimeUnit.MILLISECONDS)
@State(Scope.Benchmark)
@Threads(4)
@Fork(0)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class Test {

    private interface Operator {
        int operate(int d);
    }

    private class Method1 implements Operator {
        public int operate(int d) {
            return d + 1;
        }
    }

    private class Method2 implements Operator {
        public int operate(int d) {
            return d + 1;
        }
    }

    private void callMillionTimes(Operator op) {
        int d = 0;
        for (int i = 1; i < 1000000; i++)
            d = op.operate(d);
    }

    @Benchmark
    public void test_1_Method1() {
        callMillionTimes(new Method1());
    }

    @Benchmark
    public void test_2_Method2() {
        callMillionTimes(new Method2());
    }

    @Benchmark
    public void test_3_Empty() {
    }

    @Benchmark
    public void test_4_Method1Again() {
        callMillionTimes(new Method1());
    }

    @Benchmark
    public void test_5_NaiveLoop() {
        int d = 0;
        for (int i = 1; i < 1000000; i++)
            d = d + 1;
    }


    public static void main(String[] args) throws RunnerException, InterruptedException {
        new Runner(new OptionsBuilder().include(Test.class.getSimpleName()).build()).run();
    }
}

这段代码中我们定义了一个父类Operator和他的两个子类Method1、Method2，这两个类的实现完全相同，相当于一个自增操作。同时测试了五个方法：

1. test_1_Method1，将Method1的方法执行一百万次。
2. test_2_Method2，将Method2的方法执行一百万次。
3. test_3_Empty，这其实是一个空方法。
4. test_4_Method1Again，与test_1_Method1完全一样。
5. test_5_NaiveLoop，这个方法体现的是Method1和Method2的“本质”。

前言

前几天在面向 stackoverflow 编程时，遇到了一串有点诡异的代码:

1
2
3
4
5
6
7

private String method1(byte[] bytes) {
    StringBuilder sb = new StringBuilder();
    for (byte aByte : bytes) {
        sb.append(Integer.toString((aByte & 0xff) + 0x100, 16).substring(1));
    }
    return sb.toString();
}

对java还不是很熟，乍一看还是有点懵逼的，于是就抽了个时间研究了下。

分析

这段代码其实只做了一件简单的事，就是将一个字节数组转换成一个十六进制字符串，比如说传入{1,2,126,127,-1,-2,-127,-128}，就会输出01027e7ffffe8180。这种类似的代码在很多需要进行编码的场景下还是很常见的。

其实正常人在写这种功能的时候是这样写的：

1
2
3
4
5
6
7

private String method2(byte[] bytes) {
    StringBuilder sb = new StringBuilder();
    for (byte aByte : bytes) {
        sb.append(String.format("%02x", aByte));
    }
    return sb.toString();
}

这种代码还是比较好理解的，将一个byte转换成两个字节的十六进制字符串，通俗易懂。那method1是如何实现相同的功能的呢，这里有两个难点，理解了就简单了。

1. 为什么要& 0xff
2. 为什么要+ 0x100并且要substring(1)

第一点，是因为java中的byte是有符号的，为了使用Integer.toString()转换成16进制，必须要有一个从byte到int的转换。而默认的转换方法会保留符号，比如对于一个负数的byte，转换成int后符号位就提到最前面了，而我们期望的是无符号的转换。因此这里使用了& 0xff的方式，隐式的进行了无符号的转换。

第二点，是因为在byte转换为int后，在末8位的部分有可能是以0开头，这样转换成16进制后，生成的字符串长度就会小于2,开头的0就被舍弃了。因此我们通过+ 0x100的方式强制生成一个长度为3的字符串，再用substring(1)将开头的1舍弃，这样就保证了输出的字符串长度一定是2。

前言

好久不更新了，前段时间一直忙着毕业这段时期的各种腌臜事：找工作-当咸鱼-做毕设-当咸鱼-毕业旅行-沉迷游戏-搬家-办入职-适应新公司，到现在总算是有大把的时间闲下来做自己想做的事情了，还真是不容易。不过说是没时间，其实更大的可能还是懒吧，懒散了一段时间发现自己经常是提笔忘字，讲话以及做事情的逻辑不知道怎么就变乱了，真可怕。看来还是得重拾码字的习惯，理顺思路，整理逻辑。安顿下来的这段日子过得还算平稳，就想抽个时间把自己人生中第一次求职的经历记录下来，

实习

实习面试，想来也是一年多前的事了，可现在记起来还是历历在目。那大概是我第一次与职场接触吧，一切都是那么新鲜，对工作有着无限的好奇跟热情。看惯了破破烂烂的教室跟寝室，发觉自己突然处在一个环境优雅、干净大方、连卫生间都有香氛的地方，脑海里剩下的字也就只剩下了“惊喜”。不过随着工作的接触，我逐渐对华为有了更加深刻的理解。这是一个井井有条的小社会，高层管理者通过价值观的输出一层一层的去影响到金字塔底层的员工，使得整个公司的价值观从原则上保持高度的一致：”以客户为中心，以奋斗者为本，以结果为导向”。封闭的舆论以及权力的集中像极了党国治理国家的模式。这种方式的效率其实是很低的，但是由于上层的设计以及任务拆解做的非常的细，每一个人都只需要专注于自己做的那一小部分工作即可，然后通过一层一层大大小小的经理，将工作向上层进行汇报。在华为内部，与他人沟通的代价非常低，各种电话会议可以随便拉，这也就导致了沟通的效率很低，很多情况下是能电话打通的就不会打字，估计很多人都会在梦中被”Welcome to join the conference”的提示给惊醒。

从公司的角度上讲，这样的制度能保证公司的稳定，以及高层的指令能够被高效的传达贯彻；从个人的角度讲，每个人也都能比较轻松的适应并胜任自己的工作。可坏处就是，凝聚力的集中很容易形成互相取暖的小团体，容易产生派系斗争；而每一名员工虽然可以都能通过自己占有的资源，利用信息不对称，保证自己工作的价值，但是一旦离开了公司的平台，剩余的技能在目前的就业市场上优势就不是很大了。事实上由于通信产业的逐渐萧条，华为高层其实在努力思考转型，比如终端业务，SDN业务，无人车业务等的业务转型，以及增加福利，拥抱开放等的文化转型等。据说现在华为也有免费夜宵了，挺遗憾没有享受到过，哈哈。

随着互联网生态圈的兴起，事实上华为对应届生的吸引力已经越来越小了，无论是从文化、工作压力还是工作待遇上讲，如果能够有更好的选择，大多数同学还是更倾向选择互联网公司。但是不可否认的是，华为是一家伟大的公司，像IBM一样，即使经历各种灾难仍然能屹立不倒。

违约

由于实习期间的感觉就是工作死板，技术老旧，流程僵化，感觉对于自己的技术提升不是很高，不过由于跟主管的关系不错，部门一直缺人，所以也没有早离职，从去年七月一直干到了十一月。其实本来由于怕麻烦，怕面试，各大公司的秋招也没有参加，一开始也是打算就在华为先干几年再说的。但是后来拿到转正offer的时候无意中发现自己的offer是小组里最低的一档，顿时就感觉不是很舒服。权衡再三还是打算出去尝试下新的机会，正好经过一段时间的努力，在春招的时候捡了几个个人感觉还不错的offer，于是就打算办理违约。

虽然传说华为办理违约非常坑，但是一套流程走下来的感觉还是比较正常的，既没有很麻烦，也没有很轻松。毕竟现在是契约社会，想要食言可不是那么简单的事情。我是今年四月六号向HR邮箱提的违约申请，隔了两天HR向我提供了违约流程以及具体的方法。我得到的响应还是比较快的，但是这其实这只是按照公司流程办事，公司规定所有的违约都是四月份开始办理，所以即使是去年底提违约请求的那些人，也是四月份左右才会开始办理违约。当然，违约还是有很多坑的:

1. 违约申请单由华为提供，并且需要学院或者招就办先盖章，公司才会盖章。而很多学院是不允许盖这种章的，尤其是那种卡违约名额的学校。而且违约申请单上还注明了一句话”此单不代表公司同意违约”，这一点会在与学校沟通盖章的时候处于劣势。还好我们学校不卡本科生的违约，不过还是磨了半天嘴皮子才把章盖到的。
2. 漫长的等待，毕竟华为的违约不需要付违约金，这种事情在HR那边的优先级也就比较低了，估计都是抽空办理的，而且还有走漫长的部门审理以及法务审理。把违约材料提交上去之后就是漫长的杳无音信的等待了。我等了一个月。
3. 公司不返还旧三方原件以及就业推荐表，这一点还是很坑的。在拿到了盖了公司章的违约申请之后，大多数学校还都是需要凭借三方的原件才能给新的三方盖章，同时就业推荐表也是只印一份。我们学校的招就办也是照章办事不留情面，材料不足不给办理。后来还是去报社办理了遗失启事，拿了登了报的遗失声明给招就办的老师看了才成功领到了新的三方跟就业推荐表。