首页 软件工程&架构

软件工程&架构

软件工程&架构null软件工程&架构软件工程&架构许式伟 2010-9-25自我介绍自我介绍许式伟，目前任职于盛大创新院。致力于改善国内的创业环境。前金山技术总监，WPS Office 2005首席架构师，开源爱好者，发布有Boost Memory、StdExt、TPL、WinxGui、DocX 等开源项目。技术关注领域：分布式存储、网络操作系统、Erlang风格编程与最佳服务端编程实践、搜索引擎等。话题缘起话题缘起软件质量保障重要性从本质上说，专业、高质量的产品和服务，才是企业真正意义上的生命线。源头：开发者本身的素质 ...

null软件工程&架构软件工程&架构许式伟 2010-9-25自我介绍自我介绍许式伟，目前任职于盛大创新院。致力于改善国内的创业环境。前金山技术总监，WPS Office 2005首席架构师，开源爱好者，发布有Boost Memory、StdExt、TPL、WinxGui、DocX 等开源项目。技术关注领域：分布式存储、网络操作系统、Erlang风格编程与最佳服务端编程实践、搜索引擎等。话题缘起话题缘起软件质量保障重要性从本质上说，专业、高质量的产品和服务，才是企业真正意义上的生命线。源头：开发者本身的素质代码的设计与实现外部保障：公司成熟度的标志工程管理专业的平台成就专业的产品AgendaAgenda代码学（设计与实现） KISS —— Keep it simple, stupid Modularity Testable Orthogonal Decomposition 工程学（项目管理）代码管理跟踪变化（任务/缺陷管理）自动化测试单元测试日构建代码的设计与实现代码的设计与实现代码的生命周期开发阶段仅占代码生命周期的极少时间。但这阶段的每一分每一秒都至关重要。影响维护阶段所需的投入。维护阶段的投入占多大比重？代码的生命周期开发阶段维护阶段KISS：简单比复杂好KISS：简单比复杂好不要增加无谓的复杂性除非有人为复杂性买单正确理解系统的需求之后才进行设计易实施性让模块容易实现，比复杂的优化更重要避免惊异让你的代码（包括接口）符合惯例Modularity：模块比框架更重要Modularity：模块比框架更重要框架是易变的框架都将经历不断发展演化的过程，逐步得到完善框架是业务流，可复用性相对更低。不让模块为框架买单模块设计时应忽略框架的存在认真审视模块的接口发现“过度的（或多余的）约束”Testable：保证可测试性Testable：保证可测试性设计应该以可测试性为第一目标一个模块可以很方便地进行测试，那么就可以说它是一个设计优良的模块。坚持进行单元测试可提高设计能力。可测试性 = 低耦合环境模拟（依赖的模块、数据输入）及时发现模块构架调整的潜在问题通常模块在架构调整期（代码重构）最容易引入Bug。只有在模块开发中就不断积累经典数据、以案例的形式固化已知Bug，才可能在架构调整等最容易引发问题的情形下获得最佳效果。 Orthogonal Decomposition：正交分解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 vs. SVN vs. GITCVS：“单文件”的版本管理不管理目录，无法跟踪工程结构的变化本地无版本管理功能 SVN：“项目”的版本管理全局的版本号，代表了系统的一个镜像状态本地可管理单一的历史版本（基版本）在CVS基础上，易用性有很大加强钩子：定制工作流 GIT：“项目群”的版本管理分布式的版本管理系统，可管理任意复杂的巨型项目（如Linux）分布的、松散的项目管理，适合大型开源项目无需联网，本地就有完整的版本管理能力跟踪变化：任务/缺陷管理跟踪变化：任务/缺陷管理Trac (Ticket Tracker) 是一个任务/缺陷管理工具可和SVN配合可以看到某个Bug的修复修改了哪些代码可以看到某一次Check In是为了什么自动化测试自动化测试自动化测试的必要性常规测试的缺陷一般是基于手工的，不具备可回归性。因此测试的效率不高。由于缺乏效率，往往导致测试仅仅针对典型数据，覆盖率往往也很低。自动化单元测试的重要特征自动化、可回归性 Quiet：没有错误，就不说话案例的执行安全受控某个案例的失败，不会影响其他案例的运行。单元测试的重要性单元测试的重要性测试成本最低单元（模块）是最容易，也是最应该采用自动化测试的。而集成测试、系统测试虽然也有自动化的方法和支持工具，但需要更高额的代价。减少问题发现的周期单元测试将问题的发现周期缩短，降低bug修复成本。如果问题在集成测试、系统测试期被发现，那么同样一个问题需要花几倍甚至几十倍的时间进行定位、修复。理解单元测试理解单元测试推广单元测试其实是规范单元测试方法和认识实际上单元测试大家都会去做，我们提倡单元测试，更大程度上是要达到：规范单元测试的编写（方法）固化已经发现的Bug，最大程度保留下来我们的测试案例（认识）- 重视测试代码：测试代码也是开发成果，理应获得和模块同等重要的地位，理应被保留下来。日构建（Daily Build）日构建（Daily Build）项目质量保障的最后一道关卡每天你都可以通过它获得一个当前系统健康状况的报告。做什么？检出代码（Check out）编译工程（Build）代码自动检查（Check）运行自动化测试案例（Test）报告结果（Report）如：Build、Check和Test的失败案例怎么做？工具：Ant / Shell scriptQ & AQ & A交流：xushiweizh@gmail.com 谢谢！

                    本文档为【软件工程&架构】，请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑，
                    图片更改请在作品中右键图片并更换，文字修改请直接点击文字进行修改，也可以新增和删除文档中的内容。 
 该文档来自用户分享，如有侵权行为请发邮件ishare@vip.sina.com联系网站客服，我们会及时删除。

                    [版权声明] 本站所有资料为用户分享产生，若发现您的权利被侵害，请联系客服邮件isharekefu@iask.cn，我们尽快处理。

                    本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权，请谨慎使用。

                    网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传，仅限个人学习分享使用，禁止用于任何广告和商用目的。
                

下载需要：免费已有0 人下载

立即下载

软件工程&架构

你可能还喜欢