实践出真知，聊技术人在业务中成长

写在最开始

写出来并不是说我做的很好，教大家怎么做。主要是想记录。
另一方面，这一年来确实在打怪升级，小小感悟，贻笑大方。
本文借鉴了来自阿里巴巴中间件的系列文章「技术人生」，也是激起我记录的主要灵感。

「技术人生」专题第1篇：什么是技术一号位？

「技术人生」专题第2篇：学会分析事物的本质？

「技术人生」专题第3篇：解决问题的规律总结

「技术人生」专题第4篇：技术组织业务的一般规律和应对策略

前言

常听见大家的一个抱怨：我们每天都在做业务，哪有时间搞技术？

做业务的时候，我们绝大多数人都是在不停处理业务需求，产品经理和运营也不会特意留出时间给研发思考技术，要的很急立马上线是我们的常态。但是缺乏技术考量的业务上线又往往带来额外负担，陷入恶性循环，需求越做越多，越做越急，效果越来越不好。

在有时间做技术的时候，我们又往往理想很丰满，现实很骨感。一心想把各种高大上的东西用起来，满足个人的技术成长欲望，消除自己在技术上积累缓慢的焦虑。自我安慰的效果达到了，业务价值却说不清也道不明。

业务发展和技术发展是对立的矛盾面么？我们是否能在业务落地的过程中实现技术进步？想聊一聊这一年中产品中的实践经验。

保持有技术一号位的心态

这个答案其实是拥有一种心态。我们姑且把他叫做技术一号位。意思就是我们不能认为自己只是一个写代码的，搞技术的。这个业务安排了我去做，那么我就是技术上的负责人，站在业务的整个角度去思考是我的责任。我写的这行代码，以后业务发展了有没有变更的可能性；我执行的这个需求到底产生了什么样的业务价值，哪个方案更适合。明确自己的角色和定位是技术序列的最终责任人。

当我还是一个写代码的小兵的时候，我并不觉得这些事情和我有任何关联，理所当然地觉得安排事情思考业务是领导的职责，我听指挥就好了。然而，后来发现，与期待相反，领导正好认为，我既然安排了你去做业务，思考周全做好业务是你的责任。所以不要去觉得级别高的或者带人的是技术一号位。做业务开发的技术同学，无论是什么层级，带不带人，只要你是这个业务的直接参与者，不用过多纠结是不是，可以本着“就当自己是”的心态把自己放在技术一号位的心态上来进行工作实践和思考。

在工作中尝试形成自己的方法论

确认了自己的角色以后，我们就要开始技术一号位的具体工作。比起写代码，我们多出来的这些责任到底我们应该怎么样去落地。要开始寻找或总结一些方法论，要自顶向下地对业务有一个清晰的认知，知道自己比过去多了哪些维度的事情要关心，知道接下来会面临什么样的挑战，要知道自己在挑战中应该扮演什么样的角色，采用什么样的手段去解决业务在不同阶段一定会出现的各种问题。

认识业务

• 认识流程。 要画图，弄清楚负责业务的具体流程，业务的上游和下游。如果没有这种全局意识。以这种方式做业务，那么就会发现业务过程会有各种没有做到位的事情，会在做业务的过程中“交很多学费”，甚至会因为自己的能力不够而拖慢业务发展。

• 理解业务价值。理解了业务的价值，写下的代码就有了意义。会带来比较明确的成就感和抗挫折的能力。尤其是带领一个技术小组的，leader对业务价值的理解能够极大的增加团队的协作能力。

• 业务当前的阶段。两个好处：1是可以提前知道每个业务阶段整体的对技术的要求是什么，能完成提前的布局。在技术架构上有很强主动性。在启动阶段即在满足“有无”的时候，不再是过去那种无脑地堆代码，而是结合下阶段业务发展周期对架构的要求，对长期架构设计进行最短路径地落地：即我设计好完整的架构以后，启动期需要哪些能力，我就只按照架构设计落地哪些功能，其他没有业务需求用到的部分，一律只保留代码框架不做具体的逻辑实现即可。2:可以做业务和技术间的平衡。业务通常按照能用-易用-产品化-商业化-商品化的路线演进，如果是业务开始的阶段，有没有，能不能用这些更重要。技术上可以妥协一些。如果业务已经有很多用户了，那么业务的场景就必须考虑，技术上必须付出的代价是逃不掉的。

