随笔档案(198)

受教了,下个玩玩

非常好！有收获。

我是在Mac环境上学习的，貌似不支持exe，应该生成什么格式呢？用什么工具呢？

企业要发展。。 都请牛人的成本太高

新手求助： python如何修改/etc/hosts文件中的IP，

SqlCommandGenerator.GenerateCommand( connection,[b]null[/b], new object[] {customerName,country,province,city,address,telephone,customerId } ) MethodInfo 参数怎么传递呀？［AddCustomer］

其实还是应该给c++添加元数据，让装载器可以动态装载所需要的执行代码，这样就能保持最精简。

不错

XMPP 可以实现Web im吧？ 我现在在研究这个哦，，望前辈指教一下！

我不太同意你的看法。

敏捷的方式是好的，但是你们都没有理解敏捷。 快速开发的前提是什么？一支军队在出征前，根本就没有搞清楚自己面对的敌人，怎么控制战场节奏，怎么进军怎么撤兵，怎么布阵。 更有甚者，连自己军队需要多少兵种都不知道，连武器配备都不标准。 之后就说将在三个月内结束战争。因为你知道敏捷了！ 这不笑话吗？ 楼主的团队最多算是个迭代开发，离敏捷还差得很远

也许吧，不过最近也在看敏捷方面的资料，结合目前我们公司的开发模式，在很大程度，敏捷能解决现有开发过程中出现的问题，敏捷的宗旨是以人为本，充分相信团队的合作力，有斗志！团队的人数不在精，而在相互的信任，相互的交流与沟通！当然，除此之外，产品需求，测试等等因素也客观决定了一个release版本的质量！敏捷，每个环节都是如此，并不是只针对开发人员！

我看这思维方式就得变 不然一时半会找不到王道

中国软件，很难重视质量，或者当正版路走顺了。质量问题才得以解决

@KymoWang 也不是说在国内行不通。 关键问题是：国内的敏捷，只看到了一面，就是快速。 而实际上敏捷的另一面“质量保证”就看不见了，看看老外们的双人编程，严格的单元测试，频繁的自我重构，代码审查------如果敏捷没有严格的质量保证和“三省吾身”的态度，基本就像把车交给一个醉汉去开一样，反正眼睛看到哪，车就开的哪。刹车，油门乱踩一通，能不撞墙都是万幸了

目前的工作就是看Tata的bad code,眼泪水哗哗的

@KymoWang 敏捷就像一把剑 你难道要把是否可以成为武林高手寄托在剑上吗！ ------------ 其他他只是引入了一些思维方式，重点是自身的实力！如果希望用上了敏捷就提高团队的实力，个人觉得很难..... 不是说国内行不通！是行的不好

我想这不是敏捷的错误，这是偷懒的错误。敏捷不代表不管不顾，只管快速完成。实际上每个程序员快速完成以后，都应该立即重构他的代码来保证最小功能点这个要求。比如我见过比较狠的if（obj！=null&&obj.xxx==1）这样的判断都封成最小功能点 if(checkObj_xxx()),连这样简单的判定都封成方法的。如果说每个代码都是如此高质量的保证最小功能点的话，修改就方便很多了。所以老外一致强调“重构+TDD”，强调“红灯，绿灯，红灯，绿灯---”。这里的“红灯，绿灯，红灯，绿灯---”不是说，出了问题才去“红灯，绿灯”弄，而在整个阶段都应该时时刻刻去玩“红灯，绿灯”这个游戏

@Kevin-moon 那么是采用敏捷来提高大多的团队的实力呢，还是等团队的实力提高了再采用敏捷呢？或者说敏捷在国内根本就行不通呢？

你累了，所以你的团队就累了。

[quote]辰： 国外提出来的理论总是太美好，是针对国外的。 敏捷最终是让变动变的更加容易，而不是所谓让产品更快发布。也许lz提到的案例整个方向就错了。 比如我采取敏捷之后，以后要修改数据库结构、升级代码之类的重量级操作，和我写个helloworld简单，那么就没有任何问题。 我开发的项目，只要是稳定的，功能可以非常简单，没有任何验证，但是完成了顾客的要求，先让他用。只要他用的不爽了，提出要求，我1、2天就改好。 等顾客没有了新的要求之后，开始重构。[/quote] 等开发了一年以后，客户再提出反馈，就不是改1-2天的事了。客户没有新要求以后，也不会给你时间重构了。

[quote]阿水：敏捷最主要的就是要和客户一起做项目，否则怎么敏捷呀? [/quote] 要是客户不和你一起做呢？

