幻象和敏捷

92 views
Skip to first unread message

ozzzzzz

unread,
Nov 23, 2012, 4:17:31 AM11/23/12
to agile...@googlegroups.com
“敏捷的开发速度快。”我已经不是第一次听到这个说法了,每一次我都会对这个事情做解释,但是每次对方都觉得我多余解释,很不耐烦的去做其他事情了。这个事情从10年前我开始用agile这个词汇开始做推广的时候就开始了,只不过今天几乎我遇到的每一个新来的敏捷者都在说:“敏捷就是速度快啊!”我觉得一个头脑正常的软件从业人员就不该有这个想法。不管这个人年纪多大,地位多高,身份多显赫都应该被开除出这个行业。

《没有银弹》,这篇文章我曾经用一个晚上写了1万多字的博客,来解释和介绍他的观点。费这么大的力气,其实就是因为有个叫张询的硕士,耍小聪明,非要说银弹是可以存在的。今天其实类似张询的人,还是不少,虽然他们可能也像张询那样声称自己现在是敏捷了。当然如果他们是敏捷,那我们是什么?所以首要问题,就是要否认我们这些人存在过,于是就会说agile这种高级货是来自国外的,是来自什么什么外企的。这个是题外话,大家明白就行了,知道虽然有的人看起来很和善,但是实际是比恶狼还凶狠。而我们有些人有心无心的就做了他们的垫脚石。

于是前面有硕士,后面有这些不知道来源的所谓敏捷者,再加上一些市场人员和推广人员,就形成了现在的一个气氛。这个气氛总是在说,或是早暗示敏捷的开发速度是快的,比其他任何方法都快。于是客户们兴奋了,觉得敏捷好啊,是在是个宝贝,拿回家至少可以对付一年半载。于是到处都在说我们要敏捷起来,而且我们一定能敏捷起来。但是过了一段时间,单元测试也做了,持续集成也做了,重构也搞了,故事也用了,也scrum了,也站立开会了,可是速度还是不能达到要求。于是那一日到来的时候,自然这些人就会说敏捷不行,至少在“我们”这里不行。

所以我要早给他们做解释,大声的解释,直到他们完全能听懂我的说法,我才会继续真正的去实施敏捷。

敏捷的快,不是开发速度快,而是反映速度快。开发速度和反映速度,就好比人跑步时候的直线速度和拐弯的速度。我们知道非洲猎豹是直线速度最高的动物,但是他们对付善于转弯的羚羊时,完整不站上风。可以说敏捷的这种快速反应的能力,不仅仅不会增加开发的速度,还会降低速度。这个就跟你只要弯道多,就不可能发挥出最大速度的道理一样。那么我们实际看到的情况怎么解释呢?或者说敏捷如果是一种慢速度的开发方法,怎么会流行起来呢?

其实很简单,问题就在于敏捷的推出,是面向软件危机的,而不是我们今天所面对的这些项目。软件危机是我们开发的时候,遇到的最大问题是我们会失败,也就是我们不能按照预先的设想完成软件开发。而我们今天面对的情况是,我们虽然可以开发出一个软件,但是开发速度太慢了。请认真体会这里的不同。于是我们就会明白,因为采取了敏捷,那些本来就会失败的项目,在早期就会被结束了;那些需求不明确的项目,在早期就已经开发有一个工作的东西了,虽然这个东西还没有完全达到当初的预想;有些项目客户的想法有问题,在早期通过实际的开发他们变得理性了;在项目结束的时候最终达到了一个目标,虽然这个目标并不是开始设定的那个,但是这个很可能比那个还好些。于是人们就形成一个错觉,那就是敏捷的开发速度更快。

实际上敏捷不能直接的给你提供更多的代码行,更多的模块,更多的设计。他仅仅是减少了你犯错误的可能,和降低了你改正错误的成本。

