DàYé首席路 | 10.24条程序员生存法则

笔者曲健,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 提问的艺术

image

程序员骨子里的孤傲时常会把自己定位成一个问题终结者,提问题似乎与此格格不入。我到现在都没太想明白这种孤傲源自于哪里,也可能是知识工作者特有的清高。其实吧,大家日不离手的搜索引擎,不就是一种另类的提问么?

卜学良 子曰

亮子的中心思想是个Why,Why的表现是,搞不懂就问人,搞得懂就答人,没有人懂还可以问神…要懂得推理要心存怀疑,要充满好奇要巨细靡遗,要打破砂锅问到底。

Come on everybody!

全套流程建议的第一步是先把自己的问题明确化,并耗费一定的精力去研究琢磨,直到卡滞;第二步是不耻上问/不耻下问, 敢于开口去提问,不要怕丢人,面子相对于知识不值一提;第三步将自己的问题、自己研究的发现等等一并列出,给解答者一个完整的上下文和尽可能多的线索,以节省双方的大量时间;第四步,不管最终是否解决,可以基于解答者给出的方案或者方向,自己在想其他办法去深挖,补齐自己的只是短板。That’s it.

心理专家亚瑟·阿伦有个著名的让陌生人快速熟悉的“36问”,就是好问题的模板,节选几个:

1、如果可以跟世上任何人共进晚餐,你会选择谁?
2、你会想出名吗?以什么样方式出名呢?
3、在打一通电话之前,你会先排演要在电话中说什么吗?为什么?
4、你心中最完美的一天是做哪些事呢?
5、你上一次唱歌给自己听是什么时候?上一次唱给别人听又是何时?
12、如果你明早一觉醒来发现自己获得了某种能力,你希望是什么能力?
30、你上一次在别人面前哭是什么时候?上一次自己哭是什么时候?
36、 说一个个人问题并询问对方的处理意见,让对方向你反馈,你对这个问题所表现出的态度。

DàYé啰嗦

以下的反面教材大家耳熟能详:

# 以他的能力和水平完全可以帮我解答这个问题,为什么他不肯帮我?

帮你是情分,不帮是本分,没有什么理所应当。程序员群体大部分时候是和谐互助的,当然前提是你的问题问到点上、足够清楚、有挑战、礼数到位或者红包打头阵,否则参见下面的细分场景。

# “大神救命啊,我用这个框架老是启动不起来。我可是严格按照手册一步一步来的!”

然后就没有然后了。你的详细线索呢,你怎么排障的呢,你有初步的怀疑对象么?这种卖惨式发问只会给人一种感觉:你自己压根没分析过!我的时间可不是浪费来解决你分内事情的。

#“字符集是UTF8的Mysql5可以存储emoji表情么?”

这种简单的问题要不自己去试,要不去搜,顺便把这块相关的知识点都去阅读一下。你指望某个人给你个答复的同时,还能把整个知识点给你解释一番?

# 劈头盖脸的一堆问题怼出来,没有停顿、没有组织、没有循序渐进。

散弹枪式的发问极容易引起他人的反感,因为你把别人当成了答题人,而不是有来有往的虚心求教。适度且有节奏的发问才是王道。

# 发问前礼貌性的确认对方是否有时间帮忙,发问后不管是否解决都要表示感谢,礼数一定要到位。不要整成一次性买卖,毕竟因为一次不礼貌导致未来可能再难得到帮助,得不偿失。

# 有些人眼花缭乱的问题描述完全不在点子上,解答人若善于引导和抽丝剥茧,能从源头上帮忙解决,若只是纯粹的一问一答,那答案可能压根帮不上忙,因为问题本身的方向就错了。这种体现逻辑洞察能力或者沟通能力,下面会提到,要做到“直抒胸臆”不简单。类似的场景在程序员和产品经理之间也时常发生,聊的牛头不对马嘴,双方都找不到中间的那个契合点,冲突也就难免。

04 逻辑推理

image

程序员日常编码80%的工作除了想变量的命名,就是在写逻辑分支。而日常非编码80%的工作就是理解需求或设计架构,都需较要强的逻辑思维。

先玩个游戏:估算下中国有多少程序员(不严格定义边界)?

https://octoverse.github.com

基于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 羞耻心

image

有羞耻心的程序员才有资格清高,因为羞耻心是你的底气。一个成天写一堆低级bug毫无羞耻的程序员凭什么清高?自己首先会耻于不完美,做到无可挑剔,当然可以清高。

剖开羞耻的表层,本质其实是程序员对于自身的高要求。程序员对自己没有要求,和咸鱼有什么分别。这里还没要求程序员主动去提升自己这个层面,就是靠错误的羞耻感驱动自己提升这一层,很多人做的都不够好。出现BUG无所谓,上线失败问题不大,这是自我放逐到了如何野蛮的地步了?

DàYé啰嗦

现在的互联网应用相对企业应用,可以更快更轻更容错,给年轻人一种错觉好像出点错没什么大不了的,也导致现在的年轻程序员对于BUG, 对于生产环境没有太多的敬畏心

而从做企业应用那个年代出来的程序员,对于这些都是谨小慎微,一点点小错都了不得,感觉要死了,这或多或少与不同时代的程序员文化有关。

# 只要是BUG就是丢人的,不是拿来自黑和一笑而过的。

