身为程序员的我们更应该思考如何放慢脚步

811 阅读7分钟

慢就是快

记得有一天回来我问小码匠:你晚上学了多少pandas啊?

小码匠:看了15页资料。

我:你用了多长时间啊?

小码匠: 两个小时。

我又问:怎么这么慢啊?

小码匠: 我遇到不会的都做了笔记,非常认真的,逐字逐句理解的。

我:哦,那还有不会的吗?不理解的吗?

小码匠: 有啊,不多,我给你讲?

我:嗯,你讲吧。

小码匠拿起白板笔, 滔滔不绝讲了起来。

说真心话,讲的不错, 理解的基本都很到位。

2小时=读15页书,看似很慢,但真正消化理解了,转化成自己知识,这就应了《道德经》上所说:少就是多,慢就是多。

《论语·子路》上也说:“无欲速,无见小利。欲速则不达,见小利则大事不成。”

看我们现实的团队中,经常的场景:团队成员风风火火,接到活撸袖子就干,之后大量的返工,挖的坑太深自己想蹦也蹦不出去。

场景一: 产品讲完需求,研发同学回去就开撸代码?

Stop!!!

现在让我们尝试问自己几个问题。

  • 需求是否都理解了,各团队对需求理解的一致吗?

  • 技术实现方式考虑清楚了吗?

  • 新需求可能去会带来哪些风险评估了吗?

  • 新需求代码修改范围搞清楚了吗?

  • ...

如果这些问题没想清楚,请先慢下来,想清楚再开撸不迟的。

我们该怎么做

这种情况在我经历的团队中屡见不鲜。相信很多同学也都遇到过。

下面谈下我们团队针对技术方面做的改进。

技术方案

拿到需求直接开撸代码?

No,No。

我们要先写技术方案,技术方案包含:

  • 功能梳理

  • 新旧功能分开梳理

  • 旧功能迭代优化修改范围

  • 性能要求(并发数,响应时间有要求)

  • 数据表结构设计及索引设计

  • 是否需要缓存/消息队列等,如需要明确具体场景及命名规范等

  • 复杂的业务处理流程需要画架构图

技术方案评审:叫上产品/测试同学

技术方案评审为啥叫产品去和测试同学

  • 确认多方需求是否理解一致

  • 测试同学会根据我们的梳理的技术方案完善测试Case

好处:

  • 大家需求理解基本达成一致

  • 漏测的case变少

  • 研发都想清楚了,撸代码高效

  • 通过技术方案的交流碰撞, 全员相互取长补短,完善方案,全员技术能力得到进步

结果:方案更完善,返工更少,系统扩展性更好。慢就是快得到了很好的印证。

场景二: 需求都干不完,遵守编码规范太麻烦了,以后有时间再改规范吧。

看似理由合理,其实是自欺欺人。

记得团队最早推规范的时候,很多同学也这样想。后来跟同学们交流时,我问了几个问题。

  • 遵守规范写代码,需要多少时间,大家有评估吗?(我们当时是分阶段推规范,先推代码格式问题)

  • 写完代码按下ctrl+shift+f, 按下ctrl+shift+O格式化代码需要多少时间?

  • 使用插件把违反规范地方扫描出来,再修改如按规范空行、写注释、 复杂代码逻辑做适当拆分, 能占用你20%的时间吗?

记得当时同学们说:用不了20%的时间,也就占用5%的时间。

后来通过强化推动,大家的规范问题减少多了,代码变得更整洁易维护。

慢就是快,多花了5%的时间遵守规范,未来代码变的更容易维护, 至少能换来30%的收益不为过吧。

场景三: 因为所谓的快熬成熊猫眼

曾经经历的画面: 一上线新功能,各团队手忙脚乱(涉及后端/移动端/前端研发/测试线上回归/产品线上线收等)

  • 前后端没协调好上线步骤

  • 产品没准备好待发布产品的产品代码等

  • 测试没准备好回归数据

  • ...

当时在推动改善流程时大家也都感觉太麻烦了,还要写上线计划,还要评审计划,

太耽误时间了,本来就忙的脚朝天了,抵触情绪很大。

那怎么办: 强推, 让大家转变意识是需要时间的,先来硬的吧。

我们当时的做法:每次上线你必须要写上计划, 而且上线计划从编写代码就开始准备的,不断完善,

比如:技术方案评审阶段就要把所有涉及数据库变更的sql写好,后续测试阶段如有修改也必须同步改sql文件。

上线计划要明确各团队对接人/明确上线时间及各团队上线顺序/脚本要提前演练。

上线前要对上线方案评审,相关关系人要明确职责。

同样看似增加了不少环节,费时费力。

  • 但这些都揉到日常的环节,不是集中整理, 时间成本很小。

    比如 :如果迭代功能点多、涉及数据库变更点也多,最后花时间点去整理,能整理全吗?发生过很多次上线问题,都是因为最后慌里慌张整理,缺东少西的。

    最后整理需要回忆,一是容易遗漏,二是从头梳理时间成本更高的。

  • 大家的习惯变得更好了,做事变得有规划性,风险都提前评估了。

推动这个流程,虽然当时阻力还是蛮大的,毕竟涉及多个团队协作要去搞,大家意见很难达到统一。

但既然决定了,没办法,霸王硬上弓,不商量,照做就行。

之后团队按照这个流程做了改善

  • 上线时,大家也不用熬成熊猫眼了。

  • 上线后的故障率大幅下降。

  • 大家事前确认,沟通意识得到了极大的增强。

我们心太急,太急

慢就是快跟需要我们能改善自己的主观意识, 能去精心思考,才是真正意义上的快。

慢就是快体现在我们日常生物的任何角落,记得小码匠小时候学轮滑,在家门口找了个教练,

教练说: 学一期就能学会,一期十次课,当时感觉挺好啊,就跟着学,后来偶然一次去办事,

在鸟巢附近看到一个教练也教孩子们学轮滑,过去闲聊了几句, 那教练说: 10次保会纯胡扯,

是不是那种站着摇摇晃晃的滑,你看我这帮队员,几个基础动作练了三个月了,

现在的慢是为了他们以后的快,练速滑脚底下都不稳,将来能滑得快吗?

这种场景尤其是各种不专业的兴趣班,打的都是家长图快,马上能见效的心里。

快往往是一个巨大的坑。

慢就是快,其实这个道理很多人都懂,可一遇到事,就扎进去,跳不出来。

很多事不是杠着枪往前冲就能胜利的,看似勇敢,实则是莽汉。

尤其作为团队管理者,更应该勒缰绳,控制主想快的欲望,

让情绪平静下来,静心思考那些关键因素,专注解决重要紧急事。

1024,我们该做什么

还在一如既往的加班吗?

还在一如即往的求快吗?

我们要慢下来,

我们要静心思考,

我们要关注研发效能,

我们是一群追求高效,追求卓越的码匠。