但,是不是说只有敏捷有这个能力,其他方法就没这个能力呢?根本不是这样,只要是靠谱的人,用他们习惯的方法去工作,就可以起到这个效果。是不是就没有办法提供更高的开发速度了呢?当然不是。靠谱的开发者是唯一的真正能提高速度的开发方法。也就是说虽然没有银弹,但是确实存在能人狼的杀手。我们只能说,敏捷至少当初是被一群靠谱的人用着的方法。现在大家都来用敏捷,是不是大家就都靠谱起来了?我看这个事情未必,该是2B开发者的还是会是2B开发者。也许敏捷能让开发者更能提高自己的开发能力,并最终靠谱起来。但是这也仅仅是一种可能性的存在,而不是一个充分条件。

所以如果你希望能有一个提供量级的方法,那你就错了。而且所有的方法,几乎都是为了一个目的而开发的,那就是提供目标的重现性实现,提供更大的可操控性。即使是敏捷也是这样。也就是说,当你要开发一个软件的时候,你自己的能力是唯一决定你能否成功的指标。而方法则仅仅是提供一个在某个区段完成它的可能性。方法今天不会成为一个保障,估计明天也不可能,后天也不可能,在我看得到的日子里都不可能。但是未来的某一天它会实现,但是那将是将来的事情了。


-=Kobye=-

unread,
Nov 23, 2012, 4:19:09 AM11/23/12
to agile...@googlegroups.com
速度是速度
质量是质量

效率是效率



2012/11/23 ozzzzzz <ozzzz...@gmail.com>


--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
 
 



--
--------------------------------------------------------------------------
I love Java!
I love Sports!
I love this Game !

QQ:33093778
MSN:sportsb...@hotmail.com

home:http://www.jsports.org
blog:http://blog.csdn.net/jsports
       http://blog.matrix.org.cn/page/jsports
--------------------------------------------------------------------------

Shaopeng

unread,
Nov 23, 2012, 4:25:36 AM11/23/12
to agile...@googlegroups.com
这个比喻和我想到一块儿去了!猎豹和羚羊。。。


敏捷的快,不是开发速度快,而是反映速度快。开发速度和反映速度,就好比人跑步时候的直线速度和拐弯的速度。我们知道非洲猎豹是直线速度最高的动物,但是他们对付善于转弯的羚羊时,完整不站上风。可以说敏捷的这种快速反应的能力,不仅仅不会增加开发的速度,还会降低速度。这个就跟你只要弯道多,就不可能发挥出最大速度的道理一样。那么我们实际看到的情况怎么解释呢?或者说敏捷如果是一种慢速度的开发方法,怎么会流行起来呢?

-- 
Shaopeng
使用 Sparrow 发送

-=Kobye=-

unread,
Nov 23, 2012, 4:28:11 AM11/23/12
to agile...@googlegroups.com
 速度快有啥用 一堆BUG 一上线立即造成一堆系统down了

效率高才是好

胖子

unread,
Nov 23, 2012, 4:43:53 AM11/23/12
to agile...@googlegroups.com
好吧 好吧
应该是效率高而不是速度高。
其实速度快本身就是效率高的一个另外的说法,上线前应该保证一点的质量,消除一定的bug,这个本身是不需要讨论的。出发是学生写的课堂作业,否则哪个生产环境下,不是都有一点的发布的标准。很多稍微像样点的公司,都有人专门负责发布,都有一个流程保证发布的质量。

而且随着互联网行业的发展,发布的要求也越来越灵活,比如有些bug会存在很多的版本而不被修改。其他事情也在改变。

而实际上我非常不喜欢用开发效率这个词,因为这个东西十分不容易定义出来,而且在实际中也很难说究竟代表了什么。而速度则简单的多,明确的多。最简单的就是明天我就要上线,到时候你能把东西搞出来不?这个最明确,也最容易被审查。

在 2012年11月23日星期五UTC+8下午5时28分12秒,-=Kobye=-写道:
 速度快有啥用 一堆BUG 一上线立即造成一堆系统down了

