Sognopolis - 简单带来重用，复杂带来重复

读这样的文章真是一种享受，多谢博主啦~~

你们的头儿应该去听听潘加宇的UML公开课

--引用--------------------------------------------------
鱼片 2: 黄与贺都不看好.
贺没有团队精神,以组员的身份,却想做ceo的事情.
黄这个队长没有什么战略,没有执行力.
感觉就会喊口号.可能在部队喊惯了.
不过他们能上央视,最少比一般人强.
但我不会去黄的公司也不会去贺的公司.
--------------------------------------------------------
@鱼片 2

严重同意，不介意握个爪吧:)

黄艳泽情商不错，别的方面真是不敢恭维

@RicCC
对于自顶向下方法的缺陷，我深有同感。

我的感觉是，一个OO系统，领域分析一定要做。没有领域模型，靠Test Driven（广义上的）和Evolve，这个过程不好控制。

记得学软件工程的时候老师就在讲自顶向下、自顶向下，Bla bla bla ...
可是究竟怎么个“自顶向下”法，结构化分析方法和OO方法给出了不同的答案：加入了“抽象层次”的考虑，很多问题就迎刃而解了。反过来再看结构化方法，那是相当的简陋啊~~

又见楼主的好文，乱说两句，幸勿见怪:)

工作使用的语言（从大学时代第一份兼职开始）：C->PB->VB6->C#->C++->C#
从使用时间和熟悉程度来说，第一语言是C#，也比较喜欢，C++很好，但是没有多少时间研究
语言嘛，多用多想就好了

大家参与讨论，1个架构师拍板和负责

共同期待吧:)

视人员构成情况而定吧，要提升整个团队的能力，还是“主动编程”比较靠谱，不过成长的过程相当艰辛

受教了

上联：很黄很暴力
下联：很好很强大
横批：和谐社会

Java很好，很强大:)
不知道为什么会有那么多程序员执着于.net与Java的主义之争，有必要那么狭隘吗？

好东西，不才笑纳啦:)

长知识了，多谢楼主

@坚强2002
太客气了:)
在你的博客潜水多日，很钦佩你做人的态度。以后多交流吧！

--引用--------------------------------------------------
坚强2002: @omnislash
博主自己的团队有用xp吗？感觉如何呢？

这就是我为什么苦哈哈的翻译这篇文章的目的，就是要回答两个问题：
1.用还是不用？
2.如果用，怎么用？
--------------------------------------------------------
@坚强2002
说说我的体会
我所在的团队规模不大，开发的只有4、5个人。目前在做一个软件产品，接触不到最终用户，但是有一个同事有很丰富的行业知识和实施经验，“现场客户”勉强算是有吧。需求分析主要采用用例分析方法。

我们没有全面实施xp，只是用到了xp里面部分实践，包括每天的站立会议，时不时的结对编程，局部的tdd和不充分的持续集成。

每天的站立会议在早上举行，大约10分钟。每个人说三件事：昨天干了啥、遇到啥问题解决不了，今天打算干啥。

所谓“时不时的”结对编程有两种情况，一种是在开始开发新功能的时候，两个人一起讨论设计和编写测试用例，有问题去找客户代表当面澄清，保证同一个功能有更多的人了解和参与；另一种情况是遇到了比较棘手的问题，两个人商量着解决。

局部的TDD是这样的：一开始要求大家尽量做到测试先行。可惜弟兄们都不习惯这种乾坤颠倒的思维方式，一个月做下来，生产效率低得惊人。所以后来就没多做要求，只有一些关键的功能采用TDD开发。

持续集成服务器搭建很容易，不过更重要的是自动化单元测试和配置管理策略。所谓“不充分”是指单元测试覆盖率低。这个属于现实的无奈，人手不够，又普遍缺乏单元测试技能，输在起跑线上，只能慢慢培养吧。

至于实施效果，可以用差强人意来形容吧。总体来说，团队沟通比以前好了，程序的质量有提高，而代价是工作效率的严重下降。

具体说我们实施过的这几种实践。

站立会议不错，能够有效帮助团队沟通。

持续集成收效快，负面影响小。

结对编程有利于沟通和知识传播（相当于real time code review嘛），但前提是两个人的程度要差不多，否则很容易演变成一个人闷头写程序，另一个人在旁边傻看着；比较理想的情况是，一个人主导设计，另外一个人提出质疑或补充，两个人不停地讨论。我们管这种方式叫做“聊天编程”，呵呵。不过这也对两人的沟通技能提出了更高的要求。

