搭建架构的最低前提
1.设计清晰：
需求文档： 有哪些界面 每个界面提够了哪些功能 这些功能是怎样操作的 会有哪些反馈
2.技术：
写架构的同学：这次项目设计的技术 都要有料及（用到的技术有哪些特点 有哪些缺点）
比如： 控制台和easyx
控制台：没法接受鼠标输入
easyx：接受文本输入（中文符号）很麻烦
达到这些要求后 就可以开始架构了
谁来写？
1.技术官
2.建议 达到最低进度要求的同学 都可以试着写一份架构
注意：
1.架构是各自写自己的，不要多人写同一份架构：容易出现思路上的冲突，
架构完成后，组长整理发给小学组，由小学长选择合适的架构
2.先完成核心，在考虑扩展
核心部分的架构完成后，就可以先分工了
核心功能分工会，技术官可以再写扩展部分架构
后面 核心功能跑起来后，再安排扩展部分的分工
3.整合代码
每天整合代码，写一部分整合一部分
第一次团队项目，会出现很多重复的错误
比如：参数和架构要求不一致/全局变量用法错误/变量名重名等等问题
第一次整合时错误是最多的
这时候修正大家的代码习惯，可以避免后续的任务出现重复的问题
整合方式：
开会时，技术官屏幕共享，讨论整合代码
如果完成了扩展部分的架构，整合后安排扩展任务分工
什么是架构
数据的设计：
全局变量+对应的注释
如果有自定义类型，需要加上自定义类型的定义（成员变量，成员函数不需要写定义）
函数的声明
写函数声明，返回值，函数名，参数列表
记得要写注释
格式:
负责人：谁负责实现这块功能
功能：函数的整体逻辑描述
参数：函数的参数含义
返回值：返回值的含义
返回值类型函数名称 ([参数列表]);
架构的内容
1.是项目文件夹
，不是单个源文件，完成架构后，项目文件夹打包压缩
组员在使用时也是，不要自己创建项目，而是将整个项目文件夹拿出来使用（避免环境不统一问题）
2.数据的设计：
全局变量的生命/对应的注释/如果有自定义类型，需要写自定义类型的声明
3.函数的声明
函数的声明/对应的注释
每个函数，分别提供什么功能，参数什么意思，返回值什么意思
常见架构的思路：界面和逻辑分开
view(视图层/表示层)
负责和用户的交互：
界面展示
接受用具输入
用户输入 -> 逻辑判断/修改（service） -> 程序的反馈（界面展示）
用户输入 和 程序反馈 是view层的内容
在需求文档中的界面划分，要能在view层找到对应的界面函数
逻辑判断/修改
在需要判断/修改[全局变量]时，调用service
service（业务层/逻辑层）
负责核心逻辑的处理/判断
view层在需要处理/判断数据时，需要通过调用service来处理
注意service层不接受输入，不打印输出
最后注意
1.建议
将架构的内筒和架构的分层理解后，跟着推箱子架构案例写一遍
2.注释要写清晰
清晰标准：组员能看懂
