ball_cao thinking in REST http://ball-cao.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 淘宝的花名和企业文化 ball_cao 作者: ball_cao  链接：http://ball-cao.javaeye.com/blog/157242  发表时间: 2008年01月18日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Jerry去了淘宝后给我打了几次电话。虽然谈论的话题多是技术、设计或敏捷开发的问题。但他总是会很自然的谈到淘宝的企业文化。Jerry是很少谈论自己工作的公司的人，也许是因为他以前呆过的几个单位都乏善可陈吧，但这次去淘宝不到一个月的时间，我已经可以清楚的感受到他作为淘宝一员的自豪感。“企业文化”这个词在管理领域就像“敏捷”这个词在软件开发领域一样。没有人不知道，没有人不向往，但很少有人做好了。
由于Jerry在我耳边佛念多了，所以我终于去查了一下马云的六脉神剑文化。所谓六脉神剑是指：客户第一、拥抱变化、团队合作、诚信、敬业、激情。从口号上说“六脉神剑”四个字比较响亮，其内容却是管理者们耳熟能详的一些词句。如果单说口号，华为的企业文化口号更为精炼有力，华为的企业文化只有一个字“狼”，在这个字背后体现出来的是团队合作、敏感的市场嗅觉、不屈不挠的斗志和始终保持的危机感。尽管华为是国内知名企业中我比较不欣赏的一个，但不得不说华为的企业文化也是营造的相当成功的。马云和任正非的共同特点是强势和有煽动力。也只有这样的人才能将一批有能力的人团结在自己的周围去完成一个艰巨的任务。淘宝是我欣赏的一个企业，华为则不是。但这两个企业的领导人马云和任正非都是我欣赏的人。我欣赏他们的能力，而不是价值观。说到价值观，我想马云和我的共同点更多一些，这也是我能够更欣赏淘宝这个企业而不是华为的原因。

从我个人的看法，用武侠小说的内容来命名企业文化多少有些儿戏。但是却很复合淘宝的特点。Jerry说玩也是淘宝的一个文化特性，在淘宝提倡把工作当作游戏。同时马云又是一个武侠迷，在淘宝每个人都要从武侠小说中的正面人物中为自己选择一个花名，据说马云的花名是风清扬。关于这一点，我不知道马云是如何界定正面和反面人物的，金庸的武侠小说中对正反人物有所颠覆的小说有两部，一部是天龙八部，一部是鹿鼎记。在天龙八部的最后我们看到身为正派人物的慕容复的所作所为甚至不如四大恶人。我甚至对四大恶人中的南海鳄神有些好感。金庸构造的南海鳄神更像一个莽汉而不是穷凶极恶的坏蛋。而其他三恶人中段延庆和叶二娘都是有凄惨经历的，社会的不公导致了他们的报复心态。而鹿鼎记则更是将一个市井无赖韦小宝作为主角。韦小宝不但无赖无耻，而且是一个在感情上有残疾的人，这样的人也可以算正面人物么？不过不论对错，淘宝的花名制度让每个进入淘宝的人都有了玩的心态，从一开始就宣传了一种文化。作为一种管理手段它已经达到目的了。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 18 Jan 2008 12:53:04 +0800 http://ball-cao.javaeye.com/blog/157242 http://ball-cao.javaeye.com/blog/157242 单元测试的投入和产出 ball_cao 作者: ball_cao  链接：http://ball-cao.javaeye.com/blog/155040  发表时间: 2008年01月11日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Jerry在晚上10点打电话过来，把即将进入梦乡的我召唤回现实。除了唠唠家常外，我们自然的又谈到敏捷开发的话题上来。这次谈话终于在单元测试的问题上让他了解并认同了我的看法。对于大多数的中国的软件开发团队来说，难以实现敏捷的最重要问题是人的素质问题。一个敏捷团队要求每个成员都有较好的OOP和OOD的能力。试想你正在努力的重构有坏味道代码的同时，你的team中却有另一个新手在不断的写出新的充满坏味道的代码会是什么样的后果？这是一个难以完结的循环，不是么？单元测试能带给敏捷什么帮助是我和Jerry一直最有分歧的地方。我承认，单元测试只是软件众多测试方式中的一种。静态的看，单元测试包括其他的测试方法需要付出的成本和雇用低廉的人力进行测试的成本相比可能还高一些。但单元测试能带给我们的帮助不仅仅是在重构过程中，保证对复用代码的修改不会波及其他的调用那么简单。通过编写测试，我们可以发现代码中结构的问题并优化之。当然这建立在团队成员对OO的认识基础上，OO能力不足的程序员遇到难以测试的代码时，往往不会想着或者没有能力去将它重构为方便测试的代码。这就给我们带来一个新的管理任务，也是敏捷过程强调的一个任务，那就是培训。我们需要不断的训练我们的程序员们，使得他们能够构造出敏捷的代码。而这正是一个团队能否实现敏捷的技术关键。
在谈话的最后，我们形成的共识是，实现敏捷是一个渐进的过程。构造一个在技术上有敏捷能力的团队有两种方法，一是用足够的钱去招聘有足够能力的程序员(大部分企业没有那么多钱)。二是将现有不符合敏捷技术要求的程序员培养为合格的敏捷工作者。而在培养的路上，单元测试正是一个很好的驱动方式和实践平台。
最后，希望看到这篇文章的人们，在衡量单元测试成本的时候，将他可能需要投入的培训成本考虑进去并切实的实施这些培训，也将单元测试能对团队技术水平的提高这部分产出考虑进去。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 11 Jan 2008 13:24:05 +0800 http://ball-cao.javaeye.com/blog/155040 http://ball-cao.javaeye.com/blog/155040 敏捷团队建设 读后感 ball_cao 作者: ball_cao  链接：http://ball-cao.javaeye.com/blog/148958  发表时间: 2007年12月17日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

