智慧灯杆系统的分析、设计与实现基于单片机技术

##多种用户的调研
智慧灯杆作为一项多功能的城市基础设施，涉及到多种用户类型，每种用户都有其独特的需求和利益点。以下是一些重要的用户类型以及相应的用户调研方式：

1. 政府和城市规划者

需求：城市管理效率、安全、环境监控、数据收集与分析。

调研方式：深度访谈、问卷调查、工作坊，以收集关于城市发展和管理目标的信息，及智慧灯杆如何支持这些目标的反馈。

2. 公共安全机构（如警察、消防等）

需求：紧急响应和人群管理。

调研方式：专家访谈、小组讨论，探讨智慧灯杆在紧急事件管理和日常安全监控中的应用和需求。

3. 交通管理部门

需求：交通流量监控、智能交通引导、停车管理。

调研方式：专项调研、实地观察、数据分析，了解交通流量和停车问题，并评估智慧灯杆在解决这些问题中的潜力。

4. 环境保护机构

需求：空气质量监测、噪音监测、温湿度监测。

调研方式：数据收集与分析、专家咨询，了解环境监测数据对城市管理和居民生活质量的影响。

5. 商业用户（如零售商、广告商）

需求：广告展示、客流分析。

调研方式：市场调查、焦点小组讨论，探索智慧灯杆在商业推广和市场分析中的应用。

6. 城市居民

需求：公共WiFi、便捷的信息获取、安全感。

调研方式：在线问卷调查、社区会议、街头访谈，收集居民对智慧灯杆提供的服务的满意度和改进建议。

7. 技术供应商和开发商

需求：技术创新、市场机会、合作伙伴关系。

调研方式：行业调研、合作论坛、技术研讨会，了解最新的技术趋势和市场需求。

对于每种用户类型，设计调研的目的是理解他们的具体需求、预期的服务、潜在的问题和改进的建议。通过采用多种调研方法，可以全面地收集意见和反馈，为智慧灯杆的规划和实施提供有价值的洞见。

那么如何平衡各种需求呢？

平衡智慧灯杆项目中各种用户需求是一个复杂的过程，需要考虑不同群体的利益、预算限制、技术可行性以及长期维护等因素。以下是一些策略，可帮助在项目规划和实施过程中平衡这些需求：

1. 制定清晰的项目目标

明确优先级：根据城市管理和居民的关键需求，确定项目的主要目标和优先级。

可持续发展目标：确保项目目标与城市的长期可持续发展规划相一致。

2. 广泛的利益相关者参与

早期参与：在项目规划阶段就邀请所有相关的利益相关者参与，确保他们的需求和观点被考虑。

持续沟通：确保项目的所有阶段都有一个开放的沟通渠道，以便收集反馈并及时调整规划。

3. 多方面的需求评估

需求交叉分析：分析不同用户群体的需求，找出共通点和潜在的冲突，寻求平衡点。

风险评估：评估满足某些需求可能带来的风险和挑战，并制定相应的缓解措施。

4. 灵活的设计和技术解决方案

模块化设计：采用模块化设计使得未来可以根据需求的变化灵活地添加或调整功能。

技术兼容性：选择可以与现有和未来技术兼容的解决方案，以便于后续升级和扩展。

5. 试点项目和阶段实施

试点项目：在小范围内实施试点项目，测试解决方案的有效性，并评估用户的反馈。

阶段实施：根据试点项目的结果，分阶段推广实施，允许在每个阶段根据反馈调整计划。

6. 持续的监测和评估

性能监测：定期监测智慧灯杆的性能和用户满意度，确保服务质量。

调整和优化：根据监测结果和新的需求调整项目规划和技术解决方案，优化服务。

通过综合考虑这些策略，可以有效地平衡不同用户的需求，确保智慧灯杆项目既能满足当前需求，又具有足够的灵活性以适应未来的变化。

基于单片机实现的智慧灯杆项目，可以根据NABCD方法论来规划和实施。NABCD是一种项目评估和规划的工具，包括需求(Need)、方法(Approach)、益处(Benefit)、竞争(Competition)和差异化(Differentiation)五个维度。以下是智慧灯杆项目的NABCD分析：

需求(Need)

智慧城市的发展需要更智能、更节能的城市基础设施。传统的路灯系统在能源使用、维护成本和环境监测方面存在局限性。需要一种解决方案来提高能源效率，同时提供城市环境监测和管理能力。

