从《从小工到专家》的“道”到大厂的“法术器”-哲学篇

Posted 2021-11-04 hello_读书就是赚钱

《从小工到专家》这本书之前看过一章内容觉得平平无奇,直到最近在CSDN的首页看到了这本书做为好书推荐,抽空又翻阅了一次,这一次让我觉得“醍醐灌顶”.
作者在去年加入某大厂,进来了之后一直在思考着如何利用这个平台学习一些有用和值得思考的知识,苦于一直没有找到合适的“灯塔”.看了这本书之后发现原来我想要去寻求的“道”一直就发生在我的身边以各种方式表现出来.
所以作者想跟着《从小工到专家》这本书里面提到的思想,结合作者的亲生经历来复盘总结我所在的大厂是如何践行这些“道”.一来我希望以此来向读者推广这本有趣的厕所读物,二来是抛砖引玉让大家一起来思考发生在我们的身边的有趣知识.
读书有三上,马上,厕上,枕上,这本书是值得成为你的“上”书.

一、本文的内容

本文无干货,但是希望是一篇好的厕所读物.核心骨架是《从小工到专家》的第一篇内容,作者采摘了书中认为对作者有益的“道”(思想,)结合作者经历的“法术器”(规范与规定,行为与技巧,工具)表达出来,一起来窥探这些常见的奥秘

二、道与法术器

1、我的源码被猫吃了

标题很有趣,书作者说的是在一个程序员在deadline的时候给上级搪塞的一个借口是“我的源码被猫吃了”,突出的主题是很多程序并不会对自己的“代码”负责.在完成开发时不会对自己的代码review,一味把功能测试交给测试来背.在封版的时候随意合并代码,甚至没有提交代码.之外,还有很多人会把公司重要的代码上传到互联网,导致公司产生巨大的损失,这一切都是懒惰与责任心,态度产生的问题.
在大厂中,在开发前,一般我们要使用统一的代码规范和框架,先约束好我们代码问题,防止引入bug库,统一大家的代码格式与技术栈.比如golang的官方文档,也专门用了一篇文档写了golang的技术规范,来让大家更好的协作.
在开发中,我们会使用远程开发的工作模式,在我们入职的时候会为每个电脑分配一个人,并且分配一台云上的开发机,大家基本都不会把源码放在本地,而是放在远程机中,再结合IDE的能力直接进行远程开发.比如vscode中的ssh远程连接,这样可以防止代码外泄,也可以对操作进行审计,虽然调试起来比较困难,但也培养了我们写代码,调试的能力.
除此之外,书里也提到了“小黄鸭”理论,指的是在完成开发的时候可以向电脑前面的小黄鸭讲解你的代码逻辑,其实也就是一个自己review的过程.作者的习惯是在合并进test分支的时候review一次,在发起MR的时候review一次,上线前在体验环境验证,并查看日志,通过这几层保障来巩固代码质量.除此之外,CR也是一种不错的检查方式,就是比较费时间.
总结来说,责任心是作者一直认为的很重要的东西,对自己的代码负责是常规的操作,永远不要想让别人来给你擦屁股.

2、软件的熵

这一节给作者最大的感悟是世间万物皆有熵,比如我们的内心表现也是一个熵增的过程,只要没刻意去控制就是心猿意马.那软件也是如此,书作者给了一个有趣的示例是“破窗理论”,在一栋漂亮的建筑,只要出现一个“破窗”,那么人们就会不断的往那个破窗扔东西,直到那栋建筑成为一个垃圾堆.那软件也是如此,只要前人不注意代码整洁,那后人便会想,“害,前面的人都这么写,我只是往屎上面贴屎而已”,最后又向别人吐槽,我司的代码就是一堆屎山,可雪崩了每一片雪花都有责任的.
做为这个例子的反面,作者又举了一个“灭火理论”,说的是如果收藏馆的一处小地方着火,消防员去灭火的时候就会小心翼翼的只为那个地方灭火,而不破坏、污染其他珍贵的文物.那在我们软件工程中呢?只要我们的项目一直是保持整洁的,大家对代码又有敬畏之心的话,项目就会一直保持整洁,这是一个正反馈的过程.
在工作中,我们也是会使用譬如代码质量红线的方法来对代码做自动化检测,就是在编译的流水线中自动扫描的仓库的代码,把不规范的东西向程序员与leader抛出来,只能在修复后才能正常编译提交成功,可是有时候我们也会“忽视”掉“警告”,终归躲不过人性的懒惰.除此之外,上面说的CR也是能尽最大的程度来防治这个问题.
总结来说还是回到责任心的问题,只要人人都献出一点爱,对于代码,我们都得拥有工匠精神.

