比熊

摘要： 阅读全文

摘要： 1.一切的技术都是为实际需求服务的.需求重于技术,因为技术只是实现手段;新的技术的引入需要注意所有你要面临的问题(开发成本,维护成本,性能问题,系统升级,用户反响...);2. 事物是复杂的,需要逐步分解,但需要记住全局的把握是达到解决方案的最佳途径.3.一个优秀的策划工作可以让我们的开销降到最低.事实证明绝大部分bug是需求做出了问题,而自身的产品设计往往被自我的策划所误导;4.技术出了问题,如果不是架构师的问题,那么就是需求策划上出了问题;5.优良的架构与产品开销不可分离;6.客户的需求需要你仔细琢磨,因为既有可能似是而非,而自我产品的设计需要的是把握用户的需求.7.好的团队,希望每一个队 阅读全文

摘要： 软件工程：应用计算机科学、数据及管理学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。 1.软件生存周期 软件生存周期包括：可行性分析与项目开发计划、需求分析、设计(概要设计和详细设计)、编码、测试、维护。 1）可行性分析与项目计划 内容：确定开发目标及可行性。 参与人：用户、项目负责人、系统分析师。 输出：可行性分析报告和项目开发计划。 2）需求分析 内容：确定软件系统的功能、性能、数据、界面等要求。 参与人：用户、项目负责人、系统分析师。 输出：软件需求说明书 3）概要设计 内容：开发人员把确定的各项功能需求转换成需要的体系结构。... 阅读全文

摘要： vo的作用有两种：1.模块隔离：对外暴露，屏蔽内部实现。2.分布式支持：用于异步传输；换句话说：如果不打算进行严格的模块化/组件化，又没有分布式场景，就不应该使用VO。如果不打算进行严格的模块化/组件化，但存在部分分布式场景，比如lz所说的flex，那么针对部分进行VO开发即可；此外，决定是否启用VO除了上述两个作用对应的场景外，另有如下两个因数：1.PO是否是Rich Model？2.开发人员是按分层分工还是按功能分工？如果PO是贫血的，且是按分层分工开发的那么应该启用VO，因为，由于后台模型变化导致前台的调整会带来沟通协调的成本；如果PO是Rich Model，且是按功能分工，那么就不应使 阅读全文

摘要： 背景： 今将自己设计的系统画成结构图，该系统目前还处于初步的构思，且实现了雏形，可运行基本功能，现用随笔记录一下。内容： 需求简介：实现对Windows、Aix、空调、路由等等的实时监控，访问其关键数据并进行分析及相应操作。 设计简介：主要采用领域驱动的思想进行设计。以Windows服务作为程序运新的主要载体，通过B/S对外提供展示及配置，ORM用的是NHibernate、其他用到的包括Spring.net、Log4Net等，结构图如下： 阅读全文

摘要： 一、软件架构1.架构相关关键点： 软件架构的关键点是软件应该符合项目干系人的期待，期待包括功能性和非功能性。若想完成该目标必须满足一个架构上的约定，即一些重要的决定必须开发初期确定。因此，软件架构必须着眼于系统的组织和基础设施的分布，随后即可开始对系统进行设计和描述。2.系统分解： 系统分解是将将整个系统拆分成一个个子系统，并定义子系统间通信策略的过程。分解过程的成果是创建一系列详细设计说明书。3.如何判断一个架构的好坏: 好的架构中，所有给出的不轻易改变的决定都是正确的。 [若你发现有些东西比你想象的更容易改变，那么它就不再属于架构]4.在“架构”一词的范畴中，所有的事情都需要谨慎考... 阅读全文