MyHouse

1> 每1m地毯
材料费用： 79 = 19底 + 60上
人工费用： 50

Maven生命周期及常用命令学习

一、 常用命令
mvn archetype:create
创建 Maven 项目
mvn compile
编译程序源代码，不编译test目录源代码。第一次运行时，会下载相关的依赖包，耗时较长。
mvn test-compile
编译测试代码，compile之后会生成target文件夹，主程序编译在classes下面，测试程序放在test-classes下。
mvn test
运行应用程序中的单元测试
mvn site
生成项目相关信息的网站
mvn clean
清除目标目录中的生成结果
mvn package
依据项目生成 jar 文件，打包之前会进行编译，测试。
mvn install
在本地 Repository 中安装 jar。
mvn eclipse:eclipse
生成 Eclipse 项目文件及包引用定义，注意，需确保定义Classpath Variables: M2_REPO，指向本地maven类库目录。
mvn eclipse:clean
清除Eclipse项目结构

二、 Maven的生命周期及其与之对应的命令：
validate:验证工程是否正确，所有需要的资源是否可用。
compile:编译项目的源代码。
test-compile:编译项目测试代码。
test:使用已编译的测试代码，测试已编译的源代码。
package:已发布的格式，如jar，将已编译的源代码打包。
integration-test:在集成测试可以运行的环境中处理和发布包。
verify:运行任何检查，验证包是否有效且达到质量标准。
install:把包安装在本地的repository中，可以被其他工程作为依赖来使用
deploy:在整合或者发布环境下执行，将最终版本的包拷贝到远程的repository，使得其他的开发者或者工程可以共享。
generate-sources:产生应用需要的任何额外的源代码，如xdoclet。

三、 调用maven
语法示例：
Mvn plugin:target [ -D选项1 –D选项2 分隔符]
Mvn help
Mvn –X …

四、 生成项目
1、 建一个 JAVA 项目 ：
mvn archetype:create -DgroupId=com.demo -DartifactId=App
2、 建一个 web 项目 ：
mvn archetype:create -DgroupId=com.demo -DartifactId=web-app -DarchetypeArtifactId=maven-archetype-webapp
3、 生成 Eclipse 项目
普通 Eclipse 项目执行 ： mvn eclipse:eclipse
Eclipse WTP 项目执行 ： mvn eclipse:eclipse –Dwtpversion=1.0

4、 Maven 标准项目结构：
目录 说明
/new-app/pom.xml Maven2项目文件
/new-app/src 源代码
/new-app/src/main/java Java代码树
/new-app/src/test/java Java单元测试
/new-app/src/main/resources Java classpath
/new-app/src/test/resources 单元测试资源
/new-app/target/classes 项目输出目录
/new-app/target/test-classes 项目测试输出目录
/new-app/target/dots 其他插件输出
/new-webapp/src/main/webapp Web应用目录

五、 编译项目的源代码：
Mvn compile
六、 单元测试/代码覆盖率计算：
Mvn test
七、 打包（jar，war）：
Mvn package
编译，单元测试，物件打包，并将不需要的文件丢弃
八、 安装：
Mvn install

安装第三方jar包到本地库
Mvn install:install-file –Dfile=foo.jar –DgroupId=org.foosoft –DartifactId=foo –Dversion=1.2.3 –Dpackaging=jar

九、 清理：
Mvn cleanup

十、 POM文件：
1、 添加依赖：

Junit不会被打包

hotswap 用户手册

