慢就是快
记得有一天回来我问小码匠:你晚上学了多少pandas啊?
小码匠:看了15页资料。
我:你用了多长时间啊?
小码匠: 两个小时。
我又问:怎么这么慢啊?
小码匠: 我遇到不会的都做了笔记,非常认真的,逐字逐句理解的。
我:哦,那还有不会的吗?不理解的吗?
小码匠: 有啊,不多,我给你讲?
我:嗯,你讲吧。
小码匠拿起白板笔, 滔滔不绝讲了起来。
说真心话,讲的不错, 理解的基本都很到位。
2小时=读15页书,看似很慢,但真正消化理解了,转化成自己知识,这就应了《道德经》上所说:少就是多,慢就是多。
《论语·子路》上也说:“无欲速,无见小利。欲速则不达,见小利则大事不成。”
看我们现实的团队中,经常的场景:团队成员风风火火,接到活撸袖子就干,之后大量的返工,挖的坑太深自己想蹦也蹦不出去。
场景一: 产品讲完需求,研发同学回去就开撸代码?
Stop!!!
现在让我们尝试问自己几个问题。
-
需求是否都理解了,各团队对需求理解的一致吗?
-
技术实现方式考虑清楚了吗?
-
新需求可能去会带来哪些风险评估了吗?
-
新需求代码修改范围搞清楚了吗?
-
...
如果这些问题没想清楚,请先慢下来,想清楚再开撸不迟的。
我们该怎么做
这种情况在我经历的团队中屡见不鲜。相信很多同学也都遇到过。
下面谈下我们团队针对技术方面做的改进。
技术方案
拿到需求直接开撸代码?
No,No。
我们要先写技术方案,技术方案包含:
-
功能梳理
-
新旧功能分开梳理
-
旧功能迭代优化修改范围
-
性能要求(并发数,响应时间有要求)
-
数据表结构设计及索引设计
-
是否需要缓存/消息队列等,如需要明确具体场景及命名规范等
-
复杂的业务处理流程需要画架构图
-
…
技术方案评审:叫上产品/测试同学
技术方案评审为啥叫产品去和测试同学
-
确认多方需求是否理解一致
-
测试同学会根据我们的梳理的技术方案完善测试Case
好处:
-
大家需求理解基本达成一致
-
漏测的case变少
-
研发都想清楚了,撸代码高效
-
通过技术方案的交流碰撞, 全员相互取长补短,完善方案,全员技术能力得到进步
-
…
结果:方案更完善,返工更少,系统扩展性更好。慢就是快得到了很好的印证。
场景二: 需求都干不完,遵守编码规范太麻烦了,以后有时间再改规范吧。
看似理由合理,其实是自欺欺人。
记得团队最早推规范的时候,很多同学也这样想。后来跟同学们交流时,我问了几个问题。
-
遵守规范写代码,需要多少时间,大家有评估吗?(我们当时是分阶段推规范,先推代码格式问题)
-
写完代码按下ctrl+shift+f, 按下ctrl+shift+O格式化代码需要多少时间?
-
使用插件把违反规范地方扫描出来,再修改如按规范空行、写注释、 复杂代码逻辑做适当拆分, 能占用你20%的时间吗?
记得当时同学们说:用不了20%的时间,也就占用5%的时间。
后来通过强化推动,大家的规范问题减少多了,代码变得更整洁易维护。
慢就是快,多花了5%的时间遵守规范,未来代码变的更容易维护, 至少能换来30%的收益不为过吧。
场景三: 因为所谓的快熬成熊猫眼
曾经经历的画面: 一上线新功能,各团队手忙脚乱(涉及后端/移动端/前端研发/测试线上回归/产品线上线收等)
-
前后端没协调好上线步骤
-
产品没准备好待发布产品的产品代码等
-
测试没准备好回归数据
-
...
当时在推动改善流程时大家也都感觉太麻烦了,还要写上线计划,还要评审计划,
太耽误时间了,本来就忙的脚朝天了,抵触情绪很大。
那怎么办: 强推, 让大家转变意识是需要时间的,先来硬的吧。
我们当时的做法:每次上线你必须要写上计划, 而且上线计划从编写代码就开始准备的,不断完善,
比如:技术方案评审阶段就要把所有涉及数据库变更的sql写好,后续测试阶段如有修改也必须同步改sql文件。
上线计划要明确各团队对接人/明确上线时间及各团队上线顺序/脚本要提前演练。
上线前要对上线方案评审,相关关系人要明确职责。
同样看似增加了不少环节,费时费力。
-
但这些都揉到日常的环节,不是集中整理, 时间成本很小。 比如 :如果迭代功能点多、涉及数据库变更点也多,最后花时间点去整理,能整理全吗?发生过很多次上线问题,都是因为最后慌里慌张整理,缺东少西的。 最后整理需要回忆,一是容易遗漏,二是从头梳理时间成本更高的。
-
大家的习惯变得更好了,做事变得有规划性,风险都提前评估了。
推动这个流程,虽然当时阻力还是蛮大的,毕竟涉及多个团队协作要去搞,大家意见很难达到统一。
但既然决定了,没办法,霸王硬上弓,不商量,照做就行。
之后团队按照这个流程做了改善
-
上线时,大家也不用熬成熊猫眼了。
-
上线后的故障率大幅下降。
-
大家事前确认,沟通意识得到了极大的增强。
我们心太急,太急
慢就是快跟需要我们能改善自己的主观意识, 能去精心思考,才是真正意义上的快。
慢就是快体现在我们日常生物的任何角落,记得小码匠小时候学轮滑,在家门口找了个教练,
教练说: 学一期就能学会,一期十次课,当时感觉挺好啊,就跟着学,后来偶然一次去办事,
在鸟巢附近看到一个教练也教孩子们学轮滑,过去闲聊了几句, 那教练说: 10次保会纯胡扯,
是不是那种站着摇摇晃晃的滑,你看我这帮队员,几个基础动作练了三个月了,
现在的慢是为了他们以后的快,练速滑脚底下都不稳,将来能滑得快吗?
这种场景尤其是各种不专业的兴趣班,打的都是家长图快,马上能见效的心里。
快往往是一个巨大的坑。
慢就是快,其实这个道理很多人都懂,可一遇到事,就扎进去,跳不出来。
很多事不是杠着枪往前冲就能胜利的,看似勇敢,实则是莽汉。
尤其作为团队管理者,更应该勒缰绳,控制主想快的欲望,
让情绪平静下来,静心思考那些关键因素,专注解决重要紧急事。
1024,我们该做什么
还在一如既往的加班吗?
还在一如即往的求快吗?
我们要慢下来,
我们要静心思考,
我们要关注研发效能,
我们是一群追求高效,追求卓越的码匠。
关注公众号【小码匠和老码农】收获小码匠和老码农精心挑选的电子书
- 回复【算法】收获算法书电子书
- 回复【python】收获python基础电子书