在帆软的成长总结（心路历程）：专业篇

之前分享过一篇关于技能进阶的文章： 练级攻略，从新手到专家的历程，德雷福斯5级模型

这篇文章，总结一下我在专业技能进阶过程中突破瓶颈的经历。也会尽量对应到德雷福斯模型中去。

以下内容可分为两类，一类是某一小段进阶的过程，一类是某个特殊时间点的感悟（“顿悟时刻”）。会在标题中区分。

大致按照时间顺序。

1 BitBucket 插件开发

收获：很多问题是 Google 和 StackOverflow 没法解决的，要有这个心理准备。

BitBucket 插件开发经历，在“职业篇”中已经提及了，此处从略。这次经历带给我的，也是一个巨大的观念冲击。

以前写程序，本质上都是在模仿他人。课本上的、文章里的，跟着学，跟着做，实现个 demo。过程中遇到的绝大多数问题，都能从百度、谷歌、StackOverflow 轻松找到解答。

但是这次插件开发，我感受到了深深的挫败感。只有官网的文档可以参考，google 上的资料很少，公司里没有人可以问。感觉自己到了一座孤岛，需要用自己不熟悉的技术，解决从未遇到过的问题。这就是真实世界的软件开发。

后来分到报表组，给我的 bug 和新功能，对我而言也都是未知的。一个任务过来，我不知道自己能不能搞定，但是它就是我的活。曾经感到压力特别大。但是在报表组里有前辈带着，可以问问题，跟之前 Bitbucket 插件开发经历相比不算什么。我得以平稳地度过新手期。

【所处阶段：初级新手】

2 出差：成都某客户

收获：挖掘客户的真实需求，不要只听他说什么。

完整总结看这里：http://baimoz.me/1125/

这是刚进报表组不久，第一次出差。

产品这边预先跟客户了解了问题，觉得比较简单，就让我去出差。我做足了准备，在本地把 demo 跑通，确保可以解决客户问题了，才出发的。

结果到了客户那边，3天时间，变更了3次需求。因为没有预先做准备，前两次变更勉强能应付，最后一次实在受不了了，跟产品沟通说不做了，和客户那边也有点不愉快。（后来是成老师远程了解情况后，解决的）

后来总结经验，是因为一开始没有理解客户的真正需求，客户描述的，不是他真正想要的。这时，不应该吐槽客户。作为一个专业人员，应该站在客户的角度去了解他的真实诉求，然后用自己的专业知识，给出一套合理的解决方案。而不是客户说他要什么，就给他什么。（想一想，我们去理发、看病，或随便做什么消费的时候，其实是非常希望得到我们自己表达不准确，却又真正需要的专业服务的）

这一条经验的应用范围其实很广泛。可以把“客户”替换成你的领导、同事、女朋友，或任何与你打交道的人。从对方的角度出发，能帮助你更好地理解他人，更好地提供服务。

3 9.0 设计器改版

收获：发现严重问题要立即想办法处理，不要眼看着悲剧发生。

与产品、交互、视觉设计、研发同事，沟通合作，其实没那么难。

用 todo 页面让团队进度可视化。

大学时上《组织行为学》课的老师，教了我们沟通六字真言：及时（下对上）、主动（平级之间）、鼓励（上对下），在这次经历中，我正好用上了前两条。

3.1 与产品的沟通

当时是分配给 MoMeak 的任务，预计两周时间，让我去帮忙。

我了解了一下情况，吓得半死。要改的地方太多了，两周内根本不可能完成！我问了 MoMeak，他说之前做了一周，没推进 10%，也觉得不可能完成，但是上面分配了任务，只管做呗，到时候完不成再说。

这个情况，就跟我当时开发 Bitbucket 插件一样，面临着无法克服的困难。我知道一定要主动反馈，不然后果不堪设想。花了一到两天的时间，对任务做了拆分，然后预估了每个子任务的开发时间，形成一篇文档。最后得出了 51 个“人日”的工作量。会议上，我拿出这篇文档，陈述了工作量严重超预期，必然无法按时完成的事实。产品意识到问题后，加派了人手，并且砍掉了一部分不重要的子任务。使得此任务得以合理推进。与此同时，9.0 设计器改版任务的主负责人变成了我。

