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