方法(Approach)

采用基于单片机的智慧灯杆，不仅提供照明功能，还集成了空气质量监测、视频监控、紧急呼叫按钮、Wi-Fi热点等功能。这些灯杆连接到一个管理系统，实现远程控制和数据收集。

益处(Benefit)

节能降耗：通过智能调控灯光亮度，根据环境光线和人流量自动调整，显著降低能耗。

环境监测：集成的传感器可以监测空气质量、温度、湿度等，有助于城市环境管理。

公共安全：视频监控和紧急呼叫按钮增强了公共安全。

提供公共Wi-Fi：增加城市居民的便利性。

竞争(Competition)

市场上已有不少智慧灯杆解决方案，包括由大型科技公司和初创企业提供的。竞争产品可能具有类似的节能、环境监控和通信功能。

差异化(Differentiation)

本项目的差异化策略包括：

更高的集成度：整合更多的功能于单一的灯杆中，如环境监测、公共安全与通信服务。

更优的能效比：通过优化算法实现更高的能源利用率。

用户友好的管理平台：提供易于使用的界面，方便城市管理者监控和调整系统配置。

为了更直观地展示这个项目，展示一张描绘基于单片机的智慧灯杆在城市环境中的应用场景的图像。这将包括智慧灯杆的各种功能，如照明、环境监测、视频监控和Wi-Fi热点服务，以及如何通过管理系统连接这些灯杆。

这张图展示了一个集成了多种技术的智慧灯杆在城市环境中的应用场景，包括照明、空气质量传感器、紧急呼叫按钮和Wi-Fi热点，以及它如何连接到管理系统。周围的城市街道场景强调了这些灯杆如何通过技术提高城市生活的能效、公共安全和连通性，使城市变得更加宜居和智能。

【视频加载中，速速查收惊喜！】 https://www.bilibili.com/video/BV1FC411h7kY/?share_source=copy_web&vd_source=196781000d5853e63927b7863c68dad6

【智能灯杆项目用户调研】 https://www.bilibili.com/video/BV1p6421w7P1/?share_source=copy_web

1.重大的创新有主电源没电后实现备用电源的自动切换，还有烟雾检测和火焰检测，如果烟雾浓度过高，或者发现火焰就会发出危险信号提示。
2.我们的产品是Nth Mover。
3.维持性的技术是指单片机智能灯杆系统在运行和使用过程中保持其性能和功能稳定的能力。这包括系统的自我诊断、故障监测和自动修复等功能。
过度效能是指单片机智能灯杆系统在提供基本功能的同时，能够提高能源利用效率、减少维护成本、延长设备寿命等优点。
颠覆性的技术可能包括利用人工智能和大数据分析技术来优化灯杆的能源利用，提高灯光控制的精度和智能化程度，以及实现远程监控和自动化管理等功能。这些技术能够颠覆传统的灯杆管理模式，带来更高效、智能的灯光控制和维护体验。
4.仍未满足的需求：提供免费WIFI给行人。
仍未出现的需求：暂无。
5.节能降耗：通过智能调控灯光亮度，根据环境光线和人流量自动调整，显著降低能耗。
环境监测：集成的传感器可以监测空气质量、温度、湿度、时间等，有助于城市环境管理。
6.将5所描述的功能都实现。



1.单片机开发的最核心原型是指在系统设计初期，通过硬件和软件相合，制作出系统的原型。
2.商业用户、政府和城市规划者、交通管理部门、环境保护机构、城市居民。典型的场景是在交通道路上或者小区住宅。
3.大致需求：节能降耗：通过智能调控灯光亮度，根据环境光线和人流量自动调整，显著降低能耗。
环境监测：集成的传感器可以监测空气质量、温度、湿度、时间等，有助于城市环境管理。估计要2-3个月。

第四周作业

1. 名字
   小陈

2. 年龄和收入
   35岁，月收入约7000元

3. 代表的用户在市场上的比例和重要性
   在市场上占比约30%，重要性较高。这个群体通常是城市中的中等收入家庭，他们注重生活品质，愿意为提升居住环境的舒适度和安全性投入一定的资金。

