像盖房子一样写代码

更新日期: 2018-09-22阅读: 2k标签: 代码

当我写一个功能模块方法时,我在想些什么

// 无论什么方法,都是这样一个结构
const fn = () => {

};

比比如,我要写一个接口,查询组织下的设备列表 /api/device/list


地基

const deviceList = (params) => { // 传入一些参数
  return []; // 返回一个列表
};

我需要哪些参数:

  • 用户基本信息(主要是用户 id,用户的组织 id)
  • 用户对应的组织基本信息(主要是组织 id,组织管理员 id,层级关系,以及权限逻辑)

输出结果很简单,为一个数组。


浇筑

第一步分析,存在成功和错误(错误类型先不考虑)两种类型的结果。

// 成功
// 错误
const deviceList = async (ctx) => {
  // 错误
  if(someError) {
    // 返回错误结果
  }
  // 成功
  return getDevicesByOid(oid);
};

这是一个大概的设想,没有必要将代码写出来。然后润化该思路,写出第一段框架


主体结构

首先,传入的参数为组织 oid,用户的信息可以通过 session(或其他方式)从内部获得。


可能的一种思路

// 成功
// 错误
// 错误1:用户未加入组织
// 错误2:传入参数组织不存在
// 错误3:用户无组织权限

// 传入参数: 要查询的组织 oid
// 能够通过 session 取到的信息: user
const deviceList = async (ctx) => {
  // 用户信息 ctx.user
  // 判断用户是否有组织
  if (ctx.user.oid === 0) {
    // 错误1:用户未加入组织
  }

  // 如果不传该参数,查询当前用户组织的设备
  const { oid = ctx.user.oid } = ctx.request.body;
  if (oid === ctx.user.oid) {
    // 成功
    return getDevicesByOid(oid);
  }

  // 根据oid查询组织信息
  // 错误2:传入参数组织不存在
  // 判断是否有权限
  const checkRights = await checkUserOrgRights(ctx.user.uid, oid);
  if (!checkRights) {
    // 错误3:用户无组织权限
  }
  // 成功
  return getDevicesByOid(oid);
};


推荐的实现方式

// 成功
// 错误
// 错误1:用户未加入组织
// 错误2:传入参数组织不存在
// 错误3:用户无组织权限

// 传入参数: 要查询的组织 oid
// 能够通过 session 取到的信息: user
const deviceList = async (ctx) => {
  // 用户信息 ctx.user
  // 判断用户是否有组织
  if (ctx.user.oid === 0) {
    // 错误1:用户未加入组织
  }

  // 如果不传该参数,查询当前用户组织的设备
  const { oid = ctx.user.oid } = ctx.request.body;
  if (oid !== ctx.user.oid) {
    // 为什么这里不用等于判断:如果等于的话,则当时就需要返回出去,这样的话该方法会有两个成功的 return
    // 根据oid查询组织信息
    // 错误2:传入参数组织不存在
    // 判断是否有权限
    const checkRights = await checkUserOrgRights(ctx.user.uid, oid);
    if (!checkRights) {
      // 错误3:用户无组织权限
    }
  }
  // 成功
  return getDevicesByOid(oid);
};


封顶

完成其他的业务代码。


当我写一段测试的时候,我在想些什么

按照上面推荐方式完成代码后,需要进行代码的测试。

首先需要明确业务的流程,理清测试的思路。

  • 成功
  • 错误

    • 错误1:用户未加入组织
    • 错误2:传入参数组织不存在
    • 错误3:用户无组织权限

主要有两种设计思路:

设计思路

思路一

  1. 完成测试用例,覆盖成功的所有情况
  2. 完成测试用例,覆盖错误1的所有情况
  3. 完成测试用例,覆盖错误2的所有情况
  4. 完成测试用例,覆盖错误3的所有情况

这是传统的单元测试衍生而来的 BDD 测试方式。

这里测试用例的个数应该为8次:

  • 成功:

    • 1.当前组织的用户有传入组织 oid
    • 2.当前组织的用户未传入组织 oid
    • 3-5.上级组织,上上级组织,根级组织的管理员用户传入组织 oid
  • 6.失败1:用户未加入组织
  • 7.失败2:传入参数组织不存在
  • 8.失败3:用户无组织权限

其中,测试3-5可以优化为一次测试(即根据所有管理员 uid 的数组比较是否包含当前用户 uid),最终优化后的结果应当为6次。

但由于该思路中不明确用户,所以用户行为无法准确表达,在创建测试数据的时候较为困难,不仔细思考分析,无法优化需要创建多少条测试数据。


思路二

而实际上 BDD 测试为用户行为测试,可以以几类用户的情形分别进行测试。

  1. 模拟一个用户的数据,覆盖成功和可能错误(有可能无法涵盖到所有错误)的所有情况
  2. 根据未覆盖的部分,再模拟另一个用户的数据,覆盖成功和可能错误(有可能无法涵盖到所有错误)的所有情况

