设计模式是一系列优秀的代码构思实践。但从代码的功能性角度来说，很难定义什么是优秀的。“这不是也能跑吗”是对这个想法的准确体现。如果两份代码执行表现完全相同，凭什么说，其中一份比另外一份代码要好？设计原则回答了这个问题。 在日常开发中，看到一份代码变量名规范，注释规范，我们会说代码是好的。这是从可读性上对代码进行的评判。而设计原则从另一个角度进行评价：代码复用和拓展性。有时候设计原则和可读性是相违

Git是最常用的VCS(version control system，版本控制系统)工具。在Git中，多人协作开发涉及到多分支，而分支管理则必然会涉及新建分支和分支合并。相对于新建分支，分支合并复杂得多，是问题的高发地段。合并分支通常有两种方式，merge和rebase。其中merge是通过新建一个特殊的提交（本文不加区分地使用提交/节点），这个提交指向了两个节点（常规的提交只有一个父节点），这

最近半个月，结合视频和书籍，把设计模式反反复复看了好几遍。 编写设计模式的笔记和分享，确实具有一定难度。首先，设计模式本身是抽象的，是对实践经验的总结。这意味着，对于每个设计模式，并没有完全确定的规范，不同的人有着不同的经验，也会有不同的实现。所以设计模式本质是一种思想，是不同实现中的相同部分，而思想本身很难用文字来完整表述。其次，笔记很容易变成网络上已有资料的复制。因为从头思考每个概念，琢磨其

在SpringBoot-Lazy-Initialization提到，懒加载可以延迟容器中单实例的创建时机，从容器启动时延迟到实例被使用时。 在实际设置懒加载时，遇到了一些问题，在此记录并分析。 静态方法访问 如果试图调用一个类的静态方法，而此方法依赖的静态变量需要通过实例去进行设置，启用全局懒加载就会导致NPE（NullPointerException）报错。 常见的场景是，编写一个Spr

由于公司Java项目代码量庞大，使用Maven作为构建工具进行编译时，往往会花费较长时间。 进行代码测试时，修改一行代码，可能会引起整个项目重新编译。这是Maven的默认行为，一旦检测到代码变更，便重新编译改变文件对应的模块。但其实那些没有改动的代码，复用以前的编译结果即可。为此，引入了增量编译。 增量编译 增量编译(Incremental Compilation)是指，只重新编译修改的代码

Git在commit时，必须输入commit message，来表示对提交内容的说明。没有则无法提交。 理论上，commit message可以输入任意内容。但如果参与多人协作开发和持续开发，就会有相应的规范，帮助程序员快速理解别人写的提交，或者回顾自己以前提交的作用。 目前应用最为广泛的规范是前端框架Angular提出的Angular提交信息规范（简称规范）。 Angular Commit

在SpringBoot-Testing提到，使用Junit测试SpringBoot项目时，需要使用@SpringBootTest来创建一个Spring容器。而当@SpringBootTest标注的测试类没有使用内嵌@Configuration注解时，会自动使用@SpringBootConfiguration上的配置。 Automatically searches for a @SpringB

最近在工作中频繁使用到了Git。虽然之前基本把《Pro Git》读完了，但在实际使用中还是遇到不少问题。 究其原因，这可能因为国内的Git教程普遍基于命令行，并且只教最基础的使用。而大部分的开发人员往往使用集成在IDE中的Git，并且对于Git背后的原理和设计思路并不了解。 上一篇讲到当未commit的修改和将要进入的分支有conflict时，该怎么保存这些修改。这里将进入的分支可以是che

为了简化本地测试代码的过程，往往会对一些代码/配置进行修改。例如设置日志级别，开启Bean的懒加载，关闭一些不必要的服务。这些修改只发生在本地工作区(Working Directory)，不会commit到本地仓库(Repository)，更不会push到远程仓库(Remote repositories)。由于在IDEA中，默认没有启用暂存区(Staging Area/Index)，因此主要讨论的

前面提到，对于Spring项目来说，项目的功能取决于Spring容器中有哪些bean，每一个bean都是一个功能模块的实例化对象。所以问题就来到了如何向Spring容器中添加bean。 XML 配置文件 XML配置文件是最原始的添加bean的方式。使用XML配置文件符合了配置文件分离的原则。可以通过修改XML配置文件直接修改程序的功能，而不需要将项目重新编译。 在XML配置文件中通过<