3、石头汤的故事

讲的是一群饥饿的士兵路过村庄,因为没得食物,就用石头煮水,吸引村民过来一同享用,村民见有的吃,便每个人都贡献自己的一份食材,最终本原来只有石头的水,变成了一份真的丰富的汤.
在这个故事中,其实作者看到的就是大厂里面常见的“画饼”操作,从offer提高你的总包,到4、5🌟得激励机制,都是在推动每一个员工的自我进步,从而提高公司的收益.很多项目在初始的时候就是画的一个饼,但当每个人都贡献自己资源的时候,饼也许真的能被造出来.当我们是村民角色的时候,去参与石头汤其实是一个好的选择,毕竟汤煮好了,也有自己的一份,协同好被每个人守护的资源,有1+1大于2的效果.
假设我们是士兵的角色呢,我们可以做一个变化的催化剂,无论对上,对下都是可以给他们“画饼”,就像我们引入了OKR来促进协同,我们利用共同目标,让上下游能支持自己的,也是一个不错的思考,圆滑处理的方式.

4、足够好的软件

作者相信只要对代码有追求的程序员都会跟作者一样,无论自己的代码写的多久,都会觉得“或许xxx的实现方式”更好.而书作者在这一节是想给我们提个醒,要适可而止的相信自己的代码“足够”好.一套好的系统的面试官其实是用户,而我们要在保证质量的情况下尽快的交付给用户,让用户来评价我们的系统到底是不是足够好,系统是迭代出来的,而不是设计出来的.
现在很多大厂一直提倡的是敏捷开发,尽快交付,作者之前在公司负责的一个项目就是如此,基本是一周一个需求开始迭代,在完成第一个小版本的时候就引入了3000个用户来进行试用,收集反馈意见再迭代修改,一个个的小周期的轮询着.就像我们的微服务来说,最开始为了尽快交付,最开始就是一把搜哈,所有逻辑都是for循环从上往下搜.后面发现性能问题开始优化,比如用领域代码重构掉一些重复性问题,查库的时候从一条条优化成批量查询,加入了一二级缓存等.
总结来说,代码总是要先保证可读的+可用的,优雅和性能是其次.吃了很多“面经”的人总是很喜欢在不适合的场景强调“高性能”的方案,这是杀猪用牛刀.这个道理也是作者在最近一两年感悟到的,所有的技术,没有最好的,只有最适合的,改掉你的强迫症.

5、你的知识资产

书作者把每个人的“知识”沉淀类比成金融市场上的资产投资,其实不仅包括知识,包括经验与想法也是,书作者说管理知识资产有下面几个途径

• 坚持定投:在这一个行业,就是要不断的学习,坚信书籍有用论.现在很多人在恐惧“35岁危机”,但作者的答案是自己的知识资产,经验与想法就是最好的本钱,不怕35岁,怕的是到了35岁掌握的还是25岁时的知识经验想法,那就很恐怖.之前听过左耳朵耗子的一个演讲,核心的两个点,一个是这个世界终究会把最重要的事情交给那些30岁的人,有的人因为自己的经验所以扛起来就过去了而且还能吃后半辈子.有的人扛不起来那就会被淘汰.一个是他之所以能蹦跶这么久不被淘汰,就是因为知识经验沉淀了很多,还抨击了现在996的现象让年轻的程序员没有时间去学习,所以他就不会被淘汰.曾经问过身边的人,基本是只在面试、升级的时候看书、总结.
  对作者而言,不是想鼓励工贼式的无效努力,而是提醒自己,打的工就是悬在空中的达摩克利斯之剑,在我们休息够了有精神就做一些有意义、让自己提升的事情,后面的路会比较好走.
