Team Dev是否需要專門測試人員，大型電商網站架構分享

亞馬遜進階開發經理、酷殼博主陳皓（@左耳朵耗子）發布了一條文章引用的微博，提出：大多數Team Dev不需要獨立的測試角色。EMC中國研究院推薦了一篇Highly Scalable Blog的文章，探討一個大型電子購物網站的架構與設計。

陳皓在這條微博寫道：“關於測試和測試人員 http://t.cn/zOyfLi4 大多數的Team Dev並不需要一個獨立的測試角色。即使有一個，他的所有的開發時間比上所有的測試時間應該 >20:1。光看看一些從古至今最成功的軟體Team Dev就知道了。”

他又繼續引用了文章的內容：“‘開發人員應該測試自己的代碼。沒什麼可說的。背後的道理並不重要。這包括單元測試，全覆蓋的自動化測試或手工測試或組合測試。如果你的開發人員不能/不願意或認為這“不歸我管”，那你需要更好的程式員。’”

他還在回複中提到：“亞馬遜就是這麼做的。⋯Furthermore，亞馬遜的營運都是開發人員自己幹，從需求一直幹到營運，還要幹招聘，項目自管理等與技術無關的事。而團隊大小隻有8個人左右，自稱pizza team，一張Pizza可以餵飽團隊。”

大家的評論和反饋如下：

可惜我是程式猿：首先要看決策者是不是這麼認為的，否則是很難推的，開發不重視測試，尤其是單測，那是天性，當然最好有類似SQA的組織賦予改進流程的權力來推動開發自測，並制定自測指標列入考核，這樣驅動力更強~

KT劉世軍：觀點有道理，但不符合“國情”。很多時候，Team Dev缺失的是合格的開發人員，還根本談不上優秀的開發人員。

左耳朵耗子：我認為，沒有合格的開發人員， 就不可能有合格的測試人員。測試人員本來就是來自懂測試的開發人員。另，這與國情無關。

@其-龍：我現在越來越贊同自測試，而且是完備的自動化測試。現在很多時候測試和開發之間就是將責任弄到模糊不清，就是看誰弱勢而已。

welkinwalker：這裡面的挺多話都說到點子上了。 每個人都要對自己的代碼負責，不管你是開發工程師，還是測試工程師。 開發人員應該完成大部分的測試工作，但又不能完全沒有測試工程師來保證overall的產品品質。 覆蓋率的立意是好的，但是在實踐中關於這個東西的追求經常是被異化的，成了一種噱頭，狗屎一坨。

程式員鄒欣：回複@左耳朵耗子: 我也寫了一些感想: http://t.cn/zOCU8nT 請各位指教一二。

左耳朵耗子：先回複一點，分工最大的問題是責任不清，出了問題互相扯皮互相推，但最終解決問題的人還是DEV。

EMC中國研究院發布了一篇微博：“Highly Scalable Blog經常出高品質Blog，這篇也不例外：http://t.cn/zOKBysL 。博主Ilya Katsov最近參與了一個大型電子購物網站的架構和設計，他總結了項目裡面用的設計原則和主要技術，乾貨很多。強烈推薦大家讀一下這篇文章，與以往一樣，如果大家翻牆不方便，請點擊圖片附件看全文。”

羅翅膀716：1. 樹形資料應該用 WITH RECURSIVE 搞定。2. Facet 應該用 hstore 搞定。百萬層級的商品，都用不著分表。

@utopia_ZhouHang: 後台使用的Oracle Coherence來做cache和message bus，對於這種應用沒有看到可以媲美Coherence的開源產品 （http://t.cn/zOKrpXh），看到過幾次Hazelcast， 但是它的Elastic Memory並不免費

Launch_Bruce： 認真研讀以兼收並蓄。讀後感： 1.提供路由和負載平衡的IMDG很重要，事件驅動的Map-Reduce更先進，分布式更好; 2.大資料應用，全分布式緩衝是災難，即使只是index，需分布式DB和Cache並重； 3.海量特徵的資料的faceted search挑戰更大； 4.大資料應用，index計算是效能瓶頸，傳統公司專屬應用程式是DB；5.面向互連網的大規模公司專屬應用程式，CDN確實是問題，不用無法保證暢通訪問，用，資料太個人化，很難聚類； 6.設計大型應用，use case的全面很重要，更難的是明天的use case，做平台，更重要，離不開964原則； 7.大型產品的架構，效能、伸縮性、可靠性重要，部署、測試、維護一樣重要。

註：文章系本人原創：發佈於