技术意识

• 有意识地做设计。业务构成不是以代码写完，能通过测试case为终点。要有意识地做体系化的思考。以后端举例，从数据库设计开始，er图，数据流转。到接口文档定义。到日志定位，监控和追踪。一旦出了bug如何快速定位快速解决。技术选型，难点风险点都需要考虑。业务研发过程涉及到的技术从单一维度向多维度演变；从简单的“把业务跑起来”，逐步形成全方位支撑业务发展的技术解决方案。技术本身也从满足“有无问题”的粗犷模式，逐步演进到解决“降本提效问题”的精细模式，这是一个由主到次的过程，也是生产力提升的一个过程。这就是业务研发过程中的一般规律。

• 有意识地思考稳定性和风险。不要把懊悔、决心、对稳定性的思考和执行力体现在事故复盘会上。在上线之前就该有各种意识，要有意识地训练自己思考一些风险，比如是否需要缓存，数据读写特征是否需要异构。比如高并发环境下表现。是否创建了无用的对象。还比如一些中间件使用，消息队列会不会丢失消息或者重复消费。还要思考回滚方案，是否有风险点和避险方案 。受制于经验，我不认为有人能一开始就做得很好。但这是一个建立和完善自己脑中技术模型的一个好的机会。

团队是必选项，不是可选项

在我自己从写代码的小兵开始慢慢打怪升级到带几个同学的时候，也慢慢接触到团队这个概念。才开始的去适应这个角色的时候，一度表现的非常挣扎，因为每天要处理的事情非常多，对自己扮演的角色没有一个清晰的认知，出现该做的事情没有做。不该做的事情投入了过多的精力，陷在代码中。尤其是在和团队成员协作上表现出了比较大的短板，间接导致了一位伙伴的离职。当时一个激烈争论的主题是休息时间如何运维线上bug，尤其是凌晨和周末。如果不是我开发的bug是不是需要我处理。看起来是非常小的事情，但是亲身经历后也慢慢悟到，团队建设就是从小事一件一件堆叠起来的。

成熟的研发团队可以通过完备的研发过程管理，来避免个人能力不够而对业务产生太多负面影响，但是本质上强制的规定和“上级要求”只是在依靠行政管理手段在强制一个人做这些事情，并没有唤醒他的创造力和责任心，反而会被认为是“工作琐事”。长时间做这样的“琐事”，会让伙伴对那些看起来 “和写代码无关但是必须做的事情” 非常抵触。这种抵触情绪发生的时候，leader 再强调 Ownership 也都没有太多效果，因为不是他不负责任，而是他没有意识到，这是他应该负责的事情。所以和伙伴解释这些琐事的价值，把上下文尽可能多的传递给大家，并且给大家足够的选择权利。成了我主要的探索方向。

无限进步

总结来说，想在做业务的过程中有突破。第一件事情就是要建立一个技术是可以在做业务中进步的认知，并且在实践过程中完善自己的方法论。第二件事是注重认知的升级。不管从事哪个行业，我们一生可以持之以恒一直做下去的东西就是不断改进自己。

实践和认知的关系有很多伟大的著作，我是虔诚的学徒。摘抄了一段毛选中的实践论。

任何的认识来自于实践，人在实践过程中，开始只是看到过程中各个事物的现象，
看到各个事物的片面和事物间的外在联系。这些事物引起了我们的感觉，在我们脑子里产生了一些印象。
但是感觉到的东西，我们还不能立刻理解他。处于认识的感性阶段，就是感觉和印象的阶段。
在实践过程中，使人们在实践中引起感觉和印象的东西反复了多次，在脑子里就会引起认识的突变
，产生了飞跃，这个时候感觉就变成了概念。
此时，认识经过感觉到了思维层面，关注事物的内部规律性和本质。
认识的深化，让我们懂得客观世界的规律性，因此能够解释世界。

最后，以我最喜欢的四个字结尾。
无限进步。