在一个博客上摘抄了几个片断，感觉从中还是可以汲取一些经验的
原文：http://jgyhuzhou.itpub.net/
想学学python
===========================================================
觉得python还是不错的，比起Java来要灵活的多，很早就看过了，也学了一阵子，但是没有好好写过像样的东西，前阵子看到用Python写的客户端软件，没想到它做界面还这么好，和delphi差不多了，也许这也是一个方向。
AJAX来也！
===========================================================
这东西现在是一下子火了起来，开源库如雨后春笋般出现，看来够热闹一阵子了。
js这种语言，写一些小东西校验之类的很不错，在没有调试器的情况下把界面展现完全交给它，总还有点不放心啊。想想每次在ie上调试js的痛苦经历，要是界面都这样调出来，还不死人啊。
当然如果有一个非常成熟的跨浏览器的js库出现，也许有前途，但它不应该取代jsp，struts。只能作为jsp的补充，比如在一些需要无刷新更新页面，树状菜单等等。
对C++的感情
===========================================================
不知怎么搞的，总是对c/c++有一种很深的感情，到现在还是时不时的想用c++来写程序，有一种想好好学习c++的冲动。可能是在学校的时候学的比较多，总是有感情的，可是工作后却一直没机会做这方面的工作，不能不说是一种遗憾。
最近经常时不时拿出c++的书来翻一翻，应该来说，我的面向对象的知识全部是来自c++的，很多好的想法也是都来自c++。在我看来，c++是现在最完美的语言！
真正在用心看问题的人
===========================================================
前几天到It公司速查手册上看了看大家对我们公司的看法，当然是一片嘈杂，有人喝彩，有人抱怨，各种偏激的看法都有，但有一个人的留言给我留下了深刻印象：
“xx的主要问题是没有一个明确的问题域和解决域的对象建模，压根就没有走面向对象的路子，所以对流行的技术的迁移和应用都非常的痛苦。”
能看到这个问题的人，不多，很多人把一些新技术的应用看的很重要，以为用了新技术就能解决当前的问题了，迂腐的程序员，我见得太多了，中国软件业的发展不如人意，很大程度上和程序员这个群体的缺乏思维深度有关。
领域建模
===========================================================
最早是在Craig Larman的《UML AND PATTERNS》中看到这个概念，我的理解是通过领域建模可以对业务逻辑有一个全面，整体的理解。业务分析只能是将业务规则简单的罗列出来，将一些特殊的业务规则重点描述。而领域建模则是通过整体的建模将大家对业务规则的理解都融合到这个模型中，便于知识的共享，也便于大家的交流。
如果再继续的抽象提炼，那就是Martin Fowler的《分析模式》了。
在我看来，这是很重要的部分，标志着一个软件公司对自己所服务领域的专业程度。然而我却没发现什么公司有这一东西。确切的说，我们现在所做的项目，只不过是用程序语言将业务规则的逐条描述，没有提炼，没有抽象。这恐怕也是项目和产品的差别了。
很多公司都希望通过项目能培育出产品，美好的愿望，实现者却几乎没有，为什么呢？我想根本的还是在于两者的开发方式完全不同，要跨越其中的鸿沟需要艰辛的努力，如果每次都只是将规则简单复制，而不去发掘其中的规律和抽象，那就算做十几二十的项目恐怕也难。
Code Review
===========================================================
Code Review 是一件很有意义的事情，能提高代码的质量。但如果流于形式，就没什么意思了。
1、如果一个人本身就有比较多的开发任务，然后要抽出时间来review别人的代码，那review的质量就会差很多，谁都会把开发新功能的优先级排在code review之前。
AOP将会有蓬勃发展
===========================================================
最近好像AOP越来越火爆，看来这项技术很有前途，不过我现在对它还一无所知，需要好好的了解一下。
我们的重构
===========================================================
最近重构一词风靡一时，改代码都不叫改代码了，叫“重构一下”。但实际的情况是：我们的工作方式并没有改变，我们还是和以前一样的修改代码，在没有听说重构这个词之前，我们就这么做了。我们并没有按照Martin Fowler所说的那样，一小步一小步的进行，大量的test case，每做一小步就运行一下test。我们的做法是，大手笔，没有一个test case，一气呵成。而奇怪的是，我们居然也成功了，当然有时候会引入不少的bug，可最后总会成功的。
那是不是表示Martin Fowler说错了呢？或者是他们太小心，太蠢了？刚开始我也觉得那些重构步骤太过啰嗦，有点婆婆妈妈，后来仔细思考一下，似乎觉得不是那么回事，《重构〉一书的第三章专门列出了各种代码的bad smells，我想这是关键，先发现代码中的bad smell ，然后应用各种重构手法来消除之，但是最后会是什么样，代码是什么样子，重构的人并不是一开始就知道的，这是在重构的过程中逐渐清晰的过程，所以才需要一小步一小步，才需要频繁测试。
再来看看没有测试的大踏步的重构，实际的情况是，我们在重构开始前就想好了结果，哪个类要去掉，哪个方法要去掉，就好比重写了一遍代码，并不是从发现bad smell开始的，或者干脆是因为要加入新功能而必须修改代码，既然已经知道要到哪儿去了，当然也就没有必要在路上慢慢探索，小心翼翼了，直接一个大跨步就到了共产主义了。
老外做事情讲究过程，包括思维的过程，通过理清楚过程，发现其中的不足之处，改进过程，这是一种方法，像cmm,xp都是这样的思路。我们往往只重结果不重过程，为达目的不择手段，当然最后也会完成任务，却往往难以有持续的改进。领导们经常说的一句话是：我不管你怎么做，反正你要做出来。这样的领导当起来是容易的。我们不仅要把一件事情做好，还要明白我们为什么能做好，为什么不能做好，如何做的更好，哪儿可以做的更好，这些都需要对做事的过程进行观察，分析。
单元测试
===========================================================
一直以来就没有写单元测试的习惯，学习了java之后，知道了有unit test，有junit工具，但也仅仅是了解了一下，没有在工作中实际使用。前段时间读了kent beck的《测试驱动开发〉，里面提到的两点好处给我的印象深刻：1、先写测试可以在写代码之前就考虑供别人调用的接口，从而比较容易设计出简洁易用的用户接口；2、当你有一个非常完备的测试集之后，对程序的任何修改都会非常的放心，改了一个地方之后，运行一下test case就知道别的地方是否受影响了。
前段时间写一个程序时因为业务逻辑比较复杂，决定将业务逻辑独立出来测试，也是为了实践一下单元测试，使用之后对上面说的第2点好处是深有体会。程序在修改之后很容易引入一些意想不到的bug，而且很多很难发现，如果在修改了一个逻辑之后，能马上知道它会影响哪些地方，错误会少很多，毕竟很多时候不能单纯靠人的记忆。同时还存在修改别人的程序的问题，这时候有单元测试就更保险了。
虽然有很多好处，但是实际使用起来还是有很多麻烦之处，首先，测试主要针对的是业务逻辑层，对数据层和表示层，测试起来会麻烦很多，也不是很有必要，当程序中三层的隔离不是很清晰时，测试就会很麻烦。其次，类与类之间的耦合太高时，要想单独的测试一个类的函数就会很麻烦，就算你用easymock这样的工具来隔离，写起来也会比较麻烦，而且测试效果也不好。
要想比较顺利的使用单元测试，在我看来，需要很好的面向对象功底，首先在设计时要注意一些问题：1、分层要彻底，这一点看起来简单，不值一提，实际上却很难做到，至少在我看到的很多程序框架中，这一点做的都不怎么好，表示层和业务层的耦合，业务层和数据访问层的耦合都会在不经意中引入，需要格外的小心，不是说你用了struts或者webwork,hibernate你就彻底分层了，还有很多细节需要你去关注。而单元测试反过来也可以帮助你正确的分离，这是一个相互促进的过程。2、在设计业务类时要注意相互之间的关联，职责的正确分配，达到高内聚，低耦合，只有这样的类才是容易测试的，如果你发现一个类的方法太简单，毫无测试的必要，那你就要考虑是不是该remove它了，或者一个类也一样，如果你发现一个类的方法有很多功能，你需要写很多测试，那就要考虑是不是该把该方法拆分了，这一切又牵涉到重构了，所以xp中很多的best practice是相辅相成的。
前几天看过一点spring框架的资料，感觉对单元测试的支持比较好，你只需要写一些pojo就好，类与类之间的关联通过get和set来设置，这样做单元测试就会非常方便，现在像ejb这样的组件测试太不方便，要打包，部署，很麻烦，测试的速度也会慢很多。