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。

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