智能软件工程 课件 Ch5-如何高效地进行软件开发

智能软件工程第5章如何高效地进行软件开发5.1

AI辅助编程5.2软件构建5.3软件文档5.4代码审查软件开发让抽象设计“落地”：编写可运行的软件对应DevOps环中编程（Code）与构建（Build）阶段涵盖内容：编程与构建过程软件文档（开发活动+构建产出）高效开发的最佳实践与智能化方法代码审查（质量与效率保障）5.1

AI辅助编程AI辅助编程现状2023年调查显示，44%的受访者已在日常开发中使用AI。绝大多数使用者(83%)在写代码阶段使用AI，近半数(49%)在代码调试时使用。77%的受访者认为AI工具能够提高生产力并加快学习速度。AI在软件开发阶段的使用大大超过了计划和部署阶段AI辅助编程现状AI在软件开发中的使用情况（数据来源：StackOverflowDeveloperSurvey2023）代码补全工具基于不完整的输入，建议或自动补全代码。传统工具依赖于关键词匹配和简单语法分析。生成式AI(如GitHubCopilot)通过理解上下文和复杂的语义逻辑，提供更可靠的补全建议，效果优于传统技术。有助于开发者在学习新语言或处理不熟悉的复杂项目时快速上手，提高生产力代码补全根据方法名/代码上下文进行代码补全代码生成AI工具根据自然语言描述(Prompt)自动生成部分甚至全部代码，包括编译所需的import和测试代码。最佳实践：开发者需将需求分解为更小、更准确、互相独立的小需求，再作为提示词输入，以提高代码可用性。使用笼统的提示词会导致AI返回通用且不可用的代码代码生成代码生成示例（ChatGPT）代码理解代码解释示例（Cursor+Claude-3.5）AI工具可以自动为代码生成自然语言解释，帮助开发者快速掌握代码的意图和逻辑。对于理解他人编写的代码、不熟悉的语言、缺乏文档的遗留代码，或逻辑复杂的代码尤为重要。缺陷修复Cursor缺陷定位与修复示例AI工具（如Cursor）能定位问题代码片段并提供修复建议测试生成Cursor测试用例生成示例AI可以自动生成测试数据、测试用例或测试套件。可以指示AI生成大量的测试数据用于复杂表单或搜索功能测试。AI-generatedtests(如使用Cursor)可正确使用SpringTesting框架和JUnit,且包含对多种场景的断言代码维护Cursor代码迁移示例AI工具辅助进行格式规范、代码风格优化、代码迁移，以提高代码的可维护性5.2