效率高才是好

-=Kobye=-

unread,
Nov 23, 2012, 4:48:12 AM11/23/12
to agile...@googlegroups.com
明天我就要上线,
到时候你能把东西搞出来不?


这种的是比较危险的事情。
搞出来了,上线了,带来一系列的问题。。。。
谁为这个买单?


2012/11/23 胖子 <ozzzz...@gmail.com>
到时候你能把东西搞出来不

Shaopeng

unread,
Nov 23, 2012, 4:49:12 AM11/23/12
to agile...@googlegroups.com
to Kobye:
这样说你就误解或者说小瞧那些一定要快的人们了,bug数肯定是和速度指标一起提出的。

-- 
Shaopeng
使用 Sparrow 发送

在 2012年11月23日星期五,下午5:28,-=Kobye=- 写道:

 速度快有啥用 一堆BUG 一上线立即造成一堆系统down了

效率高才是好

-=Kobye=-

unread,
Nov 23, 2012, 4:50:26 AM11/23/12
to agile...@googlegroups.com
倒不是误解,
不希望出现很多擦屁股的事情

胖子

unread,
Nov 23, 2012, 4:57:49 AM11/23/12
to agile...@googlegroups.com
哈哈,你就是误解了。

这里其实是有个背景,那就是软件行业和互联网行业的不同。我现在是在用互联网行业的思维在想问题。

在互联网行业,其实速度是第一位的。因为商机一旦错误,就不可能挽救。所以基本上都会极端的追求速度,而质量会稍微放松点。因为即使很多很多屁股需要擦,但是也是因为有用户才会去擦。而没有用户,根本就不需要擦。所以宁可搞一个漏洞百出的试用版,也不会要一个没有bug的没有人用的正式版。

而我认为,出发是极其特殊的项目,比如12306这个类型的项目,其他项目最后都会像互联网项目靠拢。所以这个应该是一个趋势。也就是虽然是bug,但是如果没有价值也不需要去修正它们。

在 2012年11月23日星期五UTC+8下午5时50分28秒,-=Kobye=-写道:
倒不是误解,
不希望出现很多擦屁股的事情

-=Kobye=-

unread,
Nov 23, 2012, 5:01:03 AM11/23/12
to agile...@googlegroups.com
 是的

认同这样的看法


张克强

unread,
Nov 23, 2012, 11:57:11 AM11/23/12
to agile...@googlegroups.com
刚开始了解敏捷的人,望文生义,想当然的以为“敏捷软件开发”就能更快的开发软件。
英文Agile的原意貌似也有“快”的意思。
好在随着时间推移,慢慢的有更多人了解敏捷。
但总有人刚刚接触敏捷,总有人在开始想当然的以为“敏捷就是快”。
而且业界确实曾有组织报告,采用敏捷后,开发效率提升了多少多少。



在 2012年11月23日 下午6:01,-=Kobye=- <www.jsp...@gmail.com>写道:
 是的

认同这样的看法



--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
 
 

Vincent Lee

unread,
Dec 8, 2012, 10:32:14 PM12/8/12
to agile...@googlegroups.com
这个邮件组有问题了么? 我发送到agile...@googlegroups.com 怎么没反应?

张克强

unread,
Dec 10, 2012, 6:57:32 PM12/10/12
to agile...@googlegroups.com
貌似没有问题。收到你的信了。
可能是大陆访问Gmail受限的问题。
我通过vpn访问是可以的。

Aska Ryo

