其他分享
首页 > 其他分享> > 《软件开发的201个原则》

《软件开发的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