如何用ABP框架快速完成项目(2) - 快的定义!
生活随笔
收集整理的這篇文章主要介紹了
如何用ABP框架快速完成项目(2) - 快的定义!
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
為什么要從快的角度來講這系列課程呢? 因為快是一個很統一很清晰的標準. 所有人對時間都有一個統一清晰的概念.? 比如說這系列課程會講到的一個實例: 集成LinqToExcel, 用我的方法大概耗時1個小時. 如果你有異議, 那請你拿出更好的方案, 就是耗時比1個小時更少. 這么一說評判標準就很清晰, 兩個方案之間可以立盼高下. 假如我用好來做標準, 因為好的標準很模糊, 就會導致很多問題. 還是拿上面的那個實例來說吧:?集成LinqToExcel. 如果采用好來做標準, 公說公有理,婆說婆有理. 爭論估計就花了兩個小時, 而我做完它才只需要1個小時. 為什么我要專門強調這點呢? 因為我看到有很多同學因為按照好的標準而不是快的標準導致了: 很多同學遇到的問題花了很多時間和精力, 然而從最根本的角度和方向上來看這些問題應該是不存在。 很多同學在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. 理論講完了, 這節到此為止, 在接下來的章節里面, 我會講到以下幾個實踐: DDD理論要聽命于代碼生成器(節省手寫和爭論時間) 集成LinqToExcel(只耗時1個小時就開發完成) 通過BDD/TDD來節省回歸測試時間
轉載于:https://www.cnblogs.com/adalovelacer/p/abp-quickly-delivery-2-define-of-quickly.html
總結
以上是生活随笔為你收集整理的如何用ABP框架快速完成项目(2) - 快的定义!的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 基于sentry的前端错误监控日志系统(
- 下一篇: python 多线程入门试验