敏捷只是一种概念,看你怎么理解了! 不过从楼主谈的这些上看，不要怪敏捷,是你们团队实力的问题! 1、没人提真正的Feedback 你指望用户反馈有深度的东西，太不实现，这是你们BA的事情，需要根据从每个用户反馈简单的反馈中去提炼的！ 2、架构咋弄啊 从开始就缺少核心的架构人员，软件开发其实是越到后面就越轻松的事情，因为库在开发中就慢慢完善，后期基本就是简单调用的可以了！ 3、客户说没有不是Must Have的 这个就需要你们去做好沟通了，从成熟的方案开始做，用户提了很多东西，有成熟和不成熟的，这个的区分就要你们去做了！如果有好的引导，那么并不是每样都是Must Hava， 就实际来说，国内大多的团队实力都不行

so，100个functionpoint，在第一次release就应该全部实现。 如果有过去的经验框架参考就用，没有就直接写，不考虑重用。 当100个FP被顾客认可了，再开始重构。

国外提出来的理论总是太美好，是针对国外的。 敏捷最终是让变动变的更加容易，而不是所谓让产品更快发布。也许lz提到的案例整个方向就错了。 比如我采取敏捷之后，以后要修改数据库结构、升级代码之类的重量级操作，和我写个helloworld简单，那么就没有任何问题。 我开发的项目，只要是稳定的，功能可以非常简单，没有任何验证，但是完成了顾客的要求，先让他用。只要他用的不爽了，提出要求，我1、2天就改好。 等顾客没有了新的要求之后，开始重构。

我比较倾向于阶段方式，搞需求的时候，不动编码，架构好了，再动手。也许是我的经历不够丰富，体会不到你说的项目紧张程度。 大小项目，无论时间是否充足，首先应该达成需求，不能达成的，再开发原型，逐步确定。我认为你说的敏捷里，最大的问题是没有划分阶段，每个阶段都要重复所有的事情，这样就象一个旋涡，会越来越大，大到控制不住的。 当然，按照你说的如果规划一年才出效果，则结果很难保证，这个想象我认为就象一个大山。 这两种难度，不一样。小规模的项目，我倾向于你说的方式，大一点的项目，我认为还是要规划好，才能执行，即使后果难料。

@小猴子 需求敏捷了有什么用？开发敏捷了有什么用？不上线实施，怎么知道开发code是有用的，需求是用户需要的？ 如果上线实施的周期是按年计的，在一年内就有很多跑偏的机会。依赖于客户和开发团队来假想手上和计划要做的事情能够在一年后真正产生价值，太难了。具体到每一天，每一周，很容易Lost。只有把上线实施的周期压缩短，从一年到三个月，再到一个月再到按周计，才能从源头上按价值把所有的事情和人驱动起来。

原型开发项目、敏捷项目 看完文章，LZ想说的敏捷项目 就是 将敏捷覆盖到开发的各个层次，需求是敏捷的、开发是敏捷的、上线实施也是敏捷的，整个项目从上到下都敏捷。头一次有这样的感受，也许是没有细致的看，感觉错位了。

我觉得敏捷的核心问题，是如何更快发布发布一个客户可用的版本，围绕这个问题，就会发现“持续集成才是王道”。 关于架构问题，lz好像没有答案。在整个迭代过程中都是围绕着user case做的，可能觉得架构不知道什么时候就被设计出来。我认为，总体的架构从项目开始就已经有初步的认知，如何部署、大概有多少个子系统。但不是固定的，在整个开发周期都可能被调整的，而且架构不是所谓的架构师一个人决定，而是整个团队经过讨论而获得的。而单元测试保证架构调整后，每个case都顺利执行。每天30分钟短会，确保每个组员都知道架构调整的原因和演化。

系统涉及用户故事拆分. 开发进度控制. 开发问题预见等. 我是实际操作按照<<敏捷估计与规划>>这本书的方法加以控制的. 还是值得借鉴的..

如果客户需要3个月来一个版本来装门面 那么，在他不试用的情况下，他拿什么去汇报？ 直接拿我们给他的文档就可以了？ 那么就不给他文档算了，告诉他每次都要他陪同一起试用后才能写文档

敏捷最主要的就是要和客户一起做项目，否则怎么敏捷呀?

敏捷开发只是一个概念 每个人的理解和执行方式是不一样的 都有自己的套路

