XP准则12条

2001-05-24 11:19:00 300 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

Gazebo仿真UUV水下机器人：从环境搭建到避障算法实战本文详细介绍了使用Gazebo仿真平台进行UUV水下机器人开发的全流程，涵盖从环境搭建、uuv_simulator配置、传感器集成到核心避障算法实战。通过搭建水下仿真实验室并实现基于激光雷达数据的反应式避障算法，为水下机器人算法验证与开发提供了高效、低成本的解决方案。阅读详情

12条XP准则

1.三步定计划: Business and development cooperate to produce
the maximum business value as rapidly as possible. The
planning game happens at various scales, but the basic
rules are always the same:

Business 罗列想要的系统功能特征. 每个特征写成一个使用情景,
起一个名字, 大致描述需要完成的事. 这通常写在4x6卡片上.

Development 估计每个情景所需工作量, 及本小组在一定时间内可
完成的工作量(the iteration).

Business 决定哪个情景要先完成, 以及系统发布的频率和时间.

2.尽快尽早发布: 最小功能满足即发布. 尽可能频繁发布, 每次加少
量改进.

3.系统命名: 每个项目有一个有组织的命名方式, 这使名字容易记住.

4.最简设计: 需求明天会改变, 只完成今日的需求即可.

5.随时测试: 增加功能特性之前先写测试代码. 组件运行时,测试也
已经完成. XP中的测试分两步.

单元测试是自动测试,由开发人员在设计时完成,用来测试功能. 通
常测试单个类, 或一小组类. 常在一个单元测试框架(如JUnit)
下写成.

接受性测试(功能测试) 由用户指定,测试整个系统功能. 通常测试
整个系统, 或其中大部分. 对于一个特定使用情境若所有接受
性测试均通过, 该使用情景即开发完成. 至少, 接受性测试包
含一个可人工运行的测试脚本(其中包括用户接口操作和期待
的响应). 理想情况下应当自动完成, 使用单元测试框架或一个
分离的接受性测试框架.

6.去处冗余代码: 任何有重复代码的部分重新考虑,改写. 有测试作
为保证. (Once and Only Once)

7.成对编程: 所有代码由两个程序员在一台机器前完成. 基本上, 所
有代码在写出的时候被评审.

8.代码共有: 个人不"拥有"模块. 任何开发人员都可以对代码任何部
分改动.

9.随时集成: 所有改变最迟当天集成进代码库. 在集成前后100%运行
测试.

10.按时回家: 在最紧急的时刻允许加班,但持续时间不得超过一个星
期. 长期超时工作表明过程失控.

11.即时客户交流: 开发小组和一个真实的客户随时联系. 对于有众
多客户的商业软件, 由一个虚拟客户(常为产品经理)替代.

12.统一编码标准: 所有人遵循同样标准编码. 理想情况下，由代码
本身无法判断作者是谁.

...全文