开发工程师应该都遇到过以下几种情况：

• 接收新项目时，发现项目代码一团糟，很多地方代码大量重复、各种反模式、类或者接口职责非常不清晰、几百行的方法等

• 自己参与开发的项目，随着进度的推进，人员变更，需求的不断加入，使即使是最初设计整个架构的开发人员都很难理清楚项目，项目代码变得风格多样，杂乱无章，bug频出。新加功能越来越难，开发人员也在一直在埋怨这个地方设计的不好、那个地方为什么要这么做等等，项目代码里出现很多上面提到的问题。

最近在项目上遇到一个编码相关的问题， 弄清楚过后觉得这个具备一定的典型意义，所以在这里记上。

双重检查锁模式，double-checked locking在设计模式以及并发编程中可以说是一个非常“出名”的概念。很多的例子或者书上都会有如下的代码:

本系列文章主要来源为《代码大全》，并且目的仅仅是笔记。 实际设计千差万别，书中所记可为理论基础，但是一定不能照搬照抄，灵活变通才是我们“软件工程师”区别于机器的特点。
同时，这些“道理”对于没有设计经验的人来说很难记住，但是对有了一点经验的人来说，就会有一种，食之无味，弃之可惜的感觉。所以，设计中，不断思考，不断总结，不断观摩，方为进步的途径。

架构设计中的挑战

设计是一个wicked的问题

wicked，即只有通过解决或者部分解决才能被明确的问题。 拿到项目中就是，需求一直在变更，往往只有解决了一个问题才能明确设计面对的具体问题。

软件开发中，复杂度管理是最为重要、最困难的一个纬度。任何其他技术目标都不如管理复杂度重要，具体如何管理我们可以从以下几点-一个设计良好的软件应具备的特征中窥视一二。 最小的复杂度要避免做出“聪明”的设计，因为它常常难以理解，应该做出简单且易于理解的设计。如果方案不能让你在专注于程序的某一部分时安心忽略其他部分的话，这一设计就没什么用。。 易于维护设计时为做维护工作的程序员着想，时刻想象他们可能会就你的代码提出的问题，随时考虑这些问题，进而设计出能自明（self-explanatory）的系统来 ...