早期，我們確實遇到了「爛」專案……
我們的專案有時候是在非常態下進行的，這個非常態是指專案在沒有文件化需求或需求以格式文件的形式描述，專案經理以口頭的形式描述系統需求，並要求開發人員在短期內完成**開發。接下來，開發人員在模稜兩可的狀態下彆扭的編寫**，測試人員前期也無從介入，更可怕的是，積極性欠缺或責任心不夠的專案經理不但前期沒能與客戶細緻的溝通需求，在系統開發過程中，也沒有進行有效的專案進度、質量控制，連起碼的階段成果評審也沒有做。之後的系統開發成什麼樣子已經可想而知了。
原來能忽悠客戶搞好客戶關係的專案經理，不一定搞得定系統開發過程。這個時候，去追究專案經理為什麼是他已經來不及，因為開發人員說他的**已經開發完成了……
怎麼辦？貿然接收測試？沒有明確的需求，測試依據呢？開發成什麼樣就是什麼樣？在研發中心的最後一道關口，測試人員不能掉以輕心，但真的開始了，那糾纏不清的功能需求爭論將陷入無休止。
為了測試的兄弟們，為了自己的測試工作更加順利，在測試過程中有章可循、有據可依，減少無效溝通，我們唱起了主角。
我們主動與開發人員溝通，跟蹤開發過程，在專案的各個里程碑階段（開發完成了乙個完整的功能模組或業務子系統），主動建議（實際上是要求）專案經理或開發人員演示系統，同時邀請客戶支援人員、測試人員、市場人員參加，在演示過程中，將各個功能點、功能模組或業務流程所要實現的功能、業務明確，尤其是通過測試人員的提問，引出可能存在爭議的業務或功能設計，甚至現場與客戶**溝通，並以會議紀要的形式的記錄下來，以並得到相對明確的測試需求。迭代反覆，直到抽取整個系統的測試需求。
測試需求抽取是艱苦的過程，但不做這一步，我們可能更艱苦。有時候，會議中定下來的需求不一定真實，但起碼專案各干係人了解到了一致的專案狀態，後續即使客戶方有變更，專案組也能夠更快的響應變化。
有了需求，後續的測試工作就順利多了。
我們做了兩個這樣的「爛」專案，之後的變化是，無論是否有明確的需求文件，開發完成之後，都有乙個步驟：以系統演示會議的方式對完成**開發的系統進行預評審。再後來，大老闆開始強制性的要求推動需求分析工作……
這個需求我不接之事務的自動補償
什麼是分布式事務 分布式事務就是指事務的資源分別位於不同的分布式系統的不同節點之上的事務 例如 信用卡還款，包含兩個操作 從銀行賬戶扣錢 恢復信用卡額度 例子中兩個操作如果處於不同的資料庫，或者根本就是兩個微服務中的操作，想要保證資料的一致性，靠本地事務是解決不了的，這時候就需要分布式事務了。事務屬...
我們仍然需要貧血的域模型
幾種域模型的爭論持續很久了，尤其在 martin fowler 批判貧血的域模型後，爭論更加激烈，martin 的文章我剛看到，他對貧血域模型的觀點我基本都同意，但是我得出的結論確和他不同。我同意只含有屬性 甚至加上 crud 的domain object 是不符合 oo的，這樣做很類似於使用事務指...
我們不能沒有遊戲
摘自 doom啟示錄 每個人都有無法實現的夢想。或許是那夢想需要太多時間和金錢，譬如開跑車馳騁，駕飛機翱翔 或許是那夢想太過於離譜，譬如與異形進行星球大戰，與吸血鬼拼個刺刀見紅 或許是那夢想會違反法律，譬如痛毆老闆，夜半尾行。但不管能否實現，它們總盤旋在你腦海裡，每一天，讓你浮想連翩。這就是為什麼會...