unread,
Oct 29, 2015, 9:35:33 PM10/29/15
to 敏捷中国
刚从传统IT业转到互联网行业没多久,一直有个疑问求救各位大牛:
确实我可以理解互联网行业因为业务变化快,商机都是瞬息即逝的,所以很多开发团队都是认为速度>>质量的。
但是同时也有另一种说法是互联网行业竞争压力大,一个细分的行业里就有很多个同类竞争产品,所以一旦发布出去的产品质量不好就会造成用户的流失,且再也无法挽回。
所以这两种观点其实是矛盾的。
而第一种观点,就会导致开发人员不做单元测试,不做代码review,匆忙实现功能,快速上线,发现线上有问题了再快速修复(当然这种修复可能引入新的问题),据我所知包括BAT也是这么做的(当然BAT因为他们的强势地位可以让用户容忍bug)
第一种观点似乎在现在的大环境中更流行一些,但是现在BAT似乎也在强调敏捷转型(当然“敏捷”这个词已经被各种忽悠公司用滥了),但似乎他们仍然不重视单元测试及TDD的作用,主要是期望运用scrum或者kanban这种管理实践来提高开发团队效率。

我个人认为TDD与CI是各种敏捷实践中最核心的实践,但似乎在国内业界主流思想并不这么认为,是我太天真了吗?

皮宏宇

unread,
Oct 29, 2015, 10:26:22 PM10/29/15
to agile...@googlegroups.com
如果你能把活干的又快又好就没有这个问题了,所以互联网行业多数要求能力比较强的工程师,稍弱一点都可能被淘汰。另外,互联网行业多数是要求质量>速度的,但是速度也绝对不能慢,于是引入了“PM-〉dev-〉QA-〉”上线 的流程,(在我看来)使用了比传统行业更多的人力去解决同时保证速度和质量的问题

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

Aska Ryo

unread,
Oct 29, 2015, 11:08:42 PM10/29/15
to 敏捷中国
所以如何去保证把活干得又快又好呢?
可能我中tdd的毒太深了吧,按我的习惯不先写单元测试都没法下手写代码,就像开车不系安全带就浑身不舒服一样。
但是总有人告诉我,互联网企业就是要快,BAT都不写单元测试,就是为了追求尽快发布,尽快上线,否则市场就被别人抢占了。
我也找不到好的办法说服他们,甚至我不知道是不是应该说服他们,因为我的互联网经验尚浅,还是说互联网行业本来就应该是这样的?
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+unsubscribe@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

皮宏宇

unread,
Oct 29, 2015, 11:18:10 PM10/29/15
to agile...@googlegroups.com
单元测试只是保证质量的一种手段啊,你也可以通过其他手段提升质量,例如结对、例如code review,总之达到目标即可,不要纠结用什么手段,你只要保证结果又快又好就行。


要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

Aska Ryo

unread,
Oct 29, 2015, 11:36:32 PM10/29/15
to 敏捷中国
在我的理解里,pair programming和code review并不能作为UT的取代手段,它们可以共同作用,提升产品质量。
比如pair programming和code review并不能阻止引入regression的bug,也不能在引入bug时快速反馈给developer自己,
更不用说以TDD作为设计的工具的作用吧。
如欲退订请发送邮件到 agilechina-unsub...@googlegroups.com

皮宏宇

unread,
Oct 29, 2015, 11:44:15 PM10/29/15
to agile...@googlegroups.com
我就这么说把,牛逼的人写完的代码是不会出bug的,菜鸟才会出bug,互联网公司一般是选择牛逼的人,因为他能同时保证质量和效率,而传统行业更期望选择菜鸟,因为他们更便宜。


要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

Aska Ryo

unread,
Oct 30, 2015, 12:02:27 AM10/30/15
to 敏捷中国
呃,那也许是我见识太少吧,没有见过一个凭空写完代码从来不出bug的牛人
如欲退订请发送邮件到 agilechina-unsubscri...@googlegroups.com

更多选项,请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+unsubscribe@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

-- 
-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+unsubscribe@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

Glen Wang

unread,
Oct 30, 2015, 12:03:57 AM10/30/15
to agile...@googlegroups.com
有微信群吗?谁来搞一个?


