当使用 IDEA提交项目数据到 git 时, 即使配置了提交忽略文件.gitignore也无法生效,提交文件中会出现杂乱配置文件。

@Test
void booleanArrayToIntArray() {
    boolean[] inputs = {true, false, false, false, false, false, false, true, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false};
    int[] intArray = new int[inputs.length];
    IntStream.range(0, inputs.length).forEach(i -> intArray[i] = Boolean.compare(inputs[i], false));
    System.out.println(Arrays.toString(intArray));
}

类的静态方法

在类中static 修饰的方法是静态方法也叫类方法，可以直接调用，不需要创建实例

nohup 英文全称 no hang up（不挂起），用于在系统后台不挂断地运行命令，退出终端不会影响程序的运行。

首先安装 locales 软件包apt-get install locales

与复杂度的斗争是软件开发的一个永恒的主题，我一次又一次地看到它反复出现，并且不断在各个层面上看到有关的争论：到底应该在函数和方法中进行多少注释？理想的抽象是怎样的？一个框架何时开始拥有了「过多的魔法」？ 什么时候组织中有太多语言？

Netty 中内存分配有一个最顶层的抽象就是ByteBufAllocator，负责分配所有ByteBuf 类型的内存。功能其实不是很多，主要有以下几个重要的API：

前言

一个Java文件从编码完成到最终执行，一般主要包括两个过程：

UNIX 哲学基础

一个程序只做一件事，并做好。程序要能协作。程序要能处理文本流，因为这是最通用的接口。

第九章 在一起更好还是分开更好？

软件设计中最基本的问题之一是：给定两个功能，它们应该在同一位置一起实现，还是应该分开实现？这个问题适用于系统中的所有级别，例如功能，方法，类和服务。例如，应该在提供面向流的文件 I/O 的类中包括缓冲，还是应该在单独的类中？HTTP 请求的解析应该完全在一种方法中实现，还是应该在多个方法（甚至多个类）之间划分？本章讨论做出这些决定时要考虑的因素。这些因素中的一些已经在前面的章节中进行了讨论，但是为了完整起见，这里将对其进行重新讨论。

第八章 降低复杂性

本章介绍了有关如何创建更深层类的另一种思考方式。假设您正在开发一个新模块，并且发现了一个不可避免的复杂性。哪个更好：应该让模块用户处理复杂性，还是应该在模块内部处理复杂性？如果复杂度与模块提供的功能有关，则第二个答案通常是正确的答案。大多数模块拥有的用户多于开发人员，因此开发人员遭受的苦难要大于用户。作为模块开发人员，您应该努力使模块用户的生活尽可能轻松，即使这对您来说意味着额外的工作。表达此想法的另一种方法是，模块具有简单的接口比简单的实现更为重要。

软件系统由层组成，其中较高的层使用较低层提供的功能。在设计良好的系统中，每一层都提供与其上，下两层不同的抽象。如果您通过调用方法遵循单个操作在层中上下移动，则每个方法调用的抽象都会改变。例如：

第六章 通用模块更深入

设计新模块时，您将面临的最普遍的决定之一就是是以通用还是专用方式实现它。有人可能会争辩说，您应该采用通用方法，在这种方法中，您将实现一种可用于解决广泛问题的机制，而不仅是当今重要的问题。在这种情况下，新机制可能会在将来发现意外用途，从而节省时间。通用方法似乎与第 3 章中讨论的投资思路一致，在这里您花了更多时间在前面，以节省以后的时间。

第五章 信息隐藏(和泄漏)

第四章认为模块应该很深。本章及随后的其他章节讨论了创建深层模块的技术。

第四章 模块应该是深的

管理软件复杂性最重要的技术之一就是设计系统，使开发者在任何时候都只需要面对整体复杂性的一小部分。这种方法被称为模块化设计，本章介绍其基本原则。

第三章 工作代码是不够的（战略与战术编程）

好的软件设计中最重要的元素之一是您在执行编程任务时所采用的思维方式。许多组织都鼓励采取战术思维方式，着眼于使功能尽快运行。但是，如果您想要一个好的设计，则必须采取更具战略性的方法，在此上花费时间来制作干净的设计并解决问题。本章讨论了从长远来看，为什么战略方法可以产生更好的设计，而实际上却比战术方法便宜。

第二章 复杂性的本质

这本书是关于如何设计软件系统以最小化其复杂性。第一步是了解敌人。究竟什么是“复杂性”？你如何判断系统是否过于复杂？是什么导致系统变得复杂？本章将在较高层次上解决这些问题。后续章节将向你展示如何从较低的层次上根据特定的结构特征来识别复杂性。

第一章 介绍

编写计算机软件是人类历史上最纯粹的创作活动之一。程序员不受诸如物理定律等实际限制的约束。我们可以用现实世界中永远不会存在的行为创建令人兴奋的虚拟世界。编程不需要很高的身体技能或协调能力，例如芭蕾或篮球。所有编程都需要具有创造力的头脑和组织思想的能力。如果您可以可视化系统，则可以在计算机程 序中实现它。

前言

80 多年来，人们一直在为电子计算机编写程序，但令人惊讶的是，关于如何设计这些程序或什么是好的程序应该是什么样子的讨论却很少。关于软件开发过程(如敏 捷开发)和开发工具(如调试器、版本控制系统和测试覆盖工具)，已经有了相当多的讨论。还广泛分析了编程技术，如面向对象编程和函数式编程，以及设计模式和算法。所有这些讨论都是有价值的，但是软件设计的核心问题在很大程度上仍然没有触及。David Parnas 的经典论文“关于将系统分解成模块的标准”发表于 1971 年，但是在随后的 45 年里，软件设计的技术水平并没有超过这篇论文。