软件构建版权所有©️仅限于教学使用软件构建的定义软件构建(Build)是将源代码转换为计算机可执行的二进制制品(executablebinary)的过程构建vs编译编译器更适用于简单、小型项目。构建系统对于中大型项目不可或缺，须处理以下复杂性：定位分布在不同路径下的多个源代码文件。处理和定位第三方库（3rd-partylibraries）等依赖。处理复杂的依赖关系，包括库之间的依赖关系。确保模块间构建遵循特定的顺序协调多种编程语言与多个编译器协同工作。基于Shell脚本的构建方案难以维护，且缺乏可扩展性、易出错、与运行环境耦合紧密一个简单构建过程的shell脚本软件构建的本质依赖管理(下载、安装、配置制品)任务协调(确保任务按正确顺序执行)。基于任务的构建系统基本单元是“任务”，用户决定构建流程的每一步。任务的依赖对象是其它任务。常用工具：Ant,Maven,GradleAntAnt构建脚本(buildfile)与任务依赖MavenMaven构建生命周期、阶段、插件、和插件目标的关系GradleGrade的buildfile示例Gradle与Maven的性能比较基于制品的构建系统用户只需声明需要构建的“制品”（Targetartifact）和依赖关系。构建系统负责具体的构建流程、配置和调度(即使用者声明What，系统决定How)。例子：Bazel(GoogleBlaze的开源版本)。优势：系统对其运行工具有完全控制权，易于实现安全、正确的并行构建，并保证了高度的可复现性Bazel构建脚本示例软件包管理软件包(Packages)：统一指二进制软件制品，如.jar或.war等格式的文件。依赖类型：依赖包括组件(components)和库(libraries)。组件(内部依赖)：指从系统中重构或分离出的独立单元，通常由开发团队或同组织的其他团队负责。团队对其有较高的控制权。库(外部依赖)：由第三方供应商或开发者提供，开发团队可以使用但对其没有控制权现代软件依赖于复杂的组件和库；软件包管理是软件构建的核心。软件包管理：语义化版本(SemVer)格式为MAJOR.MINOR.PATCH（如2.3.1），使版本号具有意义和可预测性。主版本号(MAJOR)：当引入向后不兼容的API更改或重要功能时加1。主版本号为0通常表示尚未正式发布。次版本号(MINOR)：当添加向后兼容的功能时加1。修订版本号(PATCH)：当进行向后兼容的缺陷修复时加1。版本号后可添加预发布标识符（-分隔）和构建元数据（+分隔），如2.1.0-beta.1+20220310。软件包管理来源信息：说明软件包的来源，例如GitHub仓库的URL或ReleaseID，用于帮助使用者进行溯源。依赖关系分类：软件包的元信息说明了它依赖的其他软件包，可分为三类：编译时依赖(Compile-time)：在编译阶段所需，必须提供给编译器以确保代码正确编译(例如，Java编译所需的SLF4Jjar包)。运行时依赖(Runtime)：在项目运行时所需，用于确保程序的正确执行，通常不需要在编译时包含(例如，Web应用运行时需要的Tomcat容器)。测试时依赖(Test-time)：项目测试过程中需要的软件包(例如，JUnit)制品仓库（ArtifactoryRepository）对于复杂的项目，将依赖包与源代码一起版本控制是不可扩展的。制品库是用于存储、组织和管理软件制品的中心化存储系统，专注于二进制制品。常用工具包括Nexus和Artifactory依赖管理软件不是孤岛：开源与复用使得现代软件构建在复杂的依赖图之上；有效的依赖管理是构建系统的核心功能。依赖类型：内部依赖（组件Components）：由开发团队或同组织的其他团队负责，团队对其有较高的控制权。外部依赖（库Libraries）：由第三方提供，开发团队只能使用，对其没有控制权（如更新、决策）。依赖管理的挑战：构建系统需要假设最复杂的情况，例如完全不受控的外部依赖，以及复杂的依赖间关系依赖管理案例：在线购物平台系统可能依赖于多个组件和库。平台核心：依赖于商品引擎、用户系统和支付系统。内部组件：商品引擎和用户引擎由团队自行开发；支付系统可能由同一公司的其他团队开发。外部依赖：三个核心组件都依赖于一个第三方开源Web框架。支付系统还依赖于第三方供应商提供的API。关键问题：Web框架和支付API属于外部依赖，其出现问题或版本更新时，团队难以控制其处理流程菱形依赖菱形依赖的定义：系统依赖于同一软件包的不同版本，形成菱形结构（如系统A依赖于B和C，而B和C依赖于D的不同版本）。在线购物平台的例子中，商品引擎可能依赖Web框架2.0.0，而用户引擎依赖Web框架1.1.0。风险：编译时可能通过，但运行时可能抛出ClassNotFound异常，因为系统可能加载了错误的版本菱形依赖菱形依赖的解决方案：多版本加载：允许系统同时存储并运行时加载同一软件包的不同版本（如Java的OSGi框架）。One-versionrule：对所有第三方的外部依赖，只允许唯一一个版本存在。大型科技公司（如谷歌）常采用此对策。升级内部依赖：如果依赖组件是内部团队负责，可以升级其中一个组件（如用户引擎）使其依赖于最新版本（如Web框架2.0.0）循环依赖定义：软件包A的构建依赖于B，同时软件包B的构建也依赖于A。风险：构建系统难以判断应先构建哪一个软件包（如Maven直接不允许循环依赖）。循环依赖临时对策：采用“构建阶梯”，通过错开版本，依次构建A的新版本和B的新版本，但未能消除循环。循环依赖永久对策：重新设计系统，将相互依赖的部分提取出来，形成一个新的独立组件C，消除A和B之间的循环依赖传递依赖定义：A依赖B，B又依赖C，形成依赖链条。风险：A不知道B依赖C，

且A使用了C中的接口；如果B在升级后删除对C的依赖，A可能会因此发生问题。传递依赖对策：引入“严格传递模式”(StrictTransitiveDependency)。构建系统检测到传递依赖时会构建失败。系统自动引入从A到C的直接依赖，从而杜绝上游依赖（B）删除依赖（C）导致A出错的风险依赖地狱(DependencyHell)随着软件规模的扩大，系统会形成一张异常复杂的依赖图，其中包含过长的依赖链条、局部的循环依赖或菱形依赖。团队应通过设计与重构等方法，有意识地避免“依赖地狱”的出现构建的最佳实践构建脚本即代码(Buildfileascode)将构建脚本视为代码进行编写、维护和版本控制。确保构建过程的可重复性、一致性、可追溯性，支持CI/CD流程。构建的触发策略需平衡频繁构建（持续集成）带来的好处与成本/风险。信任度原则：对内部依赖（高信任度）可频繁构建；对外部依赖（低信任度）应采取更保守的策略，如只在外部依赖发布稳定新版本时触发构建。智能化构建Dependabot自动扫描依赖项，检查新版本和安全漏洞，并创建PullRequest建议更新，大大简化了构建管理流程。AI智能构建:提议利用AI分析依赖在代码中的使用方式，评估版本更新的“破坏性”。AI能够自动生成或重构代码以适应依赖版本更新，并自动创建MergeRequest。如果测试缺失，AI还能自动生成测试，以供CI/CD流水线运行GitLab对智能依赖管理的提议5.3

