软件工程架构.pptVIP

* KISS 是大家耳熟能详的词。我相信不管读没读过《UNIX编程艺术》一书的人都听过。这里借这个词，表达下我对程序编写最基础的一些规则的见解。 程序员都是自信的，所以设计过度是一种常见现象。“不要增加无谓的复杂性”，是希望正确理解需求。应对变化是应该的，但是不能过于扩散。 优化不应该破坏易实施性。坚信最优化的代码总是看起来很简单简洁的。 * “模块比框架更重要”，这个观点可能和很多人的看法背道而驰。 但是我想强调的是，没有一个框架是稳定不变的。 所以，在承认这个事实的基础上，你应该懂得去尽可能地减少系统为此（指框架调整）而付出的代价。 所以，我的结论是：模块很重要。模块接口比一切都重要。 * 为什么需要模块是可测试的？ * Office UI Logic的复杂性： Undo/redo 宏录制 版式 Selection 状态 … * See /xushiweizh/archive/2008/02/19/2104631.aspx (自动化单元测试的意义). * Static check：代码规范、代码检查。 Runtime check：代码覆盖率检查。 软件工程架构 许式伟 2010-9-25 自我介绍 许式伟，目前任职于盛大创新院。致力于改善国内的创业环境。前金山技术总监，WPS Office 2005首席架构师，开源爱好者，发布有Boost Memory、StdExt、TPL、WinxGui、DocX 等开源项目。技术关注领域：分布式存储、网络操作系统、Erlang风格编程与最佳服务端编程实践、搜索引擎等。 话题缘起 软件质量保障 重要性 从本质上说，专业、高质量的产品和服务，才是企业真正意义上的生命线。 源头：开发者本身的素质 代码的设计与实现 外部保障：公司成熟度的标志 工程管理 专业的平台成就专业的产品 Agenda 代码学（设计与实现） KISS —— Keep it simple, stupid Modularity Testable Orthogonal Decomposition 工程学（项目管理） 代码管理 跟踪变化（任务/缺陷管理） 自动化测试 单元测试 日构建 代码的设计与实现 开发阶段仅占代码生命周期的极少时间。 但这阶段的每一分每一秒都至关重要。影响维护阶段所需的投入。 维护阶段的投入占多大比重？ 代码的生命周期 代码首次完成 维护代码直至消亡 开发阶段 维护阶段 KISS：简单比复杂好 不要增加无谓的复杂性 除非有人为复杂性买单 正确理解系统的需求之后才进行设计 易实施性 让模块容易实现，比复杂的优化更重要 避免惊异 让你的代码（包括接口）符合惯例 Modularity：模块比框架更重要 框架是易变的 框架都将经历不断发展演化的过程，逐步得到完善 框架是业务流，可复用性相对更低。 不让模块为框架买单 模块设计时应忽略框架的存在 认真审视模块的接口 发现“过度的（或多余的）约束” Testable：保证可测试性 设计应该以可测试性为第一目标 一个模块可以很方便地进行测试，那么就可以说它是一个设计优良的模块。 坚持进行单元测试可提高设计能力。 可测试性 = 低耦合 环境模拟（依赖的模块、数据输入） 及时发现模块构架调整的潜在问题 通常模块在架构调整期（代码重构）最容易引入Bug。 只有在模块开发中就不断积累经典数据、以案例的形式固化已知Bug，才可能在架构调整等最容易引发问题的情形下获得最佳效果。 Orthogonal Decomposition：正交分解 架构就是不断地对系统进行正交分解的过程 优先考虑组合，而不是继承 做乘法而不是做加法 eg. 抽取一个url中的outlinks outlinks(in: url) - out: unique_outlinks curl url 2 /dev/null | hrefs | sort -u 通用组件 curl(in: url) - out: file_content/html_text hrefs(in: html_text) - out: outlinks regex(text/html_text, pattern) - matches/outlinks sort-u(in: records/outlinks) - out: unique_records/unique_outlinks 专业的平台成就专业的产品 代码管理：CVS vs. SVN vs. GIT CVS：“单文件”的版本管理 不管理目录，无法跟踪工程结构的变化 本地无版本管理功能 SVN：“项目”的版本管理 全局的版本号，代表了系统的一个镜像状态 本地可管理单一的历史版本（基版本） 在CVS基础上，易用性有很大加强 钩子：定制工作流 GIT：“项目群”的版