都是血泪，程序员傍身的生存法则（上）

代码的“筋骨”无非就是分层、结构、逻辑、抽象、封装、模式…曾经大行其道逢人必谈，到现在感觉都没什么人提起了的GoF 23种设计模式，其实就提供了23种“筋骨”范例，大家依葫芦画瓢就行。

代码没有编译成机器码之前，都是给人读的。业界戏称的衡量代码好坏的指标就是“阅读该代码时说脏话的次数”，我们骂的通常就是代码“筋骨”。

要“想清楚”就是想办法练好“筋骨”。TDD测试驱动模型的话，考虑应该怎么设计逻辑控制DD领域建模的话，考虑应该怎么建立领域实体DD老板驱动的话，考虑迅速翻翻老板以前写过的代码、说过的话、下过的KPI，当然这是玩笑。

曾有多少次，我们怀着一颗要求完美的心，骂着前人写的狗屎一样的旧代码，不得不妥协着项目压力，不断降低着那条曾经的标准，敲出自我放逐的同样狗屎一样的新代码，附上那句可能永远无法兑现的“以后重构”的承诺，最终进入一个不断偿还他人和自己技术债的死循环里…

DàYé啰嗦

经典的《Java编程规范》里开篇总则里的“第一次就做对”，听起来轻飘飘的一句话，背后深意满满。带脑子有思考的编码，想第一次能做对都不是那么容易，别说没动脑的了。这里罗列一些身边实际发生过的错误行为模式，供君一品：

# “初期没多少数据量的，我循环着一条一条Insert没什么问题，等哪天数据量大了，我再考虑批量插入吧！” 请问批量插入很难么需要以后/p>

# “这个代码是我从另一个项目里拷贝过来的，他那边运行的一直没有什么问题。” 然后某一天出现了内存泄漏，因为两个项目的流量完全不对等，不求甚解不动脑，搬砖型码农这里体现的淋漓尽致。

# “为了测试环境方便联调，易于排障，我每个关键点都打印了Info日志。” 实际上打印的都是无脑的不携带任何参数线索的trans begin/trans end类日志，在分布式日志平台里看到的各种无法上下串联的孤岛日志，我常常边心疼着磁盘存储和索引计算成本，边碎碎念着这些系统真的可以做好线上运维排障么/p>

# “某些逻辑点我hardcode了一些代码，用来触发某些特殊逻辑分支方便测试，等上线的时候这些我都会删掉。” 等真的上线了，这些hardcode被带上去的不在少数。

# “系统有兜底的全局异常拦截器，就算有些异常没catch, 最终也会被拦截器包装成标准 文返给前端的，所以有些类似空指针异常我就无视掉了。” 结果就是APP用户不胜其烦的看到各种“系统未知异常”的弹窗。

# “Service层就是简单的数据库CRUD，Business层这么多业务逻辑，保证数据一致那就让事务的边界扩大一些，直接把事务管理放到Business层不就完事了。” 结果就是事务里面包裹了各种耗时数据IO、逻辑计算甚至更耗时的RPC调用，导致事务整个被拉长，资源被锁住的时间也加长，最后就是各种阻塞直至雪崩。

02 动手能力

东北大兄弟说：能动手就别BB。

待续！！！

往期推荐：

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。