3.2 与交互的沟通

作为研发，以前只是单纯地“吃掉”交互做的设计。这次设计器改版，涉及的内容实在太多，交互设计没法一步到位。而且有的交互设计很难实现。于是在开发过程中，与交互一直保持沟通，甚至经常我出现让交互变更设计的情况。同理，视觉设计，也是有折衷的。

作为研发，只要有理有据，可以要求砍功能，改设计。这是一个非常有用的观念突破。以前，一个任务来了，很容易因为难以完成而焦虑；此后，一个任务来了，我会想：

• 交互、视觉是否可以稍微调整一下，让开发和维护变得更容易？
• 某些可有可无的功能，是否能够砍掉，用另一种成本更低的方式去做？
• 这个效果短时间实现不了，能否单独拿出来，放到以后实现？

然后我会跟产品、设计去讨论，结果往往都是好的。

为什么可以这样？因为大家都是为了在合理的时间内开发出性价比最高的产品。

3.3 第一次体验“带团队”

不是真正的带团队。只不过，在这个开发任务中，由我负责分配、统筹、推进开发进度，并向产品汇报进度。

每隔一两天，产品都会来问我，做到什么程度了。我就会去问对应的研发，然后汇总进度。但是天天这样搞，实在太费时间了。

于是我在 kms 中建了一个统计团队进度的页面，将所有子任务都写成一个 todo 项。每个人完成了对应任务之后，就在 todo 页面打勾。产品只要定期查看这个页面，就能了解到整体进度。可以吹个牛逼，“团队进度可视化”这个 idea，在报表组里，是我第一个提出的。（后来成老师做的酷炫的大屏，也是“团队进度可视化”的一种方式，比我的 todo 页面高大上许多）

4 【顿悟时刻】里程碑：总能改掉 bug

积累了一些迭代任务和数百个bug修复经验后，突然有一种明显的感觉：只要给我足够时间（一般3天内），总能改掉bug。

这在之后的经历中也得到验证，95% 以上的 bug，都属此类。剩下极少数 bug，都是因为它们涉及的相关知识，远超我当时的能力，只能求助成老师。

【所处阶段：“高级新手”与“胜任者”之间的过度期】

5 时间管理：遭遇成堆客户bug

收获：客户bug也有轻重缓急，合理安排时间。

客户bug是优先级最高的，一般的处理周期是3天。我当时手里至少有四五个客户bug，都不是能轻易搞定的。这时，有个技术支持提了一个客户 bug 过来，并催我尽快改。我说：“手里客户bug太多了，改不过来，得排队！”然后这个客户bug成老师帮忙改掉了。

后来小组开会，成老师说：“客户bug也是有优先级的，有的bug严重，有的bug不严重；有的客户紧急，有的客户不急；有的客户重要，有的客户相对而言不重要。”然后给我们分享了一些时间管理的经验。

此后，当我再次遇到需要同时处理的大量任务的时候，就会给它们打个优先级，实在无法安排时间又必须解决的，会跟组长协调，不至于手忙脚乱。

6 大佬提问：本地打印为什么用 socket.io

收获：思考为什么，促使我从“执行者”观念（“职业篇”中也提到了）中解脱出来。

刚开始研究本地打印功能，成老师给我指了一个方向，去研究 socket.io。然后就去做了，并实现了基本功能。

有一天下班，跟 richie 一起走。他似乎对本地打印很感兴趣，问了我好多问题。他问我：“本地打印为什么要用 socket.io？用 http 不是挺好的吗？”

我一脸懵逼，回答说：“成老师跟我说要用 socket.io 的，我就去实现了。没想太多。”

Richie 说：“这样不太好，你用一样技术，得知道你为什么用它，要用它解决什么样的问题。不然意义不大的。”