软件文档版权所有©️仅限于教学使用软件文档软件文档是软件可维护性的关键，它提供系统结构、功能描述和实现细节，影响着软件的整个生命周期。读者类型软件文档的最终目的是供人阅读并提供信息。终端用户(EndUsers)直接使用软件完成任务或获取服务的个人或组织。关注点：了解软件的功能、操作方法、安装过程和常见问题解决方案。不关心背后的技术细节和实现方式。技术用户(TechnicalUsers)对软件内部技术细节与代码实现有了解与使用需求。开发者：软件自身开发团队成员，阅读文档以理解代码、新增功能、修复Bug和有效使用API。API使用者：不直接参与软件开发，但使用软件提供的外部API编写自己的服务，关注API参数、返回值、调用示例和异常处理。文档类型外部文档(ExternalDocumentation)-面向终端用户面向终端用户的文档：用户指南、教程、安装手册等，帮助用户快速上手。面向企业用户的文档：培训手册、标准操作程序(SOP)手册等，帮助IT人员管理和部署软件。即时支持文档：FAQ页面、故障排除指南等，在用户需要时提供快速解决方案。内部文档(InternalDocumentation)-面向技术用户行政文档：项目状态报告、会议记录等，用于管理团队和项目进度。开发者文档：提供构建和扩展软件的具体信息，指导开发过程。需求文档：描述功能、性能和非功能性需求。架构和设计文档：说明整体架构、模块设计、数据流程和交互逻辑，可能包含UML图。说明性文档：README、发布说明、Wiki页面等。API文档：详细描述接口名称、参数、返回值及错误处理。代码注释：帮助理解代码逻辑和实现细节，提高代码可读性。非常规文档：如测试用例描述的预期行为、清晰的提交信息（commitmessage）。编写高质量文档的挑战尽管文档重要性是公认的，但低质量文档（错误、不完整、过时）大量存在，是开发者工作中的主要挑战之一。2016年StackOverflow开发者调查中“ChallengesatWork”的反馈。“低质量文档”被认为是开发者日常工作中的第二大挑战。编写高质量文档的挑战编写高质量文档的挑战根本原因：没有时间和没有动力（文档不被视为绩效考核的一部分），导致写代码的优先级远高于写文档。“碎片化”问题(Fragmentation)文档与代码碎片化：文档采用扁平结构，与相关代码之间没有关联，难以搜索和定位所需信息。文档所有权碎片化：文档没有明确所有权，导致无法及时更新和修复。工具碎片化：开发者需要频繁从IDE切换到文档工具，中断工作流程，影响效率最佳实践：文档即代码“文档即代码”的理念是：像对待代码一样对待文档，将其纳入版本控制和质量监控。实现关键点：文档使用Markdown格式编写。文档和源码一起存储，文件路径结构与源码对应。文档和源码一起进行版本控制与问题追踪。采用了“文档即代码”最佳实践的项目结构示意最佳实践：文档即代码最佳实践：文档即代码TensorFlow项目的文档与代码一样进行版本控制最佳实践：文档即代码“文档即代码”的优势：降低技术门槛：Markdown简洁易用，开发者无需学习复杂标记语言。工具统一：Markdown文件在IDE中即可编辑，无需切换开发工具。紧密关联：文档与代码路径结构对应，方便查找和维护，确保文档内容与代码同步更新（1+1>2的作用）。解决碎片化：将文档纳入日常开发工作流，确保了文档的实时性、可追溯性、一致性、和质量。与CI/CD流程整合：“文档即代码”与“构建脚本即代码”是DevOps持续集成与持续交付的基础AI文档生成AI在文本生成与代码理解上的能力，使其在文档撰写方面具有巨大潜力。可以辅助生成：类或方法层面的文档：生成对方法的描述、参数和返回值的详细解释。代码块或语句的注释：解释代码在做什么并分析其意图。API文档和用户说明。研究表明，GPT-4等大模型的文档生成表现优于原始文档，开发者未来可先使用AI生成文档，再进行人工微调，大大减轻负担AI文档生成Cursor文档生成示例5.4