4. 使用这个软件/产品的典型场景:
   小陈是一位中学教师，晚上经常需要备课或批改作业。当他到达学校附近的公园时，智能灯杆会自动感知到他的到来，调节灯光亮度以提供舒适的照明，同时播放背景音乐或提供临时公共WiFi，帮助他更好地完成工作。

5. 使用本产品的环境
   小陈通常在户外环境使用智能灯杆产品，如公园、校园或小区内的步行道。

6. 生活/ 工作情况
   小陈是一名中学教师，工作较为繁忙，经常需要加班备课或批改作业。他注重健康和生活品质，希望能在工作之余有一个舒适宜人的环境。

7. 知识层次和能力
   小陈具有研究生学历，对于电脑和互联网有一定的了解，能够熟练操作智能手机和使用常见的软件应用。

8. 用户的动机、目的和困难
   小陈使用智能灯杆的动机主要是为了提升生活品质和工作效率。他希望能够在户外环境享受到舒适的照明和便利的网络连接，以更好地完成工作任务。他可能会面临的困难包括光线不足导致工作困难，或者网络连接不稳定影响工作效率。

9. 用户的偏好
   小陈偏好智能化的生活方式，愿意尝试新的科技产品来提升生活品质。他喜欢简洁易用的界面设计和智能化的功能，希望产品能够满足他的基本需求并提供一定的个性化定制选项。
   
   客户： 城市市民或社区居民。
   •TA 在公司/家庭/学校/社区/…里面处于什么位置，负责什么?
   在居住区或市区的街道、人行道或公共场所。负责使用智能灯杆获取照明和其他服务，以及注意周围的安全情况。

•TA 目前用什么样的办法/工具
依赖传统的街灯和手持设备（如手机）来获取照明和信息，依靠过去的街道安全措施（如交通信号灯、报警器等）来确保安全。

•[客户待完成的任务]
•任务的频繁程度
每天都会发生。

•任务的细节
获取照明：当天色变暗或天气恶劣时需要照明。
获取相关信息：获取天气信息、社区活动信息等。
确保安全：观察周围环境，防止犯罪或其他安全风险。
客户动机：

•[ 客户动机 ]
•完成任务的动机是？
提高生活品质、增强安全感、获取便捷信息。

完成之后是达到了什么状态？
感到舒适、安全、方便。

•[ 客户问题 ]
•最大的烦恼是什么？ 现在客户是怎么绕过这些问题的？
最大烦恼： 传统街灯的亮度不足、信息获取不便、安全措施不够智能化。
绕过问题的方法： 依赖个人手机照明，主动搜寻信息，提高警惕来确保安全。

•对于 [ 待完成的任务 ]， 如果你能改变一件事情，你想改变什么？
如果我能改变一件事情，我想改变的是让获取相关信息更加便捷和智能化。通过智能灯杆，我希望可以实现更方便地获取天气信息、社区活动信息等，而不需要依赖个人手机或其他外部设备。这样，居民可以在街道上或公共场所就能够获取所需的信息，使生活更加便利和舒适。

改进措施：
为了提高10倍的用户满意度和产品效率，本团队可以采取以下改进措施：
1.提供更智能的照明服务： 将智能灯杆的亮度和光敏度根据环境自动调整，确保在任何情况下都能提供足够的照明。
2.改善信息获取渠道： 将OLED屏幕的广告位利用起来，显示实时天气信息、社区活动等，同时提供公共WiFi服务，方便居民获取信息。
3.增强安全措施： 加强烟雾和火焰检测的灵敏度，及时发现潜在的火灾风险。同时，改进语音警报系统，对危险情况进行及时警示，提高居民的安全感。
4.简化用户交互： 设计更友好、直观的用户界面，让居民能够更轻松地与智能灯杆进行交互，例如通过手机APP远程控制灯光亮度和获取信息。
5.持续优化系统稳定性： 定期对智能灯杆进行维护和更新，确保系统的稳定性和可靠性，减少因故障造成的不便。

第五周作业

一. 论述题（共1题，100分）

1. (论述题)
   共计14个作业题目

0.如果你的团队来了一个新队员，有一台全新的机器， 你们是否有一个文档，只要设置了相应的权限，他就可以根据文档，从头开始搭建环境，并成功地把最新、最稳定版本的软件编译出来，并运行必要的单元测试？ （在这过程中，不需要和老队员做任何交流）

回答：存在该文档，包括从零开始搭建嵌入式开发环境（keil5）、相关设备的使用（程序烧录及调试）等，足以新成员独立搭建开发环境及开发程序。