Date: Thu, 29 Oct 2015 21:02:27 -0700
From: aska...@gmail.com
To: agile...@googlegroups.com
Subject: Re: [agilechina] 幻象和敏捷
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

ozzzzzz

unread,
Oct 30, 2015, 1:05:00 AM10/30/15
to agile...@googlegroups.com
现在BAT的问题,并不是TDD能解决的。他们面临的问题,主要还是产品设计。
铁三角,重构,单元测试,持续集成,现在有了发展。重构,由简单设计和框架式开发,已经新的工具的使用,已经几乎很少被人们正式提起。持续集成,也发展到了持续部署,持续交付。唯独单元测试,还是那样。
现在的开发,基本上都是使用某种高能力的工具,快速开发。代码量和复杂度都比较小,而工具的支持也比较好。所以单元测试的迫切程度并不大。工具的复杂性,造成工具的开发反而更加需要引入更多的测试。基本上各个公司都有基础工具部门或者平台部门。

Glen Wang <glenw...@hotmail.com>于2015年10月30日周五 下午12:03写道:
如欲退订请发送邮件到 agilechina-unsub...@googlegroups.com

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上“敏捷中国”群组中的主题。
要退订此主题,请访问https://groups.google.com/d/topic/agilechina/SxIf0NUhg4o/unsubscribe
要退订此群组及其所有主题,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

Aska Ryo

unread,
Oct 30, 2015, 2:02:42 AM10/30/15
to 敏捷中国
所以我是不是可以理解为因为BAT的资源丰富,有成熟的支持功能开发的基础工具(可能是第三方的也可能是他们自己开发的),所以依靠这些工具开发出错的可能性比较小,所以单元测试或者TDD都不是必要的。
但是对于开发这些基础工具的团队还是需要的?
另外BAT之外的公司,特别是互联网行业成批起来又成批死掉的创业小公司来说,没有这样的基础设施建设,所以TDD对他们还是适用的?
如欲退订请发送邮件到 agilechina-unsubscri...@googlegroups.com

更多选项,请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+unsubscribe@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

-- 
-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com

更多选项,请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+unsubscribe@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com

更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+unsubscribe@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上“敏捷中国”群组中的主题。
要退订此主题,请访问https://groups.google.com/d/topic/agilechina/SxIf0NUhg4o/unsubscribe
要退订此群组及其所有主题,请发送电子邮件到agilechina+unsu...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

皮宏宇

unread,
Oct 30, 2015, 2:09:41 AM10/30/15
to agile...@googlegroups.com
“另外BAT之外的公司,特别是互联网行业成批起来又成批死掉的创业小公司来说,没有这样的基础设施建设,所以TDD对他们还是适用的?”—— 是的,不过成批起来又成批死掉的创业小公司来说,活下去才是更重要的。


要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

Bo Yang

unread,
Oct 30, 2015, 2:12:24 AM10/30/15
to agile...@googlegroups.com
你的目的是什么?你实现目的的手段又是什么?如果一个手段是达到目的不可或缺的,自然会成为教条;若不是,就可有可无。

至于“成批起来又成批死掉的创业小公司”,你得先关心人家为什么死掉。只要不是因为TDD死掉的,就与你的主题毫无关系。

    致


杨波

如欲退订请发送邮件到 agilechina-unsub...@googlegroups.com

更多选项,请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout


-- 
-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout


--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com

如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上“敏捷中国”群组中的主题。
要退订此主题,请访问https://groups.google.com/d/topic/agilechina/SxIf0NUhg4o/unsubscribe
要退订此群组及其所有主题,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

Aska Ryo

unread,
Oct 30, 2015, 3:05:49 AM10/30/15
to 敏捷中国
拿我前面说的开车不系安全带作个比喻吧。
我们都知道开车需要系安全带,但是现实情况中不系安全带的人也很多,也并不是说每个不系安全带的人都出车祸死掉了,或者说系了安全带的人就不会死掉。
所以一部分人认为开车系安全带是可有可无的,另一部分人认为开车必须系安全带。估计互相谁也说服不了谁。
就算有人出车祸死了,不系安全带也只是其中一个原因,还有很多其他原因导致车祸的发生,但是这样并不能证明不系安全带跟人出车祸死掉没有关系。

    致


