展开全部

主编推荐语

用“原则”讲透软件研发底层方法,从需求分析到产品演进,覆盖产品研发全流程。

内容简介

本书汇总了软件工程原则。原则是关于软件工程的基本原理、规则或假设,不管所选的技术、工具或语言是什么,这些原则都有效。

全书共9章,第1章为引言,后面8章将201个软件工程的原则划分为8个大的类别:一般原则、需求工程原则、设计原则、编码原则、测试原则、管理原则、产品保证原则和演变原则。

本书面向的读者包括软件工程师和管理者、软件工程专业的学生、软件工程领域的研究人员等。

目录

  • 版权信息
  • 其 他
  • 内容简介
  • 给中国软件工程师的寄语
  • 推荐序1
  • 推荐序2
  • 推荐序3
  • 推荐语
  • 作者序
  • 简装本译者序
  • 译者序
  • 前言
  • 第1章 引言
  • 第2章 一般原则
  • 原则1 质量第一
  • 原则2 质量在每个人眼中都不同
  • 原则3 开发效率和质量密不可分
  • 原则4 高质量软件是可以实现的
  • 原则5 不要试图通过改进软件实现高质量
  • 原则6 低可靠性比低效率更糟糕
  • 原则7 尽早把产品交给客户
  • 原则8 与客户/用户沟通
  • 原则9 促使开发者与客户的目标一致
  • 原则10 做好抛弃的准备
  • 原则11 开发正确的原型
  • 原则12 构建合适功能的原型
  • 原则13 要快速地开发一次性原型
  • 原则14 渐进地扩展系统
  • 原则15 看到越多,需要越多
  • 原则16 开发过程中的变化是不可避免的
  • 原则17 只要可能,购买而非开发
  • 原则18 让软件只需简短的用户手册
  • 原则19 每个复杂问题都有一个解决方案
  • 原则20 记录你的假设
  • 原则21 不同的阶段,使用不同的语言
  • 原则22 技术优先于工具
  • 原则23 使用工具,但要务实
  • 原则24 把工具交给优秀的工程师
  • 原则25 CASE工具是昂贵的
  • 原则26 “知道何时”和“知道如何”同样重要
  • 原则27 实现目标就停止
  • 原则28 了解形式化方法
  • 原则29 和组织荣辱与共
  • 原则30 跟风要小心
  • 原则31 不要忽视技术
  • 原则32 使用文档标准
  • 原则33 文档要有术语表
  • 原则34 软件文档都要有索引
  • 原则35 对相同的概念用相同的名字
  • 原则36 研究再转化,不可行
  • 原则37 要承担责任
  • 第3章 需求工程原则
  • 原则38 低质量的需求分析,导致低质量的成本估算
  • 原则39 先确定问题,再写需求
  • 原则40 立即确定需求
  • 原则41 立即修复需求规格说明中的错误
  • 原则42 原型可降低选择用户界面的风险
  • 原则43 记录需求为什么被引入
  • 原则44 确定子集
  • 原则45 评审需求
  • 原则46 避免在需求分析时进行系统设计
  • 原则47 使用正确的方法
  • 原则48 使用多角度的需求视图
  • 原则49 合理地组织需求
  • 原则50 给需求排列优先级
  • 原则51 书写要简洁
  • 原则52 给每个需求单独编号
  • 原则53 减少需求中的歧义
  • 原则54 对自然语言辅助增强,而非替换
  • 原则55 在更形式化的模型前,先写自然语言
  • 原则56 保持需求规格说明的可读性
  • 原则57 明确规定可靠性
  • 原则58 应明确环境超出预期时的系统行为
  • 原则59 自毁的待定项
  • 原则60 将需求保存到数据库
  • 第4章 设计原则
  • 原则61 从需求到设计的转换并不容易
  • 原则62 将设计追溯至需求
  • 原则63 评估备选方案
  • 原则64 没有文档的设计不是设计
  • 原则65 封装
  • 原则66 不要重复造轮子
  • 原则67 保持简单
  • 原则68 避免大量的特殊案例
  • 原则69 缩小智力距离
  • 原则70 将设计置于知识控制之下
  • 原则71 保持概念一致
  • 原则72 概念性错误比语法错误更严重
  • 原则73 使用耦合和内聚
  • 原则74 为变化而设计
  • 原则75 为维护而设计
  • 原则76 为防止出现错误而设计
  • 原则77 在软件中植入通用性
  • 原则78 在软件中植入灵活性
  • 原则79 使用高效的算法
  • 原则80 模块规格说明只提供用户需要的所有信息
  • 原则81 设计是多维的
  • 原则82 优秀的设计出自优秀的设计师
  • 原则83 理解你的应用场景
  • 原则84 无须太多投资,即可实现复用
  • 原则85 “错进错出”是不正确的
  • 原则86 软件可靠性可以通过冗余来实现
  • 第5章 编码原则
  • 原则87 避免使用特殊技巧
  • 原则88 避免使用全局变量
  • 原则89 编写可自上而下阅读的程序
  • 原则90 避免副作用
  • 原则91 使用有意义的命名
  • 原则92 程序首先是写给人看的
  • 原则93 使用最优的数据结构
  • 原则94 先确保正确,再提升性能
  • 原则95 在写完代码之前写注释
  • 原则96 先写文档后写代码
  • 原则97 手动运行每个组件
  • 原则98 代码审查
  • 原则99 你可以使用非结构化的语言
  • 原则100 结构化的代码未必是好的代码
  • 原则101 不要嵌套太深
  • 原则102 使用合适的语言
  • 原则103 编程语言不是借口
  • 原则104 编程语言的知识没那么重要
  • 原则105 格式化你的代码
  • 原则106 不要太早编码
  • 第6章 测试原则
  • 原则107 依据需求跟踪测试
  • 原则108 在测试之前早做测试计划
  • 原则109 不要测试自己开发的软件
  • 原则110 不要为自己的软件做测试计划
  • 原则111 测试只能揭示缺陷的存在
  • 原则112 虽然大量的错误可证明软件毫无价值,但是零错误并不能说明软件的价值
  • 原则113 成功的测试应发现错误
  • 原则114 半数的错误出现在15%的模块中
  • 原则115 使用黑盒测试和白盒测试
  • 原则116 测试用例应包含期望的结果
  • 原则117 测试不正确的输入
  • 原则118 压力测试必不可少
  • 原则119 大爆炸理论不适用
  • 原则120 使用McCabe复杂度指标
  • 原则121 使用有效的测试完成度标准
  • 原则122 达成有效的测试覆盖
  • 原则123 不要在单元测试之前集成
  • 原则124 测量你的软件
  • 原则125 分析错误的原因
  • 原则126 对“错”不对人
  • 第7章 管理原则
  • 原则127 好的管理比好的技术更重要
  • 原则128 使用恰当的方法
  • 原则129 不要相信你读到的一切
  • 原则130 理解客户的优先级
  • 原则131 人是成功的关键
  • 原则132 几个好手要强过很多生手
  • 原则133 倾听你的员工
  • 原则134 信任你的员工
  • 原则135 期望优秀
  • 原则136 沟通技巧是必要的
  • 原则137 端茶送水
  • 原则138 人们的动机是不同的
  • 原则139 让办公室保持安静
  • 原则140 人和时间是不可互换的
  • 原则141 软件工程师之间存在巨大的差异
  • 原则142 你可以优化任何你想要优化的
  • 原则143 隐蔽地收集数据
  • 原则144 每行代码的成本是没用的
  • 原则145 衡量开发效率没有完美的方法
  • 原则146 剪裁成本估算方法
  • 原则147 不要设定不切实际的截止时间
  • 原则148 避免不可能
  • 原则149 评估之前先要了解
  • 原则150 收集生产力数据
  • 原则151 不要忘记团队效率
  • 原则152 LOC/PM与语言无关
  • 原则153 相信排期
  • 原则154 精确的成本估算并不是万无一失的
  • 原则155 定期重新评估排期
  • 原则156 轻微的低估不总是坏事
  • 原则157 分配合适的资源
  • 原则158 制订详细的项目计划
  • 原则159 及时更新你的计划
  • 原则160 避免驻波
  • 原则161 知晓十大风险
  • 原则162 预先了解风险
  • 原则163 使用适当的流程模型
  • 原则164 方法无法挽救你
  • 原则165 没有奇迹般提升效率的秘密
  • 原则166 了解进度的含义
  • 原则167 按差异管理
  • 原则168 不要过度使用你的硬件
  • 原则169 对硬件的演化要乐观
  • 原则170 对软件的进化要悲观
  • 原则171 认为灾难是不可能的想法往往导致灾难
  • 原则172 做项目总结
  • 第8章 产品保证原则
  • 原则173 产品保证并不是奢侈品
  • 原则174 尽早建立软件配置管理过程
  • 原则175 使软件配置管理适应软件过程
  • 原则176 组织SCM独立于项目管理
  • 原则177 轮换人员到产品保证组织
  • 原则178 给所有中间产品一个名称和版本
  • 原则179 控制基准
  • 原则180 保存所有内容
  • 原则181 跟踪每一个变更
  • 原则182 不要绕过变更控制
  • 原则183 对变更请求进行分级和排期
  • 原则184 在大型开发项目中使用确认和验证(V&V)
  • 第9章 演变原则
  • 原则185 软件会持续变化
  • 原则186 软件的熵增加
  • 原则187 如果没坏,就不要修理它
  • 原则188 解决问题,而不是症状
  • 原则189 先变更需求
  • 原则190 发布之前的错误也会在发布之后出现
  • 原则191 一个程序越老,维护起来就越困难
  • 原则192 语言影响可维护性
  • 原则193 有时重新开始会更好
  • 原则194 首先翻新最差的
  • 原则195 维护阶段比开发阶段产生的错误更多
  • 原则196 每次变更后都要进行回归测试
  • 原则197 “变更很容易”的想法,会使变更更容易出错
  • 原则198 对非结构化代码进行结构化改造,并不一定会使它更好
  • 原则199 在优化前先进行性能分析
  • 原则200 保持熟悉
  • 原则201 系统的存在促进了演变
  • 作者介绍
  • 参考资料索引
  • 术语索引
