攻玉集

诗经·小雅·鹤鸣 有云：「他山之石，可以为错。」，又云：「他山之石，可以攻玉」。现在用来指他人的长处可以拿來磨练自己，使自己更加精进。

TableOfContents

M$篇

TechEd2004:

• SDM231:

  • 项目的五个流程阶段——启动->计划->执行->控制->结束，软件开发的流程特点是循环式的控制阶段——功能需求>设计规范>程序开发>测试；

  • 软件开发项目管理的十大精华指南——1.理解用户和市场要求，明确功能需求和范围。2.撰写完整的设计规范书，包括使用方案和界面。3.制定从下到上的项目进度时间表对其进行追踪。4.以设计规范书为准制定构架设计及开发设计。5.进行源代码审核、提交、版本的管理。6.编程以测试为目标、将测试作为编程的一部分。7.制定完整的测试方案，进行执行的追踪和把关。8.进行严格的更改控制管理。9.设定发行合格标准，进行发行管理。10.记录项目的历程，建立项目历史档案。

  • 软件开发管理的七大关键理念——1.整个开发历程是个循环性的重复过程（将一个开发周期分成多个段里程，多做短阶段的“发行”）。2.注重灵活机动进行调整、避免死板计划。3.设计三步法：使用方案->功能需求->功能设计。4.将测试设计到程序里去。5.渐进发行：镇定纠错，降低失误率、提高稳定性。6.更改控制建立在“三国会议”的意见基础上。7.任何项目都受“金三角”的影响：功能、时间、资源。

• DAT322:
  • 典型的数据挖掘任务：1.分类-将个体按照预先定义好的标准进行分类。2.规约-规约非顺序类型数。3.聚类-将相同个体分割成组。4.关联-高兴相关性统计。5.时序预测-预测另一组相关数据。6.偏差分析-颤沼数据相区别的原因。7.可视化-图形化显示。
• DEV343:
  • 性能方面的设计考虑
    • 在适当的时候缓存数据：1.缓存频繁检索的数据以减少往返进程。2.缓存只读引用数据。3.缓存发送给Web服务的数据。4.尽量少地缓存高度不稳当的数据。5.尽量少地缓存敏感数据。
    • 优化网络通讯：1.倾向批量的数据传送。2.避免发送整个数据集。3.将大型数据集分解。4.区分静态和动态数据。
    • 线程处理：1.优先选择异步调用。2.使用线程池代替手工创建线程。3.使用后台线程而不是UI线程。
    • 使用多线程的时机：1.进行网络通信。2.执行长时间的本地操作。3.区分任务的优先级。4.提高应用程序启动和初始化的性能。
    • 事务原则：1.避免网络上的分布式事务。2.将事务限制在某一端执行。3.使用补偿事务替代。
    • 管理可用资源
    • 优化应用程序启动时间：1.优化主窗体类中的成员变量。2.尽可能使用惰性加载。3.使用集中的程序集，但功能独立的类。4.使用预编译。
    • 优化Windows窗体性能：1.小心创建句柄。2.避免创建太多控件。3.使用分页和惰性加载。
    • 性能调整和诊断：1.制定性能目标。2.考虑用户的观点。3.考虑应用程序操作环境。
    • 性能调整过程：1.建立基准。2.收集数据。3.分析结果。4.调整应用程序。5.测试和度量。
• DEV371:
  • 何时使用多线程：1.通过网络（例如，与Web服务器、数据库或远程对象）进行通信。2.执行需要较长时间因而可能导致UI冻结的本地操作。3.区分各种优先级的任务。4.提高应用程序启动和初始化的性能。
• SDM244:
  • 灵活性模式
    • 轻型计划：1.奉行改变：从整个的项目开始起就期望计划、需求、和设计都会改变。2.整个开发过程有客户的经常参与，甚至邀请客户来到开发团队的工作处，对正在进行开发的半成品使用、审核、提意见。3.客户直接参加项目的计划的修改。4.整个开发计划是个不断更新的过程。
    • 经常性的发行：1.短期的重复开发周期。2.采取所谓的“时间盒”方法-将预定的预期锁定为一个发行周期。3.保持产品接近发行的状态。
    • 简化的设计：1.先对那些已经确定了的功能进行设计。2.意识到任何多余的功能，一旦加入到软件产品中，会增加修改和维护的费用。
    • 以测试为驱动的开发：1.编写产品的程序前先写测试的程序。2.单元测试应该全部自动化。3.单元测试的运行应该成为开发的日常工作。
    • 重新组合：1.重组：在不改变功能和行为的前提下，对软件的内部结构为更容易和更方便改动而进行设计和编程上的改动。2.采用渐进式的设计方式来逐渐完善程序。
    • 连续性的整合：1.将开发团队多人开发的各功能组件进行整合，最后生成完整的软件系统或产品，应该是一个经常进行的、连续不断的过程。2.每天或每几小时进行总汇编和产品建造（Daily Build）
    • 及时文件的编辑：1.将产品或系统的使用手册、维护条例、使用参考等等一系列文档根据各功能开发的进度进行编辑。2.趁着概念新鲜明确，将它们写入文档。