关于hotswap(该补丁的网址http://ssw.jku.at/dcevm/)

Hotswap 是一个允许在运行状态下无限制的修改加载类文件的Java虚拟机补丁。当前java虚拟机的动态加载机制只允许修改类的方法体,而打了hotswap补丁以后，可以增加，删除类属性，方法，甚至可以改变一个类的父类。

Hotswap补丁是基于GPL v2.0开源协议的。你可以通过windows，linux，mac os下载hotswap 补丁的源代码或者可执行文件。

安装hotswap

警告: 该补丁目前还处于试验阶段. 当该补丁用于调试java程序使用是，是相当稳定的。但我们不提倡在生产环境中使用该补丁。

现在提供了 32位, 64位 Windows虚拟机, 32位 Mac OS的 (从这里获得), 和32位 Linux 虚拟机的补丁. 所有的修改基于 JDK7-b102版本。

安装程序

• dcevm-0.2-win.jar (5.6 MB)
• dcevm-0.2-mac.jar (6.0 MB)
• dcevm-0.2-linux.jar (5.8 MB)

该补丁不仅能打在java7上，且打到java 6上，也一样正常工作。

在windows 启动安装程序，在控制台输入:
> java -jar dcevm-0.2-win.jar

在Mac OS启动安装程序，终端输入:
$ sudo java -jar dcevm-0.2-mac.jar

在Mac OS启动安装程序，终端输入:
$ sudo java -jar dcevm-0.2-linux.jar

安装程序会替换掉java下 bin/client/jvm.dll 和 bin/server/jvm.dll ，并将以后的jvm.dll备份到相应目录下。还会将dcevm.jar 加到lib/ext/ 目录.

图一：hotswap补丁安装界面。

执行上述命令后，就会出现图一界面，选择将要安装该补丁的java目录，单击安装就可以了。

Ps:如果你的Linux没有图形界面，您可以从这里下载已经打好补丁的java。

使用hotswap调试java程序

1. 首先用修改后的java以debug模式启动 java程序。
2. 使用eclipse连接到该java进程(也可以直接在eclipse中以debug方式启动)
3. 现在在eclipse 工程下面针对class文件的任何修改将会直接反映到java程序中去。

hotswap在淘宝

令我们高兴的是，淘宝开发人员对该技术有着强烈的兴趣，目前已有如下团队使用的该补丁：Mytaobao开发团队，TDDL（Rtools）开发团队，HSF开发团队，交易中心等团队。

我们期待你的加入。

Ps:如果你使用HSF_JETTY插件，你只要通过升级就hsf_jetty，不用手动安装，就可以使用该patch。我们并会在接下来实现spring，webx配置文件的不重启动态替换。尽情期待。

高质量软件，从点点滴滴做起

写这篇文章的想法产生在昨天晚上读《面向对象分析与设计》的时候，我渐渐发现我们这个小组不知不觉地贯彻了很多非常有价值的实践经验，这些点点滴滴都对我 们的最终的产品质量产生了或大或小的影响，保证我们的系统不会出现重大的故障。我想有必要将这些“隐性知识”稍微总结一下，以供参考和记录。

从过程的连续光谱来看，我们大概处于中间位置偏左的位置，更偏向一个轻量级团队的敏捷过程，但是也包含计划驱动过程中的因素。我们的小组是自管理的，没有 专门的QA和SA，我们自己去想出最好的工作方法，但是在执行中我们的计划还是相对确定的，每个季度做什么都会有一个比较明确的计划和里程碑，并且对问题 领域都相对熟悉；我们的过程是迭代式，一般一个季度至少会交付一个稳定可执行的新版本，我们在文档上做的不是特别好，很多都依赖于团队成员之间的“隐性知 识”；同时我们对问题的改进基本还是有一个流程和机制，会持续的跟踪问题并改进。

下面分阶段总结下我们的一些实践经验。

一、分析和设计阶段

1、在这个阶段，我们会明确准备做什么，界定问题的边界，对功能进行一个取舍。一般在一个版本完成之后会马上开始这个过程。大家都想一想接下来做什么，经过几轮PK后确定重要紧急的事情优先做，定义下一个版本的功能列表。

2、功能列表出来之后，我们会针对每个功能提出各种方案做比较，在此期间，我们会邀请更大团队范围内的专家参与方案和设计的评审，剔除不切实际以及明显有缺陷的方案，针对一些风险点提出改进建议和防范措施。

3、在设计方案出来之后，我们会分配功能的开发任务，根据每个开发人员熟悉的领域，自主领取或者被动分配任务。这个过程不是一成不变的，考虑到团队内部知识交流的必要性，也可能让不熟悉某个领域的人去做他不熟悉的事情。

二、构造阶段

1、整个系统已经有一个关键的抽象机制，针对我们的服务器有一个核心的pipeline机制，针对我们的客户端，有一个核心的发送消息流程。将所有的功能模块组织在这个关键机制周围，形成一个强有力的整体。

2、开发完成不仅仅意味着功能代码的完成，还包括测试代码：单元测试和集成测试。如果你没办法做到全面的覆盖，那就要求必须覆盖运行的关键路径和极端场景。

3、单元测试我们使用JUnit，适当使用Mock可以简化测试。但是Mock对象如果太多，也许会失去测试的价值，这里有一个权衡。

4、在整个构造过程中，我们贯彻每日构建、持续集成的原则。使用hudson做持续集成，时刻关注测试状况，有问题及时反馈给开发者。

5、有一个功能强大的集成测试框架，模拟实际环境做各种测试，它的目的是尽量在接近真实状况下去执行系统并尽早暴露问题。

6、每个功能完成之后，立即发起review，请同事和你一起复审代码。复审代码的作用不仅是发现bug，改良设计，也是一个知识交流的最佳途径。我们经常能通过代码审查发现一些设计上的缺陷，以及功能实现上的BUG。我们团队应该说是非常看重代码审查的作用。

7、使用findbugs和clover等工具，分析代码质量并改进。

8、在发布之前，做一次集中的代码review，每个人介绍下自己的功能实现代码和设计，一般我们会申请一个会议室和投影仪，并邀请团队之外的人加入review。

9、在发布之前，有一个系统的压测流程，针对每个版本更新压测方案，并预留一到两周的时间做性能压测。压测不仅能尽早暴露性能隐患，还可以发现系统在特殊情况下的一些BUG。压测除了关注系统的吞吐量、GC情况之外，还应该关注硬件的性能指标。

三、发布和总结
1、发布之前，最好让使用我们系统的用户使用新版本做一个回归测试，一方面是测试兼容性，一方面也可以及早发现BUG。

2、我们的发布流程：线下、beta、线上。每个阶段通常都持续一到两周，才会进行到下一阶段。并且是从相对不重要的系统，到关键系统的顺序进行发布。

3、发布之后，通过日志、运行时监控、用户反馈等方式收集系统运行状况，发现BUG，修正BUG，补充测试，测试通过，重新发布。

4、每个版本发布后，需要总结下本次发布过程中遇到的所有BUG以及经验教训，并提出可能的改进建议。

5、需要一个跟踪线上问题的BUG跟踪系统，可以用JIRA之类的trace软件。跟踪不仅是记录，最好列出解决的时间点，在哪个版本确定解决，甚至确定交给谁去解决，并持续跟进。