构建之法第六次随笔

我这个礼拜阅读了构建之法第12,13章。

其中,第十二章讲的是用户体验,我们要考虑用户体验的不同角度,用户的第一印象就很重要,用户第一次使用软件,就很大程度上决定了用户对软件的评价。软件服务始终都要记住用户的选择,从用户的角度考虑,要有一颗同理心。理解用户的处境,心理,动机的能力有着一颗为用户着想的同理心,是好的产品设计的出发点。也不要让用户犯简单的错误,所以要不停改进,高明的设计能让用户不需要花费额外的注意力,也不需要经验与专业知识即可凭借直觉完成正确的操作。

对于一个软件的用户界面,有一些原则:

  1. 尽快提供可感触的反馈
  2. 系统界面符合用户的现实惯例
  3. 用户有控制权
  4. 一致性和标准化
  5. 适合各种类型的用户
  6. 帮助用户识别,诊断并修复错误
  7. 有必要的提示和帮助文档

第十三章讲的是软件测试。主要讲了各种测试方法和测试的设计方法。我明白了测试的时候要各个角度都还是看一些犄角旮旯也得用一些随机的数据去鼓捣。拿到一个测试任务的时候,就想这个功能最可能在哪里出问题,测试的时候也要举一反三,看到产品标题字段出了问题就要检测一下别的字段有没有相同的问题。更要注重从产品的风险出发进行测试,也要从当前的产品特性决定测试的策略,举一反三。也可以把一些比较稳定的测试写成自动测试,这样就减轻了手工测试的压力。

时间: 2024-08-01 05:50:39

构建之法第六次随笔的相关文章

构建之法第六章学习心得

这周我学习了构建之法第六章敏捷流程,本章主要介绍了敏捷流程及其原则,Backlog.Burn-down.Sprint.Scrum方法论.以及什么时候选择敏捷的开发方法,什么时候选择其他方法..敏捷开发的原则是尽早并持续地交付有价值的软件以满足顾客需求敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势经常发布可用的软件,发布间隔可以从几周到几个月,能短则短业务人员和开发人员在项目开发过程中应该每天共同工作以有进取心的人为项目核心,充分支持信任他们无论团队内外,面对面的交流始终是最有效的沟通

读《构建之法》的第一次随笔

在收到纸质书籍到手之前,我简单的看了一些多看阅读上的试读章节.第一章开始便以程序猿们编程遇到的各种问题引出了软件工程的重要性.在一个工程的进展过程中,各种的不确定性因素会以多种不同的方式阻碍项目的正常运转,例如,软件的质量提升,特殊需求的引入,文档.流程和工具的正确性等都会蚕食项目的工期和质量.如果不加以控制和规范化,越是大型的项目,导致失败潜在的危机越是巨大. 根据多年的工作经验学习以及前人留下的案例,作者邹欣老师也总结了程序(算法.数据结构)是基本功,但在算法和数据之上,软件工程决定了软件的

构建之法 第六次心得

构建之法12.13章小结 第12章 这一章讲的是用户体验,对于软件的使用,用户的体验是非常重要的方面,如果一个软件给用户的体验不好,那么这个软件无疑是不会受到欢迎的.但是用户体验和用户界面的领域不是那么容易的,这两个需要丰富内容的学术领域.就像一个游戏,如果这个游戏界面单调,但是操作又非常复杂,那么用户可能很快就失去了兴趣. 在设计软件界面时,我们也要考虑到使用这个软件的人群的特征,使用习惯等等,可以根据这些来设计界面,还要让用户在每次使用的时候减少对自己没有价值的部分的访问,尽量使得用户不浪费

构建之法——第六篇

经过一段时间的学习,我已学习到<构建之法>的第八章需求分析.本周我将继续学习第九章项目经理.第十章典型用户和场景.第十一章软件设计与实现. 第九章项目经理主要给我们介绍的是在企业里占据重要位置的项目经理.项目经理的作用就表现于他在企业中充当了中间人的角色.对外,项目经理需要与客户交流,发现用户需求,了解和比较竞争对手的产品,改进团队流程等.对内,需要把市场/销售人员那一套MBA的套路语言翻译成程序员能懂的规格说明书,这样可以大大节省开发人员的麻烦.而一个合格的项目经理,必须要具备观察.理解和快

《构建之法》第二次随笔

阅读了<构建之法>第一章中软件工程的概论,我学习到了"软件=程序+软件工程"这个黄金公式,并且对软件工程充满了兴趣和信心.但是,一个好的软件工程开发团队需要首先确保团队里的每个成员是合格的工程师,为此我们得先普及一些基本概念和技术,即单元测试.回归测试和效能分析工具.书的第二章讲述了个人技术和流程,给我们着重介绍了PSP(个人软件开发流程). 绝大部分软件都是由多人合作完成的,大家的工作相互有依赖关系.怎么才算一个好的单元测试?单元测试应该准确.快速地保证基本模块的正确性:

构建之法第六、七章读后感

第六章 Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的.迭代的开发过程.Scrum包括了一系列实践和预定义角色的过程骨架.Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员. 敏捷流程一共有4步: 第一步:弄懂需求与任务是相互依赖的关系 第二步:想要学会把一个任务从产品层级的描述逐步细化到技术实现层面,那么技术能力和交流能力尤为重要的,根据每个人的能力来分配任务以保证任务的高效完成. 第三步:个人要

构建之法小结六

本周阅读了第六章,主要了解了敏捷流程. 敏捷流程是指价值观和方法论的集合.本章详细介绍了 敏捷流程的流程.流程的问题和解法等.该流程强调快 速反馈,从开始采取行动,到获得行动的反馈,二者之 间的时间至关紧要.和其他人一共开发模型,你的想法 可以立刻获得反馈.但敏捷并不是粗糙,它强调高效率 的工作.对卓越技术与良好设计的不断追求将有助于提 高敏捷性.

构建之法第六七八章

第六章 敏捷流程 敏捷流程开发原则 1.尽早并持续的交付有价值的软件以满足顾客需求 2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 4.业务人员和开发人员在项目开发过程中应该每天共同工作 5.以有进取心的人为项目核心,充分支持信任他们 6.无论团队内外,面对面的交流始终是最有效的沟通方式 7.可用的软件是衡量项目进展的主要指标 8.敏捷流程应能保持可持续的发展.领导.团队和用户应该能按照目前的步骤持续合作下去 9.只有

构建之法第六,七章

第六章 敏捷流程 敏捷是一种态度,而不是一个说明性的过程.它不能解决问题,但可以用于优化解决问题的过程. 我们最优先要做的是通过尽早的,持续的交付有价值的软件来使客户满意.即使到了开发后期,也欢迎改变需求.敏捷过程利用变化来为客户创造竞争优势:经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好:在整个项目开发期间,业务人员和开发人员必须天天都在一起工作围绕被激励起来的个人构件项目,给他们提供所需要的环境和支持,并且信任他们能够完成工作.在团队内部,最有效果的信息传递