如何用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來節省回歸測試時間