《从码农到工匠--学习笔记》规范

	**加粗样式**实物的复杂度在很多程度上取决于其有序程度，减少无序能在一定程度上减低复杂度，这正是规范的价值所在


理解复杂系统--发现共同抽象和机制
混乱的代价在于让我们对事务无法形成有效的记忆和认知，导致每次面对的问题都是新问题，又要重新理解一遍。思考：开发过程中，遇到的问题要好类，方便检索，文章命名要有共同性，再做到同一个事的时候，才能快速定位到解决方法。
我们有必要使用规范和约定来使大脑从记忆不同的代码段的随意性、偶然性差异中解脱出来。将有限的精神力用到刀刃上。

要一个团队要约定功能的代码风格：缩进、水平对齐、注释格式。

空行规范
	空行在概念区起到隔离作用。	

十辐共一毂，当其无，有车之用。埏埴以为器，当其无，有器之用。凿户牖以为室，当其无，有室之用。故有之以为利，无之以为用。–道德经

简单原则：相关性越强，彼此直接的距离应该越短。
同一个项目中，应该统一命名规范。java中通常使用的命名约定：
	类名采用“大驼峰”，首字母大写。 FileInputStream
	方法名采用“小驼峰”，首字母小写。sleep(long millis)
	常量命名全部大写。单词之间采用下划线。 PAGE_SIZE
	枚举类以Enum结尾。枚举类成员名称全大写，单词之间用下划线链接。
	抽象类使用Abstract开头；异常类使用Exception结尾；实现类以impl结尾；测试类以Test结尾。
	包名统一使用小写，点分隔符之间有且仅有一个自然语意的应用单词，包名统一使用单数形式。通常以com或org开头，org.springframework.beans.思考：python和golang 适用吗？

日志规范。开发人员应在一开始就养成良好的撰写日志的习惯，并在实际的开发工作中为写日志预留足够的时间。
打印日志使，要注意日志输出级别，方便运维。ERROR\WARN\INFO\DEBUG四个级别能够满足一般日常需求。

	ERROR表示不能自己恢复的错误，需要立即被关注和解决。例如，数据库操作失误、I/O错误（网络调用超时、文件读取错误等）、未知的系统错误等。对应ERROR不仅要打印线程堆栈，最好打印出一定的上下文，以便排查问题。
	对于可预知的业务问题，最好不要用ERROR日志输出，如参数校验不通过、没有访问权限等业务异常。可以使用WARN日志。
	INFO用于记录系统的基本运行过程和运行状态。
	DEBUG使输出调试信息，如request/response的对象内容。线上环境，DEBUG日志应当关闭。为防止日志量过大，我们可以采用分布式配置工具来实现基于requestId判断的日志过滤，从而只打印我们所需要的DEBUG日志。

规范错误码，一定要在系统搭建之处就制定好相应的规范。
	分为编号错误码和显性化错误码
		编号错误码可用于平台、底层系统或软件产品。需要配合写好文档。
		显性化错误码推荐用于大型分布式框架下的业务系统中。具有更强的灵活性，适合敏捷开发。可以定义为三个部分： 类型+场景+自定义标识。每个部分之间用下划线连接，内容以大驼峰方式书写 。
		可以约定P代表参数异常-ParamException、B代表业务异常-BizException、S代表系统异常-SystemException。示例：
		错误类型/错误码约定/例
		参数异常/P_XX_XX/P_Customer_NameIsNull：客户名不能为空
		业务异常/B_XX_XX/B_Customer_NameAlreadyExist: 客户名称已存在
		系统异常/S_XX_XX/S_Unkow_Error:未知系统错误
	规范表达，大大提升系统的可维护性和可理解性。

做互联网产品，了解用户的行为和心智很重要。“业务数据化、数据业务化”，即业务要沉淀数据、数据要反哺业务。要清楚用户的第一件事是做什么、接着还会做什么、用户的轨迹和运动线是怎样的。

规范埋点，采集数据，用于分析客户的需求。

破窗效应理论：
	环境中的不良现象如果被放任存在，就会诱使人们效仿，甚至变本加厉。以一幢有少许破窗的建筑为例，如果破窗不被修理好，可能将会有破坏着破坏更多的窗户。最终他们甚至会闯入建筑内，如果发现无人居住，也许就在那里定居或者纵火。一面墙，如果出现一些涂鸦而没有被清洗掉，那么很快，墙上就会布满了乱七八糟、不堪入目的东西；一条人行道有些许纸屑，不久后就会有更多的垃圾，最终人们会视若理所当然地将垃圾顺手丢弃在地上。