杨波

如欲退订请发送邮件到 agilechina-unsubscri...@googlegroups.com

更多选项,请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+unsubscribe@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

-- 
-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com

更多选项,请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+unsubscribe@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com

更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+unsubscribe@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上“敏捷中国”群组中的主题。
要退订此主题,请访问https://groups.google.com/d/topic/agilechina/SxIf0NUhg4o/unsubscribe
要退订此群组及其所有主题,请发送电子邮件到agilechina+unsu...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+unsubscribe@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

Jeff Xiong

unread,
Oct 30, 2015, 3:21:07 AM10/30/15
to agile...@googlegroups.com
这个逻辑是对的。TDD管的是质量尤其是可维护性(前面说bug的其实没怎么说到点儿上哈),但是可维护性尤其是单个代码库的可维护性这事儿究竟有多重要,我现在越来越有疑问。作为《重构》的译者,我的感觉,重构这个技术正在越来越变成一个屠龙技。


    致


杨波

如欲退订请发送邮件到 agilechina-unsub...@googlegroups.com

更多选项,请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout


-- 
-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout


--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com

如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上“敏捷中国”群组中的主题。
要退订此主题,请访问https://groups.google.com/d/topic/agilechina/SxIf0NUhg4o/unsubscribe
要退订此群组及其所有主题,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com

如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

皮宏宇

unread,
Oct 30, 2015, 3:26:48 AM10/30/15
to agile...@googlegroups.com
跟安全带不一样,都是成本收益问题,系安全带成本大约需要启动前花费5秒钟(多数时候还是车在运行中),就削减了重大事故中40%甚至更多的风险。但是施行一种新的开发方法(规则)需要大量的培训、学习成本,对那种明天搞不好就死掉的创业团队来说,是否具有性价比,有待考证。

最后,tdd也好单元测试也好,都是目前时代的一种保证质量的方法,这些东西,对于牛逼的人来说是轻车熟路的,所以,团队牛逼与否(能不能开心的活下去),主要是靠人给不给力(因为方法也是需要靠人去执行),不是靠使用了什么方法。

在未来,我们也许用机器去写代码,我们只给出思路和理念就够了^_^,到时候我们可以详细探讨下如何让机器更优雅的书写代码,因为这是机器做不到的。


要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

Glen Wang

unread,
Oct 30, 2015, 3:32:58 AM10/30/15
to agile...@googlegroups.com
如果是机器写,那么也应该由机器检查,就不用优雅了,就只用正确,不用可读性,规则都得推倒重来。


From: ds3...@gmail.com
Subject: Re: [agilechina] 幻象和敏捷
Date: Fri, 30 Oct 2015 15:26:52 +0800
To: agile...@googlegroups.com

皮宏宇

unread,
Oct 30, 2015, 3:40:30 AM10/30/15
to agile...@googlegroups.com
可读性是一定要的,万一哪天写出一个Architector,然后这个 Architector 又造出了Matix,如果没有人工干预的审查制度,我们就都变成化学燃料电池了 
(-̩̩̩-̩̩̩-̩̩-̩̩̩_-̩̩̩-̩-̩̩̩-̩̩̩)

Jeff Xiong

unread,
Oct 30, 2015, 3:42:02 AM10/30/15
to agile...@googlegroups.com
在未来,我们也许用机器去写代码,我们只给出思路和理念就够了