太好了，终于有人出来说话了。 你的感觉太对了，我最近遇到的问题也是这样。 这些问题的出现，大多数是在号称敏捷的团队，而反对他们的人，被称为反敏捷。 其实，他们说的敏捷不是真正的敏捷，而是那些打着敏捷旗帜，混淆视听，实际做的就是我们说的手工作坊式开发，混乱是自然的，偶尔的成功也会有，但成功几率很低。 识别这些假敏捷旗帜，有一些方法，首先，假敏捷一定会反对传统的软件工程，无论是CMM还是通常的项目管理。因为他们从来没有理解软件工程或者一般工程方法，而敏捷的实质，仍然是软件工程的方法，是从来没有反对过软件工程和项目管理的，只是任务分解和里程碑计划周期不同而已。 这些假敏捷，不求架构和设计，只求工作量，按工作量算工钱。如果出现问题，可以“敏捷”地修改，但是，仍然需要工作量和按工作量付费。

有时候，客户是要引导的。

敏捷对团队的要求很高..我们也在用敏捷,不过一塌糊涂

@brightwang 嗯，那是我的孪生兄弟。你信不？

楼主的头像好像在javaeye上看到过。。。

有道理。 部署很重要，但怎么提高部署律呢？

@幸运猴子 路总是有的，你可以先用廉价或者免费的 IDE 开发第一个应用，然后用来赚钱买更好的 IDE ，这是正向的商业社会循环。但是在中国，基于盗版等等原因，事情并不是如此进行。

@Cat Chen 您说的完全正确，除了EXPRESS，其他版本也不便宜的说，不过还好了，也可以用其他的来替代，比如，Sharpdevelop。

@侯伯薇 问题是公司不是这么想的

微软的利润率才25%不到，上面计算VSTS的成本明显计算的偏少。另外除了研发成本，还有运营成本（比如销售、广告、办公室的费用等等）。如果这些都算到开发的头上，那么一个人的成本就不是6W美金这么低了。另外对于VSTS的很多资深开发人员，本身已经是6W的N倍了，可以说6W只是一个入门水平。 不注重知识产权，最终的结果就是导致你的东西（知识产权）也不被人重视。所以种下恶果的恰恰就是你自己。

对设计模式应用一个升华.不错.

@幸运猴子 你确认你必须要 Team System 这样高级的版本？不能在功能和价格之间进行折衷？

Lz 在ThoughtWorks 工作？ 是在北京的总部？...

这个问题也确实引人思考.

市场的需要在决定开发人员的professional和unprofessional. 市场本来就是多元的. 国外的也是如此. 我们不单单看到国内情况就过高估计我们这个行业的形势. 只要有什么样需要就会制造什么样开发人员. 仔细想想那些做外包每天在利用Replay Work来制造项目零件及时有相关专业的业务 也只能是一个高级的代码工人. 外包就是这样的需要. 无需你过高的professional. 类似提出发起敏捷宣言的Robert C. Martin所在高Value的咨询公司. 做的是什么 而不是简单的代码堆砌 卖的是思想和服务. 简单的说我们这个行业也可以说成一个食物链的金字塔. 底层建筑决定高层基础. 同样开发人员的Professional和unprofessional同样多元存在的. 所以说也不能单一说说是环境 或是开发人员的素质.或是企业选择因素.这就类似我们把这个形势一开始就想的很理想.

@Nick Wang (懒人王) 这些做高Value产品的公司，软件就不是一个could have了。对于DRW Trading来说，这些牛人开发软件就是Must Have。对于IMIS来说，Greg Young领导开发的算法交易软件也是Must Have。对于TrafficBroker来说，Fred Georage领导的那些PB级别的Map Reduce算法就是Must Have。 开发者不重视，根源就在于没有从事High Value的工作。不是High Value，自然不是高回报，自然也就请不起Professional。即便请得起Professional，也未必让你用Professional的方式工作。

[quote]Cat Chen： 我觉得关键在于 professional 和 unprofessional 之间的回报差异不够明显。足够明显的话，无论什么环境，都会有人想要做到更加 professional 。 简单来说，你原意让一个 unprofessional 的医生来给你主刀吗？你肯定不愿意，出多少钱都要找最 professional 的。但是你敢把代码外包给 unprofessional 的人做吗？你敢。[/quote] 生命对于一个人来说，就算不是最重要的东西，也是拥有最重要东西的基础设施。但是软件对于企业来说，还不是这个最重要的基石，只是提升价值的一种方式方法。 就好像story中的must have和could have一样，软件现在还只是could have。