用了三周的早读时间读完了《软件工程师》这本书，我想分享几个让我感受颇深的点：

一、用知识库进行学习

想要做一个合格的软件工程师就要持续学习，因为这一行的既有知识和新知识都太多了，我们永远都不可能学完，而且每个人都在持续学，如果你想在知识方面去超过别人，就需要在以下几个方面做足功夫：

第一，用好知识树。任何知识都应该系统地学。系统学习要求我们去总结并归纳知识树或知识图。将知识系统化，然后进行系统化的学习，因为一个知识面往往会由多个知识板块组成，一个板块又有各种各样细小的知识点，通过一个知识点会导出另外的知识点，各种知识点之间又会相互联系，但又各不相同，所以我们在平常进行学习的时候，就要系统地学习整个知识树。

第二，探索知识缘由。我们都听过这样一句话叫“存在即合理”，任何知识都是有缘由的，了解一个知识的来龙去脉，会让你对这个知识有非常好的掌握，而不再只是靠记忆去学习。靠记忆学习是非常糟糕的方式。当然并不是所有的知识我们都需要了解缘由，对于一些操作性的知识， 比如一些函数库，只要学会查文档就好了。能够知其然，知其所以然，才能把一个知识掌握牢固。

第三，掌握方法套路。学习不是为了去寻找一个个问题的答案，而是为了找到真正的方法。我们要清楚的知道学习的目的，学习的目的就是为了掌握更为高级的方法和解决办法。

在以后的学习中，我们也应该建立属于自己的知识库，用好知识库，掌握知识的缘由，掌握方法和套路，如此才能走得更长远。

二、一加一大于二

好的团队合作，关键在于打破壁垒、协同协作，让不同业务团队相互理解、紧密配合，从而产生 “1+1>2” 的化学反应。就像拼车团队与地图团队，虽业务不同却深度关联：拼车体验的优化依赖地图的路径规划，而地图的 “顺” 需要结合拼车的实际用户体验；面对订单取消等问题，也需双方共同探究根源，利用彼此的信息和资源解决上车点不合理等问题。只有团队间常沟通、互理解，清楚彼此工作的影响，才能避免各自为战、相互甩锅，实现共同提升，反之则可能 “1+1<2”。

因此，无论是现在处于学生时期的我们，还是以后走向社会的我们，团队合作都是一门必修课，非常重要。

三、 平衡需求：判断紧急与重要

作为技术负责人，跟业务对接需求时，最关键的是得分清啥事急、啥事真的重要，这种本事最能看出一个人的水平。业务那边提需求，往往觉得每一件都火急火燎、非做不可，恨不得让技术马上动手。但你要是全接了，团队就只能天天忙着应付，根本喘不过气。

所以得拎得清：有些事看着不着急，但特别重要，得慢慢打磨。比如搞一套好用的研发工具，或者建个全公司能用的数据体系，就像谷歌那套代码发布的流水线，这些东西能实实在在提高效率，让团队水平上一个台阶。今天不弄，过阵子可能就被别人落下一大截，到时候再补就晚了，必须持续推进。

至于业务说的那些急活儿，先别急着动手写代码。想想有没有别的招儿，比如能不能人工先处理一下？对方要是就想看个数据差异，整个Excel 报表可能就搞定了，犯不着让技术团队费劲开发。技术得用在关键地方，才能发挥最大作用。

说到底，就是在这些重要的事和紧急的事之间找到平衡，这活儿干得漂亮不漂亮，直接体现你这个管理者的段位。

我们在现阶段的学习中，判断紧急和重要同样重要。学习中分清紧急与重要很有必要。紧急的事（如即时作业、小测）需及时处理，避免手忙脚乱；重要的事（如打基础、建知识框架）虽不紧急，却决定长期学习效果。做好平衡，既能应对眼前任务，又能筑牢根基，让学习更高效、后劲更足。