That way I want to stay

这是我的个人主页，有兴趣的同学大家互相关注一下：
http://www.tuijianba.com/9889.html

最近一直在开发一款IDE，本来设计的目标只是一个单机版的客户端，不会连接任何服务端。后来用户突然加了一项需求，想要访问数据库，去查询一些数据。 其实这本来也不是什么怪异的需求，只是一种C/S系统而已。那时候刚听到这个需求的时候，马上想到的是，用hibernate, ibatis还是直接用JDBC。不如用ibatis吧，只需要查询几个表的几个字段而已，这一项刚好足够。 可是要增加数据库的支持时，心里特别的别扭，这款IDE的目标客户是遍布各个地方的，这一点就决定了，我们不可能用C/S的方法。 后来是在online system上加了一个web service，让这个IDE去调用。这样任何地方都可以访问这个服务了。 就算不论这一点，在考虑要用客户端直接连数据库的时候，心里面就像吃了蚂蚁似的，非常不爽。不知道是因为B/S系统做多了，还是因为觉得客户端直接连数据库本身就是一种不对的做法，总之现在已经有点不喜欢C/S结构的系统了，或者说，不喜欢客户端/数据库服务这样的系统。 不知道诸位程序员同
文章来源:http://blog.csdn.net/Wingel/archive/2007/01/25/1493585.aspx

 程序员有个偏好，那就是实现，他们喜欢把东西实现出来。这是一个优点，实现能力越强的人，一般编程能力也越强，我们也就可以说，他的技术越强。
　　但是喜欢实现却又是程序员的缺点，因为他们在实现一样东西的时候，经常会不想去理会其他的事情。比如说，程序员接到一项任务时，普通的程序员就马上会开始动手。稍微好一些的程序员则会仔细思考一下再动手。可惜，这样子也是程序员管理能力欠缺的一个原因。
　　当你的能力足够的时候，你应该懂得，把分配给你的任务计划一下，看看多久完成，如果你要把这个任务分块的话，尝试估计一下各个块的完成时间。不要因为担心预计得不准，就不去估计。因为有个计划给领导，绝对比没有的强。
　　开发经验逐渐增多的情况下，你已经有能力相对准确的计划自己的任务了。这时候你应该去找你的领导，把他今年可能会分配给你的任务看一下。这件事情很重要，因为你不做的话，你还只是一个程序员。因为你对自己的能力已经有了充分的认识，也能相对准确的估计你的开发进度了。你可以好好把今年的任务计划一下，把更新好的进度表给你的领导。因为他对你开发进度的估计，怎么样都没有你自己估计的准确。你能给一份计划，他会很开心。
　　现在，你已经有能力计划自己整年的开发情况了。
　　但是计划会改变。　　
　　我们要拥抱计划的变更！
　　你跟客户，或者负责需求的人熟吗？只有时刻掌握着需求的变化，才能时刻把握好自己的计划。
　　你跟QA熟吗？QA对你这个人开发质量的印象如何？清楚自己的开发质量，才能保证把事情做好的能力一直在进步。
　　你跟领导熟吗？你保证你做的事情领导都知道吗？你想做什么领导也知道？
　　你敢不敢说，所有跟你有关的情况，都尽在你的掌握？
　　会不会觉得这些很像空话，很不实际！
　　但是有做总是有好处的！
　　你做得越多，你越过程序员就越快。因为你不能，也不想只是单线程的程序员！

     前了阵子，做了个firefox下的插件，在了解它的插件运作的过程中，才发现，原来程序还可以是这样组成的。
    我们现在的所有B/S程序，UI上就是由HTML＋JavaScript组成的，而它这样的局限就是，这样的UI只能在浏览器上运行；而且它的UI会比较简单，不能像桌面程序中的一些效果。
    前面那个问题，其实很容易回答，大部分桌面程序也只能在Window上运行，大部分人都会装Windows，但是大部分人也都会装浏览器。
    而后面这个问题，就是我要说的内容了。Firefox里面所有界面上的布局，都是用类似于HTML的XUL语言生成的，它比HTML支持更多的UI，更方便的一些操作。
    当你发现，用HTML就可以构造出一个功能非常复杂的GUI时，当你发现光光html就可以做出一个Firefox那样的界面时，当你发现，Firefox这个平台上所有的程序都是由HTML组成时，这就是我的惊异了。
    当你发现，其实用HTML就可以做出所有的GUI程序时，这就是Moliza的思路了（其实NetBean的RPC中各个Plugin的UI的思路跟这个有点类似）。
    当你发现，你要打开一个程序，你只需要一个浏览器，打开一个网页，其余啥都不用做时，这就是Google的思路了。
    这就是我的感觉。
    而且我在做这个Firefox的插件时，我一直感觉我在用AJAX，其实AJAX的思路，最有价值的就是，UI上每次变更，不需要刷新整个页面，不需要 Reload整个UI，只需要变更它需要变化的部分，就像桌面程序一样。而你在用Firefox的时候，你会感觉到Firefox在刷新什么东西吗？

