Published on 2009年03月9日
学习JAVA的过程中，最让我郁闷的恐怕就是接口这个东西了。这个Interface，一度让我觉得是个鸡肋，看清楚，是鸡肋不是基类。在我一直的意识中，OO就是抽象，继承，再抽象，再继承。而这个接口在我看来无非是一个继承的替代品，一个多重继承的替代品。
可以为什么，我们要做接口而不是直接实现多重继承呢，JAVA开发组毕竟不是傻的。我带着疑问询问了google和还有一些前辈。
interface，可以说是class的类别，也可以说是对class的定义的一种规范。把不同的对象放到不同的接口里面，然后更好的管理它们。是一种对对象的抽象。
抽象这个词在这里额外的重要。其实对于继承来说，继承的意义也并不是完全在于我想要复用代码，而是在抽象。假设我们有类A里面有一函数run，类B也想用这个方法。于是有些人就class B extends A，这样的做法是不经过大脑的。其实我们有办法来实现而不造成更大的负担，比如：
class B {
function run() {
A a = new A();
A.run();
}
}这种想要靠继承来完成代码复用的思想可以说是对继承的滥用，而Java取缔多重继承实际上也是在制止这样的滥用继承，体现更好的设计模式。实际上，当我们想要去抽象对象的行为，而不考虑对象的本身属性的时候，我们就应该使用接口来处理对象与对象直接的通信。
另外，接口还能帮助我们更快的开发，而不用在父类与父类之上在建立一个父类，从而面对多级继承带来的负担。比如我们这时候要描述一个吃东西的行为。我们只需要有这样的一个接口。
interface eat {
function go() {}
}这时候我们就不用去考虑是人还是狗，是黑人还是白人，吃东西前会做祈祷还是会先喝汤，即便他是个火星人，即便他吃饭前会玩一次躲猫猫，只要你觉得它要吃东西，那么你就让他使用这个接口，然后具体的实现它。这样如果我们把这些类的实例化放到一个工厂里，就能更好的体现出一个接口的抽象化。
Published on 2009年03月4日
关于敏捷开发，这已经不是一个新词了，我第一次听到敏捷开发这个名词的时候已经是好几年前。可是最近我才真正的开始关注和学习敏捷开发的思想。
首先，敏捷开发是一种针对人的以人为核心的开发模式，这是一种循序渐进的开发模式。他强调的是人与人之间的交互，而不是工具或者其他的流程。它有完整的开发团队，扁平式的，工程师与工程师之间，工程师与项目经理之间直接进行沟通。它把系统划分为若干个尽量小而简单的模块。它要求团队所有成员所做的事情都只是恰到好处。它甚至觉得我们应该拥有一个更好的沟通模式和流程控制，然后抛弃文档，因为文档会耗费大量的时间。
我们需要持续的向客户或者产品设计人员提交版本来让它了解进度并随时给出修改意见，这样做能避免更大程度的返工，也更能在不停的使用中进行测试，找出不尽人意的地方。
进度的控制很重要。进度是保持开发持续性的一个重要因素。而开发持续性是敏捷开发在代码质量控制的过程中的重中之重。
我们需要更好的架构和需求设计。更好的架构能保证模块与模块之间的解耦性，能减低模块之间的影响。而需求设计的完整能让工程师更清楚自己该做什么。
只做到恰到好处。完成所有客户提出的或者是产品设计人员提出的需求，然后仅此而已。保持开发速度，增强单位时间工作的实用性。
我们还需要，经常在一起开开小会，说说遇到的问题，然后改进。
总之我们的目标就是要刚刚好。
同时敏捷开发也存在他自身的不足：
1. 对于那些优先级不明确或者需求不明确的项目难以开展。
2. 团队的建设成本较高。这一点大部分来自于人的问题。人是有缺点的。比如人容易疏忽，犯错误，人宁愿自己写而不愿意改(我就是这样的人)，人有时候还难以保持一个优良的状态。于是我们要对团队进行不断的培训，培养，有时候还要设立很多规矩，比如不要随便打扰别人。
3. 当团队有新人进入或者有老人退出时，这一切都将变得很艰难。
其实敏捷开发，就像是一个美好的许愿，无论是公司老总，项目经理，还是工程师，对于敏捷开发都抱有不同程度的幻想，但是它真的那么容易实现吗？
Published on 2009年03月3日
我是个十足的台球爱好者。而自认为技术不错只是状态不稳定，嘿嘿。我也很喜欢写程序，至少以前是，虽然现在我更多把他看作是一种工作。但是我窃以为打台球与写程序是有相同相通之处的，如下。
架构思维
我们都知道打台球的时候要注意下颗球的走位，而且这个过程中你通常还得让这个走位更适合你在击打下一个颗球之后的连续击打。对于美式黑八，高手们通常都在开球之后就观察局面，布置战术流程，每颗球怎么走走到哪里。
在写程序的时候这个通常叫做架构思维。实际上在一个团队里，架构思维是很重要的。当你处在一个team work，你的每一个工作每一个项目都在不同程度的为你的团队、团队的其他成员以及你开发的系统服务。在一个较大系统的开发中，如果不注重架构，便会出现以下情况：1. 牵一发而动全身，当你要改动你的代码的时候你不得不去关注其他各种系统的异常，加大其他开发工程师和测试工程师的工作量，严重时可能会引起众怒。2. 一处不干净的代码可能拖慢整个系统，往往是这样，在你coding的过程中出现了一些状态，比如太困，昨天喝太多，晚上有个多年不见的美女约你心神不定盼着加班，你提交的代码可能会有那么一点两点不太干净的地方，他会消耗一些不应该被消耗的系统资源，增加了那么一点点的系统压力，这时候也许只有良好的架构才能稍微的暂时解救你，以致你在manager发现之前有足够时间完成修改。3. 架构的好处还有很多很多，它还会帮助你减少你的代码量，它有时还会帮助你处理进程的异常跳出，让你把更多的时间放在Controller层，去实现更多的功能。总之，好的架构就能带你上天堂，不好的架构就只能带你去住套房了。
稳定的心态
我说我自己经常觉得自己的状态不好，丁小晖在之前也经历了一个状态低迷期。某高人说，实际是央视的台球解说说，从业余高手到职业高手的一道重要的标准就是稳定的状态。而这个稳定的状态来自于心态。
程序员也需要稳定的心态，程序员有时候是需要高强度工作的，如果没有良好的心态，往往会觉得厌倦，特别是当你遇到一个不算难但是很繁杂的问题的时候，心态就发挥作用了。所以我觉得，平静的面对每一个问题，平静的处理每一个问题，是有技术的程序员到有经验且有技术的程序员的一道重要的标准。不急不躁就能写出更多优秀的代码而不至于出一堆人品问题，也会减少第一部分第二条所描述的问题的出现几率。
保持自己的技术领先
打台球是需要不断的学习技术和保持自己的技术领先的，即便你是个职业高手，打台球保持自己的精准度以及不断提高处理出杆时角度把握的精确是最重要的，只有你做到了才能赢得更多的胜利。
程序员在这一点上也是毋庸置疑的。就一个web程序员而言，从最初的CGI到Perl/PHP，到Java，再到Ruby等，各个时期都在流行的不同的技术。而且这个时期都很短。虽然基础是相当重要的，但是保持自己的技术革新也是相当重要的。不光是语言上的更新，还有自己的思维能力。有经验的程序员之所以能成为有经验，不应该是因为做过更多事情，遇到过更多异常情况，处理过更多的报错，而应该是比菜鸟们更懂得思维的诀窍，能更快更周密的进行思维。说到提高，程序员应该提高的还有与人交往的能力，与人交往并不是市场部门才有的专利，它对于技术人员也相当重要，与同事更好的交流能够协助你在工作中更好的与各部门进行协作，降低工作的难度，与其他人交流能够帮助你得到更多的信息，听到更多对事情的看法，学到更多能让你飞跃的知识。
Posts