系统集成心得体会.docVIP

系统集成心得体会 谈谈自己参加考试的一点小心得体会。经过半个多月的复习， 于 XX年 5 月 22 日参加了全国统考。 当天考试的人还挺多的， 我被分配到了第 24 考场，参加考试的人除了六位同事大家都互相不认识， 有 5 名老师监考， 每个人像是有多年擒贼经验的老警察。 上午考试 75 道选择题，试卷发下来后，匆匆看了一下，发现有些上次考过的类似题目，总体上还是不错。 我是分两次做题，第一次做有把握的，直接就涂在答题卡上，第二次做不太有把握的， 只能靠逻辑推理或是靠猜以及排除法找出答案的。 等我做完第二遍时，离考试时间还有近一个小时，考场剩下一半的考生了。 上午考完试后，总体感觉尚可，估计分数应该在 55 分左右。 下午 2 点开考，总共 5 到案例分析，打开一看，感觉有两道题 比较有把握，答题时根据参考资料上要求的一是要根据每道问答题的分数来答要点，比如 5 分问答，答案至少要答到 5 条；二是如果不会，也要根据经验写满，这样老师多少会给点分。 下午我到了铃声响了后才离开考场。感觉下午的考试不是很理想，估计不出大致的分数。 耐心的等待成绩的公布，如果自己通过中级考试后，那就开始准备高级的考试。 在今后的论坛学习中，我会做些考点分析，定期发布主题，希 望同样参加考试的人提供方便， 若朋友们有其他的考点有疑惑或需要 交流的都可以发布主题，我们共同讨论。 期望我们共同的进步。 心得 最后，谈谈在这次 ci 实践中感受到的一些心得： ci 和 process 及 agile ：敏捷编程中要求在每个小迭代中都有 交付件，因此要求每个迭代都有完整的集成及测试工作，因而 ci 是 一个很好的敏捷实践， 用以保证交付件的质量。 如果没有很好的 ci ， 很难做到真正的敏捷。此外， ci 的引入也会对现有流程形成一定的 影响，一个实际的例子就是：以前 rd 总是在每天晚上下班前把当天完成的代码 checkin ，而现在则是，完成了一部分就立即 checkin 一部分，并等待几分钟，确保 checkin 的代码不会让 ci 失败。 ci 和 testing 及 automation ：其实在前面的实践中也已经看到， ci 中包含了很多的测试实践， 比如单元测试、 组件测试、功能测试、 系统测试等等。 integration 不只是 pile ，更多地是通过测试来保证 质量。这对 rd 和 qa 都提出了更高的要求，首先，持续意味着我们必 须要保证测试的一直可用，在实施 ci 之前，我们也有单元测试，但 单元测试往往在进入 alpha 或 beta 后就再也没人关心和维护了，在 项目结束时甚至单元测试的程序连编译都不能通过。 其次，自动化的 要求意味着必须要更好地去考虑产品设计、 实现、以及测试的设计工 作，一个低耦合的架构才有可能更多地自动化， 糟糕的设计工作会让 自动化根本无法进行。 ci 和 cross-platform 开发：趋势很多项目都有多个平台的版 本，因此对软件的跨平台开发也有很高的要求。那 ci 对跨平台有什么意义呢？如果我们在多个开发平台上都有响应的 ci 系统，那我们 在开发任何一个平台的时候， 新增或者修改的代码都可以及时通过其他平台上的 ci 系统得到尽早的验证和反馈。 这样，通过 ci 可以更好地要求开发人员考虑跨平台的需要， 不能因为一个平台的代码而让其他平台的 ci 失败。 “持续”：我想对 ci 里“持续”的理解可以从两方面来谈，首 先是持续地集成产品，尽早地发现问题；其次，也可以把这里的持续理解为持续改进，正如前面说的， ci 里包括很多的实践，我们不可 能一下子引入全部，这就要求我们有持续改进的 sense，持续地引入新的实践（比如加入代码审查等）、持续地加入新的 case、持续地 完善 ci 和 process ，在改进的同时， ci 又很好地保证了已有部分的长期有效，不过像猴子摘西瓜那样，缺少历史的积淀。 企业文化和公司的支持：最后一点心得，和 ci 关系不大，但在 任何公司、任何组织中，要想能不断改进、尝试新的实践和流程，必 然离不开组织和制度的支持。我们在实践 ci 过程中， manager 们给 了团队很多的自由，可以充分去发掘，同时允许失败，这是任何一个实践能够有所收获的必备前提。 最后，推荐一本关于持续集成的书籍： continuousintegration:improvingsoftwarequalityandreducingri sk（持续集成：软件质量改进和风险降低之道），它对 ci 进行比较 全面的介绍，可以从这本书里开始对 ci 做个全面的了解。 ci 并不是软件开发的银弹，它也并不尝试解决软件开发中固有 的很多问题，但通过采用 ci ，可以更好地控制和降低风险，并能更 好地