敏捷开发的必要技巧完整版.rar  或者 下载

链接： 第14章结对编程.rar   或者 下载

结对编程的好处：

联合两人的知识去对付一个难题。

知识互相传递。

更有效的查错跟纠错。

程序员都很开心。

减少员工离职的损失。

 

结对编程需要的一些技能：

用代码解释已有的设计结构。

用例子来解释。

用图表来解释设计思路。

如果你无法把你的设计思路表达清楚，把代码写出来。

让比较迷惑的搭档来写代码，这样他就可以较好的融入你的概念。

经常的休息。

经常的更换搭档。

具体内容请下载pdf观看。

下载地址： 第13章测试驱动编程.rar  或者  下载

TDD及它的优点

 

    上面这种编程的方式，就叫“测试驱动编程Test Driven Development (TDD)”，因为我们总是在写真正代码之前写一个通不过的测试，然后再写真正的代码，让测试通过。

    跟测试后行的开发方式相比，它有如下好处：

                                                      

    1.为了更容易的写单元测试，我们会广泛的使用接口（比如StudentRegistryChecker等）。这个会让单元测试代码很容易读跟写，因为测试代码里面没有多余的数据。如果我们不用TDD而是直接写实现的话，我们经常会使用现成的类（比如StudentSet），测试为了调用现成的类，就不得不创建很多多余的数据，创建很巨型的对象，就像Student或者Course。

   

    2.因为广泛的使用接口，我们的类之间就不会藕合（比如EnrollmentSet就一点都不知道StudentSet的存在），因此重用性更好。

 

    3.写单元测试的时候，很容易就可以为一个行为写一个测试用例，让它通过，然后为另一种行为写另一个测试用例。也就是说，整个任务会被划分成很多小的任务，独立完成。如果我们不用TDD而直接实现的话，我们很容易就会同时把所有的行为都实现了。这样花的时间长，而且在这相当长的时间里面，写的代码都是没有测试过，不能保证准确性的。相反的，用TDD的话，我们只实现要测的行为的代码。它只花费很少的时间（几分钟），而且可以马上测试。

到 第12章单元测试.rar  或者 下载   下载pdf。

    单元测试跟验收测试有什么区别？验收测试测试的是系统的外部行为，而单元测试是测试系统内部结构，它只测一个单元（类，甚至一个方法）。验收测试属于客户的，我们没有权利决定验收测试的内容。我们顶多只是帮忙客户根据用户例事写出验收测试。单元测试属于我们，因为系统里面有什么类，每个类都做什么，是由我们决定的。客户就没有权利涉及了，而且我们也不需要他的参与。我们只是根据我们对这个单元（类）的期望写出单元测试。因此，这种测试又叫“程序员测试”。

     摘要: 之前讲了怎么对代码进行验收测试，但如果代码跟UI相关的话，验收测试又要怎么写？  阅读全文

     摘要: 当你实现了一个用户例事（user story），你怎么判断你的代码是真正的，是用户真正想要的？  阅读全文

pdf下载地址：　第9章用CRC卡协助设计.rar
或者：　下载

摘录一些东西，具体请下附件观看：

因为在这些卡里面，我们写上了类名，它的职责，以及它的协作关系，我们管这样的卡片叫“CRC卡”。CRC就是Class，Responsibility和Collaboration的简称。

