That way I want to stay

BlogJava 首页 新随笔 联系 聚合 管理
  55 Posts :: 1 Stories :: 41 Comments :: 0 Trackbacks

2006年12月1日 #

这是我的个人主页,有兴趣的同学大家互相关注一下:
http://www.tuijianba.com/9889.html
posted @ 2009-07-31 23:14 Wingel 阅读(134) | 评论 (0)编辑 收藏

最近一直在开发一款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
posted @ 2007-01-26 05:17 Wingel 阅读(247) | 评论 (1)编辑 收藏

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

     前了阵子,做了个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在刷新什么东西吗?
posted @ 2007-01-21 13:07 Wingel 阅读(2720) | 评论 (8)编辑 收藏

敏捷开发的必要技巧完整版.rar  或者 下载
posted @ 2006-12-16 09:50 Wingel 阅读(1610) | 评论 (12)编辑 收藏

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

结对编程的好处:

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

知识互相传递。

更有效的查错跟纠错。

程序员都很开心。

减少员工离职的损失。

 

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

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

用例子来解释。

用图表来解释设计思路。

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

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

经常的休息。

经常的更换搭档。

具体内容请下载pdf观看。
posted @ 2006-12-14 21:25 Wingel 阅读(1058) | 评论 (0)编辑 收藏

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

TDD及它的优点

 

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

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

                                                      

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

   

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

 

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

posted @ 2006-12-11 16:50 Wingel 阅读(1115) | 评论 (0)编辑 收藏

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

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

posted @ 2006-12-09 10:01 Wingel 阅读(999) | 评论 (0)编辑 收藏

     摘要: 之前讲了怎么对代码进行验收测试,但如果代码跟UI相关的话,验收测试又要怎么写?  阅读全文
posted @ 2006-12-08 21:21 Wingel 阅读(1051) | 评论 (0)编辑 收藏

     摘要: 当你实现了一个用户例事(user story),你怎么判断你的代码是真正的,是用户真正想要的?  阅读全文
posted @ 2006-12-07 11:17 Wingel 阅读(1368) | 评论 (0)编辑 收藏

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

摘录一些东西,具体请下附件观看:

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

CRC 卡的典型应用 

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

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

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

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

posted @ 2006-12-05 10:51 Wingel 阅读(1210) | 评论 (0)编辑 收藏

8 以用户例事管理项目

                                                 

什么是用户例事 (user story)

 

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

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

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

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

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

posted @ 2006-12-04 11:28 Wingel 阅读(1466) | 评论 (0)编辑 收藏

具体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,数据库访问,域逻辑)。        

posted @ 2006-12-01 16:16 Wingel 阅读(1113) | 评论 (0)编辑 收藏

下载:
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文件里,内容较多。

posted @ 2006-12-01 09:28 Wingel 阅读(975) | 评论 (0)编辑 收藏

或者点这个链接:

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

posted @ 2006-12-01 09:22 Wingel 阅读(355) | 评论 (2)编辑 收藏