实际写代码 interface, design pattern用的多么？

key

我对重构的理解并不局限于你所说的范围，这个就先不谈了。我们不妨基于你所说的一些内容做一些讨论。

我对系统的设计，是在我的整个coding过程中完成，重构是我两个最重要的设计步骤之一。

我想知道，

1. 如果你做一个tech leader或Architect，如何让你的同事了解他们要做什么？怎样用好你的设计？
2. 你如何知道哪些第三方组件需要引入，什么时候引入，为什么要引入？

我也经常用UML，但多数时候是和同事讨论时候用的，多数是画在白板上和纸上。 事实上，我目前的工作电脑上连画UML的工具都没有，只有家里的电脑有个UModel。 当然这个也和我的工作性质有关（我们是做产品的公司，不用和客户进行技术交流）。

我想知道：
1. 你用uml画了哪些图？为什么要画这些图？
2. 你做reverse engineering吗？

原帖由 woodheadz 于 29-4-2010 23:21 发表

                               
登录/注册后可看大图

把重构和死亡联系起来，我想你是过头了。 我本来还觉得我们对重构的观点都差不多，但现在看起来还是有很大的不同呢
有一个很好的例子，可以说明我们的区别。 就像我们都知道需求的变化不可避免，在这个 ...

woodheadz

呵呵，我喜欢这样的讨论，我想我们两个都会从中有所收益

1. 如果你做一个tech leader或Architect，如何让你的同事了解他们要做什么？怎样用好你的设计？
2. 你如何知道哪些第三方组件需要引入，什么时候引入，为什么要引入？
3. 你用uml画了哪些图？为什么要画这些图？
4. 你做reverse engineering吗？

1.这个问题，恰好就是很多人质疑敏捷方法的地方。 我的回答是：面对面的交流 + 结对编程（我几乎和每个团队成员都结对过） + Code review + 部分UML
我刚好在一个大型产品项目的一个子系统开发团队内担任过architect,我觉得在我们当时的环境下（因为要参加一个国外的行业展览，所以工期紧，而产品部门过来的需求变化很快），这种做法最后的效果还可以接受。 我后来跳槽到一家以外包为主要方向的公司，那边就是以文档为主要交流手段的。 我没有办法想象如果我在前家公司的项目中依赖文档作为主要交流手段会是什么样的一个结果。
当然这种方法不可能用于很大的团队，但是如果团队很大，而不划分成一个个的小团队以至于不能用这种方法，是不是也说明这个团队的组织有问题？

2.第三方组件的问题，我们在项目的前期或者中期都曾经做过引入第三方组件的决策。 我觉得这个是一个风险控制的问题，如果我觉得某个地方不采用第三方组件可能有风险，我自然会把这个模块放到最优先开发的列表中，尽早确定是否采用第三方组件。

3.我用的UML大多数是类图和时序图，我画UML的主要目的就是为了交流。我很不喜欢包含很多细节的UML，我觉得与其看这样的UML，还不如去看代码更清楚。
我最近比较喜欢这个：
http://yuml.me/

                               
登录/注册后可看大图

4.我不做reverse engineering，理由见第三点

[ 本帖最后由 woodheadz 于 30-4-2010 12:08 编辑 ]

procoder

设计模式可用可不用，但是设计原则要谨记，设计出来就会慢慢靠近某些模式了，如果场景类似的话。

xblues

FreeOZ真是卧虎藏龙啊，这么一个帖子引出了这么多老虎来。