一语惊醒梦中人。从此以后，我做每一个任务，选择每一项技术，都要想“为什么”，它能引导我思考得更深入。

• 这个bug为什么要这样改？
• 这段代码为什么要这样写？
• 为什么要使用这个设计模式？
• 为什么要这样设计接口？

这样一来，每次 pr 审核不让过的时候，我都可以据理力争。

（后来我也问了成老师，为什么使用 socket.io。答案是，我们需要实现打印结束后事件，打印软件打印结束后，需要主动向浏览器推送消息，这正是 socket.io 的应用场景）

7 代码质量被怼，怒看 《effective java》

收获：“代码感”提升很多，代码质量自然提升。

新增一种适合自己的学习方法：慢慢啃书，做笔记。

当时，提交 pr 是看运气的。运气好，基本都能过；运气不好，一个 pr 要改好多遍才能过。

成老师跟我提过，我的代码质量不太好。我觉得这段代码没毛病，却被指出一堆问题，而且往往是我从来不知道的规范。虽然多被卡几次，改出经验了，就好了。但是时不时被卡一次，总是不爽。

然后我找来《effective java》，刚开始，浏览了一两遍，自以为都懂。过两天全忘光了。

后来一条一条地看，并做摘抄笔记。速度很慢。从刚开始看到现在，至少有一年了，才看 2/3 左右。但是，代码质量却有了质的飞跃。

8 新打印开发方式

收获：处理复杂任务的能力大幅提高。

新打印的功能非常多，而且琐碎。按照以前的开发方式，产品创建一个迭代任务，流转到研发这里，研发要把所有功能都开发完毕，然后再转到测试验收。一开始，新打印是这么做的，然后测试测出来几十个 bug，反复修改验收，导致开发周期很长。

后来，打印二期、三期的时候，我把涉及的所有功能点都提取出来，分解为一个个相对独立的子任务，每个子任务都能在 3 天左右开发完成并转测。开发评审的时候，如果发现某些子任务风险很大或成本很高，可以从本次开发计划中取消。如果有子任务来不及开发，也可以暂停，不影响已经开发好的功能正常发布。

因为把复杂的大任务拆分为独立而简单的子任务（其实是“分治思想”的体现），在新打印的后续开发中，没有出现严重的延期问题，整个项目的可控性大大增强。

9 组内学习交流

收获：文章质量上升，学了一些感兴趣的东西。

集中总结一下在小组学习（不是后来的报表大组学习）中的收获。

写高质量的文章

每一次小组分享，都必须认真准备。准备的产物就是一篇文章。

我分享过的文章：

xx

• socket.io 使用简介
• 用 CSS3 画加载动画
• 初探 Vue.js：MVVM 与组件化开发

我以前经常写技术博客，内容常常是：

• 某个 api 的用法
• 某个环境的搭建
• 某个工具的使用
• 某个语言细节的理解
• ……

但是在小组分享中，这些都是不行的。为啥？太细，太浅。技术分享，必须有内容，有深度，不然你 1 个小时时间都说啥？

看下成老师写的文章就知道了：https://www.cnblogs.com/xdecode/

从此以后，我写的文章变少了，但是质量却更好了。以前会去写的很多东西，现在觉得意义不大，拿不出手。

正确评估 Python 水平

“人生苦短，我用 Python”。我是因为这句话喜欢 Python 的。以前也用 Python 做了一些东西。

本来是很想找 Python 岗的。到帆软之后，用上 Python 的机会很少，大多数时候，还是用我不那么喜欢的 Java。一直感觉能力没发挥出来。

有次我在团队中分享 Python 脚本入门，成老师问了一串问题，如“Python 内部的垃圾回收机制是怎样的？跟 Java 有什么区别？有编译的过程吗？Python 程序如何防止被别人破解？”

这些问题，我从来没想过！突然意识到，我对于 Python 的理解，还是停留在最基础的语法和 api 调用上。还差得远。居然变得淡定了许多。

