GHawk

扩招的理由很简单，就是为了减少失业率，大家都变成学生去学校念书了，自然就不会有那么多人竞争工作岗位了。
至于4年后学生要毕业，要找工作的问题，那时领导们差不多也该换届了吧，就留给下一任的新同志去解决好了。

Sun在科技日上轰轰烈烈地宣传了一阵。
回来试了一下，果然比之前的版本强多了。

可以更进一步Refactoring到Interpreter模式，把switch(op)去掉，给扩展运算符提供支持。

Maven2 的profile filter功能相当好用，每个开发者可以使用自己的profile，而且很容易就可以实现不同的配置策略（debug, production）

BL层确实需要造很多DAO的Mock，开销巨大。
但这完全取决于后台采用什么样的架构。如果用POJO+O/R mapping来构造Domain Model的话，应该还是比较容易测试的，当然这样就要把BL的测试和mapping的测试分开了。
如果后台的BL采用Table Module这样的模式的话，写起测试来就比较累了，而且这样的测试代码对重构的支持不太友好。

@stoneshao
util.concurrent 的确有一个backport可以在1.4jvm上使用
http://dcl.mathcs.emory.edu/util/backport-util-concurrent

自己实现多线程的东西还是比较容易出现问题的，debug和性能分析都可能花费大量的时间，个人感觉还是用现有的库更容易一些。

Java 5开始内置的java.util.concurrent.locks包里面有pthread-like的Lock和Condition，很方便。

这样设计是不是更合适？？

class Test implement OPERATION
{
//定义操作对象
//private IOCObject obj;
private IOCINTERFACE obj; //---------------依赖接口而不是类
//public void Test( IOCObject obj)
public Test(IOCINTERFACE obj) //---------------依赖接口而不是类
{
this.obj = obj;
}
public void execute()
{
if(this.obj.validate)
{
//处理业务逻辑
System.out.println(this.obj.getUsername+"hello!");
}
else
{
//异常日志
System.out.println("MB~~~给的什么数据啊~~我叼!")
}
}
}
////////////////////////////////////////////////////////////////////////////////分割线////////////////////////////////////////////////////////////////////////////////////////
/*万事具备了,借东风吧!*/
public class Main
{
public static void main(String[]args)
{
//做个东风先
//IOCObject obj = new IOCObject ();
IOCINTERFACE obj = new IOCObject(); //---------------依赖接口而不是类

obj .setUsername("KenIT");
//依赖注入了,高兴啊!
Test test = new Test(ob);
//完成工作,打完收功
test.execute();
}
}

另外，由接口的实现者来决定接口上的参数，再扔给接口的消费者，未免霸道了些吧，不是很符合DIP。

今天刚刚到手。
随便翻了翻，的确是本很棒的书。
第一印象就是这本书应该被列入软件或计算机专业的教科书书目中。

这就好比法规、制度，它存在，但是依然可以违反它。
文档提供了一个做事的准则和流程，声明了一些大家都应该知道和遵守的东西。如果一个人连明文规定的东西都无法理解和遵守。那怎么指望他能够仅仅通过沟通就能遵守团队的行动准则，成为团队的一员呢？应该是很有难度的吧。

文档是UP进行过程控制的手段，XP用来解决过程中采用的是“沟通”。文档的适用范围更普遍一些 ，“沟通”虽然便利，但是会受到很多条件的限制。从UP到XP，可以明确知道哪些文档从“文档”变成了“沟通”；从XP到UP，却很难把所有的“沟通”转化成“文档。”这是因为文档的成本通常比沟通来得高。

Pair Programming（结对编程）吧

XP应该是对老板、客户、开发人员来说三赢的开发过程。
当然，要实施好XP并不是简简单单的程序员个人能力的问题了，从上倒下、从内到外还有一个体制的问题需要解决，更深一层，还有文化上的问题，毕竟XP是强调团队的。

我们的项目也正为测试的问题而焦头烂额。对OO的误解和缺乏接口设计，导致无法写出简单清晰的单元测试，现在的单元测试成了Bottom-Up的集成测试，而且在测试系统异常捕获逻辑的时候无能为力……

这就不太清楚了，这方面的资料和宣传确实很少。
在www.eiffel.com上有一些客户应用Eiffel的成功案例。可以参考一下。

可能现在大规模采用DbC还有些问题：
1. 设计的代价过高。对于很多设计师来说要设计出DbC的OO系统，需要很多的学习和经验。验证设计出来的契约也相对比较复杂。
2. 执行的开销过大，毕竟，在运行时每验证一个Contract就要多消耗一些机器资源。（但是我认为使用DbC所带来的可靠性比起这些开销是值得的。）
3. 缺少语言层次的直接支持。Java的assert关键字还只是个语法糖而已。不过随着AOP的普及，相信在这方面很快会有突破的。