看了已经锁定的一篇老帖子
http://www.javaeye.com/topic/90821
总的来说作者描述的图景我也是向往的，不过总感觉作者写这篇文章稍有些煽动年轻人离职的嫌疑。
我想看完这篇帖子原文的大多数程序员都会被这样的图景所吸引，而国内有这样条件的公司应该不多吧。所以大多数愤青们只能看完以后只能心里大骂目前的公司如何如何的不人性化等等。
其实我想作者应该更多的说说敏捷的软环境。敏捷是一个技术管理的工作，作者提到的这些敏捷行为模式只是实现敏捷目标的部分方式而已，除了这些在制度上其他的激励机制有哪些？在技术上为实现敏捷做了哪些工作？这些作者都没有说明，而敏捷的软环境才是更重要的东西也是更难掌握和实现的东西。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 17 Dec 2007 19:36:16 +0800 http://ball-cao.javaeye.com/blog/148958 http://ball-cao.javaeye.com/blog/148958 REST表象状态转移 ball_cao 作者: ball_cao  链接：http://ball-cao.javaeye.com/blog/141691  发表时间: 2007年11月19日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

决定采纳Jerry的建议结束在论坛中长期潜水的生涯

在javaeye的第一篇blog准备写点最近研究REST的感受

对REST的研究源于dlee等翻译的Roy Thomas Fielding博士的论文《架构风格与基于网络的软件架构设计》

这篇文章可以从http://docs.huihoo.com/rest/REST_cn.pdf下载

英文原版在http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

翻译的不错了，文章有些晦涩是因为博士的原版写得就比较晦涩，所以请观众们不要质疑dlee等的翻译功力

文中讲述了软件架构的不同风格，以及作者认为评估这些风格的一些重要指标。最后，作者介绍了REST风格的软件架构。

之前我总是将REST想象为一种编程标准，在这之后才理解了REST是一种软件架构风格，因此我们看不到一个严格的REST的框架定义。不过Rails2.0已经将对REST的支持做了很好的封装，未来我们的RoR程序员可以很方便的构建REST风格的Web应用了。

对REST的学习让我重新认识了Http。往常我们常常把http理解为一个传输协议，实际上http不仅仅是传输协议，也是一种对资源的操作契约。标准的http操作get、post、put、delete代表了对资源的CRUD操作。这也是REST所要求的资源组织和操作方式。

REST除了给我们带了了一种简单的资源组织方式，更简单的url以外。也让我们的服务器变得更为专注，专注于提供资源以及对资源的标准操作，而不是资源的表述。在Ajax和flash在浏览器客户端大行其道的今天，REST的出现为我们构建更清爽的服务提供了一种便利的方法。

当然，多年的业务系统开发，让我很快想到了REST在事务方面的问题。在这里几位做了一些关于REST的讨论，里面也有一点点关于事务的。http://www.javaeye.com/topic/82227?page=1

关于REST的事务性问题，我还没有做过具体的研究和试验，在今天无法做出什么好的评述。即使最终REST并不适合做业务系统，它也给我了一种新的架构设计的启发。


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 19 Nov 2007 13:59:15 +0800 http://ball-cao.javaeye.com/blog/141691 http://ball-cao.javaeye.com/blog/141691