• SDM302:
  • 什么是“BUG”:1.造成系统崩溃，或停止运行。2.实现的功能与设计不一致。3.界面、消息、提示不够准确，不标准，不友好。4.与该兼容的系统不兼容。5.文档与帮助信息不准确，不完整，可读性不好。尚有未完成的工作，或为实现的功能。6.建议和有助于改善产品的信息。
• DEV365:
  • 性能管理：

    • 顺其自然：1.更注重功能开发&希望程序足够快。2.开发人员最通常采用的方法。3.负面因素：<1>性能问题经常源于最初的设计。<2>性能问题往往不能依靠简单的调整解决。<3>在软件开发后期解决构架与设计问题将非常昂贵，容易导致错过最后期限与结束日期的低信心。

    • 优化所有代码：1.开发人员尽力使所有代码以最快速度运行。2.负面因素：<1>高度优化的源代码很少被执行(10/90)。<2>过度漫长的开发周期。<3>贻误甚至失去市场机会。

    • 性能工程：1.把性能与伸缩性的考虑融入开发周期中。2.定义性能与伸缩性的目标。3.针对目标进行定期测试。3.根据测试结果进行调整。4.有的放矢。
  • 构架设计的主要考虑因素：1.Scale Up vs Scale Out。2.逻辑分区。3.充分利用多处理器的力量。4.线程模型。5.最大限度地减少不同组件之间的序列化。6.客户端与中间层缓冲。7.无状态与全状态。
  • 单进程与多进程：

    • 单进程：1.可靠性与安全性较好。2.进程间通讯(IPC)比较昂贵。3.在32字节的硬件上可以访问>4GB的地址。

    • 使用多线程的单进程：1.异常情况处理能俘获出错的线程。2.避免了进程间通讯的消耗。3.在32字节的硬件上可利用AWE访问高达64GB的地址空间。
  • 线程模型：
    • 理想模型：线程数=CPU数并且线程永不阻塞；实现：1.用线程来简化编程，而不是提高并行性。2.没有使用I/O异步处理。3.在不同的功能区不加分辨地使用不同的线程池。
    • 优化方案：1.总线程数不应比CPU数高很多。2.主要线程不应阻塞，除非等待工作项目。3.尽可能使用异步I/O。4.在无法避免同步I/O时，转手到专门的线程池。5.根据不同线程池的特性设置合适的线程优先权。
    • 线程与同步：多条线程改变共享数据，从而需要使用同步物体（锁定）；系统构架应尽量减少使用同步物体：1.线程应主要更新私有数据。2.尽可能使用无锁定技术。

    • 同步：1.避免在不必要的情况下使用锁定。2.通过分区来减少锁定。3.在持有锁定时：<1>把持有时间减至最低。<2>避免I/O,SetEvent。4.尽量避免同时获得多个锁定：在必要的前提下，可运用锁定排序来减少死锁。5.假如绝大多数数据访问是读，使用读写锁定。

  • 网络I/O：
    • 1.应尽量使用异步I/O。2.尽可能复合连接。3.消息成批发送可减低协议消耗的比例。4.在高流量的连接上，一次读取大量数据。5.简明有效的协议。6.连接限制/节流。7.避免引起连续饥饿。8.不要进行额外的数据拷贝。9.适当调节连接的TCP发送与接受缓冲区大小。10.连接管理。
  • 存储与缓冲：
    • 1.服务器系统应永不分页。2.预先分配存储池,并循环使用。3.考虑每条线程拥有单独的存储堆:甚至考虑每个用户连接拥有一个小的存储堆。4.存储碎片化。5.注意不分页存储池的设置。6.避免不必要的存储拷贝。7.减少使用Virtual Alloc/Free的频率。
• OFC281:
  • 搜索的四项关键技术：信息采集，建立索引，查询，回应。

  • Google的PageRank算法：假设1，一个从页面A到页面B的链接是页面A作者对页面B的一个推荐。假设2，如果页面A和页面B相互链接，那么它们很有可能是关于一个主题的。假设3，如果页面C既链接了页面A有链接了页面B，那么可能是页面A和页面B联合链接。如果A和B被多次联合链接，那么A和B和C有可能相关。