1.你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？
场景： 程序员甲正在对几个文件进行修改，实现一个大的功能， 这时候，程序员乙也要改其中一个文件，快速修复一个问题。怎么办？
一个代码文件被签出 (check out) 之后，另一个团队成员可以签出这个文件，并修改，然后签入么？
有几种设计，各有什么优缺点？
例如，签出文件后，此文件就加锁，别人无法签出； 或者， 所有人都可以自由签出文件

回答：团队源代码控制通常在版本控制系统中进行管理，用的是git系统。我们所执行的是分支开发，完全避免了主分支上的并发修改问题，每个团队成员可以自由地在自己的分支上工作。可以在分支上进行更灵活的实验和开发，不影响主分支的稳定性。

2.如何看到这个文件和之前版本的差异？ 如何看到代码修改和工作项 （work item），缺陷修复 （bug fix) 的关系。
场景： 程序员甲看到某个文件被修改了，他怎么看到这个文件在最近的修改究竟改了哪些地方？ （例子）
场景： 程序员甲看到某个文件在最新版本被改动了100 多行， 那么和这100多行对应的其他修改在什么文件中呢？ 这个修改是为了解决哪些问题而作的呢？ 那些问题有工作项 （work item，issue），或者bug 来跟踪么？

回答：若程序员甲看到了某个文件被修改了，可以通过在所被修改文件的日记文件中找到更改的信息，并通过beyond compare代码比较工具进行比对，找到修改的位置。

3.如果某个文件在你签出之后已经被别人修改，并且签入了，那么你在签入你的修改的时候， 如何合并不同的修改（merge)? 你用了什么工具来帮助你？

回到：通过Git提供的命令行工具和各种图形用户界面工具实现代码合并操作。

4.你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性），或者同时签入不成功？
场景： 程序员甲要签入 20 个文件，他一个一个地签入， 在签入完5 个 .h 文件之后， 他发现一些 .cpp 文件和最新的版本有冲突，他正在花时间琢磨如何合并… 这时候， 程序员乙从客户端同步了所有最新代码， 开始编译， 但是编译不成功 – 因为有不同步的 .h 文件和 .cpp 文件！ 这时候， 别的程序员也来抱怨同样的问题，甲应该怎么办？

回答：
使用事务性提交：一些版本控制系统支持事务性提交，即一次提交可以包含多个文件的修改，要么全部成功提交，要么全部失败回滚。程序员甲可以将需要同时签入的文件放在同一个提交中，以保证原子性。
使用分支进行开发：在进行大规模修改时，可以在版本控制系统中创建一个临时分支，进行所有的修改工作。一旦所有修改都完成并通过测试，再将这些修改合并到主分支中，以确保一次性地将所有相关文件的修改提交到版本控制系统中。
预先检查冲突：在签入修改之前，程序员甲可以先拉取最新的代码，并进行合并和冲突解决。这样可以在签入之前发现潜在的冲突，并确保所有相关文件的修改是一致的。
通知团队成员：如果程序员甲在签入修改时遇到了问题，导致一部分文件已经签入而另一部分文件未签入，他应该立即通知团队成员，告知他们不同步的文件，并说明正在解决的问题。这样可以避免其他团队成员在不同步的代码上进行开发，导致代码不一致。
及时沟通和协调：在团队合作中，及时沟通和协调是非常重要的。程序员甲可以与其他团队成员一起讨论如何解决这个问题，并共同制定解决方案，以确保代码的一致性和稳定性。

5.你的PC 上有关于三个功能的修改， 但是都没有完成，有很多文件处于半完工的状态，这时你要紧急修改一个新的 bug，如何把本地修改放一边，保证在干净的环境中修改这个 bug, 并成功地签入你的修改 — changelist management。

