故小里做开发这几年，我改过不少团队的代码，也被人改过代码。最扎心的事不是需求变来变去，而是接手一段自己上周写的代码，读了三遍还没看明白。很多时候，一段代码能不能跑起来只是及格线，能不能让下一个读代码的人快速看懂、放心修改，才是真正的分水岭。这篇分享的50个让代码更优雅的小技巧，就是我从日常开发、代码评审和一堆“事后补救”里攒出来的避繁就简经验，覆盖命名、函数设计、控制流、语言特性、异常处理、性能、编辑器习惯和重构思路，适合刚入行的开发者，也适合写业务代码写到想重构的老兵。
1. 为什么避繁就简：优雅代码的底层逻辑
先说一个有点反直觉的事：优雅的代码，写起来通常不炫技，反而看起来很“怂”，不追求一行写出天际，只追求别人接手时不用猜。你去看那些成熟的开源项目，多数核心代码都是平铺直叙的，直白到让你觉得“这我也能写”。但真到自己写，就总忍不住加一层抽象、套一个设计模式、顺手再造一个轮子。所以聊技巧之前，先立四条规矩，后面所有招式都从这里长出来。
1.1 先立规矩：四条原则，招式才有意义
技巧1：最小惊讶原则。代码的行为要符合绝大多数人的直觉。一个函数名叫 get_user，就别在里面偷偷改数据库；一个方法返回 None 表示失败，就别偶发抛异常。使用者越是能猜到你的意图，代码就越不容易被误用。
技巧2：KISS，保持简单。能用 if 讲清楚的事，不要硬上策略模式；能用一个函数解决的事，不要搭一个三层继承体系。简单不是简陋，而是每个组件只承担一个明确职责，删掉任何一个都不影响整体跑通。
技巧3：DRY，别重复自己。复制粘贴一时爽，维护起来火葬场。同一段逻辑在三个地方出现，将来改需求的时候大概率只改两处，第三处就成了隐藏炸弹。
技巧4：YAGNI，你现在不需要它。不要为了“以后可能会用到”去预留抽象接口、配置开关、扩展点。没有真实需求支撑的抽象，最后都会变成没人敢动的死代码。
这四条原则不是口号，是后面每个技巧的“裁判”。遇到拿不准的方案，就用它们过一遍：这个做法会不会让人意外？有没有更简单的写法？是不是重复了？是不是提前造了不需要的东西？四个问题问完，答案基本就浮出来了。
1.2 50个技巧怎么分布
后面六个章节按“代码从写到维护”的顺序展开：先讲命名和格式，这是代码给人的第一印象；再讲函数和控制流，这是主逻辑的骨架；然后是利用语言特性和标准库，用更少的代码表达更准确的意思；接着是异常处理、性能优化、工具链协作，最后落到重构和清理。每一节里的技巧都会配上实际代码片段和我在项目里踩过的坑，你可以直接照着改。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 命名、注释与格式：代码的第一印象
代码写出来是给人看的，顺便给机器执行。既然人是第一读者，那命名和格式就是阅读体验的起点。很多同学觉得命名浪费时间，其实一个贴切的名字能省下至少三条注释，一个糟糕的名字能制造至少三次误会。这一节是性价比最高的优化区。
2.1 命名：让名字自己会说话（技巧5-7）
技巧5：变量名要表达意图，不要用通用词糊弄人。data、temp、list、flag 这类名字，除了告诉你“这里有个东西”之外什么也没说。我见过一段处理订单的代码，变量叫 data1、data2、data3，三个人接手，每个人的理解都不一样。改成 pending_orders、paid_orders、refunded_orders 之后，逻辑瞬间就清晰了，甚至不用看注释。
技巧6：布尔变量用 is、has、can 开头，让条件读起来像自然语言。比如 is_ready、has_permission、can_retry，在 if 条件里连起来就是一句完整的话：if user.has_permission and order.can_retry: 不需要额外注释，语义自己会说话。反过来，一个叫 status 的布尔值就很容易让人困惑，到底 True 代表成功还是失败？没人敢确定。
技巧7：函数名用动词开头，表明这是动作。get_user_name()、send_notification()、calculate_total_price() 一看就知道在干什么。如果你写的函数名是名词，比如 user_name()，读代码的人就得去翻函数体，才知道这是取值还是赋值。动词开头是给函数贴“动作标签”，也是让调用点变成可读语句的快捷方式。
2.2 注释、常量与文件组织：减少视觉噪音（技巧8-11）
技巧8：注释解释“为什么”，不要复述“是什么”。 i += 1 // i加1 这种注释等于没写，因为代码本身就表达了这层意思。值得写注释的是那些“看起来奇怪但必须这样”的决策，比如：为什么要等三秒再重试？为什么不直接用现成库？为什么这里要单独处理空指针？这类背景信息代码表达不了，只有注释能留住。写注释的时候，想象你是给一个月后的自己留口信，而不是在给代码写说明书。
技巧9：魔法数字和魔法字符串要提升为具名常量。代码里直接写 if retry_count > 3，大家会问这个3是啥意思；写成 if retry_count > MAX_RETRY_TIMES，语义就清楚了。字符串也一样，散落的 "paid" 状态值，一旦拼错一个字母，排查起来非常痛苦。把这些值收敛到常量或枚举里，改一处全局生效，也不会出现“同一个状态有三种写法”的尴尬。
技巧10：整个项目要统一一种命名风格。Python 用 snake_case，Java 和 JavaScript 用 camelCase，常量用全大写。单个文件风格统一容易，难的是整个仓库统一。这个只能靠团队约定和自动化检查兜底，比如 ESLint、Pylint 里配置命名规则，不合规范直接报错，省得评审时为了下划线吵半天。
技巧11：文件、模块和类的命名也要有规律。一个文件只放一个核心类或一组高内聚函数，文件名和内部主类名保持一致。Python 模块用小写下划线，Java 类用大驼峰，目录结构按功能域而不是按技术类型划分。我从“按类型建目录”改成“按业务模块建目录”之后，找代码的速度快了一倍，因为一个需求涉及的文件都在同一个文件夹里。
2.3 格式化自动化：别让人工排版浪费生命（技巧12）
技巧12：代码格式化交给工具，不要手动对齐。Python 用 Black，JavaScript 用 Prettier，Java 用 Spotless 或 google-java-format，Go 直接 gofmt。这些工具的核心价值不是让代码变好看，而是消除“格式之争”，大家提交的代码长一个样，diff 里只出现真正的逻辑变更。我在团队里推行 Black 之后，最明显的变化是评审时间缩短了，因为不会再有人为了两行缩进来回评论。配置方式也很简单：提交前自动格式化，或在 CI 里加一道格式检查，不通过就不允许合并。
3. 函数设计与控制流：让主流程一眼即懂
函数是代码的积木。积木切得越合理，搭出来的系统越稳；函数之间边界越清晰，修改一个功能时受影响的面积就越小。这一节讲的是怎么把函数设计得短小、专注、容易测试，以及怎么让条件分支不把逻辑搅成一锅粥。
3.1 函数边界：单一职责与参数控制（技巧13-15）
技巧13：一个函数只做一件事。判断标准很简单：能不能用一句话说清这个函数做了什么？如果说“它先校验参数，然后查数据库，再发邮件，最后记录日志”，那它就该拆成四个函数。我重构过一个发送通知的接口，原函数两百多行，里面还夹着用户状态判断和模板渲染逻辑，测试根本无从下手。拆成 validate_request、load_user、render_template、send_notification 四个小函数后，每个都能独立测试，出问题也能直接定位到具体环节。
技巧14：函数参数控制在三个以内。参数越多，调用方越容易传错，测试用例组合也呈指数增长。如果确实需要传很多信息，考虑把它们封装成一个参数对象或配置对象。比如登录函数 login(username, password, device, ip, captcha, remember_me) 六个参数，不如定义一个 LoginRequest 对象，既有字段约束，又方便后续加字段。
技巧15：用默认参数替代重载和“标志位参数”。Python 里直接 def fetch(url, timeout=10, retries=3)，调用方按需覆盖。不要写 fetch(url, True) 这种带布尔标志的函数，True 是什么意思根本看不出来。看到这种代码，优先考虑拆成两个函数，或者把标志位改为枚举参数，比如 fetch(url, mode=FetchMode.FRESH)，调用点就变成可读的语义了。
3.2 控制流：卫语句与表驱动（技巧16-17）
技巧16：用卫语句提前返回，别让异常分支层层嵌套。很多代码喜欢把所有情况包在 if 里：
python复制def process(order):
if order:
if order.is_paid:
if order.items:
do_ship(order)
else:
log_error("empty items")
else:
log_error("not paid")
else:
log_error("no order")
这种写法一旦条件变多，大括号就会叠到天上去。改成卫语句之后，主流程直接平铺：
python复制def process(order):
if not order:
log_error("no order")
return
if not order.is_paid:
log_error("not paid")
return
if not order.items:
log_error("empty items")
return
do_ship(order)
先处理异常和边界，剩下的就是正常主流程。读代码的人不需要一层一层往里钻，一眼就能看到核心逻辑。
技巧17：用表驱动替代长串的 if/else 或 switch。最典型的就是“根据类型执行不同逻辑”，比如消息处理：
python复制def handle(event_type, payload):
handlers = {
"order_created": handle_order_created,
"payment_success": handle_payment_success,
"user_registered": handle_user_registered,
}
handler = handlers.get(event_type)
if handler:
handler(payload)
else:
log_unknown_event(event_type)
新增一种事件只需要往字典里加一项，不需要改动分支结构，也不会漏掉 default 分支。数据驱动天然就是“开闭原则”的一种简单实现。
3.3 扁平与组合：把复杂度拆开（技巧18-19）
技巧18：减少嵌套层级，能提前 continue 就提前 continue。循环里最常见的坏味道是：
python复制for item in items:
if item.is_valid:
if item.price > 0:
result.append(item)
把正逻辑反着写，用 continue 跳过坏数据，循环体就只剩核心逻辑：
python复制for item in items:
if not item.is_valid:
continue
if item.price <= 0:
continue
result.append(item)
嵌套每少一层，阅读负担就轻一分，改动时也不容易把括号搞乱。
技巧19：用组合小函数的方式组织流程，而不是写一个超长主函数。比如跑一个离线任务，别把“读文件、清洗数据、计算指标、写结果”全部塞进 main()。拆成 load_raw_data() -> clean_data() -> compute_metrics() -> save_output()，再用一个调度函数把它们串起来。这样每一步都能单独验证，中间某一步崩了，也能立刻知道崩在哪，而不是从头到尾打日志猜。
4. 语言特性与标准库：写得更少，做得更多
每个语言都有自己的“本命写法”。Python 写得好的人和写得像 Java 的人，代码量能有肉眼可见的差距。很多人不是不会写，而是不知道标准库里已经有现成方案，还在自己造轮子。这一节挑几个最高频的场景，看看怎么用语言特性把代码压得更薄、表达得更准。
4.1 数据处理三板斧（技巧20-22）
技巧20：列表推导式替代手动 for 循环。构建新列表时，不要再写：
python复制result = []
for item in items:
if item["active"]:
result.append(item["name"])
一行搞定：
python复制result = [item["name"] for item in items if item["active"]]
推导式不光短，还更接近“我想得到什么”的声明式表达。但注意，别在推导式里塞太复杂的逻辑，超过三层条件或带副作用的操作，还是老老实实写循环。
技巧21：解构赋值省去临时变量。交换两个变量，Python 写 a, b = b, a，不需要第三个临时变量。从函数返回多个值时，name, age = get_user() 直接拆包。遍历字典时，for key, value in data.items(): 比 for key in data: data[key] 清晰得多。这种写法让数据“流动”的姿态直接显现出来。
技巧22：三元表达式用在简单赋值上。status = "ok" if code == 0 else "fail" 很短很直白，但别嵌套多层，也不要在里面写复杂函数调用。一旦三元表达式超过一行， readability 就会迅速下降，这时候用普通 if 语句反而更清楚。
4.2 字符串与集合的巧劲（技巧23-25）
技巧23：用 f-string 拼字符串，别再用加号或百分号。Python 3.6 以后，f"{name} scored {score:.2f}" 比 "{} scored {}".format(name, score) 和 "%s scored %f" % (name, score) 都更直观。尤其在日志和报告输出里，f-string 把变量直接内联进模板，一眼就能看出最终输出长什么样。
技巧24：合并字典用展开语法或 | 运算符。merged = {**default_config, **user_config} 能让后面的配置覆盖前面的。Python 3.9 之后还可以写 merged = default_config | user_config。用这种写法可以避免手写循环去 update，代码看起来也像在做“配置叠加”，语义非常明确。
技巧25：用集合去重、求交集、求差集。列表去重直接 list(set(items))，但要注意列表元素必须可哈希，如果元素是字典，就得换方案。判断两个列表是否有交集，也别写双层循环：
python复制common = set(list_a) & set(list_b)
if common:
...
集合操作表达的是数学语义，读代码的人一眼就知道你在做集合运算，而不是在“遍历比对”。
4.3 生成器、内置函数与 collections（技巧26-28）
技巧26：生成器表达式处理大数据流，避免一次性加载到内存。比如统计一千万个数的平方和：
python复制total = sum(x * x for x in huge_numbers)
这里 sum 拿到的是一个生成器，边算边丢，不会先把所有平方值存进列表。写代码的时候要分清“需要完整列表”和“只需要遍历结果”的场景，后者一律优先用生成器。
技巧27：any 和 all 替代手写循环判断。判断列表里是否有元素满足条件，很多人写成：
python复制found = False
for x in values:
if x > 0:
found = True
break
直接写 found = any(x > 0 for x in values)，判断全部满足就是 all(...)，语义即文档。
技巧28：collections 模块是高性能数据结构的宝库。Counter 统计频次、defaultdict 处理缺失键、deque 做双端队列、namedtuple 定义轻量数据对象。比如统计单词频次，Counter(words) 一行就能得到结果，手写字典循环至少四五行，而且边界条件还得自己处理。
4.4 资源管理与枚举（技巧29-30）
技巧29：用 with 语句管理资源，文件、连接、锁都必须自动释放。Python 里 open 配 with 是最基本的习惯，with open("data.json") as f: data = json.load(f) 就不需要手动写 f.close()。同理，数据库连接、threading.Lock、subprocess 的管道，都能用上下文管理器包起来。C 语言没有这种语法，我写 C 的文件读写时总是反复检查 fclose 有没有在每条错误路径上执行，Python 程序员真的应该珍惜 with。
技巧30：用 Enum 替代散落的字符串常量。状态值、类型值、错误码，定义成枚举后既有约束又有提示。比如订单状态，OrderStatus.PAID 比 "paid" 安全得多，拼错了 IDE 直接报错，运行期也不会出现“状态值对不上”的隐蔽问题。
5. 异常、排查与调试：优雅地处理错误
代码里有一个隐藏的质量指标：错误路径处理得干不干净。很多程序正常流程跑得飞快，一遇到异常数据就崩得莫名其妙。这一节的技巧，能让你在“出错的时候”依然保持代码的可读性和可维护性。
5.1 异常处理：精确打击（技巧31-32）
技巧31：精准捕获异常类型，不要裸 except。Python 里写 try: ... except: ... 会把 KeyboardInterrupt、SystemExit 也吞掉，而且你根本不知道到底发生了什么错误。改成 except KeyError:、except ValueError:、except requests.Timeout: 这种针对性捕获，错误的处理逻辑才能匹配错误的真实原因。多异常的可以写元组：except (KeyError, ValueError):，但尽量别把不相干的异常混在一起。
技巧32：try 的 else 和 finally 要各司其职。else 块只有在 try 没有异常时执行，适合放“成功后才应该做的事”；finally 块无论是否异常都会执行，适合放清理资源动作。很多代码把“成功后的处理”直接写在 try 里，如果那一步自己抛异常，就会被同一个 except 误捕，导致排查时搞不清到底哪一步出了问题。
5.2 边界防御：不信任输入（技巧33-34）
技巧33：返回空集合而不是 None，调用方就不用到处判空。一个函数返回“用户列表”，如果没有数据，返回 [] 而不是 None，调用方就能直接 for user in get_users():。同理，返回字符串的函数用空字符串表达“没有结果”，会比返回 None 在后续处理中少很多分支。当然，如果 None 本身有业务含义（比如“查询失败”），那就保持 None，并且要在 docstring 里写清楚。
技巧34：对不可信输入做防御，但别到处防御。外部传入的数据（HTTP 参数、文件内容、用户配置）默认不可信，入口处统一校验；但内部函数之间传递的数据，依赖入口校验就够了，不要在每一层都重复判空，否则代码会被 if not data: return None 淹没。我曾见过一个项目，每个函数开头三行都在判空，加一个字段要改五个地方，这就是防御过度。
5.3 失败要快，检查要勤（技巧35-36）
技巧35：Fail-fast，参数不合法就立刻报错，不要带着错误数据跑半天。函数开头校验参数类型、范围、关键字段，不满足直接抛异常。这样做能节省大量排查时间：问题在源头暴露，而不是跑到第五步才发现数据不对，再回头猜是哪一步污染的。
技巧36：用静态检查工具做“代码诊断”，别等 bug 上线再后悔。Python 用 mypy/pyright 做类型检查，用 Ruff/Pylint 做风格检查；Java 用 SonarQube、Checkstyle；JavaScript 用 ESLint。SonarQube 扫描本地代码特别适合做代码巡检，能识别重复代码、明显的坏味道、潜在的 bug 模式。我每次重构完都会把这几个工具跑一遍，很多低级错误在提交前就被拦下来了。
6. 性能与资源：优雅而不牺牲效率
优雅的代码不是牺牲性能换可读性，而是避免“不必要的浪费”。这一节的技巧都是低成本高收益的小优化，不会让代码变复杂，但能让程序在数据量大时不那么吃力。
6.1 别让循环做多余的事（技巧37-39）
技巧37：批量拼接字符串用 join，不要在循环里写 +=。Python 字符串是不可变对象，循环里 s += item 每次都创建新字符串，数据量大时开销非常明显。应该用：
python复制parts = []
for item in items:
parts.append(process(item))
result = ", ".join(parts)
Java 里同样用 StringBuilder。这类写法不在“性能调优”时才改，而是平时就该养成习惯，因为等卡顿出现时，再回头从一堆逻辑里捞拼接代码，成本很高。
技巧38：循环内不重复计算固定值。很多人写循环时不注意，把 len(items)、datetime.now()、config.max_retry 放在循环体里反复取。如果这些值在循环过程中不变，提到循环外面只算一次。这是最容易被忽略的优化点，尤其在嵌套循环里，改一行顶得上后面加一堆缓存。
技巧39：用局部变量缓存高频访问的成员。Python 里 self.table 这种属性访问每次都有开销，在循环体里频繁 self.xxx 时，可以先在循环外 table = self.table，循环内直接用 table。这不是炫技的微优化，而是让代码减少一层“每次去对象里找属性”的间接过程，对于耗时敏感的逻辑有明显感觉，而且基础读起来也更顺手。
6.2 用标准库和缓存换性能（技巧40-42）
技巧40：成员判断用集合而不是列表。if x in list 是线性扫描，if x in set 是哈希查找，数据量上千之后差距就很明显。我之前处理一批用户 ID 过滤，列表有一万条，每次判断要遍历列表，整体跑一次要好几秒；换成 set 之后，瞬间完成。
技巧41：能用内置算法就别自己造。排序用 sorted()，Python 的 TimSort 实现稳定且快；Java 的 Collections.sort()、Arrays.sort() 也是高度优化的。很多同学为了练手会自己写快速排序，但生产代码里真的没必要，除非你有非常特殊的排序需求。同样，二分查找用 bisect 模块，计数用 Counter，优先信任标准库的实现。
技巧42：用缓存装饰器消除重复计算。Python 的 functools.lru_cache 适合纯函数、入参可哈希的场景。比如斐波那契数列、递归型动态规划，加一行 @lru_cache(maxsize=None) 就能避免指数级重复计算。要注意缓存键会受参数影响，如果函数依赖外部可变状态，别乱加缓存，否则会得到过期的结果。
7. 编辑器、Git与协作：让工具替你干活
优雅不是一个人在编辑器里自嗨，而是整个协作流程顺畅。代码写得再漂亮，如果每次提交都是“fix bug”“update”，仓库历史照样没法看。这一节聊几个让你每天工作效率明显提升的工具习惯。
7.1 编辑器与仓库的隐形队友（技巧43-45）
技巧43：给编辑器装对插件，让代码提示跟上来。很多人在 VSCode 里写 C 发现没有代码提示，大概率是没装 C/C++ 扩展，或者没配置 IntelliSense 路径。写 Python 可以装 Pylance，写 Java 用 Language Support for Java，前端用内置的 TypeScript 服务。代码提示不是花架子，它能直接把拼写错误和类型错误拦在编译前，省掉大量来回试错。工具配置好之后，写代码的体验完全是两个世界。
技巧44：提交前自动格式化加 Lint，把低质量代码拦在仓库外。本地装 pre-commit 钩子，提交时自动跑 Black、Ruff、Prettier、ESLint 这些检查，不通过就不让提交。这样评审者看到的都是格式统一、风格一致的代码，可以把精力放在逻辑本身，而不是“这里该不该有空行”。
技巧45：Git 提交信息按规范写，历史的每一步都有意义。比如 Angular 的 Commit Message 规范：feat: 增加订单导出功能、fix: 修复金额计算精度问题、refactor: 拆分订单状态判断逻辑。提交信息不只是给 CI 看的，更是给三个月后翻历史的自己看的。我要求自己每个提交解决一个逻辑问题，这样用 git log --oneline 扫一遍，就知道项目演进的全部脉络，定位 bug 时也能用 git bisect 快速找到引入问题的那次提交。
7.2 片段与快捷键：让高频操作自动化（技巧46-47）
技巧46：把重复的样板代码存成代码片段。团队里每个人的项目往往有统一的日志格式、异常封装、API 响应结构。这些代码不需要每次手敲，在编辑器里定义 snippet，输入一个触发词就能展开模板。比如输入 logerr 自动生成一段带上下文的错误日志代码，输入 resp 生成标准 API 响应体。代码片段不违反 DRY，它消除的是“手动重复劳动”，而不是逻辑重复。
技巧47：熟练使用 IDE 的重构快捷键，重构就不会靠手动删改。VSCode 里的 F2 重命名符号、提取函数/变量、选中多处同步修改，IntelliJ IDEA 的 Ctrl+Alt+M 提取方法、Shift+F6 重命名。手动全局替换变量名很容易漏改，用 IDE 的重命名功能，它会智能地区分同一名字在不同作用域的指向。磨刀不误砍柴工，这些快捷键值得花半小时背下来。
8. 重构、复用与代码整理：定期给代码做减法
代码和衣柜一样，不定期收拾，就会堆满“以后可能会穿”的衣服。重构不是推倒重来，而是在保持功能不变的前提下，把结构调得更顺。这一节是最后的收尾，讲怎么识别重复、怎么用数据驱动替代硬编码、怎么清理死代码。
8.1 删重复：从删减脚本到数据驱动（技巧48-49）
技巧48：抽公共函数前，先确认两段代码是不是真的“同一件事”。经常看到有人把长得像的代码强行合并成一个函数，参数加了三个，内部全是 if 分支，结果比原来还难读。真正的重复是“语义相同、只是数据不同”。比如多个模块都要“把原始交易记录按用户分组”，这就是值得抽的公共逻辑；如果只是“碰巧都有个 for 循环”，那还是别抽。我写过一个“优化代码重复删减脚本”，思路就是先统计重复片段，再判断语义是否一致，最后才动手提取。先分析后动手，永远不会错。
技巧49：用数据驱动替代硬编码分支。配置项、权限列表、消息模板，都应该从代码里挪到配置/数据源里。比如不同国家的运费规则，不要在代码里写一串 if country == "US"，而是维护一张规则表，代码只负责遍历规则计算运费。这样新增一种规则不需要改代码、重新部署，直接把数据补上就行。数据驱动是“把变化的部分从逻辑中抽离”，这是保持代码稳定非常有效的一招。
8.2 保养代码：死代码清理（技巧50）
技巧50：定期清理死代码和无用依赖。项目跑得越久，越容易积累一些没人调用的函数、被注释掉的旧逻辑、用不上的 import。死代码不报错，但会给阅读者制造噪音——看到一段无法确认是否还在使用的函数，研究半天，最后发现是三个月前注释掉的试验品。我每迭代一个大版本，会专门抽半天做“减法”：全局搜索未引用的函数、删除废弃接口、移除不再使用的依赖。做完之后代码库会更轻，编译速度更快，后来维护的人也会感谢你。
最后说点个人体会
这50条写下来，与其说是技巧清单，不如说是我的自查清单。每次提交代码前，我都会把当天的改动通读一遍，重点看有没有违反那四条原则的地方：会不会让人意外？能不能更简单？是不是重复了？是不是提前做了不需要的事？如果发现能删的代码，我通常当场就删，因为代码每少一行，未来的维护成本就少一份。
我特别想强调的一点是：优雅不等于“高级”。用上设计模式、写出花式语法，不代表代码更优雅；真正优雅的代码，是团队里最忙的那个人下班前看了一眼你的提交，也能快速理解你在做什么。如果你看完这50条，只记住一件事，那就记住这一句：代码是给下一个读它的人写的，而下一个人，往往就是三个月后的你自己。