1你上一家公司团队构成

• 后端工程师：都会有，一般小一点的团队3~5人；再大的团队就会分项目组，每组3~5人
• 前端工程师：目前来说不是每个公司都有
  • 公司不设前端岗：由后端负责写前端
  • 公司设置前端岗：前端人数会比后端少很多，比例大概是5:1
• 测试工程师：和前端情况一样
• 运维工程师：大公司才会有，小公司肯定没有
• DBA数据库管理员：更加是大公司才会有，小公司肯定没有

2在公司里谁负责建数据库表

• 整个项目全局范围的数据库表：项目启动时统一创建
• 专属于各个模块的数据库表：由该模块负责的程序员自己创建

3如何根据需求文档或原型页面创建数据库表？

3.1相关理论：三大范式

3.1.1数据库三大范式简介

3.1.1.1第一范式（1NF）：确保每一列都是不可分割的基本数据项

• 不满足1NF：假设有一个表记录学生的课程信息，其中一列是“课程”，值为“数学, 英语, 物理”。这就不符合1NF，因为一个单元格里包含了多个值。
• 满足1NF：应该将“课程”这一列拆分成多行，每行只记录一门课程，比如一行是“数学”，另一行是“英语”。

3.1.1.2第二范式（2NF）：在满足第一范式的基础上，确保表中的非主键列完全依赖于主键

• 不满足2NF：假设有一个表记录订单信息，包含“订单号”、“商品编号”、“商品名称”、“客户姓名”、“客户地址”。这里“客户姓名”和“客户地址”依赖的是“客户”，而不是“订单号”，所以不满足2NF。
• 满足2NF：应该将订单信息和客户信息分开成两个表，一个表记录订单信息（订单号、商品编号、商品名称），另一个表记录客户信息（客户姓名、客户地址），通过“客户ID”关联。

3.1.1.3第三范式（3NF）：在满足第二范式的基础上，确保表中的非主键列只依赖于主键，而不依赖于其他非主键列

• 不满足3NF：假设有一个表记录员工信息，包含“员工ID”、“部门ID”、“部门名称”、“员工姓名”。这里“部门名称”依赖于“部门ID”，而不是直接依赖于“员工ID”，所以不满足3NF。
• 满足3NF：应该将员工信息和部门信息分开成两个表，一个表记录员工信息（员工ID、部门ID、员工姓名），另一个表记录部门信息（部门ID、部门名称），通过“部门ID”关联。

3.1.2总结

• 第一范式（1NF）：确保每一列都是单一值。
• 第二范式（2NF）：确保非主键列完全依赖于主键。
• 第三范式（3NF）：确保非主键列之间没有依赖关系。

3.2相关理论：ER模型

1. 实体（Entity）：实体是ER模型中的基本单位，代表现实世界中可以独立存在的事物或对象。每个实体都有一组属性来描述其特征。实体可以是具体的，如“学生”、“教师”、“图书”等，也可以是抽象的，如“课程”、“部门”、“项目”等。在ER图中，实体通常用矩形表示，实体名称写在矩形内部。
2. 属性（Attribute）：属性是描述实体特征的元素。例如，一个人的姓名、年龄、性别等都是属性。属性可以是简单属性（不可再分的基本数据），复合属性（由多个简单属性组成的属性）或多值属性（可以有多个值的属性）。在ER图中，属性通常用椭圆形表示，并连接到相应的实体上。
3. 关系（Relationship）：关系是ER模型中描述实体之间联系的部分。关系可以是一对一、一对多或多对多的。在ER图中，关系通常用菱形表示，并通过连线与相关的实体连接。关系的命名应简洁明了，能够准确描述实体之间的关联。

1. boardmix：boardmix支持多人在线协作，适用于团队协作、创意设计、文档笔记和知识整理等多种场景。它提供了丰富的图形绘制工具和模板库，包括ER图模板，方便用户快速创建ER图。
2. Lucidchart：Lucidchart是一款在线协作图表工具，支持ER图的创建和共享。它具有易用的界面和丰富的模板库，适用于个人和团队。
3. Draw.io：Draw.io是一款免费、开源的在线图表工具，支持ER图的绘制。它具有强大的导出选项和多平台兼容性，无需安装任何软件，用户可以直接通过浏览器访问和使用。
4. Dbdiagram.io：Dbdiagram.io是一个专门为数据库设计的在线工具，支持ER图的创建和自动生成SQL代码。它具有直观的界面和协作功能，适用于数据库设计师和开发团队。
5. Microsoft Visio：Visio是Microsoft的图表设计工具，支持ER图的绘制。它具有强大的功能，适用于大型项目和企业。Visio内置了大量的数据库模板，包括ER图模板，用户可以根据需要选择并应用不同的样式。

3.3操作落地

1. 查看需求文档、原型页面或接口文档，确认所有要保存到数据库的数据有哪些
2. 设计出各个实体（Entity）
3. 确定各个实体内部需要包含哪些属性（Attribute）
   1. 要求1：涵盖所有需要保存的数据
   2. 要求2：基本满足三大范式
   3. 要求3：一定要注意除了表面上看得到的数据之外，还有哪些隐含的数据
4. 确定各个实体之间的关联关系（Relationship）

4你们之前团队中任务分配与任务进度跟进使用的是什么软件？

4.1一、概述

4.1.1①专业软件统计数据

4.1.2②通用软件统计数据

4.1.3③其他形式统计数据

4.2二、jira简介

5项目是怎么从0到1开发出来的？

5.1一、立项

5.1.11、传统软件开发项目

5.1.22、互联网项目

5.1.2.1①个人发起

5.1.2.2②企业发起

5.2二、软件工程

5.2.11、概念

5.2.22、瀑布模型

5.2.2.1①瀑布模型的优点

5.2.2.2②瀑布模型的缺点

5.2.33、其他模型

• 边做边改模型(Build-and-Fix Model)
• 快速原型模型(Rapid Prototype Model)
• 增量模型(Incremental Model)
• 螺旋模型(Spiral Model)
• 演化模型(evolution model)
• 喷泉模型(fountain model)
• 智能模型(四代技术(4GL))
• 混合模型(hybrid model)
• RAD模型

5.3三、敏捷开发

5.3.11、曾经

5.3.22、互联网时代的新挑战

• 特定受众模糊，所以产品经理们会根据典型用户的特征创建用户画像，作为一个假想的用户个体。
• 项目功能边界不稳定，需要在市场运作中摸索
• 项目功能需要根据用户的新需求进行迭代更新
• 项目的终端设备日新月异，从PC客户端到PC浏览器再到移动客户端再到移动端浏览器不断发展，相应的交互方式和系统界面都需要持续改进
• 竞争激烈，不及时占领市场很可能被淘汰

5.3.33、敏捷

5.3.3.1①概念

5.3.3.2②实现

• 原型：将最初的功能创意想法绘制成草图，基于这个草图让功能需求更加直观，前端和后端工程师据此分头开始各自的工作。相比较瀑布模型省略了大量的中间环节，快速启动项目。
• 持续部署：项目不能满足于单元测试通过，而需要在开发过程中保证本模块可以在服务器上运行，避免大范围返工。
• 持续集成：项目不能满足于模块独立运行正确，还必须要保证各个模块集成在一起后可以正常工作，对于庞大复杂的系统尤其如此。
• 持续交付：要在项目有细微升级时就交付给最终用户，及时获得反馈，而不是很长时间后推出一个重大更新版本——这会导致对用户体验的感知严重滞后。

6软件项目的开发流程是什么？

7开发团队内你需要知道的黑话

7.1开发环境

7.2测试

7.3岗位名称

7.4文档