**加粗样式**实物的复杂度在很多程度上取决于其有序程度,减少无序能在一定程度上减低复杂度,这正是规范的价值所在
理解复杂系统--发现共同抽象和机制
混乱的代价在于让我们对事务无法形成有效的记忆和认知,导致每次面对的问题都是新问题,又要重新理解一遍。思考:开发过程中,遇到的问题要好类,方便检索,文章命名要有共同性,再做到同一个事的时候,才能快速定位到解决方法。
我们有必要使用规范和约定来使大脑从记忆不同的代码段的随意性、偶然性差异中解脱出来。将有限的精神力用到刀刃上。
要一个团队要约定功能的代码风格:缩进、水平对齐、注释格式。
空行规范
空行在概念区起到隔离作用。
十辐共一毂,当其无,有车之用。埏埴以为器,当其无,有器之用。凿户牖以为室,当其无,有室之用。故有之以为利,无之以为用。–道德经
简单原则:相关性越强,彼此直接的距离应该越短。
同一个项目中,应该统一命名规范。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:未知系统错误
规范表达,大大提升系统的可维护性和可理解性。
做互联网产品,了解用户的行为和心智很重要。“业务数据化、数据业务化”,即业务要沉淀数据、数据要反哺业务。要清楚用户的第一件事是做什么、接着还会做什么、用户的轨迹和运动线是怎样的。
规范埋点,采集数据,用于分析客户的需求。
破窗效应理论:
环境中的不良现象如果被放任存在,就会诱使人们效仿,甚至变本加厉。以一幢有少许破窗的建筑为例,如果破窗不被修理好,可能将会有破坏着破坏更多的窗户。最终他们甚至会闯入建筑内,如果发现无人居住,也许就在那里定居或者纵火。一面墙,如果出现一些涂鸦而没有被清洗掉,那么很快,墙上就会布满了乱七八糟、不堪入目的东西;一条人行道有些许纸屑,不久后就会有更多的垃圾,最终人们会视若理所当然地将垃圾顺手丢弃在地上。