软件工程师具体的工作内容是什么？

故事背景

之前在一家小公司待过一年多，在里面做了什么呢？

1. 去过现场采集客户需求，也就是跟客户沟通交流，主要还是做好记录，形成文档。
2. 每次开会讨论需求（需求审核），不仅要理解同事们讨论的内容，还需要积极的记录会议纪要。有一次周末，两个领导和我在办公室讨论，一个会议纪要，他要求我修改了4次才算合格，现在想想估计领导想培养一下我。
3. 还要整理需求文档。整理项目有哪些功能点，功能需求是什么，功能如何才能嵌入到已有的系统中去。
4. 还要画实体图，利用实体图标注数据流向，其实就是一个利用实体来说明项目流程。
5. 还要写用例规约。模范用户和后台服务这样的，比如用户在浏览器页面做一个操作，后台响应一个操作，如此往复地写用例规约。并且每个字段都需要把业务规则写的明明白白清清楚楚的。
6. 为了理解得更好，我也会偷偷地画UML图，完全按照自己主观去做，没有什么规定，自己觉得需要画画才能理解得更好，就画出来。
7. 编写代码。完成功能模块。
8. 做测试。使用jmeter测试，修改一些sql,调整一些参数配置。
9. 修改bug。
10. 跑现场。看用户使用。

---

现在在一家创业公司，在里面又干些什么呢？

1. 公司分布在各个城市，沟通全程使用语音。这个就增加了很大难度。
2. 创业公司，做事是没有那么多条条框框的，不会写什么需求文档，概要设计，详细设计之类的，策略就是，小步快跑，快速迭代，反正都是工程师敲代码。一个需求，先弄出来，客户看看，不合适再修改。也不知道对还是不对，反正就是很反感。
3. 询问需求。使用语音跟产品负责人沟通，问问这个功能要这么做吗？换个方式怎么样。
4. 讨论需求。主要是和同事们一起讨论，主要是自己不懂，然后主动问问同事们，毕竟他们工作经验丰富，聪明。
5. 讨论实现方案。还是和同事们讨论，说某个功能，这样做可以吗？询问一个比较好的实现方式，不然最后还是得修改回来。或者说需要反复修改。时间和精力都是资源，浪费了就没有了。
6. 编写代码。
7. 修改bug。
8. 写文档。会写一些基础的文档。不过大都时候都是自己记录一些项目的重要事件。比如梳理核心逻辑，记录重要的时间节点。
9. 上线，后期维护。

---

软件工程师具体的工作内容是什么呢？

1. 熟悉公司技术栈。一个公司应该有自己固定的技术栈。这套技术栈会应对公司具体的业务需求。当然，创业公司的技术资源是比较少的，需要招聘人员从上一家公司带来一些。
2. 询问需求。需求先跟产品沟通讨论需求，了解客户有哪些需求信息。
3. 整理需求。以文档的方式把跟产品沟通后的需求，按照功能模块逐一进行梳理整理，需要写得尽可能详细。
4. 讨论需求。就是需求评审，确认哪些需求是合理的，哪些需求是不合理的。进行有意义的需求评审，这个特别重要。
5. 确认需求。再次跟产品确认需求，一方面是确认就是要做文档中呈现的需求，另一个方面也是检验开发者是否对需求理解到位了。如果发现开发者跟产品理解不一致，是需要作出修改。这个时候产品也需要跟客户再次沟通，确认需求是否是客户真实需要的。
6. 整理文档。把项目的时间周期呈现在文档中。把项目中所有需要的功能模块，都需要用文档进行详细说明。
7. 设计表结构。根据产品画的原型，抽象成软件设计的概念，现在大都是抽象面向对象概念。
8. 画实体流程图。用实体流程图来说明项目的核心流程和数据流程。因为一个系统其实就是实体来描述的，而实体数据的流动其实就是核心流程逻辑了。
9. 画必要的UML图。加强实体间相互关系理解，这样可以搭建一个好的类关系组织图。这里没有好或者不好，只是如果把这些需求当成工程技术那样严谨的思考，这些步骤还是可以做的。根据自己需要，灵活应对，如果自己理解力够好，经验够了，这些步骤可以直接在脑子里做。如果理解力不够好，还是该画就画。
10. 画项目核心功能逻辑图。把项目中比较复杂的和非常重要的功能逻辑，画成图，目的：辅助自己理解。
11. 用汉语把功能写出来。其实写代码就是写故事，用汉语可以先把故事写一写，然后用编程语言把故事在描述一次。做两次是非常好的，第一次会考虑到一些细节，因为当接触一个新的功能逻辑，其实是陌生的。用熟悉的汉语写成一个故事，是可以辅助理解的。其实，橡皮鸭的调试法就是这样的。用自己的话，用自己的理解把整个过程说出来。
12. 编码。把前面的工作都踏实做好了，编码就是一件非常简单的事情。
13. 单元测试。需要注意一下，哪些是必须测试的，哪些内容根本无需测试。
14. bug修复。
15. 上线。
16. 总结。一个项目做完后，把重要的bug，进行整理和学习。把做得不好地方进行梳理，下次需要改善。
17. 学习新技术。这个也是工作的一部分，而且特别重要。

---

大厂的软件工程师都做些什么呢？(20210516)

1. 横向开发模式。项目被拆分很多个技术团队付出 。即使在一个技术团队中，都是只负责自己那点儿内容，保证自己负责的内容不出问题即可。
2. 大厂确实是需要高级和专家级别上的人。一般大厂可能中高级就可以了。越是一线城市反而好进入大厂，因为岗位需求量大。而新一线和二线城市反而更加难进入大厂，对人的综合能力有更高的要求。
3. 以为进去大厂就是解决高并发，其实，普通程序员进去，就是真的拧螺丝的。因为，大厂的一个项目会设计到几十个团队，每个团队只负责自己的内容即可，保证自己的内容不出问题即可，换句话说 ，不要关心边界以外事情，这句话很重要，可以减少很多焦虑，不要关心边界以外的事情，不要关心边界以外的事情。相信边界以外能够做好。
4. 很多时候，程序员直接拿到PRD上手开发，也没有 参与需求的讨论，模型的创建。当遇见问题的时候，直接跟相关负责人沟通。
5. 软件行业涉及大的东西还是多，岗位也多。软件设计非常厉害，也不一定要他解决非常难的技术问题。擅长设计也许是一个发展方向（架构师）。
6. 能够有一个好的软件设计，需要对业务的深入理解。需要对DDD的深入理解。需要对设计模式理解。需要经历过比较好架构设计，从中学习到好的东西。比如对分层的深入理解，对层与层之间的交互的深入理解。也就是用基础知识（DDD、设计模式、经历好的架构设计）+ 业务知识，去构建一个非常好的分层，并定义好层与层之间交互的协议。

…

---

小结

1. 梳理软件工程师工作内容。