如何用ABP框架快速完成项目(2) - 快的定义!

为什么要从快的角度来讲这系列课程呢?

 

因为快是一个很统一很清晰的标准. 所有人对时间都有一个统一清晰的概念. 

比如说这系列课程会讲到的一个实例: 集成LinqToExcel, 用我的方法大概耗时1个小时.

如果你有异议, 那请你拿出更好的方案, 就是耗时比1个小时更少.

这么一说评判标准就很清晰, 两个方案之间可以立盼高下.

 

假如我用好来做标准, 因为好的标准很模糊, 就会导致很多问题.

还是拿上面的那个实例来说吧: 集成LinqToExcel. 如果采用好来做标准, 公说公有理,婆说婆有理. 争论估计就花了两个小时, 而我做完它才只需要1个小时.

 

为什么我要专门强调这点呢? 因为我看到有很多同学因为按照好的标准而不是快的标准导致了:

1. 很多同学遇到的问题花了很多时间和精力, 然而从最根本的角度和方向上来看这些问题应该是不存在。
2. 很多同学在DDD理论上钻了牛角尖, 花费了很多时间和精力却没啥收获.

同时也导致了IT界发生了不少争论, 比如“PHP是最好的语言”和“代码缩进用tab好还是空格好”

 

那么快的定义是什么呢?

很快速的写完代码提交但是出了一堆bug要修复, 这样并不叫快, 因为我们计算时长是要这样计算的: 写代码的时间+修复bug的时间.

所以我们是这样定义快的: 在保证没有Priority1和2 bug的前提下总耗时越短越好。这里的总耗时是指写代码的时间+修复bug的时间

 

有同学还是觉得有点抽象, 我具体解释一下.

首先, 没有bug的程序是不存在的, 大家打开github, 请找出一个100star以上而又没有bug的项目给我看看?

所以我们不追求0 bug.

我们只追求没有Priority1和2 bug. 也就是优先级为1和2的bug.

 

现在让我们打开AzureDevops(就是以前的TFS), 看看bug的Priority定义在哪里.

 

好啦, Talk is cheap, just show your code.

理论讲完了, 这节到此为止, 在接下来的章节里面, 我会讲到以下几个实践:

1. DDD理论要听命于代码生成器(节省手写和争论时间)
2. 集成LinqToExcel(只耗时1个小时就开发完成)
3. 通过BDD/TDD来节省回归测试时间