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