笔者曲健，1024生人，天选程序员，浆糊人送外号“大爷Dà Yé”，目前在奥琪科技担任首席架构师一职。
彼得德鲁克的经典之作《卓有成效的管理者》里提到，知识管理者必须学会自我驱动、自我管理，而动力取决于工作是否卓越有效，是否有所成就。程序员就是典型的知识工作者，本文就是细数一下程序员的生存之道，或者说自驱之道。
00 优雅的命名
程序员生存法则Number One, 无出其右者，且不接受挑战。
务必记住，程序员的第一武装不是格子衫不是脱发，是代码! 如果把代码比喻成人体，那么逻辑(指令)是经脉，数据是气血，而命名就是穴位。
大家想想在阅读代码的时候，不管是变量名、方法名、类名还是系统名，都是用于辅助理解逻辑/功能的特别重要的标识。我可以负责任的说：程序员命名能力的高度基本决定了他/她未来的高度。命名绝不仅是名字本身，它更可映射出作者的思维框架、知识外延、逻辑推理、语言能力、创造力、想象力等等，所以是不是瞬间拔高了？
可以参见我之前关于取名技巧的一篇文章《IT范儿 | 你是个会取名儿的人么？》
DàYé啰嗦
# 长点心好好补补英文，程序员阅读各种英文文档需要词汇量自不必说，如果你每次命名都需要翻译软件，不自知的取最生僻的那层含义，或者各种拼写错误，往大了说特别容易引入BUG，往小了说实在丢人丢份。
# 同一代码块/层级/工程中一定不要出现过于相似的名字。由于相似导致写逻辑的时候把自己整乱的大有人在！每每评审看到这种代码吾必痛心疾首。
userVo, userDTO, userBo, userPo...
userAddedList, userAddedLists...
getUsers(), usersQuery(), getUserList()...
# 切不可文不对题，切不可“百转千回”。何意？比如说判断一个人是否是注册会员，变量名被定义成了 notRegisteredUser，大家想想在写各种if条件组合的逻辑判断时会有多酸爽。
01 想清楚再动手
我经常跟团队的人强调慢动手脑先行，可惜能领悟到精髓的人真心不多，其余的通常会以项目进度为由，将“先码起来”列为第一要务，殊不知灾难就是这么悄然来临。
书法看筋骨，代码亦如此。
代码的“筋骨”无非就是分层、结构、逻辑、抽象、封装、模式...曾经大行其道逢人必谈，到现在感觉都没什么人提起了的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 动手能力
程序员的基本工作除了前面说的动脑，紧接着就是动手了。这里需要做一下澄清：基础的编码仅仅是动手能力的一部分，而真正的动手能力远不仅于此。
身为一个程序员，可以搭建一个完整的网站，可以开发一个桌面效率工具，可以编写一个Excel的VBA脚本，可以根据官方文档部署和定制开源系统，可以根据API实现自动化偷懒...
以上才是我想说的动手能力。
大家都知道人和动物的区别是“使用工具”，而程序员群体是更加需要善用工具、甚至创造工具的一类人。当然不要本末倒置，使用工具不是目的只是手段，是为了提高效率、保证质量、降低成本等的手段。
那么最牛逼的工具是什么唻？
Quora有个回复很带感：“A web browser, with Google as its default opening page.” 一个默认打开首页是Google的浏览器。
隐晦的表达了我们程序员很多时候是面向搜索引擎编程的尴尬...
程序员应该跪谢这位大神，Larry Tesler, 就是他发明了Copy&Paste。
这是如此伟大的一项发明，如此的基础和常用，以至于大家好像都忽视了它的巨大能量。
DàYé啰嗦
# “代码的搬运(Copy&Paste)”绝对不是动手能力，“搜索”却是。因为优秀的程序员必然善用搜索引擎、具备良好的搜索技能。
参见我之前的一篇推文《技术人如何高效搜索》
# 承认Copy&Paste是个伟大的发明，但是我还是建议能不用就不用，能手敲就手敲，除非是严重影响工作效率不得不C&P。历史上由复制黏贴引起的BUG还小么?
# 熟练IDE、操作系统、常用软件的一些快捷键。不使用快捷键，就和手机不用手势一样。先不说了，WIN+L锁屏，泡个程序员红茶去。
03 提问的艺术
程序员骨子里的孤傲时常会把自己定位成一个问题终结者，提问题似乎与此格格不入。我到现在都没太想明白这种孤傲源自于哪里，也可能是知识工作者特有的清高。其实吧，大家日不离手的搜索引擎，不就是一种另类的提问么？
待续！！！
