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

慢就是快

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

小码匠：看了15页资料。

我：你用了多长时间啊？

小码匠： 两个小时。

我又问：怎么这么慢啊？

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

image image

我：哦，那还有不会的吗？不理解的吗？

小码匠： 有啊，不多，我给你讲？

我：嗯，你讲吧。

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

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

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

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

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

场景一： 产品讲完需求，研发同学回去就开撸代码？

Stop！！！

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

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

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

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

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

• ...

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

[图片上传失败...(image-4fd259-1635139510842)]

我们该怎么做

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

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

技术方案

拿到需求直接开撸代码？

No，No。

我们要先写技术方案，技术方案包含：

• 功能梳理

• 新旧功能分开梳理

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

• 性能要求（并发数，响应时间有要求）

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

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

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

• …

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

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

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

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

好处：

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

• 漏测的case变少

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

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

• …

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

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

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

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

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

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

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

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

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

image

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

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

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

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

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

• 测试没准备好回归数据

• ...

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

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

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

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

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

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

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

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

• 但这些都揉到日常的环节，不是集中整理， 时间成本很小。 比如 ：如果迭代功能点多、涉及数据库变更点也多，最后花时间点去整理，能整理全吗？发生过很多次上线问题，都是因为最后慌里慌张整理，缺东少西的。 最后整理需要回忆，一是容易遗漏，二是从头梳理时间成本更高的。

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

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

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

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

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

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

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

我们心太急，太急

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

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

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

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

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

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

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

快往往是一个巨大的坑。

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

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

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

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

1024，我们该做什么

还在一如既往的加班吗？

还在一如即往的求快吗？

我们要慢下来，

我们要静心思考，

我们要关注研发效能，

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

image

关注公众号【小码匠和老码农】收获小码匠和老码农精心挑选的电子书

回复【算法】收获算法书电子书
回复【python】收获python基础电子书