回答：保存当前工作状态：首先，我会保存当前工作目录中所有未完成的修改。这可以通过提交未完成的修改或者使用版本控制系统的临时存储功能来实现。确保所有修改都被安全地保存起来，以便稍后恢复。
创建新的变更列表：接下来，我会创建一个新的变更列表，并将所有与紧急 bug 修复无关的修改放入其中。这些修改可能涉及三个功能的开发，但由于尚未完成，所以需要暂时放一边。
切换到干净的工作环境：在创建了新的变更列表之后，我会切换到一个干净的工作目录或者新的分支中。这样可以确保我在一个没有任何未提交修改的环境中进行紧急 bug 修复，避免其他未完成的修改对修复过程造成干扰。
解决 bug 并提交修改：在干净的工作环境中，我会专注于修复紧急 bug。一旦修复完成，我会将修改提交到版本控制系统中。这个提交可以作为一个单独的变更列表，以便于跟踪和管理。
恢复之前的工作状态：修复完 bug 后，我会返回到之前保存的工作状态，恢复未完成的修改。这可以通过切换回之前的变更列表或者恢复之前的工作目录状态来实现。

6.规范操作和自动化
你的团队规定开发者签入的时候要做这些事情：
运行单元测试，相关的代码质量测试。
– 代码复审 （要有别的员工的名字）
– 和这次签入相关的issue 编号， 任务/task， 缺陷/bug 编号，等等， 以备查询。
请问你的团队有这样的自动化工具让开发者方便地一次性填入所有信息然后提交么？ （高级功能， 代码提交之后， 相关bug 的状态会改动为 “fixed”， 并且有链接指向这次签入。），举个例子。

回答：在现代软件开发实践中，实施规范的操作流程和自动化是至关重要的，旨在提高效率、保障代码质量，并确保跟踪问题的能力。针对您提到的需求，许多团队采用持续集成/持续部署（CI/CD）工具链配合源代码管理系统（如Git）来实现这些自动化流程。以下是如何使用这些工具来满足您的需求的示例。

自动化工具和流程

①运行单元测试和代码质量测试

CI/CD工具（如Jenkins, GitLab CI/CD, GitHub Actions）可以配置为在每次代码提交时自动运行单元测试和代码质量分析工具（如SonarQube）。这些工具可以检查代码覆盖率、寻找潜在的漏洞和代码异味。

② 代码复审

大多数现代代码仓库平台（如GitHub, GitLab, Bitbucket）都内置了代码审查功能。您可以设置强制代码审查的规则，要求至少一个或多个同事审查并批准更改才能合并代码。

③ 关联Issue和Task

GitLab：可以在提交信息中使用特定格式来关闭或引用issue，例如，“Fixes #123”。

GitHub：类似地，提交信息可以包含“Fixes #123”来自动关闭关联的issue。

JIRA：与Bitbucket或GitHub集成时，可以配置在提交信息中引用特定的任务或缺陷编号，如“JIRA-123”。

④ 高级功能：自动化状态更新和链接

一些任务管理工具（如JIRA）和CI/CD平台（如GitLab, GitHub Actions）允许你进一步自动化工作流。例如，当代码提交并通过所有测试后，可以自动将关联的Bug或Task状态更新为“Fixed”，并在任务跟踪系统中生成指向该提交的链接。

示例：GitHub Actions + JIRA

假设您的团队使用GitHub和JIRA。
①GitHub Actions Workflow：在.github/workflows目录下创建一个YAML配置文件，配置在每次push到特定分支时运行测试并触发代码审查流程。
② JIRA Integration：使用市场上的GitHub-JIRA集成应用（如Atlassian的官方GitHub app）连接您的GitHub仓库和JIRA项目。这样，在提交信息中提到JIRA Issue编号时，可以自动在JIRA Issue中添加提交的链接，并可配置为自动更改Issue状态。
③提交信息规范：教育团队成员在提交信息中遵循特定格式，如“Fixes ABC-123 – 实现了新的用户认证功能”，其中“ABC-123”是JIRA中的任务编号。
通过这样的设置，您不仅实现了代码的自动化测试，还加强了代码审查的流程，并能够有效地追踪代码更改和相关任务的状态更新，极大地提高了团队的效率和代码质量。

7.如何给你的源代码建立分支？
场景：你们需要做一个演示，所以在演示版本的分支中对各处的代码做了一个临时的修改， 同时，主要的分支还保持原来的计划开发。 你们怎么做到的？ 在演示之后，演示版本的有些修改应该合并到主分支中，有些则不用，你们是怎么做到的？
场景： 你们的软件发布了，有很多用户，一天，一个用户报告了一个问题，但是他们是用某个老版本，而且没有条件更新到最新版本。 这时候，你如何在本地构建一个老版本的软件，并试图重现那个问题？

