It’s Never Too Early to Think About Performance
2015-07-31 09:05
183 查看

BuSinESS uSERS SpECiFy THEiR nEEdS primarily through functional requirements. The nonfunctional aspects of the systems, like performance, resiliency, up-time, support needs, and the like, are the purview of the archi- tect. However, often the preliminary testing of nonfunctional requirements is left until very late in the development cycle, and is sometimes delegated com- pletely to the operations team. This is a mistake that is made far too often.
The reasons are varied. There is presumably no sense in making something fast and resilient if it doesn’t actually perform the required function. The envi- ronments and tests themselves are complex. Perhaps the early versions of the production system will not be as heavily utilized.
However, if you aren’t looking at performance until late in the project cycle, you have lost an incredible amount of information as to when performance changed. If performance is going to be an important architectural and design criterion, then performance testing should begin as soon as possible. If you are using an Agile methodology based on two-week iterations, I’d say performance testing should be included in the process no later than the third iteration.
Why is this so important? The biggest reason is that at the very least you know the kinds of changes that made performance fall off a cliff. Instead of having to think about the entire architecture when you encounter performance prob- lems, you can focus on the most recent changes. Doing performance testing early and often provides you with a narrow range of changes on which to focus.
26 97 Things Every Software Architect Should Know

In early testing, you may not even try to diagnose performance, but you do have a baseline of performance figures to work from. This trend data provides vital information in diagnosing the source of performance issues and resolv- ing them.
This approach also allows for the architectural and design choices to be vali- dated against the actual performance requirements. Particularly for systems with stringent requirements, early validation is crucial to delivering the system in a timely fashion.
Technical testing is also notoriously difficult to get going. Setting up appro- priate environments, generating the proper data sets, and defining the neces- sary test cases all take a lot of time. By addressing performance testing early, you can establish your test environment incrementally, thereby avoiding much more expensive efforts once you discover performance issues.
Dr. Rebecca Parsons is ThoughtWorks’ chief technology officer. She has more
than 20 years’ application development experience, in industries ranging from telecommunications to emergent Internet services. Rebecca has published in both language and artificial intelligence publications, served on numerous program committees, and reviews for several journals. She has extensive experience leading in the creation of large-scale distributed object applications and the integration of disparate systems.
It’s Never Too Early to Think About Performance
Rebecca ParsonsBuSinESS uSERS SpECiFy THEiR nEEdS primarily through functional requirements. The nonfunctional aspects of the systems, like performance, resiliency, up-time, support needs, and the like, are the purview of the archi- tect. However, often the preliminary testing of nonfunctional requirements is left until very late in the development cycle, and is sometimes delegated com- pletely to the operations team. This is a mistake that is made far too often.
The reasons are varied. There is presumably no sense in making something fast and resilient if it doesn’t actually perform the required function. The envi- ronments and tests themselves are complex. Perhaps the early versions of the production system will not be as heavily utilized.
However, if you aren’t looking at performance until late in the project cycle, you have lost an incredible amount of information as to when performance changed. If performance is going to be an important architectural and design criterion, then performance testing should begin as soon as possible. If you are using an Agile methodology based on two-week iterations, I’d say performance testing should be included in the process no later than the third iteration.
Why is this so important? The biggest reason is that at the very least you know the kinds of changes that made performance fall off a cliff. Instead of having to think about the entire architecture when you encounter performance prob- lems, you can focus on the most recent changes. Doing performance testing early and often provides you with a narrow range of changes on which to focus.
26 97 Things Every Software Architect Should Know

In early testing, you may not even try to diagnose performance, but you do have a baseline of performance figures to work from. This trend data provides vital information in diagnosing the source of performance issues and resolv- ing them.
This approach also allows for the architectural and design choices to be vali- dated against the actual performance requirements. Particularly for systems with stringent requirements, early validation is crucial to delivering the system in a timely fashion.
Technical testing is also notoriously difficult to get going. Setting up appro- priate environments, generating the proper data sets, and defining the neces- sary test cases all take a lot of time. By addressing performance testing early, you can establish your test environment incrementally, thereby avoiding much more expensive efforts once you discover performance issues.
Dr. Rebecca Parsons is ThoughtWorks’ chief technology officer. She has more
than 20 years’ application development experience, in industries ranging from telecommunications to emergent Internet services. Rebecca has published in both language and artificial intelligence publications, served on numerous program committees, and reviews for several journals. She has extensive experience leading in the creation of large-scale distributed object applications and the integration of disparate systems.
相关文章推荐
- One Line of Working Code Is Worth 500 of Specification
- 2019 数列有序!
- JS特效实现图片自动播放并可控的效果
- 嵌入式环境下的算法开发之学习建议
- Hdu 1950 bridging signals
- Quantify
- #每日Linux小练习#01 select命令的使用
- poj 3468 A Simple Problem with Integers
- 初始MVC
- 源码推荐(7.31):RENCache(文件缓存),头像设置,汉字拼音搜索
- uva140 Bandwidth(排列树+剪枝)
- 传入一个字符串,已知字符串只由字母组成,将其中的大写字母转换为小写,小写转换为大写,返回转换后的字符串
- 最小二乘法原理及极值点判定
- 利用Java注解将常量类生成js文件供前端调用
- java中的快速排序
- 另类SEO分享:利用JS封装iframe骗过搜索引擎
- PAT (Advanced Level) 1090. Highest Price in Supply Chain (25) 供应链,BFS
- SQL WHERE IN CHARINDEX()使用
- Linux下软件的安装与卸载方法
- 内存泄露方式有哪些和如何查询内存泄露?