MVVM，最新的前端思想

总感觉落伍了。然后我去学了 Vue 的基础知识，然后在小组内分享。顺便感受一波前端技术浪潮的冲击。

最终也没地方用 Vue。但是见识过了，知道 Vue 是什么了，似乎也就满足了。这段经历，至少能让我不惧怕前端技术。

10 业余：微信小程序项目

收获：增长见识，有一个个人项目。

本着增长见识和磨练技术的想法，业余时间，跟以前学校的几个小伙伴组队，做了一个小程序项目。

看看队友阵容：

• 产品经理A：东南大学机器学习相关专业的研究生，本科时的项目得到过风投，负责把控进度和谈客户；
• 产品经理B：腾讯某部门产品经理；
• 设计：不太熟，好像是本校艺术系的；
• 后端开发：网易互娱研发；
• 小程序前端A：阿里某部门研发；
• 小程序前端B：唯品会前端研发；
• 小程序前端C：就是我啦。

细节略过。

以下是收获：

• 增强信心。我的开发能力并不比队友们弱。帆软的开发流程，似乎比某些大公司更加规范。
• 发现前端的套路。小程序也是一个 MVVM 框架，有了之前 Vue 的学习经验，上手起来非常容易。我也自己撸了一个玩具小程序：伊索寓言。
• 专业目标更明确。虽然是一个中小型项目，但是也太费精力了。工作之余，我只想多花点时间学习和休息，而不是浪费精力编写业务代码。所以这个项目结束后，我再也没参加类似的小组。

11 【顿悟时刻】里程碑：总能完成迭代功能

在完成足够多的迭代任务后，突然有一天感觉到，任何迭代任务，只要时间足够，我都可以完成。业务代码的瓶颈已经突破了。

【所处阶段：胜任者，初级阶段】

12 设计模式的学习

收获：我写的不是代码，是设计。

也是小组内的“设计模式”专题学习。我认真啃了 《HeadFirst 设计模式》，连续看了200页之后，似乎真的体会到了设计模式的真谛。

小组内讨论的时候，其实大家都似懂非懂，因为大部分同学都是在网上找的文章学习的。相对而言，我理解得更加透彻，于是发言比较积极。别人讨论的，我基本都知道，能很快理解；他们观点中的漏洞，我能感知出来，并及时补充。这段时间，我参与小组学习的积极性非常高。

从 《HeadFirst 设计模式》里，我还学会了 UML 的使用，并应用到工作中。学习设计模式后，我能识别出报表代码中用到的模式（很多是我以前看不懂的代码，比如观察者模式）。在实际开发中，我会用模式写出更有弹性的代码。我用过的模式：

• 工厂方法模式；
• 抽象工厂模式；
• 迭代器模式；
• 策略模式；
• 单例模式；
• 观察者模式。

还有一些收获：

• 提高思维层次（关注设计，而不是具体的代码）
• 越来越喜欢 Java
• 体会到认真的快乐

13 高内聚与低耦合

收获：豁然贯通，有一种打通任督二脉的感觉

紧接着，有一次报表研发大组的学习交流，主题是“耦合与内聚”。http://baimoz.me/1612/

在学习过程中，我很快理解了“耦合”与“内聚”的概念，并且概念非常清晰。得益于之前设计模式的学习，我写的文章得到最多赞。

交流讨论的时候，爆发了好多个争论点。但是在我看来，都是不必要的，因为结论显而易见。这次的学习，本质上与设计模式的学习没有区别。

我的理解：

我们使用各种“设计模式”，让我们的代码尽量符合通用的“设计原则”，最终目的就是得到一个“低耦合高内聚”的系统。因为这样的系统，易维护，易扩展，不容易出错。

此后，又有多次讨论内聚与耦合，都没有超出我的理解之外。难者不会，会者不难。这就是一种突破吧，别人反复争论，甚至迷惑不解的概念，对我而言，却是显而易见、确凿无疑的东西。

【所处阶段：胜任者，中级阶段】

