系统集成心得体会
谈谈自己参加考试的一点小心得体会。 经过半个多月的复习，于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！