2018年和1998年其中兩大區別就是:

1. 前端蓬勃發展, 前後端分離是一個十分大的趨勢.
2. 專門的測試人員角色被取消, 多出了一個很重要的角色, 產品經理

  ABP只要加入即可馬上加快專案進展, 選擇前後端+產品經理分工結構會比前面的全棧篇好十分多!!! 因為:

1. 分工協作和流水線作業工作效率會遠遠比傳統的個人全能型先進很多, 這個道理很多同學都懂, 我就不贅述了.
2. 前端快速和迅猛發展, 6個月釋出一次大版本, 瀏覽器6周釋出一次小版本, 導致傳統程式設計師光是學習新技術就已經很吃力, 要談精通更難了.請欣賞此圖:
3. 招人擴展團隊加快專案進度更容易了!!! 這才是重點!!! 流水線作業減低每個人的技術難度, 讓招人和培訓新手更容易 招校招生上手難度降低, 更容易招聘和更快能夠有產出 招社招生更容易, 質量更高, 特別現在是前端爆發期

  接下來說說是怎麼流水線作業的.   考慮到並不是所有同學都運用過BDD, 有很多同學只用過TDD的. 所以我分成兩套流水線作業講述.  先說第一套沒有BDD只有TDD的流水線作業工序吧:

1. 前後端一起定義介面
2. 後端寫好C# interfaces用Swagger生成介面文件
3. 前端將後端寫好的介面用refresh.bat生成前端ts proxy
4. 前後端各自幹各自的活

  以上流水線自然而然就運用瞭如下技術思想和技術點, 避免為了技術而技術, 為了思想而思想:

1. TDD
2. IOC/Mock
3. Interface

讓技術和思想自然而然的為你服務, 而不是你為技術和思想服務.   大家看到, 在第一套流水線裡面, 產品經理並沒有參與進來. TDD是由開發人員寫的, 與產品經理無關. 而在接下來的第二套流水線裡, 產品經理通過運用BDD參與進來了:

1. 前端根據產品經理寫好的Specflow的.feature檔案用cucumber寫BDD程式碼
2. 前後端一起定義介面和實現BDD的step definition程式碼
3. 後端寫好C# interfaces用Swagger生成介面文件
4. 前端將後端寫好的介面用refresh.bat生成前端ts proxy
5. 前後端各自幹各自的活


這麼說有可能會比較抽象, 在往後的日子裡我會增加具體實際操作文章和視訊.   與第一套流水線相比:

1. 產品經理參與進來, 給開發人員寫明瞭詳細操作步驟級的測試結構程式碼.
2. 開發人員不需要思考詳細操作步驟, 只需要實現具體每個操作步驟.
3. 每個操作步驟是獨立分割的, 遇到專案緊急時, 通過臨時調人加人來加快專案進度變得更可行.
4. BDD與TDD相比, 天然的具備了結構性, 避免書寫重複程式碼, 減少了測試程式碼的書寫量.
5. 很多公共的測試程式碼可以分割出來, 讓專門的技術專家去寫 (這會在後面一節裡提到)

  可以看到, 第二套流水線比第一套流水線先進十分多.   那麼有個問題, 產品經理有能力寫BDD嗎?  從目前市場現狀來看, 從測試人員改行過來做產品經理的, 是十分有能力寫好BDD的. 反而開發人員很難寫好BDD, 甚至寫好TDD都很困難. 這也是為什麼BDD和TDD在很多企業推廣不起來的原因之一, 因為角色和能力錯配了.   2010年開始, 行業裡面逐步減少測試人員, 到了2015年, 這個趨勢終於成了氣候, 微軟在2015年大量裁減測試人員成了這類現象的里程碑事件. 那麼這麼多被裁減的測試人員都去哪裡了呢? 絕大多數人並沒有離開IT這個這麼火的行業, 很多都改為做產品經理了. 他們寫測試用例的能力和寫BDD能力是對標的, 並且切換很容易.   在這裡要說明一下, 產品經理來源有兩類:

1. 校招/美工/市場銷售轉過來的, 會用Axure等原型設計工具,這種情況應該由三個人結對程式設計寫BDD.
2. 測試人員改行的, 這種人寫測試用例的能力就很容易很天然的演變為寫BDD的能力