展开全部

评分及书评

4.3
6个评分
  • 用户头像
    给这本书评了
    3.0
    软件开发遵循的基础原则

    虽然看起来有 201 个原则,但是某一些原则可以合并,实则没有 201 个那么多。本书将软件开发原则分为:一般原则、需求工程原则、设计原则、编码原则、测试原则、管理原则、产品保证原则和演变原则。书中的每个原则内容短小精悍,独立成文,又相互联系,沉淀大量软件工程理论,虽然有点旧,但依然是软件开发必读书籍。

      转发
      评论
      用户头像
      给这本书评了
      5.0
      一本像目录一样的纯干货书

      本书涵盖了软件工程中的方方面面,包括需求,设计,开发,测试,维护,项目管理等,每个原则都是精华当不能理解规则的要求时,就遵守他。书中有些原则需要参考一些其他资料才能补齐,可以当一个地图或大纲来用。

        转发
        评论
        用户头像
        给这本书评了
        5.0
        迈向职业化的必读书

        看过太多乌七八糟的代码,这本书给出了程序员的职业原则,并给出了索引资料。他其实就是程序员的三大纪律八项注意。能理解别人为什么给出低分,无收获的原因,因为法条和入门书籍相比不公平,这也不是武功秘籍,先职业才专业。

          转发
          评论
        • 查看全部4条书评

        出版方

        电子工业出版社

        电子工业出版社成立于1982年10月,是国务院独资、工信部直属的中央级科技与教育出版社,是专业的信息技术知识集成和服务提供商。经过三十多年的建设与发展,已成为一家以科技和教育出版、期刊、网络、行业支撑服务、数字出版、软件研发、软科学研究、职业培训和教育为核心业务的现代知识服务集团。出版物内容涵盖了电子信息技术的各个分支及工业技术、经济管理、科普与少儿、社科人文等领域,综合出版能力位居全国出版行业前列。