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

最新推荐文章于 2024-04-26 22:27:32 发布

技术琐话

最新推荐文章于 2024-04-26 22:27:32 发布

阅读量267

点赞数

本文链接：https://blog.csdn.net/u013527895/article/details/103121949

版权

笔者曲健，1024生人，天选程序员，浆糊人送外号“大爷Dà Yé”，目前在奥琪科技担任首席架构师一职。

彼得德鲁克的经典之作《卓有成效的管理者》里提到，知识管理者必须学会自我驱动、自我管理，而动力取决于工作是否卓越有效，是否有所成就。程序员就是典型的知识工作者，本文就是细数一下程序员的生存之道，或者说自驱之道。

00 优雅的命名

程序员生存法则Number One, 无出其右者，且不接受挑战。

务必记住，程序员的第一武装不是格子衫不是脱发，是代码! 如果把代码比喻成人体，那么逻辑(指令)是经脉，数据是气血，而命名就是穴位。

大家想想在阅读代码的时候，不管是变量名、方法名、类名还是系统名，都是用于辅助理解逻辑/功能的特别重要的标识。我可以负责任的说：程序员命名能力的高度基本决定了他/她未来的高度。命名绝不仅是名字本身，它更可映射出作者的思维框架、知识外延、逻辑推理、语言能力、创造力、想象力等等，所以是不是瞬间拔高了？

DàYé啰嗦

# 长点心好好补补英文，程序员阅读各种英文文档需要词汇量自不必说，如果你每次命名都需要翻译软件，不自知的取最生僻的那层含义，或者各种拼写错误，往大了说特别容易引入BUG，往小了说实在丢人丢份。

# 同一代码块/层级/工程中一定不要出现过于相似的名字。由于相似导致写逻辑的时候把自己整乱的大有人在！每每评审看到这种代码吾必痛心疾首。

userVo, userDTO, userBo, userPo...

userAddedList, userAddedLists...

getUsers(), usersQuery(), getUserList()...

# 切不可文不对题，切不可“百转千回”。何意？比如说判断一个人是否是注册会员，变量名被定义成了 notRegisteredUser，大家想想在写各种if条件组合的逻辑判断时会有多酸爽。

01 想清楚再动手

我经常跟团队的人强调慢动手脑先行，可惜能领悟到精髓的人真心不多，其余的通常会以项目进度为由，将“先码起来”列为第一要务，殊不知灾难就是这么悄然来临。

书法看筋骨，代码亦如此。

640?wx_fmt=png

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

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

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

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

DàYé啰嗦

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

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

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

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

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

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

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

02 动手能力

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

640?wx_fmt=png