14 【顿悟时刻】找到技术学习的方向

曾经以为，编程，就是学习各种 api，然后把它们组合起来，完成特定的业务功能。那么多技术理论，其实是毫无意义的，我也没必要去学。这就是所谓的“api程序员”。

后来逐渐发觉到技术上的晋升阶梯。

一个功能我实现了，

• 是否实现得足够好？
• 是否实现得足够快？
• 是否满足性能要求？
• 并发量支撑是多少？
• 是否足够稳定？怎样保证 bug 数量不超标？
• 怎样保证扩展性？
• 怎样最大程度降低维护成本？

我发现，这些才是评价一个程序员价值的标尺，而不是看他曾经实现过多少业务功能。然后我的学习路线就明确了——纵向深入，而非横向蔓延。解决了我学的技术一直杂而不精的毛病。

15 下班路上与 Abel 的聊天

收获：实践“阅读源码”的方法，并从中收获

Abel 提起，他经常阅读各种框架的源码，如 dubbo、netty，从中学到了不少东西。我深受震动。

“阅读源码”这个方法，早就在很多地方见过，一直觉得离我太远，但是这一次看到身边的人在实践，还收获颇丰。于是我开始重视这个方法。

后来，尝试看了 JUnit 源码，译出《JUnit3.8.x 框架设计》一文，并在组内分享，获得一致好评。开阔眼界，技术信心也有了大幅提高。

16 单元测试的学习

收获：测试驱动开发，新功能做起来很稳，发现 bug 可以快速定位

去年开始，团队要求写单元测试。积累了一些经验，包括 EasyMock 和 PowerMock 的使用。一般都是功能开发完后，另提一个任务去补单元测试。代码耦合较强，写得很痛苦，好多方法没法写单元测试，就忽略了。

后来想读一本单元测试相关的书，看看别人是怎么写单元测试的。找到了 《单元测试之道Java版：使用JUnit》（比较惊喜的是，这本书的作者是 Andy Hunt 和 Dave Thomas，写《程序员修炼之道》的那两位）。

细读之后，主要收获是：

• 明确单元测试的目的：证明代码的行为和我们的期望一致。通过对所有单独部分的行为建立起信心，确信它们都和我们期望的一致；然后，我们就可以开始组装和测试整个系统。这样一来，可以把很多小模块本身的 bug 消除在萌芽期，而不是等到系统测试的时候才发现。
• 左冲右突改 bug 的能力不算什么，真正牛逼的是，从一开始就编写清晰、健壮的代码，bug 很少，一旦出现 bug，可以很快定位和修复；
• 分清主次，有的方法需要详尽的单元测试，有的方法可以略写甚至不写；
• 保持独立性。每个单元测试都是独立的，不要相互依赖；
• 像对待产品代码一样，认真对待和维护测试代码。

对测试驱动开发的理解

我好像突然就学会 TDD 了（皮毛），虽然没有看过任何一本 TDD 的书。我理解的，测试驱动开发的核心思想是：先明确我要开发的模块需要支持哪些功能，在各种输入的情况下，应该产生哪些输出；然后编写单元测试，把这个假设固化下来；最后编写功能代码，让它通过单元测试，也就说明实现了预期功能。

tip1

一开始可能无法完全想清楚要实现的功能，只想到一部分，那就先针对这一部分运用 TDD。然后再一次次迭代，直到实现所有功能。

tip2

有时候对要实现的业务系统很陌生，在实现的过程中，随着对业务的深入理解，需要反复变更接口。这时，可以先写功能代码，但只写接口，不写具体实现（就先假设已经写了实现），然后反复调整接口设计，直到稳定下来，再应用 TDD。

17 重构的学习

收获：稳步提升代码质量，历史代码也能重构

主要是看了一本书《重构-改善既有代码的设计》（只看了前半部分）。

收获如下：