可以参考一下这篇文档 http://www.iturls.com/Articles/doc/XP_Value.pdf
XP也具有一定的局限性。Agile Process也并不只有XP而已，可以试试其他的过程。有了实践和总结，应该会有提高的。

的确有投机之嫌，说敏捷过程的东西太少了，就几章而已。^_^

To Samuel Cai,
说的有道理。
写的时候一直在斟酌哪样的例子比较合适，因为OCP相当抽象，所以选出好的例子很难，要说明一定要以某种模式实现OCP很困难，我的这个例子有点类似书中OCP那章一开始那个Client/Server的例子。不过，要举出违反OCP的例子倒是不少。最典型的就是通过RTTI（运行时类型鉴别）+ switch 或是 if-else 来进行设计。这样的用法越多，封闭性就越差，模块的刚性也就越强。OCP主张在设计中采用多态等动态机制取代静态机制。当然，通过配置文件的方式进行模块的动态配置也是实现OCP的一种手段。

UP和Agile都是工程过程实践的总结，林德彰先生说过“UP是正楷，XP是草书。先学好了UP，才能学好XP；先学XP再学UP就会乱套。”
Agile强调的是“代码是真正有价值的东西。”这同样也是实践的结果。二位对于过程有不同的看法并不能说明孰是孰非，这只是在不同的实践内容和阶段上的总结。在过程的选用问题上，只有不断地实践才是前进的方向。

越是需要操作的灵活性，对象映射的对象性自然就会下降。这样倒不如不用ORM，直接写JDBC和SQL，但是这对整个系统的架构会产生很大的影响。要指望Mapping和持久层没有性能损失是做不到的。就像吃海鲜，你越是要新鲜的海鲜，就越要放弃复杂的加工和运输手段。这个问题的解决可能不是ORM能够胜任的，或许更大程度上依赖于数据库系统。
软件设计是一种trade-off，技术本身没有优劣之分。工程师所要做的就是如何把各种技术融合到一起。性能或是对象性操作的获得也遵循这一原则。

^_^加油！

就是Martin C的那本^_^

现在的越来越像是用面向过程的方式开发的了，OO的踪迹越来越浅了。也许是因为我没系统地用过C,或是我用不好面向过程方法，我觉得非OO的设计正在把这个系统变得越来越丑陋。（我没有贬低面向过程方法的意思，好的面向过程设计应该也有它优美之处吧^_^）大家花费时间和精力写出来的代码没有什么重用性可言。大家在设计上下的工夫太少了……

读书笔记一直没开始写。究其原因，这本书实在写得太贯通了，OO的五大原则都是相互牵扯的，设计模式也是综合运用的。读书心得颇多，而整理归纳需要花些时间。既然决定要做，就该认真去做，不会敷衍了事的。

我本来在制造业，转行转了两年，才转到软件行业。对工作看得很穿了。应届毕业生，对社会的了解不多，当时找工作也很盲目。我想，当时，无非就是希望找个既能学到东西又能赚到大钱的公司，次一级么，只能赚到钱或是只能学到东西也行。虽然，最后进了一个公司赚钱不算少，但是做的事情实在是…… 感觉自己的青春就这样浪费了，于是往外跳。因为是转行的，没什么实际经验，IT现在抢饭碗的人又多。投出去的简历一度没有结果。曾经怀疑自己这样坚持是否有意义。直到今年，情况才渐渐好转，群硕、花旗都给了我offer，但最后都没有选择去那里。现在在一家小公司，因为觉得现在的老板不是一个浮躁的人，并不是趁着IT红火的时候来卷钱的“商人”。最后，我明白了自己的需求：不是快速赚大钱，而是好好利用青春时光，充实自己的阅历，牢固自己的基础，做自己喜欢的事情。

对于应届生，最重要的是清楚自己真正想要的，可以是钱，是知识，是健康…… 无论做什么事，之前请先明确目的，再制定计划实施。可能后来很多事会跟你想象的不同，但是请你在心中牢记自己选择，坚定地去实践。道路可以不同，但是目标不应该偏离。

在这样的一个团队中开展xp是比较费力。我觉得XP倒不是要个人能力怎么高，而是团队的平均水平比较一致，水平低就一块儿低，水平高就一块儿高，这样用于沟通和理解的花费就比较小了。
另外，测试也很重要，XP的快速原型迭代依赖于优良的测试案例。也是迭代得以推进的必要条件。

在Agile的实施方面有没有比较好的Guide？
请高手多多赐教！