回答：
创建演示版本的分支：
使用版本控制系统的命令或者图形用户界面工具，在主要的开发分支（通常是主分支或者开发分支）上创建一个新的分支，命名为演示版本分支。在演示版本分支上进行临时修改，以满足演示的需求，保持主要的开发分支不受影响。
合并修改到主分支：
在演示之后，评估哪些修改需要合并到主分支中。
切换到主分支，并使用版本控制系统的合并功能，将演示版本分支中的必要修改合并到主分支中。
对于不需要合并的修改，可以选择在演示版本分支上保留或者丢弃。
本地构建老版本软件：
确定用户报告的问题所在的老版本号。
使用版本控制系统或者相关工具，切换到对应的老版本分支或者标签。
在本地环境中构建老版本的软件，以便重现用户报告的问题。

8.一个源文件，如何知道它的每一行都是什么时候签入的，为了什么目的签入的 （解决了哪个任务，或者哪个bug）？
场景： 一个重要的软件历经几年，几个团队的开发和维护，忽然出现在某个条件下崩溃的事故， 程序员甲经过各种debug手段，发现问题是在某一个文件中有一行代码似乎显然出了问题， 但是这个模块被很多其他模块调用， 这行代码是什么时候，为了什么目的，经过谁签入的呢？ 如果贸然修改， 会不会导致其他问题呢？ 怎么办？

回答：
查看文件历史记录：使用版本控制系统的命令行工具或者图形用户界面，在指定的源文件上查看历史记录。这些历史记录会显示每次提交的详细信息，包括提交者、提交时间、提交信息等。
检查提交信息：针对每次提交，查看提交信息中的说明。提交信息通常会包含对所做修改的简要描述，以及相关任务/缺陷编号（如果有的话）。
关联任务/缺陷编号：如果提交信息中包含了任务/缺陷编号，可以进一步查看任务/缺陷系统中的详细信息。这些信息通常会包含对问题的描述、修复方案等，有助于了解修改的目的和意图。
谨慎修改：在了解了文件的签入历史和修改目的后，程序员甲可以根据需要谨慎地修改问题代码。在修改之前，最好先进行代码审查或者测试，以确保修改不会引入新的问题或者影响其他模块的正常功能。
记录修改：在进行修改时，及时记录修改内容和修改目的。这样可以帮助团队成员理解修改的背景和意图，并且有助于未来的代码维护和排查问题。

9.如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？
代码每天都在变， 有时质量变好，有时变差，我们需要一个 Last Known Good （最后稳定的好版本） 版本， 这样新员工就可以同步这个版本， 我们如果需要发布，也是从这个版本开始。 那么如何标记这个 Last Known Good 版本呢？

回答：
选择标签名称：首先，选择一个合适的标签名称，以标识这个 Last Known Good 版本。通常可以选择类似于 “last_known_good” 或者 “stable_version” 的标签名称。
标记所有源文件：使用版本控制系统的命令行工具或者图形用户界面，在系统的主要分支（如主分支或者稳定分支）上标记所有的源文件。具体操作取决于版本控制系统，通常是通过指定标签名称和要标记的文件列表来实现。
推送标签到远程仓库：如果团队使用的是分布式版本控制系统（如Git），则需要将标签推送到远程仓库，以便他人可以同步这个标签。使用版本控制系统的相应命令将标签推送到远程仓库。
通知团队成员：一旦标签被创建并推送到远程仓库，通知团队成员该标签的存在和意义。这样新员工就可以轻松地同步到这个 Last Known Good 版本，并且团队在需要发布时也可以从这个版本开始。

10.你的项目的源代码和测试这些代码的单元测试，以及其他测试脚本都是放在一起的么？ 修改源代码会确保相应的测试也更新么？你的团队是否能部署自动构建的任务？
在签入之前，程序员能否自动在自己的机器上运行自动测试，以保证本地修改不会影响整个软件的质量？
在程序员提交签入之后，服务器上是否有自动测试程序， 完成编译，测试，如果成功，就签入，否则，就取消签入？
团队是否配置了服务器，它自动同步所有文件，自动构建，自动运行相关的单元测试，碰到错误能自动发邮件给团队

回答：
源代码和测试代码的组织： 通常，源代码和测试代码（包括单元测试和其他测试脚本）会一起组织在同一项目仓库中，但它们通常会被放在不同的目录下。例如，在许多Java项目中，源代码可能位于src/main/java目录下，而单元测试代码则位于src/test/java目录下。这样做既能保持项目的结构清晰，也便于管理。