• 以前觉得“重构”是一个特别高大上的名词，没想到自己学了之后也能用起来；
• 掌握了一些基本的重构技巧（例如“抽取方法”、“消除重复代码”、“修改名称”、“提取类”等等），可以在保证（一方面足够小心，一方面只运用最简单的重构手法）不引入 bug 的情况下，提升代码质量；
• 曾经以为只要代码没有 bug，就不要改它；修复 bug 的时候，改动要尽量小，不要影响到原来的代码。看书之后，视野开阔了许多。可能某个类，只要改动一行就能修复 bug 了，但是我会去理解整个类，观察它的设计，一旦发现有改进的余地，就会做一些重构。不管这个类原本是不是我写的；
• 用重构帮助理解代码，并把对代码的理解固化下来。这样在定位 bug 的过程中，也可以改善项目里的代码质量；
• 方法论：开发与重构的帽子。在实际开发中，有两顶帽子，一顶是“开发的帽子”，一顶是“重构的帽子”。我们戴上开发的帽子，去实现业务功能，写着写着，感觉这个小模块的功能实现了，但是代码质量不好，然后就戴上重构的帽子，专心做重构，等重构做得差不多了，又切换回开发的帽子，专心开发。如此循环往复；
• 重构的时机。以前的想法是，专门提任务做重构。但是常常没办法安排时间。这本书告诉我，最好的时机是，改 bug 和开发新功能的时候，不必单独找时间。每次改善一点点，日积月累，就能得到一个设计精良的系统；
• 重构、单元测试、设计模式，三者有着紧密的联系。

践行一段时间后，我发现日常开发已经离不开重构了。

9.0 上报大用户量优化

对上报这边的代码进行了大幅重构。每次都是小步前进，引入的 bug 很少。

模版信息收集

做迭代的时候，看到以前写的代码很烂，于是花了一天时间重构，同时补单元测试。维护的时候舒服多了。

18【顿悟时刻】“大前端”思维

“前端”不局限于网页技术。凡是直接与用户打交道的层面（UI），都可以叫做前端。

所以设计器是前端，App 是前端，小程序是前端，聊天机器人也是前端……它们都会通过某种方式，与后台交换数据。

19 内存数据源开发

收获：难得的技术提升机会

以前都是写业务代码居多（舒适区），开发内存数据源，则是纯粹的技术活。

第一道坎：汇总求和

刚接到这个任务的时候，非常难受。要实现一个内存数据库？完全无从下手。所以心里害怕，耗时也很长。想了几天，把汇总的算法想通了，然后攻克了第一个难关。

第二道坎：功能定义

花了很多时间去手动写编译后的模版，牵扯到的陌生类越来越多，理解很困难，而且很容易出 bug。越做越不知道，我要做的是什么，做到什么程度才算完成。

后来理清思路，我要实现的是内存数据源，只要实现基本的类 SQL 查询功能就行了。不需要去管模版是怎么编译的，这些问题上层都会处理好，然后调我的查询接口。我需要做的，是定义这个接口，然后实现它。

之后我就去写了一个单元测试，用例覆盖了常用的 SQL 查询语句，并询问了 loy 的意见。单元测试明确之后，剩下的任务，就是编写代码，把单元测试跑通。

就这样，基本功能都实现了。这是 TDD 的一大好处。

第三道坎：加索引

我在这里卡了很久。本来想绕过去的，但是没办法交差，只好硬着头皮上。参考了原来的索引实现，pr 也反复被卡。最后弄出了二分索引和哈希索引，确实起到了明显的优化效果。pr 被卡时，在与大佬的反复交流中，学到一些精妙细微的东西，代码质量又有一丝提升。

【所处阶段：胜任者，高级阶段】

20 业余：感受算法的威力

收获：框架、api、平台、语言，都是次要的，较短的时间内可以上手。算法能力才是核心。

其实一直都知道算法能力的重要性，但是一直都怕算法，也觉得平时用不上算法。业务代码写多了之后，会发现，瓶颈往往都在算法上，一个功能，如果有较为清楚的算法思路，实现起来就很容易，反之，就会卡很久。