相比结对编程，TDD更具有争议。我的感觉是大家普遍不喜欢它，因为这种方法完全颠覆了以往形成的开发习惯和思维方式。不过我个人还是很喜欢这种方式，而且确实从中获得了很多好处。

总之，我个人感觉XP对参与者的技能要求还是很高的，如果不考虑项目的具体情况就实施xp，很容易造成code & fix的混乱局面。记得有人讽刺说XP是鼓励老板Hire the best，Fire the rest，我觉得还是相当有道理的，呵呵。

一点浅见，仅供参考

多谢博主翻译马大叔的这篇经典好文：）

感觉现在能用好xp的不多。有一次听微软Office的产品经理说，微软不少开发团队在用敏捷方法，不过是scrum，而不是xp。他本人的团队里面实践过tdd和paired programming，也是感觉不爽浅尝辄止。博主自己的团队有用xp吗？感觉如何呢？

有句话怎么说的来着？

“人傻，钱多，速来”

补充一下：
string和bool是C#语言规范的一部分
System.String和System.Boolean是.NET框架类库的一部分

产品部和开发部权责不明，这是老板的错。
指望产品部的同事良心发现来解决问题，这个基本上有点难

ms还是windows的死忠多啊~~

《上帝与新物理学》也很好，如果楼主没看过，推荐一下
这本书和《量子物理史话》、《系统化思维导论》（温博格的那本）可以作为一个系列来读

PS:《幸福之路》很不错:)

我觉得用这个词更贴切一些
http://en.wikipedia.org/wiki/Infinite_regression

这种情况用回调接口更合适一些

欧洲是世界的敬老院，研发这种体力活他们干不了多久了

只有定性没有定量不行
我的团队这四条都有，但是我不认为我的团队足够敏捷
另外，敏捷团队关注的是人，这四条似乎反映不出来

我比楼主痴长几岁，当年的想法也差不多，回头看看，不胜唏嘘啊~~

1、想换文凭不一定读脱产的研
2、学位和水平没有必然关系，以目前国内的研究生教育质量，除非你考上的是顶尖学校的顶尖专业，否则意义不大。
3、有信心是好事，但是你没有考研的经验，所以一定要谋定而后动，不能想当然。
4、脱产读研，你将会失去一个发现问题的环境，换句话说，可能会迷失方向。
5、写文章和读研没有必然关系，如果你真的想写，随时都可以写。能阻止你的人其实只有你自己而已。

总之，我认为研究生文凭决不是什么必须的东西。而要得到研究生文凭，也有不止一条路，而脱产读研恰恰是其中代价最大的一条。

--引用--------------------------------------------------
daizhj: @omnislash
他们之间堪称是"强强联手"吧:)
--------------------------------------------------------
客观上看，合作效果不错，至于动机和心态，咱就不揣摩了:)

刘禅和诸葛亮，君臣互相成就，难能可贵呀

三十六计之：漫天要价，就地还钱

OO神话，是指人们对OO的种种误解。
期待楼主继续展开

这文章放新手区可惜了，建议博主在系列结束后整理一个完整版发到原创吧

多谢，又学一招~~上趟新手区也很有收获呀，呵呵

--引用--------------------------------------------------
没剑: 哈哈，看到楼主的婚纱照偶就放心料，谁说程序员找不到老婆的？！
--------------------------------------------------------
对，这个主要靠主观努力，不能因为做了程序员就自暴自弃，呵呵

恭喜博主，贺喜博主。祝百年好合，早生贵子：）

好东东，谢谢：）

请问一下，测试时iBatisNet是跑在反射优化模式下吗？

提个小建议：先提出对“可重用代码”和“模块”的正式定义。一千个人眼中有一千个哈姆雷特，虽然只是两个简单的词，大家的理解肯定会有不一样的地方。
名正才能言顺，是不是这个道理？

只剩板凳了啊

@jillzhang
ps = P.S. = post script
大约是“另外”、“又及”的意思
http://en.wikipedia.org/wiki/Postscript

没有银弹，最重要的还是团队的能力

水果真理教主并非浪得虚名：）

沙发

好文章！
特别钦佩博主的认真态度，看得很舒服，谢谢：）

用操作符优先级就可以了，不要不相信C#的language specification嘛

我理解，就是Top-down和Bottom-up的区别。
新手更倾向于关注实现细节，而对整体缺乏把握。改变这种思维习惯，还真不太容易做到。

配色和背景图让人看起来很不舒服……