本节案例主旨：设计匠艺/流程再造
实践案例读一读
第四篇 设计匠艺/流程再造
持续交付由问题倒逼产生－豆瓣持续交付实践总结
一切以产品发布为起点向前用问题来倒推。
问：围绕着更快地发现问题这个前提我们能做什么？
答：监控和反馈。只有通过全方位的监控、快速的反馈和有效的通知提醒才能更快地发现和解决问题。
问：上线之后问题抛出之前，我们一般做了什么？
答：发布上线程序和更新相关配置文件。配置文件纳入版本管理系统，并且每次提交用pull request来作为审核和告知团队的方式；并将配置文件分发更新自动化，我们只需要关心实际变更即可，减少人为操作错误。
问：按流量上线过程是怎样的？
答：发布上线程序，再往前推，其实经历了一个复杂的过程才会发布，到达最终用户使用手中。按流量分发到单机和集群，最后全量；线上环境、预发布环境和开发环境互相隔离。
问：发布到预发布环境前测试工作怎样？
答：分层测试，底层测试数量多运行最稳定，执行时间最短的单元测试；中间层测试数量适中，比较稳定的接口测试；上层UI或面向用户测试，数量最少，运行时间最长。代码合入主干前也会持续测试并进行实时反馈。
问：为什么要引入pull request？
答：减少问题的产生，尤其是feature branch合并代码；使用pullRequest可以将changeset变得更小更碎片化，使code review变成可能，使主分支小步快走，任何时间版本都可以发布，使回滚变得容易。
问：工作流只有一份二进制文件么？
答：首先在持续集成环境执行编译和测试－测试通过会进入预发布环境－数据推送预发布服务器－问题通过监控系统反馈出来－修复问题直到正常再发布到线上服务器。每种解决方案都是针对特定条件的特定问题。日常问题解决，抽象出根源，找出根本原因和为什么，根本性解决问题。问题是什么？问题的根源是什么？更有信心更快地发布。互联网唯快不破。
集成与交付方案目标－去哪儿网快速开发实践总结
化整为零（系统解耦、独立研发、独立上线）电信行业必须所有源代码放在一起编译，一起打包，一起部署（紧耦合，牵一发而动全身）；互联网软件松耦合，模块间有关联，有依赖，意味着改动一个模块只需要几个模块编译、打包、部署到服务器上。
小步快跑（持续演进、持续交付）做一个交付一个，可以先后甚至同时有好几个feature在开发。原因是系统解耦 + 交付软件本身是低成本过程，周期时间缩短，从做一个功能（比如一次改版、一次促销、一次政策调整），到程序实现这个功能，到把这个功能网站上线总共花的时间。每个功能点单独上线，会有需求分析描述文档，然后研发、测试、上线－BUG FIX搭车发布；但多个功能点一起发布，放在一起测试可更节约成本，提高开发速度，也需要因地制宜。
一键发布（从源代码一直到线上运行），需要考虑的点包括：往服务器拷贝要保证准确、有些内容不能拷贝，有些内容不能覆盖、常常是要更新好多服务器而不是一台、更新版本不能影响网站运行、需要停止容器运行、部署后需要进行简单验证－最好是在代码提交前就已经能方便地定位问题。
主干即线上（自动保证线上版本的继承性），概念上为某个改动拉出分支，然后合并回来。做新功能从主干拉出分支、开发过程中及开发结束后，从主线上往你所在的功能分支做合并、开发过程及结束后做同等质量保证、确认功能分支源代码质量合格就可以上线，合并分支进主线。
待做改进的要点：
比持续集成更进一步。监控功能分支，增强提交前的自动检查。
多个模块上的改动一起处理，一起部署多个模块，每个有自己的分支。
测试运行环境管理，测试环境联调，相关模块测试。不仅仅是部署相关模块的正确版本，还包括数据库的结构及测试数据的管理。还包括各种配置各种参数的管理等等。
如何进行多终端Web前端优化
移动设备硬件配置低、电池容量有限、网速慢且不稳定。性能优化注定是一个纠结过程，开发者要在成本、时间、性能、体验等多方面进行不断地取舍。
跨平台。多终端很多开发者选用本地代码+HTML5。性能优化考虑兼容性、又要考虑通用型、甚至多个应用共用一个页面的可扩展性和可维护性。
登录：优化启动速度。QQ互联是腾讯免费为第三方网站、媒体、终端提供的开放能力，包括PC和移动端的登录、分享等社交组件及开放API等。QQ互联对很多应用都是超级入口，接入网站和应用上万。前端优化不等于优化前端。
QQ互联支持多种登录场景：PC上的网站和客户端应用可以通过web页面进行登录，安卓和苹果设备既可以通过移动版页面进行登录，也可以通过手机QQ进行SSO登录。采取的措施包括：优化流程步骤、JS文件减少，图形资源用CSS实现，减少资源请求，优化HTTP请求数－不同网络不同设备单独测试、手机QQ登录。
定向分享就是将应用内容发送给QQ好友－难点在于QQ好友的选择页面，移动设备上不可接受文字+图片可能达到一兆，需要针对不同设备制定不同加载策略。PC可一次性加载所有好友信息，分时加载头像；移动设备分时加载头像和好友列表，取Top20，在用户停止滚动列表时拉取方式可见的头像－划分延时加载粒度的时候要充分考虑用户场景和平台特性。
JS放在页面最后执行？导致样式、数据和程序代码串行执行－将一部分负责加载数据的JS代码放在HTML页面头部，从而使得浏览器在加载HTML页面可以并行加载数据，页面底部JS加载后可以马上展示数据无需等待。webkit内核webview使用新的webp格式文件展示图像。
后台综合优化：影响软件可用性包括负载均衡、多网接入、就近接入、容灾备份监控防御等等。
心得：前端优化不等于优化前端、明确优化目标，为什么要优化、投入产出要做取舍，降低成本也是一种优化、拥抱新技术。
淘宝定向广告算法创新案例介绍－淘宝网广告创新算法总结
互联网广告算法，脱胎于机器学习和数据挖掘。
定向纬度创新：店铺定向
“店铺风格倾向性”（经常访问、曾经搜藏、经常购买某店铺）的人群比例超过三成－不定期访问、店铺依赖性、新品出售、新活动进行。经过对数据进行各方面分析，我们对喜欢店铺排序打分，原则：不同店铺浏览行为对点击贡献不同：浏览较大，其他次之、时间衰减、行为频度上限（在上限附近人群对于点击贡献急剧下降）。对点击贡献进行拟合分析、分析时间衰减，给出衰减函数、对高行为频度给出一个反向补偿。
定向纬度创新：季节定向
有些热点总在特定的时间出现，茶叶其特点：跟季节有关、热点爆发曲线陡峭、某个热点总是针对某一类人：每年重复率高、热度高，消失得快。跟季节相关的热点，是一个崭新的定向纬度，我们把每个热点都叫做一个事件，这个事件可以由发生时间、热度、影响用户、热门商品集合表示成一个四元组，Event（频率，热度，能影响到的用户，热门宝贝等），不同人群进入不同事件，事件触发时满足该部分人群特定时间的需求。
商品聚类：每个商品属于一个部类，但类目概念太粗不利于描述商品。再细化分为小类别：首先，利用搜索词对应的商品信息，对搜索词进行相关性计算；其次，对搜索词进行聚类，并根据热度等指标对距离很近的节点进行归并；最后，将商品挂到新的聚类节点上面，组成一个新聚类体系。最上面是老类目体系，中间是新聚类体系，最下面就是商品和同商品聚合。新节点体系当中，所有的边都是有权有向边，权重就是结点相似度，并归一化。
未来：定向纬度增加新维度，点击率和用户疲劳、多样性的关系，已展示成果对后续优化的指导意义、负反馈－目前算法不够深入后续可挖掘负反馈的渠道并进行特征化，加入CTR预估、利用文本相关性提升点击率预估的冷启动问题
TCPCOPY击败Double Click的利器－网易广告投放系统开发实践总结
网站自主研发广告投放系统，因double click无法满足业务新需求且越来越复杂（通用性的局限性在于对新业务需求显得无力，其自身的同步架构导致受到DDoS攻击时表现不力）。网易自身的广告投放系统需要实现如下目标：满足日益增长的广告业务需求、替换过程中不能出大问题、节省服务器资源、更能抵御DDoS攻击、投入少。
解决思路：避免线上失误，常规做法是记录log或者录制，通过回放线上请求，以暴露线上问题。请求回放，可以分为离线回放（应用最广泛，实现起来比较简单，网络环境异常复杂的外网应用，无法暴露线上问题）和实时回放（更好暴露线上问题，可用回放工具往往在应用层复制请求－难模拟网络条件，而是应用层这种操作会影响线上请求的处理响应时间，从而影响最终用户的体验）。
基于底层的流量复制方法模拟线上压力进行实时回放，并开发TCPCOPY支持引流测试－只有采用跟线上类似的环境，才能提前暴露出线上问题（和线上环境越接近，测试效果越好），引流工具：底层流量复制工具，它成为新广告投放系统开发、试验和部署的关键，是实现比Google double click更强大稳定广告投放系统的基础。从线上服务器上面运行TCPPROXY程序，从线上服务器的数据链路层捕获线上请求数据包，并实时转发给测试服务器，由于转发是基于包的转发，既可以保持线上网络延迟，丢包等底层特性，又可以把绝大部分线上请求导入测试服务器，测试服务器压力可以接近于线上服务器所承受的压力。
细节考虑：线上请求去测试服务器，需要解决若干难题，如尽量降低对线上系统性能方面的影响（底层开始复制，被复制请求经历的过程最短/资源消耗少/速度快），不能影响线上系统的正常运行（测试服务器同样返回真实客户端，需要采用iptable去掉测试服务器的响应包；不需要中断线上处理；测试系统独立，与线上系统没有业务往来）等。
几个关键实践：突破常规思路，采用基于底层的流量复制方法，是开发网易广告投放系统的转折点和关键点；采用好的方法，不仅可以减轻开发压力，而且能够加速新系统开发；利用TCPPROXY，可以提前暴露线上问题。
柔性流程设计－一种真正面向业务价值的软件开发过程体系
CMM能力成熟度模型第一次接触过程模型，基于此流程的误区：强调在流程中建立严格定义的控制点/检查点（例如：里程碑）；强调在流程中设立严格定义的、明确分配的角色与职责（例如：项目经理、配置管理者、质量保证QA）、强调各个环节明确的准入准出条件、强调统一的文档模板和交付件；而敏捷方法：对员工个人能力（技术能力/个人职业素养/主观能动性）要求很高、敏捷方法对客户要求很高－推荐客户人员/代表直接参与需求分析的过程，以工作坊形式，让客户代表与开发人员对于需求达成共识－这就要求客户（对业务模型有清晰的认识、有强烈的主观意愿参加工作坊、有时间）、敏捷开发对团队的稳定性要求很高，很多沟通事宜是通过成员彼此之间的默契来达成的。
CMMI一抓就死［结构化的生命周期模型、明确的角色与职责定义、文档化的沟通方式、强调记录的过程控制要素］、敏捷一放就乱［个性化的生命周期模型、人员一专多能、多样化的沟通方式、强调快速响应的过程控制要素］。
作为跷跷板的两端，无论CMMI还是Agile，都依赖以下事实：无论哪一种模型，必须要针对业务产生价值，流程要服务和服从于业务目标；流程的执行，必须要服从于它所处的环境，即客户的要素。客户对业务的规划、客户对技术的理解，乃至于客户的主客观的参与程度，都是采用何种流程 体系的重要考量基石、流程的执行，还需要服从于它的应用对象，即开发人员。开发人员之间的配合程度和默契程度、开发人员的技术能力和业务能力等，也是采用何种流程体系的考量要素。
柔性流程设计希望能够平衡企业内部日益增长的业务类型与相对单一的流程体系的矛盾，希望能够面向业务场景和应用环境、同目前既有流程模型形成一体化的集成，并且真诚希望将流程的选择与应用的权利交还给流程执行的第一线人员－项目经理－让听得到炮声的人做决策。
项目启动时，根据项目特征，有项目经理、高层经理和QA一起，选择一组适合于自己的过程组件集合，将所有可能的流程/方法论预先定义成不可再分的流程组件。
项目自身的特征：客户业务能力、客户技术能力、客户参与度、项目成员技术能力、来自高层的项目管理目标、项目规模大小、项目特殊交付保障要求、项目所需要的第三方应用要求等8个纬度判断的项目的场景。每个项目启动时，需要完成“对本项目最适合的场景描述”的选择。
流程组件定义使用场景，每个项目选择，推荐使用、可以使用、不推荐使用等。包括需求开发、需求规格化、需求管理、解决方案制作、编码及代码验证、系统级验证、确认与部署上线、用户文档制作。
组织级识别、定义、发布、执行和维护的过程组件的全体，构成“过程组全集”；某一项目组所选取的组件集合，同时构成该项目组的生命周期。过程组件是过程全集的最小单元，不得拆解，但是可以与其他组件组合（必须符合全集定义）。每个过程组件的定义都包括如下内容：选择条件列表－倾向性建议、入口与出口条件、角色与职责定义、模板/备忘录/样例、可能的相关培训材料。每个项目选择自己的组件流程。各个项目组的过程集合根据自身情况选定组合，个性化流程服务。
使用Adobe Air进行跨平台桌面软件开发
比较流行的跨平台技术主要有Adobe AIR，HTML。对于技术平台的原则，其实受到的限制很多－包括技术人员组成，项目时间和资金的情况，以及所选技术的成熟度。技术选择非常重要，是因为它不仅关系到产品的开发效率，产品的实际效果，还有项目是否可以按期按质交付。在技术平台的选择过程中，一定要做足功课，对所有功能点都要进行实践论证，确保每个特性需求都可以在该平台上方便地实现。项目后期没有预料到的问题，改变技术平台往往不是最好的方案－应该考虑通过改变产品特性，甚至牺牲部分功能或降低用户体验来继续完成项目。等产品发布出去后，再考虑是否在后续版本中更换技术平台。
每个模块可以单独开发调试并测试，最后进行整合，并行开发。ANE独立测试程序包括本地库，本地代码写的测试程序（它会调用本地库），用于最终产品的SWC库（它也会调用本地库），共享代码，功能模块化。多模块并行开发，要注意子项目的进度和构建时间协调和统一。避免出现一个模块等另一个模块的情况频繁发生。
基于Zookeeper和Storm的车载流式计算框架－富士通实践总结
数据源源不断的特征，且需要对组织进行持续的加工，这一特征可以用流式计算来表达。在流式计算方面，开源流式计算框架Storm符合我们的业务场景，具有很好的扩展性以及高可用性，处理性能也不错。数据存储需要扩展性和高可用性选择NoSQL。在集群协调与监控方面，选择ZK用于监控集群中节点的状态以及保存全局配置信息。
事件层：终端通过前端负载均衡连接到转发服务器，转发服务器将终端事件产生的数据发送给消息中间件。
消息层：该层存储终端产生的实时数据，采用MQ+DB的方式保证数据的高可用性及备份，其中MQ起到通信转发和数据分析的解耦作用。
处理层：该层接受来自MQ的实时消息数据，并在流式计算框架中进行计算，不同数据可能有不同处理过程，通过设置流式计算中不同节点的计算过程，可以很好的解决这个问题。
持久层：该层存储式计算平台后的结果，并将计算结果存储在数据库中，供上层应用层展现。
应用层：该层将经过计算平台计算后的数据进行展示。
来自于终端的数据源源不断，数据在流通过程中会经过很多环节处理，使用Twitter的Storm框架进入我们的视野－可以帮助我们完成不同节点间的数据传输以及任务协调上的诸多工作。计算框架出来我们可以专注于业务，而不太关注底层消息传输及任务协调细节，只需要设计自己的Bolt即可（数据库－取－分析－预处理－统计）。
使用分布式的NoSQL，MongoDB，从文档丰富程度、社区活跃度、使用者数、稳定性和扩展性五个方面进行考量。一些教训：Mongo不支持外键、不支持事务、复杂查询会比较痛苦，但具有优秀的扩展性，sharding功能解决了传统关系数据库复杂水平垂直切分，数据插入和查询提高很好规划，Replicate Sets为其高可用提供坚实的保障。
ZK作为协调者高可用，重要数据存储在ZK上，并且ZK还可以作为集群节点运行状态的监控平台。
成功要点：对现有系统充分理解与吸收，掌握现存系统业务流程、对开源框架深入调查及各种开源软件框架的整合、团队合作。各种策略并用，系统稳定性提升，维护费用变低、数据分析能力提升，数据吞吐量提升、原始数据到用户可视数据的分析加快，实时性提升。
启示：适合自己的才是最好的、架构设计过程（需求分析－头脑风暴－借鉴开源框架－理解开源框架－改造开源框架）。
程序蓝图可视自动化逆向工程技术
程序代码理解是学习开源软件和维护遗产软件系统的基础和前提－采用自主研发的代码逆向模型自动化技术与工具，通过代码词法语法扫描分析，结构分析、模型格式化转换，中英文名字映射表构造，以及自然动作汉语语义描述的自动变换等步骤将大型开源OpenCMS和十余个遗产软件系统的JAVA程序代码自动逆向变换为可视化类图和过程蓝图模型，将Java程序语句自动逆向变换为自然动作模式语言汉语描述，自动构造分层抽象的程序蓝图的视图模型，以直观图形和自然易懂的汉语分层揭示程序代码中隐含的模块结构、算法思想、及其设计与实现细节。
整个逆向工程过程可分为程序蓝图逆向自动变换和程序蓝图文档和代码自动生成两个阶段。第一个阶段完成将软件源码自动转换为类图和过程蓝图模型库的工作。第二个阶段将模型库内容以模型文档和中英文程序代码的形式自动输出。
敏捷转型初体验－开发自测实践
传统理念强调测试人员对质量负责，而敏捷测试强调整个团队共同承担质量责任。分阶段、分步推广实施开发自测实践，并运用PDCA戴明环过程改进方法指导实施，解决测试资源瓶颈和投入产出不高的问题，并提高开发人员的质量意识和测试能力，提高整体产品质量和研发效率，团队合作也更加高效。并发测试任务很多，测试返工频繁，回归测试工作量大，沟通成本很高，导致整体测试投入很高－前期参与度不够，产品质量不高，计划性较弱，临时性紧急需求多。团队时间短，测试积累不够，缺乏完善的自动化测试体系，自动化投入产出不高。
一些数据特点：
项目按照复杂度、重要程度及开发工期可分为A/B/C/D四级，A/B级项目周期长，比较重要，C/D级项目基本都是一周内能够完成的功能需求。
经过统计，发现C/D级项目占据项目总数的80%以上，每个月A级项目仅有1-2个，B级在10个左右。
缺陷分析－测试人员80%的精力只产生20%的价值，投入产出比低
A/B级项目由于周期长，需求变动大，功能复杂，缺陷数量多，但人员比较稳定，项目质量比较容易控制。
C/D项目周期很短，变化快，容易出错，大多数是页面设计和交互功能问题多，容易被发现，严重度不高，但测试回归所耗费的资源反复比较多。
提高测试有效性，开发人员自测，把相对比较容易进行执行、重要性不高的测试任务交给开发人员自己完成，从而可以让测试人员专注于更重要的测试任务。
怎样执行呢？分阶段、分步骤，PDCA，有问题立即改进，分两年完成
第一阶段的时间从2011年底到2012年，主要目标是通过提测版本验收提高提测版本质量，避免测试返工。
针对A/B级项目，测试人员提前整理项目的重要测试用例作为验收用例，开发人员在提测前自行根据验收测试用例实施测试，并提交测试报告，说明用例验收情况，所有验收测试用例全部通过并且没有严重缺陷才允许提测。如果测试通过，则由测试人员实施全面的集成测试和系统测试。自测通过率较高的项目，测试阶段发现的缺陷数量会变少，而未有效实施自测的项目BUG数明显较多。碰到的问题包括开发人员不知如何执行测试，或者测试执行效果不好，一些项目没有通过验收就提交测试，导致刚开始时执行效果不好－开发负责人认可该方式+测试人员提供测试技能培训、指导开发实施测试+团队接受验收测试规范［项目编号、项目名称、上线车次、用例总数、自测用例总数、自测失败用例、自测通过率、项目缺陷数目］
第二阶段C/D项目开发自测，持续改进和优化，目标是实施小型项目免测－提高测试效率+开发自测经验，缓解测试人员紧张的局面
第一步选择风险较小的D级项目试行，这些项目数量不多，功能简单，基本上都是界面修改，测试手段容易，功能影响面小，即使出现一些问题也能及时修复－做法是开发人员根据需求整理测试点，不超过5个功能点，测试人员评审，指导测试方法。开发自测后出现问题自己修复。
D级实施一段时间后，C级项目推广，功能相对复杂，开发和测试人员一起整理测试点，通过共同参与，帮助开发人员正确理解测试点。开发完成由开发实施功能测试，测试人员负责性能测试－开始阶段测试人员会复查。个别开发测试结果不理想，通知主管介入，按月统计
强调UAT环节需求验收
第三阶段A/B级项目开发自测，技术架构和实现上进行重构优化，测试主要是回归，针对代码的修改很难直接实施测试，单元测试和集成测试往往是最有效的测试手段。由开发人员开发设计测试用例，并且实现单元测试、接口测试、集成测试代码，并实施压力测试、稳定性测试和性能测试。测试人员参与需求评审、评估风险点，并监控分析业务数据，提供反馈意见。
提高质量意识，拥有者意识，沟通加强，质量提高，测试投入产出和研发效率，成员满意度，共同承担责任。是否实施开发自测，如何实施开发自测，都要结合团队实际情况而定。
其它保证效果的必要条件：公司高层的支持尤其是研发负责人－至少不能成为阻力，从上而下强调对质量的重视、开发负责人的态度、业务类型的原则－只要快速修复，不会导致重大故障、敏捷思维宣导。
网友评论