• 程序员的职业素养 读书笔记


    需求的沟通

    开发方与业务方之间最常见的沟通是关于需求的。业务方描述他们认为自己需要的东西,程序员按照自己理解的业务方表达的需求来开发。

    在现实里,关于需求的沟通是极其困难的,其中会出现各种问题。

    过早精细化

        做业务的人和写程序的人都容易陷入一个陷阱,即过早进行精细化。

        1、不确定原则

            每次向业务方展示一项功能,他们就获得了比之前更多的信息,这些新信息反过来又会影响他们对整个系统的看法,这种现象也叫观察者效应。

        2、预估焦虑

            开发人员会掉进精确化的陷阱。他们知道必须评估整个系统,而且通常认为需要精确评估。

            评估可以而且必须基于不那么精确的需求,这些评估只是评估而已。开发人员通常会在评估中使用误差棒,这样业务方就能理解不确定性。

    迟来的模糊性

        避免过早精细化的办法是尽可能地推迟精细化。但是,这可能造成另一个问题:迟来的模糊性。

        在具体的语境中看来,意思可能是非常清楚的,但是对阅读文档的程序员来说,意思可能截然不同。

    验收测试

    业务方与开发方合作编写的测试,其目的在于确定需求已经完成。

    “完成”的定义

        完成意味着所有的代码都写完了,所有的测试都通过了,QA和需求方已经认可。这才是完成。

    沟通

        验收测试的目的是沟通、澄清、精确化。

    自动化

        验收测试都应当自动进行。原因很简单:要考虑成本。

    额外工作

        验收测试是为了确定系统的各项指标符合要求。确定系统的指标;程序员才能确知“完成”;业务方才能确认开发的系统确定满足了需求;做到自动化测试。

    验收测试什么时候写,由谁来写

        在理想状态下,业务方和QA会协作编写验收测试,程序员来检查测试之间是否有冲突或矛盾。

        但实际上,业务方通常没有时间,或者有时间也难以达到所需要的细致程序,所以他们通常会把测试交给业务分析员、QA甚至是开发人员。

        业务分析员测试“正确路径”,以证明功能的业务价值。

        QA测试“错误路径”、边界条件、异常、例外情况,因为QA的职责是考虑哪些部分可能出问题。

    开发人员的角色

        实现某项功能的代码,应该在对应的验收测试完成后开始。

    测试的协商与被动推进

        专业开发人员,与编写测试的人协商并改进测试是你的职责。每个人都需要关心错误和疏忽,并协力改正。

    验收测试和单元测试

        单元测试是程序员写给程序员的,是正式的设计文档,描述了底层结构及代码的行为。关心单元测试结果的是程序员而不是业务人员。

        验收测试是业务方写给业务方的(可能会由开发者来写),是正式的需求文档,描述了业务方认为系统应该如何运行。关心验收测试结果的是业务方和程序员。

    图形界面及其他复杂因素

        测试系统功能时,应当调用真实的API, 而不是GUI。

    持续集成

        务必确保在持续集成系统中,单元测试和验收测试每天都能运行好几次。

        在持续集成系统里,失败的集成应该视为紧急情况,也就是“立刻中止”型事件。

  • 相关阅读:
    数据中台的“自动化数据治理”时代已来
    如何利用缓存机制实现JAVA类反射性能提升30倍
    快速入门开发实现订单类图片识别结果抽象解析
    Nginx专题(1):Nginx之反向代理及配置
    Github 上热门的 Spring Boot 项目实战推荐
    设计模式之命令模式(二)
    设计模式之命令模式(一)
    设计模式之单例模式(二)
    设计模式之单例模式(一)
    好的学习带给我什么
  • 原文地址:https://www.cnblogs.com/TanSea/p/ClearCoder-7.html
Copyright © 2020-2023  润新知