标签：本书 读后感 06 总结 流程 用户 体验 第二篇 软件测试

《构建之法》却是本可以让人边学习边找乐子的优质教材：接地气的实战经验，与时俱进的产品案例，语言生动、寓教于乐，还附赠吐槽小技能，其犀利诙谐让人不禁捧书傻笑。而这种特色，正可让人愉快地接受理解知识且印象深刻，想必这位作者的授课教学也必是循循善诱的:)
虽说“内容重于形式”，但为提升用户体验、让阅读学习变得更更愉快，有建议如下：
① 格式建议：
1) 对章节分“篇”：这本书囊括广泛，开发、项目流程、交互设计、软件测试、管理，都有所涉及。将相关的几章归为一“篇”后，既可方便读者有针对性地阅读，同时在阅读过程中（譬如从第4章结对编程看到第5章团队和流程时）也不会因跳转突兀而感觉奇怪。
2) 每章末增加总结：在顺畅又愉快地通读完一章后，若能看到几句话的总结重述本章的重点，便可以及时温故。也与章开篇大纲、章末思考题相呼应。
3) 部分段落增加高亮/加粗的使用。这本书的知识点是和故事融合在一起，如果将概念或思想相关的字句都加粗，则可避免在快速浏览或复习时有所遗漏。同时这也将是备考学生们的福音。
②部分章节结构改进：
所涉案例和概念们在涉猎广泛的同时，也应有所类别划分以及侧重点，若有作者的综合评述则更佳。具体如：
1) 第12章（用户体验）：初次给我的阅读体验是，似乎每段都有所收获，读下来也很顺畅，结构却有些乱，尤其在看到某些部分联想到先前读过的书时难免觉得没“到位”。——该问题是难免的。毕竟是将可以写上好多本书的主题浓缩到一章内。
（既然类似文献综述的概述与本书风格有违）本书在介绍用户体验的一章就应另辟蹊径，更多体现与软件工程相关的流程，而不仅仅是具体的体验设计案例：可将12.2与12.1调换顺序：先叙述“用户体验设计的步骤”，随后再以各种案例锦上添花。而最好也能对设计步骤进行拓展。
此外，对于12.3中的7条评价标准，若要实践难免需硬背才能够记全那些标准。而其实各出处的标准都很精辟却又有些重合，建议分一下层次类别，就可以将其总结到一起~（譬如：Constraints, Affordances, Natural Mapping, Visibility and Feedbacks 相关都可归到*提高易用性*一类，此外考虑各种用户及操作情况的*周全完整的流程设计*，及error strategy相关的*风险/错误应对措施*均可作为分类。）这样不论是在评价体验设计时都会有章可循。
2) 第5章（团队和流程）13章（软件测试）：其中都涉及到较多定义。在读过后，难免会一时迷糊这段都讲了什么、该如何应用。因此适当地加入对比分析和作者总结，将使本书将不仅具备课堂上娓娓道来幽默风趣的生动带入感，更兼具老师的对比分析和复习指点，学习的体验和效率将大为提升。
比如5.2，虽已清楚地介绍各种团队模式的特点和优劣并有举例，但好坏混在一起，不知道哪种模式才是被推崇、应选择的。同样地，13.2中的各种软件测试方法，在概念叙述后也可以进行综合的总结。此外在随后的13.3实战流程中，也建以将测试方法的选用融合其中，从而体现其在实战中的应用和价值。这种有一定重复性的总结可以助力于温故而知新的过程。
最后，不要被高大上的书名和高冷的封面误导哦~

标签：本书,读后感,06,总结,流程,用户,体验,第二篇,软件测试
来源： https://www.cnblogs.com/liuchao437/p/15865597.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。