修改源代码与更新测试： 理想情况下，当源代码被修改时，相应的测试代码也应该被更新或新增，以确保测试覆盖率。这通常需要开发人员的纪律性，以确保每次更改都伴随着测试的更新。一些团队还会使用代码覆盖率工具来强制或鼓励这种实践。

自动构建的部署： 许多团队设置了自动构建任务，这些任务可以在代码被签入到版本控制系统之前或之后自动执行。这些构建任务通常包括编译代码、运行单元测试和其他类型的测试（如集成测试、性能测试等）。

本地自动测试： 在代码签入之前，开发人员通常可以在本地运行自动化测试。这是通过使用构建工具（如Maven、Gradle、npm等）和测试框架（如JUnit、TestNG、Mocha等）实现的。这有助于确保本地更改不会降低软件的质量。

服务器上的自动测试程序： 多数团队会使用CI/CD服务器（如Jenkins、GitLab CI、GitHub Actions等）来自动化编译、测试和部署过程。当代码提交后，CI服务器会自动运行一系列的测试，如果所有测试都通过，更改可以被合并到主分支。如果测试失败，通常会阻止合并，并通知开发人员修复问题。

自动构建、测试和通知： 在CI/CD的上下文中，服务器不仅会自动同步所有文件并构建项目，还会运行相关的单元测试。如果遇到错误，它可以配置为自动发送电子邮件或通过其他方式（如Slack消息、JIRA票据等）通知团队成员。

11.分析比较各种软件构建环境：
就像一个厨师要分析各种厨房用具，挑选适合自己的工具组合， 一个软件团队也要挑选适合自己的源代码管理和其他配套工具，请选择至少三种，比较各自的优点缺点，成本：
github
https://gitee.com/education
coding.net
code.csdn.net
gitcafe.com
www.visualstudio.com
code.taobao.org
Visual Studio Team Foundation Server
gitblit， 在Windows系统下构建 git 服务，带网页端管理…
Visual Source Safe (VSS)
本团队自行搭建的系统

回答：
①GitHub
优点：
广泛使用与社区支持，有大量开源项目和资源。
强大的协作特性，如分支管理、合并请求（Pull Requests）和代码审查。
集成了CI/CD（如GitHub Actions）、项目管理工具等。
缺点：
私有仓库和高级功能需要付费。
在一些国家访问速度可能较慢。
成本：提供免费计划，高级功能需要订阅付费计划。
适用场景：适合各种规模的开发项目，特别是开源项目和需要广泛协作的项目。
②Gitee（码云）
优点：
国内访问速度快，面向中国用户优化。
提供免费的私有仓库。
支持Git Large File Storage（LFS）。
缺点：
国际化和英文社区支持不如GitHub。
相比GitHub，第三方集成和插件生态可能不那么丰富。
成本：基本使用免费，某些高级功能可能需要付费。
适用场景：适合中国团队或个人开发者，特别是那些需要快速访问速度和国内优化服务的项目。
③Visual Studio Team Services (现为Azure DevOps)
优点：
提供全面的开发工具集，包括代码仓库、项目跟踪、CI/CD等。
与Microsoft生态系统（如Visual Studio、Azure）集成紧密。
支持多种语言和平台的开发。
缺点：
对于非Microsoft技术栈的项目，可能不是最优选择。
可能比较依赖于Microsoft生态系统。
成本：基本功能免费，更高级的功能需要根据使用量付费。
适用场景：适合使用Microsoft技术栈的企业和团队，以及需要紧密集成Azure服务的项目。
④ Visual Source Safe (VSS)
优点：
简单易用，适合小型团队。
微软产品，与某些旧的Microsoft技术栈集成良好。
缺点：
已被微软弃用，不再推荐使用。
不支持现代的开发实践和大规模协作。
成本：已被弃用，无新的许可或支持。
适用场景：不再推荐使用，建议考虑现代的替代方案。

12.每个小组说明自己团队的开发环境和流程有什么需要改进的地方？
开发环境：
①用户友好性改进：Keil开发环境和单片机开发流程可以更加用户友好，易于理解和操作。界面设计可以更加直观，功能布局更加合理，减少用户学习成本。
② 支持更多单片机型号：Keil开发环境可以考虑扩展支持更多单片机型号，方便用户在不同型号的单片机上进行开发和调试。
③ 社区支持和交流：建立健全的社区支持和交流平台，让用户可以互相交流经验、解决问题，促进技术共享和进步。

