月度归档： 2020 年 3 月

世道与人心

两个不同故事,同样的选择,简明解释世道与人心

故事1:一个富二代看下一个穷姑娘,假装穷小子接近,后来成为情侣, 有一天男子家境暴漏
故事2:一个穷小子看下一个穷姑娘,假装富二代接近,后来成为情侣, 有一天男子家境暴漏

姑娘的选择:A)我不在乎钱,只想和他一起 B)渣男,欺骗我感情,分手

故事1,多数选 A 这就是世道
故事2,多数选 B 这就是人心

JDK 14 正式发布，新特性关注

2020年3月17日JDK 14 正式发布了，其中还是有一些值得关注的新特性。如果你觉得我写的东西对于您有帮助，希望得到您的关注！

一、instanceof的模式匹配：

Instanceof是java中用于检查对象引用是否为给定Type类型的实例，并返回布尔值。在Java 14之前，我们在完成判断之后，经常需要做一下类型的强制转换，如下：

if (obj instanceof String) {
    String str = (String) obj; // 需要强转
    .. str.contains(..) ..
}else{
     ....
}

Java 14增强功能特性：

if (!(obj instanceof String str)) {
    .. str.contains(..) .. // 不再需要转换代码，实际发生了转换
} else {
    //.. str.... 这里 str 会是未定义
}

更多示例：

if (obj instanceof String str && str.length() > 5) {.. str.contains(..) ..}

if (obj instanceof String str || str.length() > 5) {.. str.contains(..) ..}

注意：仅当object不为null时，instanceOf才会匹配，然后仅将其分配给str。在instanceof中使用模式匹配可以减少Java程序中显式强制转换的数量。

二、NullPointerExceptions（注意带s）

在java 14之前，我们经常在调试代码的时候，发现一行代码中有多个对象，抛出异常之后你也无法确定到底是哪个对象为null。假设此代码中出现一个NullPointerException：

 a.b.c.i = 0;

//下面是异常信息
Exception in thread "main" java.lang.NullPointerException
                            at Prog.main(Prog.java:5)

文件名和行号不能精确指出哪个变量为空。是a还是b或c？JDK14对此做了改进。

Exception in thread "main" java.lang.NullPointerException:
        Cannot read field 'c' because 'a.b' is null.
    at Prog.main(Prog.java:5)

但是，这也存在一些风险。空指针异常消息包含源代码中的变量名。暴露此信息可能被视为程序的安全风险。

三、switch表达式

在Java 14之前*

switch (day) {
    case MONDAY:
    case FRIDAY:
    case SUNDAY:
        System.out.println(6);
        break;
    case TUESDAY:
        System.out.println(7);
        break;
    case THURSDAY:
    case SATURDAY:
        System.out.println(8);
        break;
    case WEDNESDAY:
        System.out.println(9);
        break;
}

Java 14增强功能

switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
    case TUESDAY                -> System.out.println(7);
    case THURSDAY, SATURDAY     -> System.out.println(8);
    case WEDNESDAY              -> System.out.println(9);
}

四、record

Java 14使用record关键字来减少类声明语法，这有点像lombok。我们有时候需要编写许多低价值的重复代码来实现一个简单的数据载体类：构造函数，访问器，equals（），hashCode（），toString（）等。为了避免这种重复代码，Java 14推出record。 java14之前的代码：

final class Point {
    public final int x;
    public final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    // 很多的equals, hashCode, toString，getters、setters
}

Java 14中就用这一行代码

record Point(int x, int y) { }

五、文本块

在Java中，要将HTML，XML，SQL或JSON代码片段嵌入到代码中通常很难阅读，为了克服此问题，Java 14引入了Text Block。 java14之前，没有文本块的HTML示例

String html = "<html>\n" +
              "    <body>\n" +
              "        <p>Hello, world</p>\n" +
              "    </body>\n" +
              "</html>\n";

java14，带文本块的HTML示例，下面的代码看上去是多行的，实际上字符串的拼接结果仍然是一行的。

String html = """
              <html>
                  <body>
                      <p>Hello, world</p>
                  </body>
              </html>
              """;

如果你希望字符串中有换行，在每行的行尾加上“\”,这样字符串就是换行的了，可以打印出来看一下。

String html = """
              <html>  \
                  <body>  \
                      <p>Hello, world</p>  \
                  </body>  \
              </html>
              """;

IDEA2019.3安装和激活

之后进到这个界面，点击 Configure -> Edit Custom VM Options

在最后加上   -javaagent:/data/jetbrains-agent.jar

 这个jar包是需要用来破解的jar包：   https://files.cnblogs.com/files/quyf/jetbrains-agent.zip

IntelliJ IDEA 破解之后，用了一段时间后，打开软件提示 no suitable licenses left on the license server

需要让我们重新注册，原来是之前的地址服务更改为了新的地址： http://fls.jetbrains-agent.com