所以会抽一些业余时间，看算法课程，刷算法题。做算法题的时候，还会想办法去优化，调优的过程，跟平时解决性能 bug 的过程非常相似。坚持一段时间之后，发现写程序更加得心应手了。一个功能上来，首先想一下核心算法思路，然后就能信心满满地去开发了。

对具体技术的执念，进一步减小（暂时对 Spring 的兴趣减弱了）。因为我觉得，工具学起来都是相对容易的，算法能力的提升则是相对困难的。为了验证这个想法，前段时间写了一个连连看脚本。

我已经至少半年没写过像样的 Python 程序了，连好多内置 api 都记不清楚了。但是想清楚核心算法后，我就用了一天时间，撸出了这个脚本。在这个过程中，还学会了两个新模块的使用，代码质量也比以前写的脚本要好。

21 造轮子的意识

收获：尽量多用轮子、多造轮子

突然的一个想法：我们一直在开发各种各样的功能，有的人善于造轮子、用轮子，开发速度越来越快；有的人不善于造轮子，每次需求过来，都是从头开发。一个码农的生产力有多强，大致可以看他积累了多少可复用的轮子。

那天我整个人都不好了，因为工作两三年，似乎没积累什么可复用的轮子。岂不是浪费了宝贵的开发经验？

到知乎提了问题：https://www.zhihu.com/question/325566772

然后我就憋出了几个开源库。

现在回顾一下我收集的“轮子”：

• 【可复用项目】企业微信提bug机器人
• 【可复用项目】HttpTest
• 【可复用项目】FileNativePrint
• 【代码库】JsWatermark
• 【代码库】JavaWatermark
• 【文章】水印积累的浏览器兼容经验
• 【文章】画加载动画
• 【文章】jsonp 跨域
• 【文章】tomcat 配置 https（自签名证书）
• 开发功能的套路：研发评审、TDD、重构等
• 写文档的套路：有没有发现，我最近写的文档都是一个模式？
• ……

思考1

如果有一天，你终将离开团队，你能从这段经历中带走些什么？技术上的，非技术上的。

思考2

有没有发现，FineReport、FineBI、简到云，都是轮子。它们功能足够强大，封装得足够好，所以能卖给客户赚钱。所有的产品，都是轮子，能帮助用户解决某种问题（否则，用户为了解决问题，就得花大力气自己去造轮子）。

电脑、手机、微信、淘宝，都是轮子。

思考3

我们读书，学方法论，学新技术，了解各种类库，买各种产品，为了什么？

为了用别人的轮子，来解决自己的问题。

所以持续学习，保持开放的心态，很重要。

思考4

我们在开发的时候，就应该有轮子意识，时刻想着代码复用。开发之前，先找找有没有现成的轮子可以用；找不到的话，自己开发某个模块的时候，也要想着尽量把它做成通用的轮子，让它不仅能在这里跑，还能在任何需要它的地方跑。

这种自己造的轮子，会体现为工具方法、工具类、类库、框架。看阿里开源的框架，谷歌、FaceBook 开源的框架，其实都是他们内部用的轮子。只不过做得足够通用了，就开放给别人用。他们并没有专门去开发开源项目。

思考5

轮子意识的其他用途。

例 1

我在看到一篇关于 Java 容器框架的文章，觉得很不错。是英文的，看起来有点慢。然后我就想，慢慢看没问题，能不能在看完之后，有所产出（造个轮子出来）？

然后就开始翻译。等翻译完，也就仔细看完一遍了。它还能变成我的一篇精品文章。

例 2

最近在看一些有关唐诗的故事。诗人写诗，主要目的是抒发自己的感情，为了自己爽。牛逼的是，他们在抒发感情的同时，把它写下来了。于是，诗人的一个个人生片段、一个个感悟时刻，都变成诗，流传千古。我们读诗的时候，也能稍微感受到诗人当时的情景，甚至有某些喜欢的诗句，能用来抒发自己的感情。

这些诗歌，也都是轮子。