CRC 卡的典型应用　

为什么用CRC卡，而不用文档或者更先进的UML工具？

1. 卡片上面的空间很小，这样就可以防止我们给这个类太多的职责。如果一个类的职责太多的话（比如，超过4个），尝试以更抽象的方式去考虑一下，将职责划分。

2.CRC 卡主要是用在探索或者讨论类的设计的阶段。如果我们觉得这个设计不行的话，我们既不用修改文档，也不用修改类图，只要把卡片丢了就行了。此外，一旦设计完成，我们就可以把所有的卡丢了。它们不是用来做文档的。

   3. 如果我们觉得现在的卡片不合适，之前设计的比较好，我们只要简单的把之前的卡片拿出来组合就行了。

第 8 章 以用户例事管理项目

                                                 

什么是用户例事 (user story)

 

假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。

因此，我们的客户就是他们的市场经理。谈需求的时候，有一回他这样说：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。”

上面的话描述的是一件事情，一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。这样的过程就叫“用户案例 (user case) ”或者“用户例事 (user story) ”。也就是说，上面我们的客户所说的话，就是在描述一个用户例事（ user story ）。

( 我解释一下为什么用例事这个词，没兴趣也可以忽略。在一个系统面前，每个用户要完成同样的目标，都要做这个系统设定的例行的事，这件事情不是一个例子，所以不叫事例，这也不是故事，也不能算一段历程，而是一个例行的事。 )

　pdf下载地址：　第8章以用户例事管理项目.rar

具体pdf的下载地址：
分离数据库访问，UI和域逻辑

http://wingel.javaeye.com/topics/download/ce15b67a-1df7-4a75-8f03-1a505aca35d8

请从链接中下载，下面的内容只是摘要。

处理三种类别的代码都混在了一起：

   1.UI: JDialog, JTextField, 响应用户事件的代码。

   2.数据库访问: Connection, PreparedStatement, SQL statements, ResultSet 等等。

   3.域逻辑: 参会者的默认id，参会者的名字必填，所属地区的限制等等。域逻辑又称为“域模型”或者“业务逻辑”。

这三个不同类别的代码混在一起，会造成下面的问题：
1.代码很复杂。
2.代码很难重用。如果我们想创建一个EditParticipantDialog，让用户更改参会者的信息，我们就想重用部分域逻辑（比如，地区的限制）。但实现这部分域逻辑的代码跟AddParticipantDialog混在了一起，根本不能重用。如果是在一个web系统中，就更难重用了。
3.代码很难测试。每次要测这样的一段代码，我们都要建一个数据库，还要通过一个用户操作界面来测试。
     4.如果数据库表结构更改了，AddParticipantDialog这个类，还有其他的很多地方都要跟着更改。
5.它导致我们一直在考虑一些低层的太细节的概念，比如数据库字段，表的记录之类的，而不是类，对象，方法和属性这一类的概念。或者说白了一点，一直在考虑怎么往数据库里面装数据，而没有了面向对象的概念，没有了建立业务模型的思维。

因此，我们应该将这三种类别的代码分离开（UI，数据库访问，域逻辑）。        

下载：
http://www.blogjava.net/Files/Wingel/第6章处理不合适的引用.rar
or
http://wingel.javaeye.com/topics/download/afd36f87-a11b-4d18-a01b-a843092ec1bc

　　如果现在有一个类Parent，里面有个属性的类型是Child，add的方法里面还有个参数的类型是Girl：
　　class Parent{
        Child child;
 void add(Girl girl){
    ...
 }
     }
     因为上面Parent里面用到了Child跟Girl这两个类，我们就说，Parent引用了类Child跟类Girl。现在的问题是，如果Child这个类或者Girl这个类编译不过的话，那么Parent这个类也编译不了了。也就是说，Parent依赖于Child跟Girl。这章讲述的，就是因为一些类的依赖造成的无法重用的问题。

具体的内容在上面的下载链接里面的pdf文件里，内容较多。

或者点这个链接：

http://www.blogjava.net/Wingel/category/17919.html