所以我们在使用服务器激活的时候使用新的地址代替原来的地址即可：http://jetbrains-license-server/

沟通难四个原因

《PMBOK 指南》将沟通管理划为一个专门的知识领域，建议项目经理花 75% 以上的时间在沟通上。根据美国普林斯顿大学的调查报告，在所有对工作产生影响的因素中，沟通占的比例高达 75%。而我们工作中出现的 80% 问题都是由沟通不当造成的，可见沟通的重要性，因为沟通实在太难了。多数时候，我们只想着表达自己的观点，只关注自己想说什么，我们会尽量使用漂亮的 PPT、华美的语言、一堆的数据、甚至引章据典，而不关心别人听懂没有，没有思考别人是否想听，别人是否听得懂。

沟通难主要出于以下四个原因：

第一种是由于立场、利益、背景的原因，当双方缺乏信任，或处于敌对状态时是无法沟通的，这个时候的沟通和所说内容的对错没有必然的关系，对方只想找差错，找到了就会理解为阴谋论，并且非常兴奋，所谓道不同不相为谋。这是最困难的沟通场景，越沟通，矛盾分歧会越大，实际是无效沟通。在公司中，经常会因为组织架构设计的不合理，造成团队利益的冲突，从而产生很多的无效沟通。

第二种是由于语言、专业知识、职位、环境的巨大差异，造成沟通方面的巨大鸿沟，本质上是思维方式、常识、知识储备的不一致造成的认知差异，这样的沟通成本非常巨大，需要恶补相关知识，参加专业培训消除鸿沟才能够创造沟通的条件。

第三种是由于沟通信息衰减造成的，语言文字是我们主要的沟通方式，但是很多时候光靠语言文字会有歧义，比如我们对名词概念的理解可能会有不同，甚至可能会完全相反，对语言中所带情绪的理解也不同，而这些都会造成信息的压缩。有研究表明，对话沟通中语言起到的作用仅占 38%，而肢体语言所占的比例高达 55%。你想表达的意思和你说出来的话语会有差异，对方听到的信息和对方理解的意思又会有差异，这就形成了我们通常说的沟通漏斗：
第一个漏掉 20%：你想表达的是 100%，实际表达的只有 80%，主要原因有语言词汇的限制等；
第二个漏掉 20%：听者只接收了 60%，主要原因有信息衰减、听得不仔细等；
第三个漏掉 20%：听者只理解、听懂了 40%，主要原因有词语理解能力、注意力不集中等；
第四个漏掉 20%：最后听者只记住了 20%，主要原因是没有反馈、容易忘记等；而随着时间的推移，如果不持续做交流沟通，最后的 20% 也会被忘记。

第四种沟通障碍是沟通交流者的心态，这个又和企业、团队的组织架构及文化有关，以下举例一下可能存在的心态对沟通的影响：刚刚进入

充满信任的技术团队

LinkedIn 首席执行官杰夫·韦纳（Jeff Weiner）认为，“在时间的流逝中保持一致就是信任”，这个“一致”有很多含义，如目标的一致、行动的一致等；微软首席执行官萨提亚·纳德拉（Satya Nadella）认为，“信任 = 同理心 + 共同价值观 + 安全可靠”，他把“同理心”放在了信任等式的第一位，认为无论做什么事情，都需要大家对所做的事情产生共鸣。

团队合作中，每个成员的工作多多少少都会和其他人有一些上下游交互，如果上游的人总是能够对下游人的诉求快速响应，无疑会让下游的人感觉更加安心。以我们的交付团队为例，我们有专职的集成测试团队，他们要负责软件发布前的最后一轮验收，但是开发团队的交付延迟总是会把集成测试团队搞得手忙脚乱，团队内的相互指责也从来没有停止过。后来，我们引入了统一研发看板系统，使得每一个员工的任务都在看板上可见，任何下游的同事都可以看到其依赖的上游员工的进展和潜在的风险。通过这套实时反馈系统，下游员工可以提前了解风险，以便及时采取应对措施，那种一无所知的不信任感很容易就消除了。可见，员工之间要及时进行沟通，才能及时获取自己关切的信息，团队人越多，沟通效率越低，越要想办法增加沟通的带宽，而构建可以透明呈现所有人信息的系统是一个不错的实践。

1994 年，心理学家 Freeston 等人提出了“无法容忍不确定的程度（The Intolerance of Uncertainty）”这一概念，简称 IU。一系列研究认为，IU 是担心、焦虑产生和维持的关键影响因素，也是焦虑及焦虑障碍的最重要预测指标。对于不确定的焦虑，会影响我们的知觉控制水平，也就是我们所感知到的“自己能够在多大程度上影响事情的结果”。当我们对不确定的焦虑越高时，我们就会越不相信自己能够影响事情的结果，对自己的贡献就会越不信任。