??xml version="1.0" encoding="utf-8" standalone="yes"?>
http://www.tuijianba.com/9889.html
]]>
文章来源:http://blog.csdn.net/Wingel/archive/2007/01/25/1493585.aspx
]]>
我们要拥p划的变更Q?br /> 你跟客户Q或者负责需求的人熟吗?只有时刻掌握着需求的变化Q才能时L握好自己的计划?br /> 你跟QA熟吗QQA对你q个人开发质量的印象如何Q清楚自q开发质量,才能保证把事情做好的能力一直在q步?br /> 你跟领导熟吗Q你保证你做的事情领导都知道吗?你想做什么领g知道Q?br /> 你敢不敢_所有跟你有关的情况Q都在你的掌握Q?br /> 会不会觉得这些很像空话,很不实际Q?br /> 但是有做L有好处的Q?br /> 你做得越多,你越q程序员p快。因Z不能Q也不想只是单线E的E序员!
]]>
]]>
]]>
l对~程的好处:
联合两h的知识去对付一个难题?span lang="EN-US">
知识互相传递?span lang="EN-US">
更有效的查错跟纠错?span lang="EN-US">
E序员都很开心?span lang="EN-US">
减少员工职的损失?span lang="EN-US">
l对~程需要的一些技能:
用代码解释已有的设计l构?span lang="EN-US">
用例子来解释?span lang="EN-US">
用图表来解释设计思\?span lang="EN-US">
如果你无法把你的设计思\表达清楚Q把代码写出来?span lang="EN-US">
让比较迷惑的搭档来写代码Q这样他可以较好的融入你的概念?span lang="EN-US">
l常的休息?span lang="EN-US">
l常的更换搭档?span lang="EN-US">
TDD及它的优?span lang="EN-US">
上面q种~程的方式,叫“测试驱动编E?span lang="EN-US">Test Driven Development (TDD)”,因ؓ我们L在写真正代码之前写一个通不q的试Q然后再写真正的代码Q让试通过?span lang="EN-US">
跟测试后行的开发方式相比,它有如下好处Q?span lang="EN-US">
1.Z更容易的写单元测试,我们会广泛的使用接口Q比?span lang="EN-US">StudentRegistryChecker{)。这个会让单元测试代码很Ҏ(gu)读跟写,因ؓ试代码里面没有多余的数据。如果我们不?span lang="EN-US">TDD而是直接写实现的话,我们l常会用现成的c(比如StudentSetQ,试Z调用现成的类Q就不得不创建很多多余的数据Q创建很巨型的对象,像Student或?span lang="EN-US">Course?span lang="EN-US">
2.因ؓq泛的用接口,我们的类之间׃会藕合(比如EnrollmentSet׃炚w不知?span lang="EN-US">StudentSet的存在)Q因此重用性更好?span lang="EN-US">
3.写单元测试的时候,很容易就可以Z个行为写一个测试用例,让它通过Q然后ؓ另一U行为写另一个测试用例。也是_整个d会被划分成很多小的Q务,独立完成。如果我们不?span lang="EN-US">TDD而直接实现的话,我们很容易就会同时把所有的行ؓ都实C。这栯的时间长Q而且在这相当长的旉里面Q写的代码都是没有测试过Q不能保证准性的。相反的Q用TDD的话Q我们只实现要测的行为的代码。它只花费很的旉Q几分钟Q,而且可以马上试?/span>
因ؓ在这些卡里面Q我们写上了cdQ它的职责,以及它的协作关系Q我们管q样的卡片叫?span lang="EN-US">CRC卡”?span lang="EN-US">CRC是ClassQ?span lang="EN-US">Responsibility?span lang="EN-US">Collaboration的简U?span lang="EN-US">
CRC
卡的典型应用
Z么用CRC卡,而不用文档或者更先进?span lang="EN-US">UML工具Q?span lang="EN-US">
1.
卡片上面的空间很,q样可以防止我们给q个cd多的职责。如果一个类的职责太多的话(比如Q超q?span lang="EN-US">4个)Q尝试以更抽象的方式去考虑一下,职责划分?span lang="EN-US">
2.CRC
卡主要是用在探烦或者讨论类的设计的阶段。如果我们觉得这个设计不行的话,我们既不用修Ҏ(gu)档,也不用修改类图,只要把卡片丢了就行了。此外,一旦设计完成,我们可以把所有的卡丢了。它们不是用来做文档的?span lang="EN-US">
3. 如果我们觉得现在的卡片不合适,之前设计的比较好Q我们只要简单的把之前的卡片拿出来组合就行了?/span>
什么是用户例事
(user story)
假定q个目的客h个饮料自动售货机的制造商。他们要求我们ؓ他们的售货机开发一ƾY件。我们可以找他们的市场经理了解这个Y件的需求?/span>
因此Q我们的客户是他们的市场经理。谈需求的时候,有一回他q样_“用户往售货机每塞一个硬币,售货机都要显C当前该客户已经投了多少钱。当用户投的钱够买某一N料时Q代表这N料的按钮的灯׃亮。如果那个用h了这个按钮,售货机就放一|饮料到出口Q然后找雉l他。?/span>
上面的话描述的是一件事情,一件用户通过pȝ完成他一个有价值的目标Q买一|饮料)的事。这L(fng)q程叫“用h?/span> (user case) ”或者“用户例?/span> (user story) ”。也是_上面我们的客h说的话,是在描qC个用户例事( user story Q?/span>
(
我解释一下ؓ什么用例事q个词,没兴也可以忽略。在一个系l面前,每个用户要完成同L(fng)目标Q都要做q个pȝ讑֮的例行的事,qg事情不是一个例子,所以不叫事例,q也不是故事Q也不能一D历E,而是一个例行的事?/span>
)
pdf下蝲地址Q W?章以用户例事理目.rar
然后在要验证的Form里面加个属性validatable=true,如下Q?br />
注意Q这边不要加onsubmitҎ(gu)
接下来,好了,比如说有个输入框Q?br /><ww:textfield name="name" id="name"/>
我想验证Q让它必填,如下可以了Q?br /><label for="name" validate="required">请填写名U?lt;/label> 其中 for属性里面填的要是验证的输入框idQvalidate填的是验证方?;label里面的文本就是验证不q的时候要昄的信息?br />如果我想验证一个输入框的输入值长度怎么办,q样子就行了
后面的参数用Q号隔开Q验证的Ҏ(gu)名跟参数? 隔开?br />wingel.js里面已经包括了一些常用的验证Ҏ(gu)Q现在问题来了,如果要自定义验证Ҏ(gu)怎么办,如下办:
比如你想加个验证Ҏ(gu)是hello
则label里面的validate属性写成hello,
然后加一个JavaScriptҎ(gu)Q?br />
里面三个参数,shit , couldn't input Chinese. now English will be used.
The first parameter is the value of the input element you want to validate,the second one is the validated element, the third one, is the parameters you add in validate label, the last one, is a utility class, you can invoke its method to make your code easier.
菜单生成:struts-menu,q有自己做的JavaScript控g.
l计?jfreechart
MVC框架:Mytapestry(每次改个界面都要重启服务?,Webwork,Struts
持久?hibernate,ibats
XML解析:dom4j比较易用,臛_代码可以比较z?但是如果要在里面传输二进制文件的?比较麻烦了.|上有两U方?一U是二q制用BASE64~码成字W串,或者在MINI头里面传?后者这方式我还不懂要怎么?前者那L(fng)?除了用Base64以外,直接用十六进制{字符串会更快,不过安全嘛~
日记功能:log4j,其实Java关于日记功能的好像就?U包,但是好像q个比较好用.另外直接用Logger.getLogger()生成logc?
ajax:dwr可以利用JavaScript讉KJavac?它会自己JavaҎ(gu)q回的类序列?转换成JavaScript变量;dojo则是有很多特?/p>
Web service:axis 的Web service不错,不过如果排除那些规范的话,自己做一个轻量的会更实在
工作?目前没有了解哪开源的,但是一直想了解
XML装:SOAP是XML的一U协?而且利用J2EE提供的api,可以很方便的操作附g,再?臛_规范的Web service是用SOAP传递消息的.
惌用模板的?Velocity,至于不明白什么时候用到这U情늚?可以参考一?a >www.blogcn.com中的模板更改q道了
全文搜烦:lucene,它会把关键字索引存在文g?而不是数据库,不过x数据库不也是把数据存在文件中?lucene的速度比较?而且易用.刚开始也不明白ؓ什么lucene会那么快,后面了解到是个博士做的这个开源包,呵呵,看来人家是有很精q法.
hibernate的session理:利用U程ID的帮助来理该线E的Session,好像大家现在也都是这样子?
事务理:spring有一好处就是这个了.而且听说它的JTA理也很不错
业务层和DAO层的bean理:spring很好?不过是每个Bean都要写在配置文g?当然,有h喜欢,有h不喜?,如果不想写配|文件中的话,p己写工厂理Bean?我相信会比spring快一?但是spring写在配置中这h点好处就?如果你想把某个接口的实现cL掉的?改一下配|文件就可以?
动态bean理:JMX,其实自己也可以写E序来管理内存中的bean或者把bean属性放在配|文仉面的,JMX是多加了一层规?Jboss的JMX机制很方?真的叫热插拔了.
消息机制理:JMS,q项我也只是看了些例子而已,q没在项目中应用q?
d调控:quartz,不明白什么是d调控?你想一?比如你想在每天的某一个时间执行一些操?比如定时更新数据库中的某些数据啦.当然数据库系l也有这U功?但是如果想用E序来控制的?q它吧.不好的地方就是文档太了,上回Z搞明白它怎么用的,源代码就M好久.
重量U的东西:EJB,q个??...............................?sh)信金融行业的可能觉得这东西很重?不过我们?׃说这东西?没有发言?
现在的框枉有一个理?那就是可配置,M东西都要可配|的.struts的配|啦,hibernate的配|啦,spring的配|啦,ibats的配|啦.但是有个有东西冒出来?rails on ruby,它有个理?是"?fn)惯优于配?quot;,你不明白?x,自己最好什么东襉K不用配置,一切根据用L(fng)?fn)惯定制?当然,q样对于开发是非常方便?而第二个方便的地?是代码自动生成(脑v里突然想?net?!
说到代码自动生成的话,提一个xdoclet:要用q个的话,得先了解一下ant,xdoclet是个很有用的东西.不过我比较俗,我就是用它生成一个业务层或DAO的实现类和接口类代码.如果Java惌有跟Rails on ruby一L(fng)东西的话,一定要用到xdoclet来了
其实现在也有一个框?它号U是Java中的Rails on Ruby,那就是JdonFramework?上回看了?没啥感觉,没有Rails on Rubyl的震憾?/p>
验证码的生成:是在输入页面A中嵌入一个生成验证码的页面B,B里面有Java代码,生成随机字符?再把字符串存入Session?
Oracle:一直识别不了本地服务。后面才发现Q是tnsnames.oraq个文g中,有的版本不支持SERVER_NAMEQ而只是支持SERVER?/p>
有想q访问dll文g?有个东西叫JDI,步骤ȝ了点的东?/p>
处理囄:sun公司有个开源Y件jimi,是个不错的东?处理囄的开源包有很多种,我那时候ؓ什么选了jimi也忘?好像是因为格式支不支持的原因?
PROPAGATION_MANDATORY:
Indicates that the method must run within a transaction. If no
existing transaction is in progress, an exception will be thrown.
PROPAGATION_NESTED:
Indicates that the method should be run within a nested transaction
if an existing transaction is in progress. The nested transaction
can be committed and rolled back individually from the enclosing
transaction. If no enclosing transaction exists, behaves like
PROPAGATION_REQUIRED:
Beware that vendor support for this propagation behavior is spotty at best.
Consult the documentation for your resource manager to determine if nested
transactions are supported.
PROPAGATION_NEVER:
Indicates that the current method should not run within a transactional
context. If there is an existing transaction in progress, an
exception will be thrown.
PROPAGATION_NOT_SUPPORTED:
Indicates that the method should not run within a transaction. If an
existing transaction is in progress, it will be suspended for the
duration of the method. If using JTATransactionManager,
access to TransactionManager is required.
PROPAGATION_REQUIRED:
Indicates that the current method must run within a transaction. If
an existing transaction is in progress, the method will run within
that transaction. Otherwise, a new transaction will be started.
PROPAGATION_REQUIRES_NEW:
Indicates that the current method must run within its own transaction.
A new transaction is started and if an existing transaction is in
progress, it will be suspended for the duration of the method. If
using JTATransactionManager, access to Transaction-
Manager is required.
PROPAGATION_SUPPORTS:
Indicates that the current method does not require a transactional
context, but may run within a transaction if one is already in
progress.
Isolation levels:
In a typical application, multiple transactions run concurrently, often working
with the same data to get their job done. Concurrency, while necessary, can lead
to the following problems:
?Dirty read—Dirty reads occur when one transaction reads data that has
been written but not yet committed by another transaction. If the
changes are later rolled back, the data obtained by the first transaction
will be invalid.
?Nonrepeatable read—Nonrepeatable reads happen when a transaction performs
the same query two or more times and each time the data is different.
This is usually due to another concurrent transaction updating the
data between the queries.
?Phantom reads—Phantom reads are similar to nonrepeatable reads. These
occur when a transaction (T1) reads several rows, then a concurrent transaction
(T2) inserts rows. Upon subsequent queries, the first transaction
(T1) finds additional rows that were not there before.
Isolation level:
ISOLATION_DEFAULT:
Use the default isolation level of the underlying datastore.
ISOLATION_READ_UNCOMMITTED:
Allows you to read changes that have not yet been committed. May
result in dirty reads, phantom reads, and nonrepeatable reads.
ISOLATION_READ_COMMITTED:
Allows reads from concurrent transactions that have been committed.
Dirty reads are prevented, but phantom and nonrepeatable
reads may still occur.
ISOLATION_REPEATABLE_READ:
Multiple reads of the same field will yield the same results, unless
changed by the transaction itself. Dirty reads and nonrepeatable
reads are prevented by phantom reads may still occur.
ISOLATION_SERIALIZABLE:
This fully ACID-compliant isolation level ensures that dirty reads,
nonrepeatable reads, and phantom reads are all prevented. This is
the slowest of all isolation levels because it is typically accomplished
by doing full table locks on the tables involved in the transaction.
我用了一q的旉,从工?>Ҏ(gu).我很?但我又清醒的知道我要E稳的走!唉~
"实现"的欲望是E序员出w的通病.无论是从l构?q是模式?那是l节.
做着做着的时候,发现Q咦Q好像这表得增加一个字D|行,增加了,然后所有查询的SQL语句加一下,所有insert跟update的代码修改一下,面修改一下,嗯,现在应该正常了,看v来倒是没什么问题,咦,报表好像不怎么对啊Q靠Q这边还有调用这个表的代码,妈的Q改吧改吧。磨y了好几个小Ӟ当然Q熟l的话,q不用几个小ӞQȝ看v来都正常了?/p>
q一回,q个功能中有一ơ用戯求,讉K了好几次数据库,不行Q这里应该用个cacheQ否则性能上会有问题啊Q算了,用算法解决一下,量访问数据库好了Q我对cacheq不熟呢。(写啊写啊QBatch SizeQ这样多Q那样多QFetch Size。。。,l于Q看h正常一些了Q。过了一D|_靠,q边又要讉K好几ơ数据库QYa的受不鸟了,性能爱咋的咋的,反正一个地Ҏ(gu)又不要紧。Oh shit!!!q边也是好几ơ,q边又是好几ơ,那边又是好几ơ。不行了Q我老老实实写个cache支持吧,于是又叮叮当当了好几天,l于Q有个粗p的cache出来了,l于速度可以看一些了。后来改q又改进Q测试又试Q篏MQ老子好不爽啊?/p>
好像天下有点太^了,啊,你说我这个地方忘记更C增加的那个子表啊Q算了,没关p,我明天看一下代码,q个Ҏ(gu)解决炏V嗯Q我改了那边的代码了Q会更新子表信息了。什么?你说取主表的记录跟相应的子表记录列表ȝ啊,没关p,我更C下处理resultset的公共模块,明天再说?br /> Oh shit......对这样子复杂的查询好像现在的公共模块支持不了啊,了Q这样子的查询不要用q个公共模块Q我们手动写一些代码好啊,别跟我讲q样代码l构很难看,你以为我不知道啊QTMD?/p>
TMD的,怎么q边的SQL老是q行不了啊,不会是分底层模块的问题吧,靠,怎么你的SQL语句有这么多order,group byQ靠Q还有top啊,q当然过不了了,不要吵了Q现在时间改Q不理它Q直接用个假分页p了。你又说代码l构隄Q小心我抽你哦?/p>
公司新来一个程序员Q看了几天代码,不停的抱怨说Q这代码写得真差啊。。。。。?nbsp;
PROPAGATION_MANDATORY:
Indicates that the method must run within a transaction. If no
existing transaction is in progress, an exception will be thrown.
PROPAGATION_NESTED:
Indicates that the method should be run within a nested transaction
if an existing transaction is in progress. The nested transaction
can be committed and rolled back individually from the enclosing
transaction. If no enclosing transaction exists, behaves like
PROPAGATION_REQUIRED:
Beware that vendor support for this propagation behavior is spotty at best.
Consult the documentation for your resource manager to determine if nested
transactions are supported.
PROPAGATION_NEVER:
Indicates that the current method should not run within a transactional
context. If there is an existing transaction in progress, an
exception will be thrown.
PROPAGATION_NOT_SUPPORTED:
Indicates that the method should not run within a transaction. If an
existing transaction is in progress, it will be suspended for the
duration of the method. If using JTATransactionManager,
access to TransactionManager is required.
PROPAGATION_REQUIRED:
Indicates that the current method must run within a transaction. If
an existing transaction is in progress, the method will run within
that transaction. Otherwise, a new transaction will be started.
PROPAGATION_REQUIRES_NEW:
Indicates that the current method must run within its own transaction.
A new transaction is started and if an existing transaction is in
progress, it will be suspended for the duration of the method. If
using JTATransactionManager, access to Transaction-
Manager is required.
PROPAGATION_SUPPORTS:
Indicates that the current method does not require a transactional
context, but may run within a transaction if one is already in
progress.
Isolation levels:
In a typical application, multiple transactions run concurrently, often working
with the same data to get their job done. Concurrency, while necessary, can lead
to the following problems:
?Dirty read—Dirty reads occur when one transaction reads data that has
been written but not yet committed by another transaction. If the
changes are later rolled back, the data obtained by the first transaction
will be invalid.
?Nonrepeatable read—Nonrepeatable reads happen when a transaction performs
the same query two or more times and each time the data is different.
This is usually due to another concurrent transaction updating the
data between the queries.
?Phantom reads—Phantom reads are similar to nonrepeatable reads. These
occur when a transaction (T1) reads several rows, then a concurrent transaction
(T2) inserts rows. Upon subsequent queries, the first transaction
(T1) finds additional rows that were not there before.
Isolation level:
ISOLATION_DEFAULT:
Use the default isolation level of the underlying datastore.
ISOLATION_READ_UNCOMMITTED:
Allows you to read changes that have not yet been committed. May
result in dirty reads, phantom reads, and nonrepeatable reads.
ISOLATION_READ_COMMITTED:
Allows reads from concurrent transactions that have been committed.
Dirty reads are prevented, but phantom and nonrepeatable
reads may still occur.
ISOLATION_REPEATABLE_READ:
Multiple reads of the same field will yield the same results, unless
changed by the transaction itself. Dirty reads and nonrepeatable
reads are prevented by phantom reads may still occur.
ISOLATION_SERIALIZABLE:
This fully ACID-compliant isolation level ensures that dirty reads,
nonrepeatable reads, and phantom reads are all prevented. This is
the slowest of all isolation levels because it is typically accomplished
by doing full table locks on the tables involved in the transaction.
那么在事务A中,query1跟query2查询出来的结果是否一样呢Q这p事务隔离U别有关了?br />SQL的标准定义里面,一共有四种U别Q?br />read uncommitedd未提交的数据 是其他事务求提交的数据Q都可以d出来
read commitedd已提交的数据 query2会跟query1d的数据不一?br />repeatable read可重复读取,即query1跟query2d的数据是一L(fng)
serializable 序列化,
SQL 标准用三个必dq行的事务之间避免的现象定义了四个别的事务隔离?q些不希望发生的现象是:
脏读Qdirty readsQ?br /> 一个事务读取了另一个未提交的ƈ行事务写的数据?
不可重复读(non-repeatable readsQ?br /> 一个事务重新读取前面读取过的数据, 发现该数据已l被另一个已提交的事务修改过?
q读Qphantom readQ?br /> 一个事务重新执行一个查询,q回一套符合查询条件的行, 发现q些行因为其他最q提交的事务而发生了改变?
隔离U别 脏读QDirty ReadQ?nbsp; 不可重复读(NonRepeatable ReadQ?nbsp; q读QPhantom ReadQ?br />L提交QRead uncommittedQ?nbsp; 可能 可能 可能
d提交QRead committedQ? 不可能 可能 可能
可重复读QRepeatable readQ?nbsp; 不可?nbsp; 不可?nbsp; 可能
可串行化QSerializable Q?nbsp; 不可?nbsp; 不可?nbsp; 不可?/p>
SQLServer
我们首先在SQLServer上做了实验,SQLServer一共支持四U隔ȝ别,read uncommited跟read commited我们没有实验Q我们直接先实验
repeatable readQ如果事务A定义了如下别,那么当事务B执行到modify1q条语句Ӟ如果modify1是update的话Q就被锁hQ一直等
C务A提交完以后,锁才会被释放Q而如果是insert的话Q刚可以利q行下去Q然后在事务A中,query2查到的数据,是已l被事务B
修改q的数据Q如果将U别定义在serializable的话Q则在modify1语句中,update,insert或者delete都会被锁掉?br />也就是说QSQLServer对这些别的支持Q是通过锁来做到的,虽然可以保证事务正常q行Q但是ƈ行的性能却很差?br />Oracle
oracle只支持两个别,read commited跟serializableQ结果这里就不用详细说明Q实验的l果是,oracle的serializable是通过版本
控制来完成的Q而不是通过锁机Ӟq就保证了ƈ行的性能。Oracle的默认别是read commited
MySQL
MySQLServer也支持四个别,而且MySQL也是通过版本控制而非锁机制来完成的?br />