近日，聽了一段關於單元測試的討論，在回家路上細細品味時產生了一些想法，這裡記錄下來，大家一起**。
當時是這樣一件事：專案上的乙個子系統（subsystem）剛剛增加了單元測試的測試用例， 這些用例在開發人員那裡編譯是沒有問題的，但是在ci中總是失敗。
原因是單元測試的makefile檔案中，使用了產品工程中的乙個環境變數$，該變數用於指示外部標頭檔案所在的目錄。而$只有在設定了產品環境之後，才會有定義。目前的ci環境中並不會執行設定產品環境的指令碼，而只是單獨執行單元測試的 makefile 檔案；這樣 ci 編譯測試用例的時候，被引用的外部標頭檔案都無法被找到，導致編譯器報錯退出。
ci負責的同事就來找子系統的開發人員，要求他修改makefile取消對$的使用，而採用將外部標頭檔案直接複製到單元測試目錄中的方法。而開發人員則表達了不同意見：
直接複製標頭檔案，一方面是一件費時費力的事情，另一方面，當外部標頭檔案發生變化的時候，子系統的單元測試無法立刻發現可能的問題。他甚至希望能夠直接呼叫外部的函式，而不是將它們打樁或者mock掉。因為這樣，可以更快捷的發現一些外部的錯誤。學習過單元測試的同事，都知道它有個first原則，其中 i 就代表著isolataion（隔離）。目的就之一就是為了使得
『乙個錯誤只會導致少量測試用例失敗』，為此，單元測試中有打樁，有mock；這樣才能更快地定位和修復模組內部的錯誤。
在實踐中，我們不可能只遵循於任何一種理論，而枉顧其他；一般來說我們不得不做一些妥協，使得各方面都基本滿意。
而單元測試的理論要求測試用例有相當的隔離性，不要直接呼叫外部的服務，這樣便於測試用例本身定位和修改錯誤。
不能絕對地說，這裡一定是誰錯了或者誰對了。讓我們想一想這兩種想法背後的故事：
1.開發人員，不滿足單元測試只是測試子系統本身，還希望它能夠提前發現別的子系統可能帶來的風險；這個好處是顯而易見的。
2.ci系統，希望能夠單獨執行某個子系統的單元測試用例，不依賴於產品工程。
另一部分，如果按照開發人員設想的實施，在糟糕的情況下，某個子系統的修改，會導致大量子系統單元測試用例失敗，快速定位錯誤會比較困難。
權衡之下，是否可以這樣：
1.子系統裡的單元測試用例，盡量不要直接使用其他子系統的服務，而是使用打樁或者mock掉；
2.如果子系統依賴的外部服務至關重要，或者外部服務處於不穩定期，可以單獨撰寫測試外部服務的單元測試用例；這樣外部的錯誤，既能夠被提前發現，也只會導致少部分用例失敗。
單元測試問題可以到此告一段落，但是再仔細想一下，當初決定 ci 中單元測試有如此的要求，可能還有乙個原因：
「減少『我』失敗/出錯的機會，同時也不想管『別人』是否失敗/出錯」。這個想法和
「這個bug不是我的問題，而是其他人的問題，所以請找別人」是同一種思路。
這是一種典型的『防禦性合作』的思想，產生於畫地為牢，按照**劃分權責範圍的分工工作方式。這種方式，在歷史上曾經成功的運用於我們的很多產品。但是如果要進一步提高研發效率，幫助部門成功轉型，它肯定是做不到的。軟體業，有這麼一句俗話：
什麼樣的組織結構，一定會創造出類似結構的軟體。相信大家都還有記憶，以前當出現涉及多個開發組的 bug 的時候，各組之間是如何合作的？都能聽到哪些抱怨？
同樣，開發新功能的時候，在整合測試、系統驗證的時候還會發現缺少了一些功能？ 交付給客戶的時候，客戶是否滿意質量或者時間？
實際上的後果是：
開發組缺乏產品意識員工們很多的主觀能動性被抑制住了，但是軟體公司比其他型別的公司更加需要員工的主觀能動性。可以怎麼辦呢？各人自掃門前雪，休管他人瓦上霜
要釋放員工的主觀能動性，端到端負責，自我驅動，自我管理，自我演進的自組織團隊，在其他軟體公司已經被證明了是好方法。
我們是否可以進行類似的嘗試呢：讓乙個團隊完全端到端地負責某個 服務的全部（包括產品，設計，實現，測試，整合，維護），直接面對客戶交付產品。
讓對產品負責的思想進入到每一位團隊成員意識中，讓團隊能更直接的獲得客戶的反饋，更加直接的參與到競爭中，釋放他們自己的主觀能動性。
這樣，當問題產生或者新的需求產生之時，很明確該團隊的成員將成為唯一的 owner負責到底。
這樣是否可以提高研發效率呢？讓我們拭目以待吧
使用單元測試引發的一些思考
單元測試是保證邏輯正確的重要組成部分和驗證方式，但是單元測試的使用方式需要注意，大部分時間要保證簡單邏輯沒有問題，單元測試主要用在複雜的邏輯 以及單個演算法及其複雜 的時候，這種情況下使用單元測試junit等，就可以很好地測試邏輯，並且避免由於過多的單元 測試導致，由於程式變化花費大量時間調整測試。...
一次產品討論會引發的思考
雅安 發生後，各大網際網路公司都相繼快速的做出了反應，有些出錢，有些出物，有些出力，在自己的產品中追加了相關功能，便於大家報平安，找人，或是在產品中表達對此次事件的關心，體現了自己的乙份社會責任。我們公司的領導也及時召集大家召開了產品討論會，主題是 我們能做什麼 大夥熱情極高，花了大量的時間，提出了...
一次討論volatile指令重排引發的經歷
public class tcatch exception e i system.out.println m end public static void main string args catch exception e t.runing false 結果會 我一直以為，時間片輪詢，遲早runi...