流程方面：
①零部件选择：
选型不当可能会导致后续的性能瓶颈或成本过高，要考虑零部件的可获取性，避免因零部件短缺影响生产。
②代码质量：
代码可能存在的冗余和不够优化，使得程序效率不高。
采用模块化编程、清晰的注释及文档将有助于后续维护和更新。
③团队协作：
硬件设计师和软件开发者间的沟通不顺畅，可能会导致设计不一致。
跨部门协作中的信息同步不及时，影响整体进度和效率。
④回顾和反馈机制：
缺乏项目完成后的回顾机制，忽略从错误中学习的机会。
欠缺有效的用户反馈收集和处理机制，未能持续改进产品。

13.考虑下面的软件需求：
•手机英语背单词软件，用户可以选择单词本的类型（四级，六级，GRE，等），每天背单词的进度。

•可以和好友分享自己背单词的进度。还可以挑战好友，挑选20个单词，送给好友，让好友选择正确的解释，并把成绩自动分享回来。

•假设有微博/微信/email 可以确定用户的身份

•假设有服务器可以返回 【中文 – 英语单词】的对应关系

用下面的工具进一步分析这些需求，做出草图

•思维导图

•ER图

•Use Case

•Data Flow Diagram

•UML

第六周作业

（1）代码规范采用什么方式？
答：该代码段采用了 C语言的命名规范、缩进和格式化、注释规范、中断处理、硬件相关性和错误处理和调试。

代码	内容
代码名称	解析GPS回传数据
日期	2024-4-7
1.1 代码符合需求和规格说明么？	符合，代码段采用了C语言的命名规范、缩进和格式化、注释规范、中断处理、硬件相关性和错误处理和调试
1.2代码设计是否考虑周全？	考虑了，遇到异常的数据时会跳转到解析错误的函数中进行错误情况打印，且有足够的注释给后期的维护人员理解和修改
1.3代码可读性如何？	可读性好，变量命名简洁易懂，注释充足，容易理解
1.4代码容易维护么？	容易，代码有充足的注释，有利于有助于后续维护和修改
2.设计规范部分
1.1代码有没有依赖于某一平台，是否会影响将来的移植（如Win32到 Win64）？	有，依赖于以C语言编程的单片机，如果移植到非C语言编程（如arduino）或io缺失的单片机（单片机对应的io口没有在硬件上引出）可能会带来影响
1.2在本项目中是否存在类似的功能可以调用而不用全部重新实现？	有，如串口发送函数Usart_SendString，它底层调用USART_SendData函数，该函数是在标准库内的，不用重新实现该功能
1.3有没有无用的代码可以清除？	无
3.具体代码
1.1有没有对错误进行处理？	有，对于数据错误会调用自定义的函数errorLog去循环打印出对应的错误信息
1.2有没有使用断言（Assert）来保证我们认为不变的条件真的得到满足？	有，如串口发送函数Usart_SendString，它底层调用USART_SendData函数，它的内部会调用assert_param断言函数来确保条件满足
1.3有无可能存在资源泄漏（内存、文件、 各种GUI资源、数据库访问的连接，等等）？	无，理论上不存在泄露的情况，数据是通过覆盖实现的，而且存储数据的变量的大小是回传数据的2倍大，以确保不会 内存溢出
1.4数据结构中有没有用不到的元素？	无
4.可测试性
4.1代码是否需要更新或创建新的单元测试？	目前没有这个需要，但是根据情况会更新单元测试（已对每一个模块进行了单元测试，也实现了部分的混合式集成测试）

（3）运用“代码复审核查表”，回顾本小组项目这段代码
a 确认代码是否容易理解?
答：代码容易理解，主要功能是解析 GPS 回传的数据，虽然注释不算多，但逻辑相对清晰，能够理解代码意图。
b 是否符合代码规范？
答：符合代码规范，但注释需要进一步完善，以符合代码规范的要求。
c 代码是否正确?
答：代码逻辑正确，没有语法错误，可以正常编译和运行。
d 对于各种边界情况能否正确处理？
答：代码中考虑了部分边界情况，如数据是否为空等。

作者：dyxz1