• 多元化投资:这个也是最近收获比多的点,真的有时候我们不得不相信看书有用论,也就是什么书都可以看,管理学,心理学,营养学,对我们人生都是一个提升的过程.回顾k12真的对我们影响很大,它让我们学一些不爱学的东西很抗拒,养成书籍无用论的观点.
  现在出来社会,我们要跳出这个框框,举个例子,作者看了《毛泽东传(红皮书)》版本,说教员在看书的时候写的注释比书的内容还多,作者就实践了一次,发现真的是不错的方式,只要看到一句让自己动心的句子,就可以记录起来,后面在输出的时候很快,也是一个很好的思考过程.
• 低买高卖:说的是我们可以去选一个冷门的知识去学,说不定一天那个知识就变成了热门.这在作者身上没实践过,不过让作者体会比较深的一点就是看书,就比如在看《小工》这本书,最开始看的时候觉得写的是啥都是些理论,等到去经历了,复盘了,发现原来是如此呀,古人诚不欺我,虽然这是一个马后炮的过程,但是这种感觉也是很美妙.
• 评估自己的知识资产:适时的评估自己的知识面,有的人喜欢在面试的时候总结,而我的路是根据自己做的项目技术栈来做规划的,比如作者在第一家公司的时候,用起了微服务,数据库分库,缓存,搜索引擎,负载均衡,监控等技术组件,那作者就会去复盘哪些是不懂的,先过一次,并尝试输出方面方便review.到第二家的时候,其实还是这些东西,但是对自己是第二个学习周期,所以作者会再去学一次,但这次就是往深一点去挖,比如看mysql的时候不在只关心怎么“面”,还要质疑知识点,去官方查文档,然后记录起来.除此之外,还会向往思考, 比如现在别人的海量数据是怎么做分库存储等.

总结来说就是不断沉淀,在大厂内也是鼓励大家去输出技术文章,特别是10级以上的高工是要在内网输出培训视频与有深度技术文章,这些于己于司都是一份很好的资产.

6、交流

没有有效的交流,一个好的想法就是一个无人关心的孤儿.在大厂里面是比较重视“交流”这个环节的,在平时是体现在每日的站会,周会,都是一个交流反馈的好的过程,这里也是鼓励大家勇敢的表达自己的想法.但从交流这个点出发,有几个点我们可以注意一下.
1、要找到听众的G点:去说出你的听众比较感兴趣的话,比如在晋升答辩中,我们要说的是我们对自己项目的高层抽象设计,如何做,做后的成果等,因为你面向的是评委都是高工,没人愿意跟你说代码里面的细节,抽象化的方法论总结才是他们感兴趣的地方.
2、一道好的菜一定是色香味俱全的:很多程序员都认为只要代码优雅就好了,不想做ppt程序员等这样的观点.其实这东西就像做菜,苍蝇馆的菜炒的多好吃都是上不了五星级酒店.我们除了要修炼内功外,也一定要做好表面工程.比如你的服务设计得非常高性能,高可用,但是让你画个架构图完全没体现分层、领域的概念;让你讲的时候一直纠结在哪一行代码你做了什么改进等,都是无益于去展示自己.所以我们可以经常锻炼自己的“交流技能”,譬如写好这篇厕上读物,就是作者在尝试着提炼着自己的观点与对自己的经验的总结归纳,以此来与读者进行有益的交流.虽然作者也是一颗“螺丝钉”,但是希望能让读者看到作者是一个闪闪发光的人.
总结,多维度的考虑受众面,见人说人话,见鬼说鬼话.多渠道的去交流,表达自己的观点,我们不要做一个焖烧的程序员.

第一篇总结,书中这一章的名字叫“注重实效的哲学”,确实很哲学.比较喜欢外国佬的书,因为他们说技术的时候总可以从生活的方方面面对知识和思想说类比,讲故事,而这篇文章也是写出了作者自己的故事,希望引起大家的思考,下面还会对其他章节做总结输出,希望大家关注期待.