代码审查版权所有©️仅限于教学使用代码审查代码审查旨在发现缺陷、优化质量，并确保代码符合团队规范和设计原则代码审查是软件质量控制的第一道防线，通过同行评审发现潜在问题，与开发效率密切相关。代码风格确保团队成员遵循统一的编码习惯，避免代码库杂乱无章（如缩进、命名法）。命名规范：变量、方法和类的命名应清晰、直观，准确表达作用（如userAge优于a）。代码格式：如花括号的位置（K&R风格vs.Allman风格）。统一风格提高协作效率，使开发者专注于逻辑代码风格编程规范关注代码结构、变量作用域、异常处理等，减少低级错误，使代码健壮。资源管理：确保资源（如文件流）被正确关闭，避免资源泄露（如Java中的try-with-resources）。避免“魔法数”：使用常量替代代码中出现的未命名常量，提高可读性和可维护性。注释：应适度，最佳实践是编写“自解释代码”，通过清晰命名和结构表达意图逻辑正确性确保程序按照预期执行，是代码质量的核心。技术性错误：留意null引用访问、数组越界等边界情况，防止程序崩溃。业务逻辑错误：发现不易被编译器检测到的业务规则违背（如转账前未检查余额）。互补性：代码审查通过静态分析发现潜在设计缺陷和不合理逻辑，与软件测试（动态运行验证）互补，共同保障质量非功能性审查关注代码的效率和安全，在早期发现问题，避免进入生产环境。性能优化：检查低效算法（如O(n²)嵌套循环）、不必要的重复计算、未优化的数据库查询等。安全性：关注输入验证、身份验证和权限控制。检查敏感操作是否经过严格权限校验，避免硬编码的安全凭证代码审查的工作流程1.代码提交：开发者完成功能后，创建合并请求(PR/CL)，并应先进行自检。2.指派审查者：由经验丰富的开发者或代码所有者进行审查。3.阅读和分析：审查者检查逻辑正确性、可读性、可维护性、潜在性能和安全问题。4.提供反馈：反馈可以是具体代码建议，也可以是高层次的设计质疑。同时，审查也是重要的学习机会。5.修改与迭代：开发者根据反馈修改代码，与审查者进行多次迭代，直至问题解决。6.合并：所有问题解决并获得批准后，代码正式合并入库案例：Google的代码审查要求必须通过正确性与理解性检查（获得“LGTM”标记）。必须获得代码所有者(Owners)的批准，以确保与现有架构和设计理念匹配。必须通过可读性审查，由专门获得“可读性”资格的工程师进行。自动化代码审查静态分析工具：如SonarQube,Checkstyle,PMD，在代码执行前扫描，识别漏洞、重复代码、不必要的复杂度和规范违规。集成开发环境(IDE)：内置静态分析能力（如IntelliJIDEA），可识别未使用的变量、空指针路径等，实现及时修正。代码审查平台：GitHub,GitLab,Bitbucket集成审查功能，方便审查者直接在代码变更处添加评论。整合至CI/CD：通过配置GitHubActions等，使每次提交自动触发静态分析检查，不合格的代码直接拒绝合并，减少人工审查工作量智能化代码审查大模型驱动审查：如GitHubCopilotCodeReview，可以像人类审查者一样扫描代码更改和上下文，提供反馈意见和具体修改建议。定制化审查：用户可以通过自然语言描述的编码指南（codingguidelines）定制Copilot的审查，以符合项目特有的风格和实践本章小结AI可以在代码补全、代码生成、代码解释、代码审查、缺陷修复、测试生成、代码优化、以及软件文档生成等方面辅助软件开发。软件构建的本质是依赖管理与任务协调。其中，依赖管理对系统需要的第三方库、模块、框架、插件等制品进行下载、安装与配置；任务协调确保编译、测试、打包等任务按照正确的顺序和依赖关系执行。现代构建系统需要处理源代码、测试代码、数据文件、和配置信息等输入，以及第三方库与框架、工具等依赖。构建系统的输出包括可执行文件以及测试报告等软件工件，一般存储于制品仓库（ArtifactoryRepository）。构建系统可以分成基于任务与基于制品的两种类型，前者是命令式，后者是声明式。在基于任务的构建系统中，任务是构建的基本单元，用于执行某一指定的逻辑。同时，任务的依赖对象也是其它任务。Ant、Maven和Gradle等常用构建工具都属于此类型。在基于制品的构建系统中，使用者只需声明需要构建的制品，制品的依赖，以及有限的一些配置，具体的构建流程、配置、任务执行和调度则交由构建系统决定。Blaze和Bazel都属于此类型。本章小结语义化版本（SemanticVersioning,SemVer）使得开发者和用户可以更清晰地了解软件版本之间的差异，并且可以根据版本号的变化来判断是否需要进行更新和升级。在软件设计与开发过程中，团队应注意菱形依赖、循环依赖、依赖链条过长