以此循环,直至覆盖所有。

  • 用户1(非组织管理员,查询自己的组织)

    • 1.成功(未传入组织 oid)(组织1)
    • 2.成功(传入组织 oid)
    • 3.失败2:传入参数组织不存在
    • 4.失败3:用户无组织权限(组织2)
  • 用户2(上级某组织管理员)(组织3)

    • 5.成功
  • 用户3(未加入组织用户)

    • 6.失败1:用户未加入组织

非常简洁明了的关系,需要3个测试用户,3个组织(上下级关系进行数据复用,一个无权限的组织),即可涵盖所有范围。

最终优化版设计:

  • 用户1(某组织管理员,有下级组织)

    • 1.成功(未传入组织 oid,查询自己的组织)
    • 2.成功(传入当前的组织 oid(组织1))
    • 3.成功(传入下级的组织 oid(组织2))
    • 4.失败2:传入参数组织不存在
    • 5.失败3:用户无组织权限
  • 用户2(未加入组织用户)

    • 6.失败1:用户未加入组织(组织3)

两个用户,三个组织。完成所有覆盖。


当我以测试驱动开发的时候,我在想些什么

可以从上述测试思路二中进行反推。

实际上思路可能是在写代码或者写测试的过程中不断的改进和完善的。

  • 如果已经写好了测试正在写代码,可以及时回过头来调整测试;
  • 如果功能写好了又再重新测试,可以在测试优化后再去看逻辑代码是否还有优化的空间。

更多关注: https://leader.js.cool/#/expe...


链接: https://fly63.com/article/detial/2514

不要浪费时间写完美代码

一个系统可以维持5年,10年,甚至20年以上,但是代码和设计模式的生命周期非常短,当对一个解决方案使用不同的方法进行迭代的时候,通常只能维持数月,数日,甚至几分钟的时间

Google内部在代码质量上的实践

良好的编程习惯涉及到很多方面,但在软件行业内,大多数的公司或组织都不会把良好的编程习惯列为主要关注点。 例如,具有可读性和可维护性的代码比编写好的测试代码或使用正确的工具更有意义,前者的意义在于可以让代码更易于理解和修改。

减少嵌套,降低代码复杂度

减少嵌套会让代码可读性更好,同时也能更容易的找出bug,开发人员可以更快的迭代,程序也会越来越稳定。简化代码,让编程更轻松!

关于 Google 发布的 JS 代码规范

Google为了那些还不熟悉代码规范的人发布了一个JS代码规范。其中列出了编写简洁易懂的代码所应该做的最佳实践。代码规范并不是一种编写正确JavaScript代码的规则,而是为了保持源代码编写模式一致的一种选择。

你解决的问题比你编写的代码更重要!

程序员似乎忘记了软件的真正目的,那就是解决现实问题。您编写的代码的目的是为了创造价值并使现有世界变得更美好,而不是满足您对自我世界应该是什么的以自我为中心的观点。有人说:如果你拥有的只是一把锤子,那么一切看起来都像钉子一样

tinymce与prism代码高亮实现及汉化的配置

TinyMCE是一个轻量级的基于浏览器的所见即所得编辑器,由JavaScript写成。它对IE6+和Firefox1.5+都有着非常良好的支持。功能方强大,并且功能配置灵活简单。另一特点是加载速度非常快的。

js函数式编程与代码执行效率

函数式编程对应的是命令式编程, 函数式编程的核心当然是对函数的运用. 而高阶函数(Higher-order)是实现函数式编程的基本要素。高阶函数可以将其他函数作为参数或者返回结果。所以JS天生就支持函数式编程

接手代码太烂,要不要辞职?

朋友发表了一条说说:入职新公司,从重构代码到放弃”,我就问他怎么了?他说,刚进一家新公司,接手代码太烂,领导让我先熟悉业务逻辑,然后去修复之前项目中遗留的bug,实在不行就重构

js高亮显示关键词_页面、搜索关键词高亮显示

页面实现关键词高亮显示:在项目期间遇到一个需求,就是搜索关键词时需要高亮显示,主要通过正则匹配来实现页面关键词高亮显示。在搜索结果中高亮显示关键词:有一组关键词数组,在数组中筛选出符合关键字的内容并将关键字高亮

写优雅的代码,做优雅的程序员

软件工程学什么? 学计算机,写程序,做软件,当程序员。听说学计算机很辛苦? 是的,IT行业加班现象严重。在计算机世界里,技术日新月异,自学能力是程序员最重要的能力之一。选了这个专业,就要时刻保持好奇心和技术嗅觉,不能只满足于完成课内作业。

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!