# 代码被评审出一堆意见来是丢人的,重复犯错更丢人。

# 系统上线漏了个配置是丢人的,就算你前面的开发测试再完美,最后临门一脚没做好,前功尽弃不羞耻?

# 系统上线后的问题都是客户报障的,自己的监控不到位,告警处理不到位,永远是落后客户一步,自己的系统自己HOLD不住,羞耻么?

# DaYe自己对于有些异常如NPE、越界、类型转换,一旦抛出来会觉得特别羞耻,会捶胸顿足为何写这部分代码的时候没有考虑清楚。你会么?

08 同理心

image

同理心Empathy,简单来说就是换位思考,懂得倾听,设身处地的共情共感。也是情商EQ理论里的专有名词。我觉得程序员在同理心方面做的奇差,也是程序员画像“智商高情商低”的口实之一。

程序员思维特别擅长把任何交流转换成技术语言来表述,程序员说的口沫横飞,其他人一脸懵逼。不会说“人”话这一点,一直是程序员的硬伤,缘由大概是大部分时间跟电脑打交道,导致的达尔文式退化吧。

程序员会说“人”话,境界必然升华。因为你若能把程序思维包装成一种非技术人也能听懂的语言,说明你已经脱离了程序员固有的思维框架,可以对等的用对方的语言来直接交流。就像我们在英语对话中,过程是对方的英语通过耳朵进入脑中,先转换成中文,然后想好中文的回答,再翻译成英文,最后用嘴说出来。都知道这是不对的,但碍于英文水平渣渣,臣妾确实办不到屏蔽中文切换环节,直接英文输入输出这种最优秀的交流方式。

当程序员开始用技术来碾压或者嘲笑对方的无知,这时候的交流一定会出现争执和冲突。要求我们立马停顿且站在对方的立场想事情,确实有点强人所难,但是我们可以从一个第三方不相干的人的立场来看这次交流,尽量保证客观,可能会发现另一种思路。

特别程序员在面对BUG和线上故障时的第一反应,通常也不是站在对方立场,而是下意识的抗拒。前线一线商务人员密切关心故障进度,一定会时不时的催促,而程序员思维这时经常会丢出来的一句话是“在处理呢,别催”,如果站在对方的角度来表述“我们已经找到问题的症结了,还需要大约一刻钟的时间,走个紧急审批流程,已在着手修复了,请再耐心等待一下”,将我们的努力过程表达出来,再给一个可期的未来时点,会好一些么?

09 近距离榜样的力量

有人说“我的偶像是Linus Benedict Torvalds”,这个事情对你当前的职场可能并无太多益处。因为Linus人家底子硬,可以怼天怼地怼上帝,而大部分愚钝的我们还差得远…

所以我标题里的重点是“近距离”和“榜样”。也就是在你当前职场环境下,离你最近的最容易效仿和咨询的那个榜样型人才,才是你需要当下尽全力追逐的。

比如自己的代码在最近几次评审里老是被提出很多评审意见,傻的程序员没感觉怎么样,每次提多少改多少,下次可能还犯;聪明的程序员会每次做好总结,保证下次不会再犯;而智慧的程序员,会直接找评审人聊聊他心目中的好代码的标准,找公司的代码规范checklist,翻阅有优秀编程能力同事的代码,反复的学习和实践,主动推动自己往下一个Level演进。

不管是技术、业务、产品还是管理,除非你一骑绝尘,公司范围内在你视野里已经Nobody了,否则每个维度都会有自己可以对标的对象,务必虚心求教,刻苦训练。

我不知道程序员是不是很容易看不上公司内部的一些分享课程,经常因故缺席。然而在收集想听什么课程的时候,又说分享少,最好请外面的一些大神来讲讲课啥的。我一直断言,有这种想法的程序员就不是为了知识,而只是为了有个接触所谓大神的机会,甚至最后能加个好友就有吹嘘资本了。且不说有些所谓的大神很水,就是真正的大神讲的那些干货,你先确定自己能接得住么?根基不稳、眼高手低,所以别怪DaYe啰嗦,先找近前看得见摸得着的对象,试试超过他看看?

10.24 拥抱开源

现而今很多国际顶级的开源技术都是国人搞出来的,不仅让世界看到了国人的技术能力,也让国内的信息化水平有了质的飞越。

开源这个大宝藏用不好,就是可耻的浪费。我经常提醒团队在造轮子之前可以先去开源社区,找找灵感找找思路,千万别一头扎进去,写出来一个残次品没人愿意用。

反过来,开源对于程序员还是比较神圣的一种认可,所以我也会推动团队做一些开源方向的努力。当团队在开发一个内部系统,被安上一个开源的KPI之后,大家的专注力和自我要求都会加强N个档位,毕竟谁也不想开源一个让人嗤之以鼻的软件,执行力、羞耻心和荣誉感会无限爆棚。

以上,是我心目中程序员安身立命的几条黄金法则。有人可能会说,扯了那么多,竟没提程序员的基本功,其实基本功就藏在这10.24条里了,自己去发现吧。

THE END

# daye, rules
You forgot to set the qrcode for Alipay. Please set it in _config.yml.
You forgot to set the qrcode for Wechat. Please set it in _config.yml.
You forgot to set the business and currency_code for Paypal. Please set it in _config.yml.
You forgot to set the url Patreon. Please set it in _config.yml.
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×