算法设计作业--第一周

任务一：
[https://developer.aliyun.com/article/1587468]

一、代码命名规范

1. 通用规则：命名不能以下划线或美元符号开头/结尾；严禁拼音与英文混合，更不允许直接用中文；包名统一小写，点分隔符间仅含一个自然语义英文单词，且统一用单数形式。
2. 特定元素命名
   类名：用UpperCamelCase风格（领域模型相关命名除外），有复数含义可使用复数形式；抽象类以Abstract或Base开头，异常类以Exception结尾，测试类以被测类名开头、Test结尾，枚举类建议带Enum后缀，使用设计模式建议在类名体现。
   方法名、参数名、成员变量、局部变量：统一用lowerCamelCase风格。
   常量：命名全部大写，单词间用下划线隔开；Service和DAO类的实现类用Impl后缀与接口区分，形容能力的接口用对应形容词命名。
   Service/DAO层方法：获取单个对象用get前缀，多个对象用list前缀，统计值用count前缀，插入用save（推荐）或insert前缀，删除用remove（推荐）或delete前缀，修改用update前缀。

二、常量与变量使用规范

1. 常量管理：不允许魔法值直接出现在代码中；不建议用一个常量类维护所有常量，需按功能归类；常量复用分五层，即跨应用、应用内、子工程内、包内、类内共享常量；变量值在特定范围变化或带延伸属性时用Enum类；接口尽量不定义变量，若定义需与接口方法相关且为应用基础常量。
2. 变量类型：long或Long初始赋值用大写L；POJO类属性、RPC方法返回值和参数必须用包装数据类型，局部变量推荐用基本数据类型；数据库is_disabled字段映射，若字段不可为null，建议用基本类型保证数据完整性。

三、方法与类相关规范

1. 方法规则：覆写方法必须加@Override注解；可变参数放参数列表最后，且尽量不用可变参数编程；对外暴露接口签名原则上不允许修改，过时接口需加@Deprecated注解并说明新接口/服务，不能使用过时类或方法；方法参数校验需区分场景，如调用频次低、执行时间开销大等场景需校验，极可能循环调用、底层高频调用等场景可不校验（需注明）。
2. 类与属性规则：序列化类新增属性不修改serialVersionUID字段；定义DO/DTO/VO等POJO类不设属性默认值；构造方法禁止加业务逻辑，初始化逻辑放init方法，多个构造方法或同名方法需按顺序放置；类内方法定义顺序为公有/保护方法＞私有方法＞getter/setter方法；setter方法参数名与类成员变量名一致，getter/setter方法尽量不加业务逻辑；类成员与方法访问控制从严；业务逻辑中尽量不用setter方法，优先用构造函数或有逻辑意义的方法。

四、代码格式规范

1. 基础格式：缩进用4个空格，禁止用tab字符；单行字符数不超过120个；IDE的text file encoding设为UTF-8，文件换行符用Unix格式。
2. 代码结构：方法体内执行语句组、变量定义语句组，以及不同业务逻辑、语义间需插入空行。

五、并发处理规范
1.线程与线程池：获取单例对象及其中方法需保证线程安全；创建线程或线程池指定有意义名称，线程资源通过线程池提供，不允许自行显式创建，且线程池需通过ThreadPoolExecutor创建，不用Executors。
2.定时任务与同步：多线程并行处理定时任务用ScheduledExecutorService，避免Timer因未捕获异常导致其他任务终止；用CountDownLatch异步转同步时，线程退出前必须调用countDown方法，且需catch异常确保该方法执行。
3.线程安全问题：volatile可解决多线程内存不可见问题，适用于一写多读，多写仍无法保证安全；HashMap高并发下resize可能出现死链；ThreadLocal无法解决共享对象更新问题，建议用static修饰。

六、注释规范
1.基本要求：所有枚举类型字段必须有注释说明用途；注释优先用中文说清问题，专有名词与关键字保留英文原文；注释掉的代码需配合说明；好的命名和代码结构应自解释，注释力求精简准确。

七、数据库设计规范
1.字段与表命名：是与否概念字段用is_xxx命名，数据类型为unsigned tinyint（1表示是，0表示否）；表名、字段名用小写字母或数字，禁止数字开头及两个下划线间仅含数字，表名不用复数名词，禁用保留字，最好加业务名称_表的作用，库名尽量与应用名称一致。
2.字段类型选择：小数类型用decimal，禁止用float和double；字符串长度几乎相等用char，可变长字符串用varchar且长度不超5000，超过则用text类型并独立建表；日期用date类型，Java字段命名加xxDate，时间用date_time类型，Java字段命名加xxTime。
3.表结构与索引：表必备id、gmt_create、gmt_modified三字段；修改字段含义或追加状态需及时更新注释；字段可适当冗余但要考虑数据同步；单表行数超500万行或容量超2GB推荐分库分表；业务唯一特性字段（含组合字段）需建唯一索引，普通索引名用idx_字段名，唯一索引名用uk_字段名；varchar字段建索引需指定长度；建组合索引时区分度最高的放最左边。
4.查询与操作：超过三个表禁止join；页面搜索严禁左模糊或全模糊；order by场景利用索引有序性；超多分页场景用延迟关联或子查询优化；查询不用count(列名)或count(常量)替代count()；分页查询count为0时直接返回；不使用外键与级联，在应用层解决；禁止使用存储过程；in操作尽量避免，若使用需控制集合元素数量在1000个内；表查询明确指定所需字段，不用。

八、代码逻辑与性能规范
1.逻辑控制：推荐少用else，if-else可改写为满足条件return的形式；if()…else if()…else…逻辑不超过3层，超过用状态设计模式。
2.性能优化：循环体中尽量将定义对象、变量、获取数据库连接、不必要try-catch等操作移至体外，避免重复执行影响性能。

任务二：
在《数学之美》中，“信息的度量和信息熵” 这一章节让我印象尤为深刻。

书中用 “猜硬币”“猜扑克牌” 的例子，把抽象概念拉到了生活里 —— 比如猜一枚均匀硬币的正反面，每次猜对需要 1 比特信息；但如果是猜一副洗好的扑克牌里某一张，因为可能性有 54 种，需要的信息量就远大于 1 比特。这个对比瞬间点通了我：信息熵的本质，其实是 “消除不确定性所需的信息量” 。不确定性越高，熵值越大，我们需要的 “有效信息” 就越多。

这让我联想到生活里的场景：比如刷社交媒体时，有些内容翻来覆去都是相似观点（低熵），我们很快会觉得 “没新东西”；但遇到一篇逻辑严密、观点新颖的文章（高熵），会明显感觉 “学到了”，本质就是它帮我们消除了更多认知上的不确定性。还有工作中做决策时，如果手里的信息零散、模糊（高熵），我们会犹豫纠结；而当数据完整、逻辑清晰（低熵）时，决策会更果断。

读完这一章，我对 “数学之美” 的理解不再停留在 “解题的巧妙”，而是意识到：数学的真正魅力，是用简洁的逻辑框架，把复杂世界的规律 “翻译” 成我们能理解、能利用的语言。