|
|||
 公告 |
应该多触动组员。他们不喜欢发言，就必须让他们发言，我的方法是：开会的时候，我就始终叫一个愿意说的（这个人需要选好），让他先发言，然后再让每个人发言，让一个人负责记录。时间长了，让那个愿意说的来组织会议。定期对会上发言多，采纳意见多的人给予表扬，并适当的奖励（这种奖励有很多，可以将这个解决办法以他的英文名字的开头字母来命名，这样不需要花很多钱，还有成就感）。平时自己在旁边聆听，在最后将自己的腹稿跟大家的意见统一起来，发表一下自己的意见。我想大家就感觉你是在尊重他们的意见，时间长了，他们也能自己去独立的思考问题是如何解决的。 性格很多是由于习惯养成的。
posted @ 2005-01-29 15:25 情怀依旧 阅读(375) 评论(0) 编辑 最近看了一篇CSND上的一个帖子，提到了该问题，看来他的困惑也是我的困惑。 posted @ 2004-11-01 10:47 情怀依旧 阅读(420) 评论(0) 编辑 引用(O6Z)
减少耦合首先要从判断什么是耦合开始，这个问题我们不会有太多的分歧。 我们都应该明白耦合不是不可避免的，所以完全的去耦合根本就不可能。而实际上任何的应用在现实中，以及在我的认识中都受到其他因素的影响。这也使我们的设计实际上根本就不可能完全的达到去耦合。于是我们可以从职责的细分开始，也就是让职责可以在一个合适的粒度上，这样这个粒度的职责就总是被调用，而不是去调用别人然后又被调用这样的互相紧密关联。 同时我们也要注意到去耦合根本就不只是一个存在于面向对象领域的特殊概念，而是在任何的方式下都存在的问题。我也要注意到去耦合所要解决的问题是更好的面对变更，或者说是更好的可以被扩展。忘记这两点，单纯的探讨去耦合是没有意义的。也就是说我们要认识到，如果你的程序需求完全的确定，不需要考虑变更，你为区耦合作出的努力根本就没有价值。而且去耦往往还意味着，对于运行效能的降低。而实际上去耦的同时往往可能会带来新的潜在的耦合。实际上这里还是要落实到你的程序段落的职责是不适很明确的问题。 而耦合会带来系统的关联钝化，让你很难确认你的关注点。这其实也带来了你去耦的难度。而这实际上还是你的系统职责不清稀带来的去耦隐患。你要做的还是明确各个部分的职责。 而说到最后，实际上情况非常简单，就是你明确你的系统的职责。这可以用单一职责规则来得到保障，也就是你的程序中一个要素变化的原因，就只能是一个，一个改变只能带来一个直接的结果。任何的去藕无非就是在这个原则下就职责和职责的原因以及后果进行细分和组织。 posted @ 2004-11-01 09:43 情怀依旧 阅读(2415) 评论(1) 编辑 如何去掌握Architecture的构建.但是这些发言纯粹是一种学术性的见解,和实际中的情况基本完全不符合,到不是我不联系实际,而是实际上国内的公司基本上还都处于一种很无知而盲目的境地. Architecture的定义我已经在这里做过阐述,就不再多重复.在下面的联结中有我的一些讨论,基本上解答这个问题就足够了. 实际上Architecture基本上都是面向重用的,也就是面向变化的.而一个企业设置(注意是设置而不是设计)Architecture的时候,就意味着其将所有的开发过程和产品都用一种统一的风格来进行，而实际上设置一个Architecture基本上包含的技术因素非常少。我自己的说法是最多占25%.主要的成分是管理和对于市场的把握，而建立在此基础上的企业资源的调配.都是虽然技术的含量不多，但是技术在这里是一个基础性的条件，也是一个必要的条件，而设计(这里是设计)一个Architecture(我指的是在企业内部。而不是说j2ee或者dotnet这样的Architecture)，首先就是要掌握目前本身企业的技术活动的各种具体情况，其次就是把握自己过在行业的发展方向，然后就是技术的发展趋势，而对上述三点的把握基本上不是一个企业底层职员所可能知晓的，同时Architecture高度的抽象和概括，细节化是应该经过充分的基于对市场和行业的认识基础之上的，这一点基本上也从根本上消除了通过所谓的学习掌握这项技能的机会。 同时Architecture的构建是一个比较长期的过程，也是一个动态化的过程,这也是那些所谓的学习论者的一种不可逾越的鸿沟，而同时由于Architecture是一种高度的抽象，就需要大量的可供抽象的素材，也就是说企业已经进行了大量的实践，或者可以吸取其他人的大量实际操作的经验。而多数情况下，是企业已经有了自己的习惯性的框架framework，在此基础上作抽象,从而得出这个framework的设计主题,基于这个主题来建造Architecture.而实际上单纯的Architecture是没有任何的价值的，还需要基于这个Architecture的各种工具和组件，以及使用这些基础性结构的方法，而这些工作基本上都是以技术为基础的非技术性工作,可以说对于管理和市场的要求更高。 大家可以思考为什么现在的Gates的职务不是CEO,而MS的未来发展方向还主要掌握在他的手中,一个重要的原因就是实际上Gates就和他现在的头衔一样在负责设置MS的Architecture,实际上也只有他才能完成这个工作. 具体地讲，对于一个信息系统来说，架构可以分成三种：逻辑架构，物理架构和系统架构。 物理架构更多牵扯到硬件之间的关系，应用服务器、web服务器、数据库服务器、防火墙、代理服务器是如何配置和连接到一起的。 逻辑架构是指系统软件部件之间的关系，包括数据库软件、操作系统、应用服务器软件、应用系统等部件如何相互作用。特别是自己的应用系统内部的设计，至关重要，这可能是大家通常所指的架构设计部分，但这仅仅是逻辑架构的一部分而已。 系统架构说的是这些逻辑部件是如何放到物理部件上去的，以便取得所需要的scalability和performance。 posted @ 2004-10-27 09:29 情怀依旧 阅读(1609) 评论(1) 编辑 按照计划，今天应该完成ROSE导出模板，对于制作导出模板还不成问题，毕竟已经做过几次了，做完这次以后，想写一个模板制作的帮组文档，做一个小的工作总结。 posted @ 2004-09-13 10:34 情怀依旧 阅读(636) 评论(1) 编辑 在面向对象建模中，每一个对象都有一个生命期。对象创建时，生命期开始，对象删除时，生命期结束。在整个生命期中间，对象可能会接收到许多外部事件。
事件（Event）。 事件分两种，同步事件和异步事件。 posted @ 2004-09-06 08:50 情怀依旧 阅读(646) 评论(0) 编辑 |
||
