0. 背景

作为一个非科班转码的开发岗实习生，由于在学校呆了太久，科研思维深度浸润入脑，很多时候并不能适应大厂的工作方式。好在有一位资深的同事跟我聊了一下，因此整理了一下我跟他的谈话内容，希望能掌握大厂的工作方式。

1. 文档优先的开发模式

在学校中，尤其是在做科研的时候，因为科研具有的极大不确定性，比如：

• 需求不确定，你只要能解决一个前人没解决过的问题就能发文章，很多时候会有一些“无心插柳柳成荫”的情况出现，因此需求的变动性很大；
• 代码是否能达成我们所需要的效果不确定，很多时候代码是达不到预期的目标的，需要经常迭代代码，更换各种处理环节的逻辑，甚至算法的主要逻辑。
• 团队成员少，很多需求需要自己去提出、自己去实现，没有其他同事去辅助，项目相关的上下文只保留在少数人的脑子里，“船小好调头，也总是掉头”，基本不依赖团队协作。

这些原因导致在学校中往往采用代码优先的开发模式，项目相关的文档很多时候是被忽视的一环。但在vibe coding 十分发达的今天，“Code is cheap，show me your prompt”。一份完善的项目文档，显然能帮助我们更好地理解项目的功能、实现原理等，也能更好地与团队成员合作。

因此在大厂中，文档优先的开发模式是非常重要的。我们需要在正式开发之前，先写好项目相关的文档，包括设计文档、接口文档、技术评审文档等，这些文档能够帮助我们更好地理解项目的需求和设计，也能更好地与团队成员合作。

2. 拉通对齐

常见的需要拉通对齐的场景有：

1. 需求不明确，需求方和开发方对需求的理解不一致；
2. 设计不合理，设计方和开发方对设计的理解不一致；
3. 调用其他模块的接口时，需要充分了解其他模块的功能，了解利用其他模块的功能解决，我们需求的时候存在哪些风险点，必要时需要与其他模块的开发人员沟通，确认是否有其他方案。

其实对于技术来说，技术评审会往往就是一个双向拉通对齐的过程，你依赖的其他模块的开发者会问你你开发的东西中关于他们的模块是怎么用的，而你也会问他们用他们的模块是否合适，是否存在风险点。

做项目其实也就是主要就关注需求和风险这两者，真正的技术细节和代码实现是次要的。

3. 开发前问自己的几个问题

以能获取 眼镜端各种能力 的 手机端sdk开发为例，在正式开发之前，我们需要问自己以下几个问题：

1. 你做的sdk是给谁用的，是公司内部人员，还是公司外的客户？他们对于你sdk的需求和潜在的需求是什么？
2. 手机端sdk能获取眼镜端的什么能力，能通过这些sdk实现什么功能？
3. 眼镜端的能力作为一个服务，需要通过什么形式暴露给手机端sdk？
4. 眼睛端服务需要提供哪些功能？在什么时候能被手机端拉起来，什么时候拉不起来去世了？如果拉不起来了，手机端sdk应该怎么处理，眼睛端服务如何能尽量复活？
5. 眼镜端和手机端是如何交互的，他们的通信链路是怎么样的？走的什么协议？用的什么接口？双方的进程状态如何？
6. sdk的接口如何设计？需要考虑哪些因素？比如接口的参数、返回值、错误码等？
7. 如果存在一些特殊的要求，比如低功耗、性能要求等？你要怎么处理？

4. 结语

对于自己一知半解的问题，切勿自行理解，一定要和对应的成员及时沟通，避免和其他成员的理解出现偏差。

需求开发流程：需求方 -> 设计方（包括ui设计等） -> 开发方 -> 测试方 -> 需求方