一幢有少许破窗的建筑为例，如果那些窗不被修理好，可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内，如果发现无人居住，也许就在那里定居或者纵火。一面墙，如果出现一些涂鸦没有被清洗掉，很快的，墙上就布满了乱七八糟、不堪入目的东西；一条人行道有些许纸屑，不久后就会有更多垃圾，最终人们会视若理所当然地将垃圾顺手丢弃在地上。这个现象，就是犯罪心理学中的破窗效应。
我们做项目也是一样的。一定要好好写代码，不要让“破窗”在我们的项目中发生，不能让项目有任何变混乱的趋势，保持项目清爽，这可以给我们开发者到来很好的工作体验，也就是所谓的心流体验。
如何命名？在一些命名格式上，可以遵循编码规范就好了。但是如何给一个类/方法/变量/枚举命名呢？
在问这个问题前，我们来问另外一个问题，那就是程序语言，所谓的语言是给谁看的？一是给计算机或者编译器能看懂。二是给我们人类看的。让计算器或者编译器看懂很容易，只要遵循程序的语法去写就 OK 了。但是如何让人更容易看懂，当然答案也很简单，就是好好命名。关于如何命名，一些笔者至今受用的命名准则这里这里简单介绍下。
使用业务相关的词汇命名而不是计算机相关的词汇
比如，SaveMgr 中的 Save 是保存，是业务相关的词汇。而 SerializeHelper 中的 Serialize 则是计算机相关的词汇。这条准则在 业务/逻辑/UI 层会有很大的效果。而在 Framework 层或者说底层还是使用计算机相关的词汇比较好。
方法/函数命名用谓语 + 宾语方式命名
比如 PlayerData.Save，或者 SavePlayerData
类名和方法参数使用名词
表示一个动作状态时通过动词的不同时态进行命名。
比如 Connecting，Connected，Connect 表示连接的三种状态。
关于命名和规范就先讲到这里，命名是一门学问，其内容多得可以去写一本书去介绍了。如果想深入学习，建议首先看《代码大全》的第 11 章 《命名的力量》。
小结还记得在前边说的架构的定义嘛？架构是“约定、规则、共识”，而确定各种规范也是准备阶段要做的事情，也是架构的一部分。
在新的公司度过了一段加班生活，之后加班次数慢慢就减少了。这时候就又有时间去搞点东西了。
一个视频教程的学习首先是当时，在某教育网站上学习了《万能游戏框架》视频教程，笔者从头到尾跟着手敲了一遍。教程里的一个基于模块的消息框架实现得很有意思。这里简单说一下。 QFramework 之前收录的 MsgDispatcher 就是一个全局的字典，字典的 key 是事件名字，而 value 则是 委托 List，所以不管怎么定义消息，它们都是全局的。当消息的规模变大之后，会有很大的性能压力。如图所示：
全局消息与单例模式一样都是用起来很方便，但是风险很大的设计。