笔者曲健，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 动手能力
东北大兄弟说：能动手就别BB。
程序员的基本工作除了前面说的动脑，紧接着就是动手了。这里需要做一下澄清：基础的编码仅仅是动手能力的一部分，而真正的动手能力远不仅于此。
身为一个程序员，可以搭建一个完整的网站，可以开发一个桌面效率工具，可以编写一个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 提问的艺术
程序员骨子里的孤傲时常会把自己定位成一个问题终结者，提问题似乎与此格格不入。我到现在都没太想明白这种孤傲源自于哪里，也可能是知识工作者特有的清高。其实吧，大家日不离手的搜索引擎，不就是一种另类的提问么？
卜学良 子曰
亮子的中心思想是个Why，Why的表现是，搞不懂就问人，搞得懂就答人，没有人懂还可以问神...要懂得推理要心存怀疑，要充满好奇要巨细靡遗，要打破砂锅问到底。
Come on everybody!
全套流程建议的第一步是先把自己的问题明确化，并耗费一定的精力去研究琢磨，直到卡滞；第二步是不耻上问/不耻下问, 敢于开口去提问，不要怕丢人，面子相对于知识不值一提；第三步将自己的问题、自己研究的发现等等一并列出，给解答者一个完整的上下文和尽可能多的线索，以节省双方的大量时间；第四步，不管最终是否解决，可以基于解答者给出的方案或者方向，自己在想其他办法去深挖，补齐自己的只是短板。That's it.
心理专家亚瑟·阿伦有个著名的让陌生人快速熟悉的“36问”，就是好问题的模板，节选几个：
1、如果可以跟世上任何人共进晚餐，你会选择谁？
2、你会想出名吗？以什么样方式出名呢？
3、在打一通电话之前，你会先排演要在电话中说什么吗？为什么？
4、你心中最完美的一天是做哪些事呢？
5、你上一次唱歌给自己听是什么时候？上一次唱给别人听又是何时？
12、如果你明早一觉醒来发现自己获得了某种能力，你希望是什么能力？
30、你上一次在别人面前哭是什么时候？上一次自己哭是什么时候？
36、 说一个个人问题并询问对方的处理意见，让对方向你反馈，你对这个问题所表现出的态度。
DàYé啰嗦
以下的反面教材大家耳熟能详：
# 以他的能力和水平完全可以帮我解答这个问题，为什么他不肯帮我？
帮你是情分，不帮是本分，没有什么理所应当。程序员群体大部分时候是和谐互助的，当然前提是你的问题问到点上、足够清楚、有挑战、礼数到位或者红包打头阵，否则参见下面的细分场景。
# “大神救命啊，我用这个框架老是启动不起来。我可是严格按照手册一步一步来的！”
然后就没有然后了。你的详细线索呢，你怎么排障的呢，你有初步的怀疑对象么？这种卖惨式发问只会给人一种感觉：你自己压根没分析过！我的时间可不是浪费来解决你分内事情的。
#“字符集是UTF8的Mysql5可以存储emoji表情么？”
这种简单的问题要不自己去试，要不去搜，顺便把这块相关的知识点都去阅读一下。你指望某个人给你个答复的同时，还能把整个知识点给你解释一番？
# 劈头盖脸的一堆问题怼出来，没有停顿、没有组织、没有循序渐进。
散弹枪式的发问极容易引起他人的反感，因为你把别人当成了答题人，而不是有来有往的虚心求教。适度且有节奏的发问才是王道。
# 发问前礼貌性的确认对方是否有时间帮忙，发问后不管是否解决都要表示感谢，礼数一定要到位。不要整成一次性买卖，毕竟因为一次不礼貌导致未来可能再难得到帮助，得不偿失。
# 有些人眼花缭乱的问题描述完全不在点子上，解答人若善于引导和抽丝剥茧，能从源头上帮忙解决，若只是纯粹的一问一答，那答案可能压根帮不上忙，因为问题本身的方向就错了。这种体现逻辑洞察能力或者沟通能力，下面会提到，要做到“直抒胸臆”不简单。类似的场景在程序员和产品经理之间也时常发生，聊的牛头不对马嘴，双方都找不到中间的那个契合点，冲突也就难免。
04 逻辑推理
程序员日常编码80%的工作除了想变量的命名，就是在写逻辑分支。而日常非编码80%的工作就是理解需求或设计架构，都需较要强的逻辑思维。
先玩个游戏：估算下中国有多少程序员(不严格定义边界)？
基于GitHub的2018年度数据报告，目前一共3100万注册用户，20%美国本土用户，中国是仅次于美国的GitHub大户，打个八折，算出中国注册用户500万(无视不同程度的水分)。
https://www.idc.com/getdoc.jsp?containerId=US44363318
再按照IDC估算的全世界2200万左右软件工程师，按比例折算下中国码农群体 500万/1.4≈350万。
本人宣称对中国码农群体350万这个虚数负责到2019年年底。
参考链接：
世界人口(77亿)：https://www.worldometers.info/cn/
中国人数(13亿，就业人数7.7亿)：
https://www.ceicdata.com/zh-hans/country/china
以上是个典型的考察逻辑推理能力的小例子。《超级思维》这本书里面有更多奇奇怪怪的逻辑题目，都是让你感觉无从下手的。
其实，在拿到一个即使简单如APP登录的需求时，作为知识工作者的程序员就也需要展现出自身强大的逻辑推演能力，抽丝剥茧，将需求抽象为领域模型或者转化为系统设计。这方面有大量的方法论，比如奥卡姆剃刀，比如WBS，都不重要。重要的是你一定要沉心静气，不能是闷头苍蝇似的一通乱撞。要找到最适合自己、最适用当下的那个方法。是砍掉枝叶先看主干，还是抽丝剥茧层层拆解，都是逻辑推理的一种体现罢了。
DàYé啰嗦
APP登录过程究竟发生了什么，或者应该发生什么，是我面试时经常用来考察一个人逻辑思维能力的题目。除了是人都知道的用户名密码校验还有什么呢？
# 用户名的长度区间是什么？
# 用户名支持的字符集是什么？存储会乱码么？
# 密码的长度区间是什么？字符组合是什么？
# 密码的加密方式是什么？如何确保传输通道不会被中间人劫持？
# 用户名/密码是否含有非法字符(代码注入)、政治敏感、低俗不雅的文字？
# 密码最多可以输错多少次？超过后账户禁用多久？
# 是否支持用户多终端登陆？如果支持的话，账户在A终端被禁用后，在B终端的已登入态是否被踢出？
# 用户在终端的登录有效时长如何考虑的？
# 登录的错误提示有很多种，用户名不存在、密码错误、账户禁用，还有哪些？
还有很多没展开，如手机号/邮箱绑定，短信/邮件验证码验证，常用设备管理等等，可以继续推演下去，但是如果能在面试的压力环境下，有条不紊的罗列出用户名、密码、安全、状态、话术、用户体验面等等这些维度上的思考，那基本上没毛病。真实情况是不少人在这些维度上跳来跳去，没有条理性、延续性，想到哪儿是哪儿，只能说明逻辑推理上有所欠缺。
05 时间规划, 要事优先
我们身边不乏这种人：每日忙忙活活，勤勤恳恳，乐于助人，看起来是公司里最敬业爱岗的那个。实情却是大量任务一旦堆积到他手里就失去了进度，甚至因为同时赶很多任务，导致高优先级任务的质量不达标。这类人的典型问题就是做不好时间规划，分不清轻重缓急。
爱因斯坦老头的相对论告诉我们，时间是相对的。同样的每天8小时，有序、有效和高效的使用了这8小时的产出，可以比无序、无效和低效的产出高出2倍不止。核心点是什么呢？
DàYé啰嗦
# 让时间的无效流逝产生罪恶感
理解前先举个栗子。小时候暑假的前半段基本都是瞎玩，最后一周疯狂的写作业，连吃饭都觉得在浪费时间，如果吃饭的时候还在看电视，那时的罪恶感爆棚，时刻觉得我的作业还在等着我...所以明白了么，产生罪恶感的前提是我的任务是有优先级的，加上自己的责任感，一旦高优先级任务阻滞了，而我还在浪费时间在某个无意义的事务上，就会及时叫醒自己，阻止自己的继续浪费。
# 好记性不如烂笔头
曾几何时公司里的笔记本还是用来记事的，现在好像成了用来涂鸦的了。一般开会我都会要求大家都带笔记本，无他，我就是不信你的脑子记得住会议上的所有要点或者决议；而日常项目中有些重要的事项或者节点也都应该记录下来，项目上线前翻一翻确认自己没有遗漏；等等。当然上面说的这些你可能有其他的工具来实现，殊途同归罢了。
# 请学会拒绝
烂好人这种事情在职场基本是行不通的。因为你好，你的事情就会多而杂；因为你好，你的事情就都是高优先级；因为你好，流程规范就容易违反；因为你好，时间一长就成了理所当然，这事将永远粘着你；因为你好，任务积压到你手里，任务最终延期交付，你得背锅；因为你好，你就再也拒绝不了别人了，因为“雷锋”是不会也不该拒绝他人，会一直被道德绑架在十字架上。
06 心向自由, 遵纪守法
人是生而自由的，却无往不在枷锁之中。
-- 卢梭 《社会契约论》
人生而自由，清高的程序员更加的心向自由。不喜欢西装革履，不喜欢一板一眼，不喜欢上班打卡，不喜欢规章制度...
每家公司都制定了各种各样的制度、规范、流程，这些东西经常被视为洪水猛兽，枷锁镣铐。只有不成熟的人才会把自由放在嘴边，成熟的人怎么会不知道
自由是要付出代价的！
上班时间是自由弹性的，结果可能是开敏捷站会的时候少一个人更新进度，因为你没来，这个代价谁来支付？
生产上线可以随意发挥，上挂了再上一次呗。如果一个面向C端用户的产品，你确定要让用户承担无法使用、公司承担损失用户的代价么？
数据权限是自由的，这样查数据方便多了，谁来承担数据被导出打包卖的代价？
开发私接需求，不走那套评审、设计和进入迭代的繁琐流程，测试不知道这块的回归内容，上线后出问题才发现，这个代价谁承担？
选择了自由，必须承担代价，也同时选择了责任。没有责任的自由只是小孩子过家家。所以在感觉自已被约束了之前，先扪心自问，自己是否有能力消解跳出框架的风险，是否有担当承担自由之后的代价。
07 羞耻心
有羞耻心的程序员才有资格清高，因为羞耻心是你的底气。一个成天写一堆低级bug毫无羞耻的程序员凭什么清高？自己首先会耻于不完美，做到无可挑剔，当然可以清高。
剖开羞耻的表层，本质其实是程序员对于自身的高要求。程序员对自己没有要求，和咸鱼有什么分别。这里还没要求程序员主动去提升自己这个层面，就是靠错误的羞耻感驱动自己提升这一层，很多人做的都不够好。出现BUG无所谓，上线失败问题不大，这是自我放逐到了如何野蛮的地步了？
DàYé啰嗦
现在的互联网应用相对企业应用，可以更快更轻更容错，给年轻人一种错觉好像出点错没什么大不了的，也导致现在的年轻程序员对于BUG, 对于生产环境没有太多的敬畏心。
而从做企业应用那个年代出来的程序员，对于这些都是谨小慎微，一点点小错都了不得，感觉要死了，这或多或少与不同时代的程序员文化有关。
# 只要是BUG就是丢人的，不是拿来自黑和一笑而过的。
# 代码被评审出一堆意见来是丢人的，重复犯错更丢人。
# 系统上线漏了个配置是丢人的，就算你前面的开发测试再完美，最后临门一脚没做好，前功尽弃不羞耻？
# 系统上线后的问题都是客户报障的，自己的监控不到位，告警处理不到位，永远是落后客户一步，自己的系统自己HOLD不住，羞耻么？
# DaYe自己对于有些异常如NPE、越界、类型转换，一旦抛出来会觉得特别羞耻，会捶胸顿足为何写这部分代码的时候没有考虑清楚。你会么？
08 同理心
同理心Empathy，简单来说就是换位思考，懂得倾听，设身处地的共情共感。也是情商EQ理论里的专有名词。我觉得程序员在同理心方面做的奇差，也是程序员画像“智商高情商低”的口实之一。
程序员思维特别擅长把任何交流转换成技术语言来表述，程序员说的口沫横飞，其他人一脸懵逼。不会说“人”话这一点，一直是程序员的硬伤，缘由大概是大部分时间跟电脑打交道，导致的达尔文式退化吧。
程序员会说“人”话，境界必然升华。因为你若能把程序思维包装成一种非技术人也能听懂的语言，说明你已经脱离了程序员固有的思维框架，可以对等的用对方的语言来直接交流。就像我们在英语对话中，过程是对方的英语通过耳朵进入脑中，先转换成中文，然后想好中文的回答，再翻译成英文，最后用嘴说出来。都知道这是不对的，但碍于英文水平渣渣，臣妾确实办不到屏蔽中文切换环节，直接英文输入输出这种最优秀的交流方式。
当程序员开始用技术来碾压或者嘲笑对方的无知，这时候的交流一定会出现争执和冲突。要求我们立马停顿且站在对方的立场想事情，确实有点强人所难，但是我们可以从一个第三方不相干的人的立场来看这次交流，尽量保证客观，可能会发现另一种思路。
特别程序员在面对BUG和线上故障时的第一反应，通常也不是站在对方立场，而是下意识的抗拒。前线一线商务人员密切关心故障进度，一定会时不时的催促，而程序员思维这时经常会丢出来的一句话是“在处理呢，别催”，如果站在对方的角度来表述“我们已经找到问题的症结了，还需要大约一刻钟的时间，走个紧急审批流程，已在着手修复了，请再耐心等待一下”，将我们的努力过程表达出来，再给一个可期的未来时点，会好一些么？
09 近距离榜样的力量
有人说“我的偶像是Linus Benedict Torvalds”，这个事情对你当前的职场可能并无太多益处。因为Linus人家底子硬，可以怼天怼地怼上帝，而大部分愚钝的我们还差得远...
所以我标题里的重点是“近距离”和“榜样”。也就是在你当前职场环境下，离你最近的最容易效仿和咨询的那个榜样型人才，才是你需要当下尽全力追逐的。
比如自己的代码在最近几次评审里老是被提出很多评审意见，傻的程序员没感觉怎么样，每次提多少改多少，下次可能还犯；聪明的程序员会每次做好总结，保证下次不会再犯；而智慧的程序员，会直接找评审人聊聊他心目中的好代码的标准，找公司的代码规范checklist，翻阅有优秀编程能力同事的代码，反复的学习和实践，主动推动自己往下一个Level演进。
不管是技术、业务、产品还是管理，除非你一骑绝尘，公司范围内在你视野里已经Nobody了，否则每个维度都会有自己可以对标的对象，务必虚心求教，刻苦训练。
我不知道程序员是不是很容易看不上公司内部的一些分享课程，经常因故缺席。然而在收集想听什么课程的时候，又说分享少，最好请外面的一些大神来讲讲课啥的。我一直断言，有这种想法的程序员就不是为了知识，而只是为了有个接触所谓大神的机会，甚至最后能加个好友就有吹嘘资本了。且不说有些所谓的大神很水，就是真正的大神讲的那些干货，你先确定自己能接得住么？根基不稳、眼高手低，所以别怪DaYe啰嗦，先找近前看得见摸得着的对象，试试超过他看看？
10.24 拥抱开源
现而今很多国际顶级的开源技术都是国人搞出来的，不仅让世界看到了国人的技术能力，也让国内的信息化水平有了质的飞越。
开源这个大宝藏用不好，就是可耻的浪费。我经常提醒团队在造轮子之前可以先去开源社区，找找灵感找找思路，千万别一头扎进去，写出来一个残次品没人愿意用。
反过来，开源对于程序员还是比较神圣的一种认可，所以我也会推动团队做一些开源方向的努力。当团队在开发一个内部系统，被安上一个开源的KPI之后，大家的专注力和自我要求都会加强N个档位，毕竟谁也不想开源一个让人嗤之以鼻的软件，执行力、羞耻心和荣誉感会无限爆棚。
以上，是我心目中程序员安身立命的几条黄金法则。有人可能会说，扯了那么多，竟没提程序员的基本功，其实基本功就藏在这10.24条里了，自己去发现吧。
THE END
