SCM第一讲
Download as PPT, PDF0 likes559 views
本讲讨论了提高开发效率的多种方法，包括个人和团队的专注、自动化、内部通讯平台和版本控制。此外，还介绍了持续集成的好处和实施步骤，以便提高代码质量和项目管理效率。总结强调，企业内部的有效沟通与协作对于优化开发流程至关重要。
SCM第一讲
- 1. 如何让开发更有效率 - 第二讲 崔晓旻 LOG 团队
- 2. 加速法则（个人） 专注法则（团队，个人） 自动化法则（团队，个人） 规范性法则（团队，个人）
- 3. 键盘 命令行 VS 图形界面 操作系统 开发环境（ Vi / Emacs ） Eclim 开发自动化
- 4. 隔离策略：听觉，视觉 关掉不需要的提示 创造安静的时间（ 团队规定 ） 多显示器
- 5. 内部通讯（企业微博，企业 SNS ） 版本控制（ CVS ， SVN ） 持续集成（ Cruise Control ） 问题跟踪（ bugzilla ）
- 6. 内部通讯（企业微博，企业 SNS ） 1 、封闭性的企业微博：可以和企业的邮箱系统进行整合，只供企业的内部员工访问，即提供了企业内部的信息交流平台，又防止了企业敏感信息外泄，是替代企业内部论坛的一个工具。 应用实例：企业内部论坛，企业异地办公用户或手机移动用户的在线讨论、评论的内部论坛。企业的最新消息动态也可在上面发布。
- 8. 内部通讯（企业微博，企业 SNS ） 2 、内部协同办公平台：主要应用于工作管理、项目团队协同工作上。团队的用户可以了解大家的工作状态、工作存在的问题。团队的成员可以在群组中实时提出问题，请求帮助，提出解决问题的思路等，实现类似 QQ 群的功能。 应用实例：项目团队的的时间管理工作，团队成员可以在上面进行日计划、周计划、月计划等。每天的工作内容可以实时更新，项目精力可以随时了解开发人员的研发进度。
- 9. QQ 群可以吗？ 如果把 QQ 群当做一个微博平台，那么其做为微博的缺点： 1 、没有 Feed ，无法查看某个用户的所有发言； 2 、不支持回复，无法实现类似 Buzz 的线性讨论； 3 、 WEB 页面的显示不友好，信息不全。 4 、手机端的界面不太简明，操作较为繁复。
- 11. Yammer 企业微博的未来 1 、移动终端的应用 - 通过手机实时追踪企业最新消息。 2 、内容分享平台 - 企业内部知识管理和分享信息平台。 3 、客户端应用 - 电脑桌面客户端的即时通讯，自动同步本地分享文档到服务器端，自动同步企业通讯录。 4 、网络营销平台 - 连接外部微博系统，自动将企业网络营销信息同步到外部微博。 5 、应用商店 - 通过开放 API 平台，吸引第三方软件商开发针对 Yammer 的应用。 总的来说，企业微博主要侧重于企业内部的协同和交流和信息分享，企业让每位成员都加入，动态分享自己的状态，让内部员工互相订阅，甚至主管等管理层亦可通过微博发布简短的会议和通告。随着手机的多元化应用，企业微博或许会成为企业内部交流和分享的一个重要工具。
- 13. 内部通讯（企业微博，企业 SNS ） 版本控制（ CVS ， SVN ） 持续集成（ Cruise Control ） 问题跟踪（ bugzilla ）
- 14. 问题提出！ 不可见的逻辑实体 软件项目的规模日益庞大和复杂 参与软件项目的人员增加，人员间的沟通渠道数量按指数倍增。 产品非常容易拷贝 时时处在演化和变更状态。 技术 业务环境 不同用户各有不同的需求 需求变更 开发人员的离去有较大的影响
- 15. 需求分析 设计 开发 测试 需求分 析文档 设计文档 源程序 可执行代码 测试文档 需求 分析员 设计员 开发员 测试员 项目经理 产品经理 任务 文件
- 16. 程序员的问题 无法找到最新的源程序文件 无法找到源文件的历史修改信息 多个人修改同一个源文件，有些人的修改被冲掉了 程序被误删了，尝试恢复失败，只能重写
- 17. 项目经理的问题 为在项目组成员中共享和隔离资料烦恼 无法有效掌握项目过程产生的文件、代码和工作成果 调试过程中，项目成员经常为一些问题扯皮，搞不清楚到底是谁产生的错误
- 19. 已经发现的 BUG 又重新出现 已经发布的软件不能够再次构建（ Build) 丢失软件版本对应的源代码 丢失关键文件 文件被“神秘”地修改了 多人协助开发难以继续 软件开发过程中的其他问题
- 20. 源代码、文档管理将更为可靠和有序 多人协作并行开发简单了 系统可以自动构建并且更加快速 已经解决的 BUG 将不会再骚扰程序员 保证软件正确的配置，如兼容性配置 软件配置管理的好处：
- 21. 代价和风险 商业成本将增加 专门软件、服务器 专业软件配置管理的培训 人的因素 各人的偏好难以统一 抵制使用或假装使用 可靠性和安全 如何控制对软件资产的访问权限 扩展性问题 软件配置管理的好处：
- 22. 见附加 PPT ！ 基本的版本控制
- 23. 内部通讯（企业微博，企业 SNS ） 版本控制（ CVS ， SVN ） 持续集成（ Cruise Control ） 问题跟踪（ bugzilla ）
- 24. 持续集成还是阶段集成？ 究竟那种方式更加理想，更加符合项目的开发和管理呢？ 对于一个 微型 程序来说，阶段式的集成或许是最佳方法。 （何谓微型程序，就是那种二三十个类的项目，也许使用阶段集成也不会出啥子问题
- 25. 持续集成的好处 易于定位错误。 及早在项目里取得系统级的成果。 改善对进度的控制。 改善客户关系。 更加充分地测试系统中的各个单元。 能在更短的时间里建造整个系统。
- 26. 有助于项目的开发数据的收集 与其它工具结合的持续代码质量改进 FindBugs, Fxcop 等等等等的结合。 与测试工具或者框架结合的持续测试 。 便于 Code Review 。 便于开发流程的管理 持续集成的好处
- 27. 持续集成的常用工具 Open Source 的工具： CruiseControl ， Hudson ， LuntBuild 等 商业产品：如 TeamCity ， QuickBuild 等 自己实现：如 Cron+Ant/Maven/Make 等
- 28. 持续集成的过程 首先，遵从编码规范！ 其次，使用类似 Cobertura 作为代码覆盖（ code coverage ）工具。 再次，使用类似 JUnit 作为 unit test 工具 基于上述几点，可以写 Ant 脚本，完成如下 Task: compile, source code analytics, unit test, generate reports, generate javadoc, package artifacts
- 29. 持续集成的过程 2 有了这样一个脚本以后，配置的项目到 QuickBuild 中去， 在 QuickBuild 中，配置一个 configuration 。 对应于这个 configuration ，可以配置四个子 configuration ，分布是 Development Configuration, QA Configuration ， Integration Configuration 和 Release Configuration 。 每天的代码在下班前都提交到 subversion 里去，第二天， Development Configuration 就自动的编译完成了，并且发送通知给我们。 开发人员做 Promote 触发 QA Configuration 给 QA Lead QA lead 做 Promote 触发 Integration Configuration 给客户， 做 VOC (Voice of Customer) ，听却客户的意见，如果客户没有什么易见的话，那么就会在 Integration Configuration 上做一个 Promote 到 Release Configuration 上去。
- 30. 内部通讯（企业微博，企业 SNS ） 版本控制（ CVS ， SVN ） 持续集成（ Cruise Control ） 问题跟踪（ bugzilla ）
- 31. 问题跟踪（ bugzilla ） 见附件 PPT2
- 32. 不要重复你自己 Don’t repeat yourself ， DRY 重构 模式 示例 7
- 33. 追求 DRY 的效果： 逐渐精于重构 最终得到一个令人满意的设计 – 通常并非最佳，但比团队凭空想出来的好多了 发现一些更通用的模式，并因此真正理解他们 团队中有经验的人会有更多机会来传授各式各样的封装机制，设计策略等
Editor's Notes
- #5: 80/20 法则，是按事情的重要程度编排行事优先次序的准则是建立在“重要的少数与琐碎的多数”原理的基础上。
- #25: 有很多人说，我不做持续集成，照样工作的很好。因为我们一个（小）阶段出一个版本，照样控制得非常好。我得恭喜你，首先持续集成也好，阶段集成也罢，你做了，做了就好，比没有做要好很多，也使你的项目管理上了轨道了。这两者之间的区别仅是频率而已。 不过，你要真的是懒到连个阶段集成都不愿意做的话，那么你至少也该到庙里点支香，求求佛祖保佑你的项目一切顺利。
- #26: 易于定位错误。 持续集成失败了，说明新加的代码或者修改的代码引起了错误，这样很容易的就可以知道到底是谁犯了错误，可以找谁来讨论。 及早在项目里取得系统级的成果。 代码已经被集成，即使整个系统不是那么可用，至少你和你的团队都已经可以看到它已经在那了。 改善对进度的控制。 如果每天都在集成，当然每天都可以看到哪些功能可以使用，哪些功能还没有实现。如果你是程序员，你不用在汇报任务的时候说我完成了多少百分比而烦恼，而如果你是项目经理的话，那么你也不再烦恼程序员说完成了编码的 50% 到底是个什么概念。 改善客户关系。 理由同上。 更加充分地测试系统中的各个单元。 这也是我们常讲的 Daily Build 与 Smoke Test 相结合带来的绝大好处。 能在更短的时间里建造整个系统。 持续集成并没有为每个项目都缩短时间，但却比没有实施时，项目更加可控，也更加有保证。
- #27: 有助于项目的开发数据的收集 。比如说，项目代码量的变化，经常出错的 Tests ，经常出错的 source code ，等等。 与其它工具结合的持续代码质量改进 。如与 CheckStyle, PMD, FindBugs, Fxcop 等等等等的结合。 与测试工具或者框架结合的持续测试 。如与 xUnit ， SilkTest, LoadRunner 等等的结合。 便于 Code Review 。在每个 build 里，我们都可以知道与前一个 build 之间有什么改动，然后针对这些改动，我们就可以实施 Code Review 了。 便于开发流程的管理 。比如说，要把一个开发的 build 提交给测试组作测试，测完满意了，再提交到发布组去发布。