这个是幻想。编程的根本困难是对连续的、模拟的物理世界进行离散的、数字的建模,将一个模拟问题描述为一个图灵机可计算的问题。至于这个模型怎么实现,《人月神话》说了,那是偶发困难。大多数人不会编程,不是因为不懂Java,而是因为不会逻辑地思考。普元的黄柳青当年说,只要在一个图形化的界面上拖拽,你就不需要编程了。结果呢?结果大家发现,你要把问题想清楚,然后选择合适的元件加以合适的装配,这个就叫编程。思路和理念,你要么表述得模糊、抽象、不清晰,因此图灵机不可计算,因此机器写不出代码;要么你表述得清晰、明确、图灵机可计算,那么你做的事就叫编程,其复杂度跟今天的编程不会有本质区别。



    


杨波

要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout


-- 
-- 
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
--- 
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论,请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项,请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agilechina+...@googlegroups.com
要查看更多选项,请访问https://groups.google.com/d/optout

Aska

unread,
Oct 30, 2015, 4:00:10 AM10/30/15
to agile...@googlegroups.com
深有同感,不光是重构,整洁代码,结对编程等实践似乎也都使不上力。
在互联网环境下,可能业务变了,这个功能过两个版本就没了,我今天开发的代码过不了多久就不用了,我何必去管它的可读性可维护性或者可扩展性?又何必去给它加单元测试?
似乎人们渐渐都开始接受这样的思想,而且有一个破窗效应在里面,渐渐波及到其他的我们以前认为正确的实践。
这也是我最近比较迷茫的地方,是这些实践真的跟不上时代的发展了吗?

Jeff Xiong

unread,
Oct 30, 2015, 4:14:50 AM10/30/15
to agile...@googlegroups.com
跟不上时代的发展也是很正常的事。单一代码库的可维护性变得不那么重要,那么代码库与代码库之间(在运行时通常是进程与进程之间)的可维护性就会变得愈发重要。容器,微服务,都是在讲这个事。重构这种特定的技术过时了,康威法则仍然生效,Martin Fowler说的“白痴都能写出机器能读的代码,好的程序员要写人能读的代码”仍然生效。知识过时,学习不过时。

Bo Yang

unread,
Oct 30, 2015, 4:15:26 AM10/30/15
to agile...@googlegroups.com
单元测试是手段不是目的。重构,整洁代码,结对编程都是手段。可读性可维护性或者可扩展性,也是手段,目的是产品的长期生命。
目的有轻重缓急,手段自然需要相应选取。如果你有资源有时间做单元测试,自无不可。如果你东西不上就丢饭碗,急着上了会冒出大问题被责骂的风险,多数人还是会冒冒险的。至于不知道哪天死的创业企业就完全看决策者的情怀了。他们的生存还是死亡,优先短期还是长期收益,他们自己都不见得弄得清楚,我们从旁妄加评判,终归有点“站着说话不腰疼”的感觉。而且,他们做错了决定,市场会让他们关门的。
撇开这些不谈,工程的事,大部分的准则都有上下文的,适不适用,用的人才清楚。

    致


杨波

2015-10-30 16:00 GMT+08:00 Aska <aska...@gmail.com>:

吴亭

unread,
Oct 30, 2015, 7:18:37 AM10/30/15
to agile...@googlegroups.com
哈哈哈,看笑了,写的好😀

Xu Yi

unread,
Oct 30, 2015, 10:55:17 AM10/30/15
to agile...@googlegroups.com
建了一个,大家加吧,不过这个群沉默很久了,不晓得是否有这个需求,试试吧。群二维码过期的话,可以加我,注明“加敏捷中国谷歌讨论组”即可

内嵌图片 1

内嵌图片 2

- - - - - - - - - -
Xu Yi, Kaverjody
Site: http://kaverjody.com
WeChat / Skype / Twitter: kaverjody
LinkedIn: http://www.linkedin.com/in/kaveri
- - - - - - - - - -

有微信群吗?谁来搞一个?

如欲退订请发送邮件到 agilechina-unsub...@googlegroups.com

ozzzzzz

unread,
Oct 31, 2015, 12:29:55 AM10/31/15