系統集成心得體會

談談自己參加考試的一點小心得體會。 經過半個多月的複習，於XX年5月22日參加了全國統考。

當天考試的人還挺多的，我被分配到了第24考場，參加考試的人除了六位同事大家都互相不認識，有5名老師監考，每個人像是有多年擒賊經驗的老警察。

上午考試75道選擇題，試卷發下來後，匆匆看了一下，發現有些上次考過的類似題目，總體上還是不錯。

我是分兩次做題，第一次做有把握的，直接就塗在答題卡上，第二次做不太有把握的，只能靠邏輯推理或是靠猜以及排除法找出答案的。

等我做完第二遍時，離考試時間還有近一個小時，考場剩下一半的考生了。

上午考完試後，總體感覺尚可，估計分數應該在55分左右。

下午2點開考，總共5到案例分析，打開一看，感覺有兩道題比較有把握，答題時根據參考資料上要求的一是要根據每道問答題的分數來答要點，比如5分問答，答案至少要答到5條；二是如果不會，也要根據經驗寫滿，這樣老師多少會給點分。

下午我到了鈴聲響了後才離開考場。感覺下午的考試不是很理想，估計不出大致的分數。

耐心的等待成績的公佈，如果自己通過中級考試後，那就開始準備高級的考試。

在今後的論壇學習中，我會做些考點分析，定期發佈主題，希望同樣參加考試的人提供方便，若朋友們有其他的考點有疑惑或需要交流的都可以發佈主題，我們共同討論。

期望我們共同的進步。

系統集成心得體會（2）：

心得

最後，談談在這次ci實踐中感受到的一些心得：

ci和process及agile：敏捷編程中要求在每個小迭代中都有交付件，因此要求每個迭代都有完整的集成及測試工作，因而ci是一個很好的敏捷實踐，用以保證交付件的質量。如果沒有很好的ci，很難做到真正的敏捷。此外，ci的引入也會對現有流程形成一定的影響，一個實際的例子就是：以前rd總是在每天晚上下班前把當天完成的代碼check in，而現在則是，完成了一部分就立即check in一部分，並等待幾分鐘，確保check in的代碼不會讓ci失敗。

ci和testing及automation：其實在前面的實踐中也已經看到，ci中包含了很多的測試實踐，比如單元測試、組件測試、功能測試、系統測試等等。integration不只是compile，更多地是通過測試來保證質量。這對rd和qa都提出了更高的要求，首先，持續意味着我們必須要保證測試的一直可用，在實施ci之前，我們也有單元測試，但單元測試往往在進入alpha或beta後就再也沒人關心和維護了，在項目結束時甚至單元測試的程序連編譯都不能通過。其次，自動化的要求意味着必須要更好地去考慮產品設計、實現、以及測試的設計工作，一個低耦合的架構才有可能更多地自動化，糟糕的設計工作會讓自動化根本無法進行。

ci和cross-platform開發：趨勢很多項目都有多個平台的版本，因此對軟件的跨平台開發也有很高的要求。那ci對跨平台有什麼意義呢？如果我們在多個開發平台上都有響應的ci系統，那我們在開發任何一個平台的時候，新增或者修改的代碼都可以及時通過其他平台上的ci系統得到儘早的驗證和反饋。這樣，通過ci可以更好地要求開發人員考慮跨平台的需要，不能因為一個平台的代碼而讓其他平台的ci失敗。

“持續”：我想對ci裏“持續”的理解可以從兩方面來談，首先是持續地集成產品，儘早地發現問題；其次，也可以把這裏的持續理解為持續改進，正如前面説的，ci裏包括很多的實踐，我們不可能一下子引入全部，這就要求我們有持續改進的sense，持續地引入新的實踐（比如加入代碼審查等）、持續地加入新的case、持續地完善ci和process，在改進的同時，ci又很好地保證了已有部分的長期有效，不過像猴子摘西瓜那樣，缺少歷史的積澱。

企業文化和公司的支持：最後一點心得，和ci關係不大，但在任何公司、任何組織中，要想能不斷改進、嘗試新的實踐和流程，必然離不開組織和制度的支持。我們在實踐ci過程中，manager們給了團隊很多的自由，可以充分去發掘，同時允許失敗，這是任何一個實踐能夠有所收穫的必備前提。

最後，推薦一本關於持續集成的書籍：continuous integration: improving software quality and reducing risk（持續集成：軟件質量改進和風險降低之道），它對ci進行比較全面的介紹，可以從這本書裏開始對ci做個全面的瞭解。

ci並不是軟件開發的銀彈，它也並不嘗試解決軟件開發中固有的很多問題，但通過採用ci，可以更好地控制和降低風險，並能更好地保證團隊和流程走在不斷成功和改進的正確道路上，從而讓我們有更大的信心去release產品，refractor代碼，agile流程。

擁抱敏捷、擁抱變化、擁抱ci！