分类目录归档：Engineering

复盘 CheckList

发表于由
回复

复盘步骤

  • 过程回溯
  • 问题描述 & 影响统计（正面、负面）
  • 优化方案 & 方案评估
  • 经验总结
  • 方案执行追踪

复盘检查点

下面是一些标准问题。如果在原因分析/改进措施中已经处理，请写上改进措施序号。对于没有处理的，说明为什么不需要处理。

例行检查点 答案示例
为什么会发生这个问题？ 内部不够、以及新出的坏道告警处理方式双方没有对齐。
在哪个阶段出现的问题？ design、coding、操作？
为什么测试阶段没有发现? 新上的告警灰度阶段发现的问题，测试阶段无法覆盖
系统为什么不能容错？ 不需要处理
能不能更早发现问题？ 双方建立告警对接机制
解决过程能否更快？ 不需要处理，主要是流程优化。
怎么防止类似的事情发生？ 加强内部宣导；进一步完善SOP；对于新告警，双方及时对齐处理方案
我们是否过度思考了？ 方案太过长远，无法解决短期问题
方案三阶段 短期、中期、长期

C++网络服务迭代开发-模板

发表于由
回复

需求分析

需求相关内容

系统设计

系统升级方案

系统设计、更改相关内容

测试用例设计

No. case 预期
1
2
3
4 回归测试-点

发布方案

包含灰度、全量发布流程

人力评估

项目 人力
合计

编码开发

grerrit code review地址：

测试结果

功能测试

No. case 预期结果 测试通过（✅ or ❌）
1
2
3 回归测试

性能测试

qps cpu idle 内存 失败率 延时P99 是否通过（✅ or ❌）
实验 50% ❌
基线 50% –
实验 30% ❌
基线 30% –

稳定性测试

测试项目 qps 内存是否异常增长 是否产生core文件 是否通过（✅ or ❌）
cpu idle 保持50%以下，持续压力测试4小时 ❌

特征打分一致性验证

测试项目 是否通过（✅ or ❌）
预发环境验证打分一致性，bdsp任务结果是否通过 ❌

上线部署

预发验证

功能验证

性能验证

分类 项目 是否通过
性能 CPU
内存
延时
带宽
服务 失败率
超时率
错误日志
特征大小变化
数据打分 ctr 骤变
cvr 骤变，各类cost type
cvr2 骤变
ecpm
特征一致性监控 观察特征一致性报警

灰度上线并验证

功能验证

性能验证

分类 项目 是否通过
性能 CPU
内存
延时
带宽
服务 失败率
超时率
错误日志
特征大小变化
数据打分 ctr 骤变
cvr 骤变，各类cost type
cvr2 骤变
ecpm
特征一致性监控 观察特征一致性报警

主干上线并验证

功能验证

性能验证

分类 项目 是否通过
性能 CPU
内存
延时
带宽
服务 失败率
超时率
错误日志
特征大小变化
数据打分 ctr 骤变
cvr 骤变，各类cost type
cvr2 骤变
ecpm
特征一致性监控 观察特征一致性报警

工程师文化&工匠精神名言名句

发表于由
回复

Scientists study the world as it is. Engineers create the world that has never been. –Theodore von Kármán

但尽管Google的核心算法出自冰雪聪明的工程师创新，但能否拧成一股绳才是公司持续发展的关键。

不要去做设计高手，只去做综合素质高手！ –贝聿铭

知者创物，巧者述之守之，世谓之工。百工之事，皆圣人之作也。 –《考工记》

我亦无他，惟手熟尔。(欧阳修《卖油翁》)

打工的状态并不可怕，打工的心态很可怕。(付守永《工匠精神》)

人心惟危，道心惟微；惟精惟一，允执厥中。(《尚书·大禹谟》)

建于精诚，工于品质。–作者：宋杰

在长期实践中，我们培育形成了爱岗敬业、争创一流、艰苦奋斗、勇于创新、淡泊名利、甘于奉献的劳模精神，崇尚劳动、热爱劳动、辛勤劳动、诚实劳动的劳动精神，执着专注、精益求精、一丝不苟、追求卓越的工匠精神。劳模精神、劳动精神、工匠精神是以爱国主义为核心的民族精神和以改革创新为核心的时代精神的生动体现，是鼓舞全党全国各族人民风雨无阻、勇敢前进的强大精神动力。——《人民日报》2020年11月25日

劳动者素质对一个国家、一个民族发展至关重要。技术工人队伍是支撑中国制造、中国创造的重要基础，对推动经济高质量发展具有重要作用。要健全技能人才培养、使用、评价、激励制度，大力发展技工教育，大规模开展职业技能培训，加快培养大批高素质劳动者和技术技能人才。要在全社会弘扬精益求精的工匠精神，激励广大青年走技能成才、技能报国之路。——《人民日报》2019年9月24日

执着专注、精益求精、一丝不苟、追求卓越。(领导人讲话)

分布式系统讲义（二、负载均衡策略）

发表于由
回复

同学们欢迎回来，这节课，我们来讨论分布式系统的那些事当然负载均衡的问题，什么是负载均衡的问题，呢就是上一节课。我们讲过分布式系统呢可能会有非常多的服务器来呃来组成这个系统。那么，这个系统，它是如何分工的呢？当很多用户都过来发送请求的时候，这些请求应该怎么样，去被分摊到不同的服务器上，让他们来处理呢？这个呢，实际上就是负载均衡要解决的一个问题。负载惊鸿，从字面意思就是让我们的服务器的负载，都能够均衡些。

这是字面意思。那么，我们是怎么做的呢？我们还是一个WEB网站为例子，当非常多的用户同时或者说任意同一段时间里面都来请求我们的系统的时候，我们就要把这些请求给他给分流分流到不同的服务器上。然后让他们老师让不同服务器呢，然后都能够同时来去处理这样用户。那么，这样做的一个目的是什么呢？第一个就是一定要让我们的服务器就是能够均匀地去呃去承受这些用户的请求，其实从用户的那个角度来讲呢，就是它能够及时的，它发出的请求能够被及时都给处理。

那么，我们来举这么一个例子啊，假如我们没有负载均衡的情况会怎么样？一个分布式系统，哎，哪怕强，如美国队长。那么，非常多的一个系统，它来一个请求就出了一个请求。那么，他也是处理不过来的，而好在呢我们是有非常多的一些服务器，我说一些计算单元，然后来平摊。那么，这些工作，这样的话，我们就我们就会让这个系统，呢然后在同一时间就可以处理非常多的一个系统，呃非常多的一个请求。那么，我们是怎么样去用什么一个方法，然后去把这些系统给它分流，呢这个时候，呢，就说到一个负载均衡的一些策略，最常见的一种两种策略呢是一个时装的，另外一个是软的意思，呢绒的的意思，呢实际上是轮询的意思就是来一个请求分配给你当前的第一台服务器。

那么，来第二个请求的时候，然后就把这一个请求呢，分配给第二个处理器进行呃进行处理，第三个就返回第三个，然后所有的服务器转了一圈以后，然后就这么轮询的完成。那么随机这种策略呢然后也是很好理解了。当一个请求过来的时候，它会随机的a选一台服务器，给他去分配处理这么一个星球。这样这两种复赛翻飞的策略，呢然后都能够让所有的机器呢然后都在运行，而不会出不会出现某一台机器，比如说不干活，另外一些机器又特别忙是吧？

这样子，呢然后就可以更快地去处理一些用户用户理解请求呃这么做的一个目的，呢实际上就是为了让那个用户呢然后及时的去那个得到呃得到处理。其实我们有的时候，我们可能会去一些。比如说政府部门或者说去银行办业务的时候，其实我们会排队，其实，这个原理呢，其实已经是非常类似了，在银行当中获得政府过程当中，它有非常多的一扇窗口。那么，他的那个排队系统用的是什么样的策略？呢其实很多时候是一个荣的是吧？那其实也不全是中的落地呃也不全是一个软得对，因为实际过程中很复杂，其实，我们解决计算机的问题。

啊跟我们的解决。现实生活中这么一个I期银行排队这么一个我其实很类似的，但是呢，我们也面临一个一个问题，就是有的服务器呢，年富力状有的服务器呢，性能比较差。那么这个时候你就不能用，就简单粗暴地用轮询，或者说说用随机的这种方法变得给他去哪个范围这个任务。那么，这个时候，有用的一个什么方法呢？就是一个加权，我们叫价钱的一个轮询，有些有些服务器呢年富力强，我们给他给他个全职，比如说一点吧，有些机器呢弱一点，啊我们给它的系数是0.8。
这样子的话，那么，一点的服务器他就可以接受更多的那些处理接触更多的请求去处理它，能够更快的呢，然后去返回那个性情用户请求的结果就有这么一种方法。那么，我们除此之外呢，实际上还有一种负载均衡方法。教你的意思呢，是叫最小负载的一种方法，呃这句话是怎么理解呢？这句话呢？实际上是一种比较，我们设置权重都要学人工的去标，实是把这台机器是个年富力强的还是一个呃，比如说是一个特别就的这么一个电脑，一个信号。那么，我们能不能自动系这个时候呢，实际上在我们的负载均衡里面，我们会写一个算法，我们会依据。
比如说CPU某一台机器的响应时间，或者说某台机器，它的那个队列的一个等待时间，我们通过一个一个算法，然后我们就能计算出它的全职来获得全职高的，呢它依然会给他分配更多的更多的一些请求我举个例子，大家如果是做c加加开发的话，会有一个b r PC的c加加框架，它里面那就有一个叫LA的这么一个负载均衡的一个算法，它呢，就依据它下游的服务器的一些等待时间，比如说CPU的负载还有那个返回的状态么？和响应时间，他就能判断出这台机器是不是一个性能更高的机器还是一个性能差的机器？

这样子的话，他就可以比较自动的去那个吧，就是自动的，去给那个依据机器的不同性能给他分配不同数量的一些请求。嗯，咱们再说一下。那么负载均衡他，有的时候，它是依据什么呢？我们依据什么来判断，就说我给哪台机器呢？其实还有一种方式就是我，如果我们做，如果我们做一个映射和随机的话，我还可以通过。比如说听说我校4层4层负载均衡还有呢？叫7层负载均衡这句话是什么意思呢？7层和4层负载均衡脑，只要指的是TCP IP当中的第7层和第4层4层呢，是指我们依据IC IP的地址呢，然后呢，我们就给他进行随机的去分配。

呃依据这个IP地址，然后给他做负载均衡，然后给他分配的后面相应的机器当中去。还有一个7层负载均衡，呢实际上是一具，比如说第7层实际上在TC标题里边是应用层，那么我们就一句在应用层当中的一些什么一些带过来的一些信息，我说是一些cookie，就类似于这样的一些应用带过来一些信息呢，然后给他趣，唉，比如说随机分配给那个下游的一些服务器，这个呢，是依据网络环境，然后我们来去见4层呢还是西，曾因为4层大家都知道的IP内层会更基础一些，会底层一些好了，大家我们来就是总结和分享一下。

总结一下，就是我们的负载均衡的方法都有哪些几种呢？实际上其实呢？都有这四种，主要都是有4楼，第一个呢，就是轮询随机。还有最小负载对外还有一个最小链接，但是也让过程中我们可能不是在实际过程中不会经常常见，我们来那个给负载均衡下一个定义啊。那么，食什么是负载均衡负载均衡，其实它的本质，啊它是一个起到一个路由的作用就是当一个用户过来的一个用户的请求。过来的时候，我们怎么给他录入到后端的一台机器上，让他去处理。
这有这个嗯完成了这么一个负载均衡以后，呢实际上分布式对于一个应用来讲，是否就结束了呢？呃其实不是的，啊就是我们怎么样去找到它下面的服务。呢这个内容呢我们会在下节课的时候，然后进行一个呃进行一个讲解。

分布式系统讲义（一、什么是分布式系统？）

发表于由
回复

同学们大家好，今天由我来同大家一起，通过大白话的方式，聊一聊分布式系统的那些事儿。

到今天为止，分布式系统已经是一种非常基础或者说非常通用的一种技术了。在互联网应用的后端服务中，分布式技术几乎无所不在，那么到底什么是分布式系统？我们为什么要用分布式系统？它到底有哪些优势？以及我们今后工作中面临的一些问题，如何通过设计分布式系统，解决这些问题呢。围绕着这些问题，我们在这门课中展开来讨论。

回到这门课的最开始的一个问题，什么是分布式系统？在给出这个定义之前，我们先来看一下一个后端服务的演化过程，拿一个外部网站来举例，最早的时候，它只部署在一台机器上，这一台机器承受的用户的数量是很有限的，一台服务器大概只能承受住300个人同时进行访问，但是用户量会慢慢的变大，从最开始的300到后来的1000人，在到后来的几万人。中国现在大概有接近10个亿的网民，这么1个数量级的用户数，我们这么一台服务器绝对是承受不住的，这个时候应该怎么办？

一般想到的它有两种方法，我们说的第一种方法升级我们的服务器，把我们的服务器从一个性能比较差的变成一个性能比较好的，它数据的存储本来是比如说只有几百g然后把它变成几个t这么一个容量的磁盘放到这个服务器里边去，这样子也能解决问题，但是它只解决了比如说用户数从300到1000这么一个问题，但是我们的用户数如果是几个亿，那个时候怎么办？

我们会有一个第二种方法，就是用几千台机器，然后让几千台机器，然后相互协作，去满足几亿用户的这么一个数量的这么一个访问，所以这个方法基本上已经给出了一个分布式系统的一个雏形了，由此我们其实是可以引出来，那么分布式系统到底是一个什么样的定义。然后出自分布式的概念与设计这么一本书，就是国外的一个经典的用来用来介绍分布式的这么一本经典巨著。

他说分布式系统是指位于联网计算机上的组件，仅通过传递信心进行通信和协调行动的系统。同时他又给了这么一句话叫分布式系统，它是一个即便是已经崩溃了部分机器，但是它仍然能够完成工作这么一个系统。除此听到这么几个定义，大家可能还是感觉比较细。

我来给大家举一个例子，我所在的智能平台部，我所负责的系统就是一个服分布式系统效果广告的预估服务，那么这个预估服务现在有多少台机器，这个事情我给大家说一下，大概是就是说大概是有3000台左右的机器，那么我们的小广告服务大概有3000台机器这么一个数量级的，而且这3000台机器各有分工，相互协作，然后能够满足我们现在广告这么一个业务。

同时它也满足这么一个定义。如果只有一部分机器宕机，那么它仍然能够满足效果广告，预估的工作，而不至于整个服务都不可用。

今天的例子，介绍什么是分布式系统，我们就是到此为止，下节课我们会去探索分布式系统它面临哪些技术挑战。谢谢大家。

互联网公司里有哪些不好的潜规则

发表于由
回复

喜欢做0到1，而不喜欢做从1到100的事情

这个现象非常普遍，做从无到有的项目的工程师，往往得到公司的资源倾斜，获得更多的晋升机会；与之相对的，如果是接收老的项目的工程师，承担了先前项目中各种不稳定的风险，产出没有从无到有做项目多，技术进步慢，晋升机会少。

深谙此规则的工程师，在职场上善于利用这个规律，专挑0到1的项目去做，做完后把项目交给其他工程师去维护，自己又挑别的新项目做。打个比喻，就是对项目管生不管养。这类工程师在职场上的表现往往有1个特点，就是非常喜欢挑活儿干。

这个问题的出现，往往是绩效考核和管理层价值取向有问题导致。

广告引擎技术特点

发表于由
1

是一种搜索引擎

广告引擎，是适用于广告搜索场景下的搜索引擎。广告引擎特点，也是由广告业务需求所决定的。

流量大

  • 依附于大流量的用户产品之中，负责将用户流量转化为商业流量。
  • 用户量大，但客户数广告数少。
  • 虽然流量大，但是对并发度的要求比较低。和用户产品相比，广告引擎的业务场景往往不需要和客户端维持长连接。

低延迟

  • 信息流广告必须快于信息，才能不伤害用户体验。
  • 特殊场景广告，必须低延迟，比如APP的开屏、插屏，不然会影响客户使用APP。
  • 在RTB系统中，对低延迟的要求更高。

一方面，由于exchange的存在，增加了一次网络请求和中间的竞价过程，DSP系统的响应时间就要更加短；另一方面，exchange对于DSP的响应时间会作为二次竞价的权值，提高响应速度对提高收入有利。

检索数据量少

  • 业界广告主数量少， 100万~1000万量级
  • 广告物料也少，1亿量级

和传统的搜索引擎相比，广告引擎的数据量并不大。

生产的数据量大

  • 用户每次的访问、展示打点追踪、点击打点追踪都要被记录，每日产生的数据按TB计算。

高可用

虽说高可用几乎成了所有后台服务的特点，但是广告引擎对高可用的要求尤其要高。

  • 系统的每次故障，都可能会造成公司收入的直接降低。

用户的产品的后台系统一旦出现故障，可能损失是用户数，或者伤害了用户体验，但是广告系统损失的是最直接的收入。

实时性

实时性的要求主要体现在广告的及时上下线。如果广告上线不及时，则不能及时产生收入；反之，如果广告下线不及时，则会引发广告超投，也是一种收入损失。

时序性

时序性比较表现在，同一广告的上线、修改、下线等改动，作为消息传递给广告引擎时，必须保证时序性。不然广告的上线和下线等投放状态会出现错误。

二八原则规律的一些特征

  • 80%的收入来自20%的大客户
  • 80%的收益得益于20%的数据

广告收入异常原因追踪总结

发表于由
1

本文内容梗概

总结和列举作者常见的广告收入异常的原因，总结问题定位和修复的经验。

因为作者日常多从事广告引擎的开发工作，所以下面的内容往往从广告引擎的视角来阐述。

本文内容多依赖数据监控的一些指标，比如流量、广告展示数、广告点击数、CTR、CPC、CPM、广告召回率、广告存量等。

正常的收入曲线特征

以下特征，仅适用于pv、广告数量级大，收入高的广告系统。

  • 收入曲线平滑变化，没有骤升骤降。
  • 收入变化呈现周期规律特征
  • 同比和环比没有大的变化。日期上与近几日或上周同一时间、上月同一时间，时间上取相同时间间隔内（5分钟）的收入相比，没有特别大的变化
  • 曲线变化符合当日特殊事件给广告收入带来的影响，比如双十一春节等节日、国家重要事件发布、大面积自然灾害等。

如果不满足上面的特征，则收入可能异常。

广告收入异常的数据表现

  • 流量异常
  • 广告展示量异常
  • 广告点击量异常
  • CTR异常
  • CPC、CPM异常

不同原因数据指标的表现不同

  • 流量异常

流量的异常，往往也导致展示量、点击量降低和升高，但是CTR、CPC、CPM等指标不会发生变化。这种情况将收入下降的排查范围缩小到流量端。

  • 广告展示量异常，但流量没有变化
  1. 如果广告召回率（广告存量）是否有异常，排查范围则缩小至广告上下线流程。比如系统问题导致广告上下线异常，广告主是否有大量的上下线操作等。
  2. 如果广告投放机有问题，则把排查范围缩小至广告投放机。
  • ctr 异常
  1. 广告展示量、CPC、CPM不变，则广告主投放的广告质量降低，广告创意素材吸引力差等。
  2. 广告展示量不变，CPC、CPM异常，有可能是由广告主调整价格。
  • CPC、CPM异常，流量、ctr、展示量、点击量都无变化
  1. 算法和竞价策略
  2. 广告主调价

为便于浏览，可参考下面的鱼骨图：

广告收入异常原因

总结

  • 有一个直观易读的数据监控和展示平台非常重要，有利于排查问题的效率。
  • 问题的排查特别依赖数据监控平台，因此数据监控平台必须先保证高可用和数据准确。

工程师手记-将多进程后台服务改造为多线程

发表于由
回复

背景

2016年秋，部门计划将移动广告引擎和新的移动DSP引擎做架构融合。保留原来的移动广告引擎的业务逻辑，将其移植到新的框架当中去。

新框架有很多特点，其中之一是所有模块都使用了多线程模型而老的移动广告引擎的一个模块则使用了多进程模型。

改造注意点

  • 临界资源的共享
  • 单例资源
  • 内存的共享

改造的陷阱

改造方法

在多进程模型中，单例模式可以安全地被使用。但是在多线程环境中，则要考虑多线程都要抢占单例类，单例类会成为瓶颈，而且还有可能出现线程不安全的问题。

解决方法：

将多进程的单例类，改造成进程体里多例模式，但是在每个线程体内单例。具体方法参考线程安全的单例模式

改造结果

改造成功，并且顺利上线，正常服务。

改造后带来的好处和坏处

  • 性能的提升
  • 内存

工程师手记-升级PNI以支持PHP7

发表于由
7

本文内容简介

  • 简要介绍本博客写作背景和目的：升级PHP Native Interface的代码使其支持PHP7。
  • PNI 升级以支持PHP7的过程做简单介绍。
  • 对这次升级的思路和方法进行总结。
  • 思维发散，假设其他情况下应该用什么样的方法进行升级php7的扩展。

背景和目的

PNI在2016年10月之前仅支持php5系列的版本。9月份时进行升级，使其支持PHP7。

PNI是什么？ 具体参考这边博文《PHP Native Interface》。PNI代码规模只有1000行左右，升级大概花费了一周时间（工作外时间），其中包含2天寻找思路、2天的代码升级，3-4天的问题排查。

这篇博客记录了一下PNI升级过程，包括自己学习PHP7扩展框架、API定义的过程，调试、压测、修复bug的过程等。

把这些东西记录下来，主要是为了总结出自己的学习方法和操作方法。写成博客后，可以更好地帮助自己反思升级过程中是否有哪些不好的地方。当然其中也会有自己的成功经验。

PNI 升级过程简述

面临哪些问题，以及有哪些不确定的地方？

  • 代码从何处改起？
  • 如何保证编译通过？
  • 功能能否保证不变，以及PNI自身定义的PHP接口是否需要发生变化。
  • 升级过程中遇到bug和陷阱怎么办？
  • 这次升级的代价有多大？

升级PNI，从哪入手？寻找突破点的过程。

用搜索引擎搜到了几篇博客，都是介绍PHP7和PHP5的 zend api 不同的网文。随意浏览了一下，感觉帮助不是特别大。

自己下载了PHP7.0的源代码，编译一下，稍微看了一下 Zend的源码（主要看Zend_API、zend_list、zend_hash），少数几个ext里的扩展的源码。

看了后收获特别大， 了解了 php7扩展编写的几个特点：

  • php7 ext 扩展编写框架结构变化小
  • API函数名称变化小，多数无变化
  • API函数参数列表变化大
  • 宏的变化小

升级的思路就有了。

升级方法？

依据发现的php7扩展代码的特点，决定以PHP5版本的PNI的代码为基础，进行升级。代码不需要做太大的变动，更不需要完全重写。

设立3个目标，并按顺序分步骤实现。 1. 升级代码，编译通过。 2. 功能验证通过。 3稳定性验证通过。

为了达到第一个目标，使编译通过，使用下面方法：

  • 参考其他extention，首先对比php7和php5扩展的框架，优先修改PNI的框架。

  • 对比PHP7 源码中的zend_API.h、zend_list.h、zend_hash.h等。

  • 要修改的函数多，可能会有API没有升级被遗忘怎么办？ 所以一边升级代码，一边make，看着gcc的错误提示去一点一点改正代码。

达到第2个目标的方法，则多写功能验证的测试case。

达到第3个目标的方法，是做压力测试，观察内存和cpu的使用情况。

  • 观察变量和资源是否被及时回收，是否有内存泄漏
  • 观察cpu负荷是否过高

在升级过程中遇到过最大的一个问题是，pni中遇到了内存泄漏。为了定位内存泄漏的原因，花了非常多的时间。

  • 打日志，定位内存泄漏逻辑。
  • 定位后，添加efree、free等函数调试。
  • 添加efree逻辑无效，打印对象引用计数的个数
  • 找到原因，是存储资源类型的变量，作为另一个对象的属性时，如果对象释放，存储资源类型的成员变量不会主动释放。
  • 解决办法，在对象释放的析构函数中，添加释放资源的逻辑。

总结

总体上说，这次升级PNI比较顺利。

在做的过程中，思路其实并没有上面写的那么清楚，心中也只有个大概思路。

在刚开始时，寻找从何下手的过程中，还是走了一点弯路，但浪费的时间不多。

走的最大的弯路则是，上文说的定位和解决pni内存泄漏的过程中， 没有首先想到去观察对象或变量的引用计数的。这使pni升级的过程直接阻塞了。今后遇到内存泄漏的情况，应该首先观察zval的引用计数数目是否为0.

思维发散

下面开始做各种假设，假设我会面临不同的情况（实际并不存在），我该设计什么样的思路和方法进行PNI的升级呢？

  • 假设PHP7和PHP5扩展开发的框架和结构有大的不同，对PNI的升级，完全重写也许是好方案。

  • PNI的代码规模只有1000行，假设10W行规模以上，我在达到上文说的，第1个编译通过的目标，就不能直接用gcc的错误信息去定位没有升级的代码，不能用一边改代码一边查php7 zend api代码。应该把PHP7的代码都给熟悉了，再去升级代码。

  • 假设升级代码规模大，php7的扩展框架和代码与php5也有大不同呢？学习成本和工程量将变得非常大，这种情况怎么做呢？ 1.大规模的代码，逻辑上应该做好分层和抽象。 在升级大规模代码前，应该先写一个小的PHP7扩展，拿来练手，这样学习的曲线就会平缓很多。

Web服务压力测试工具BullBench

发表于由
回复

什么是 BullBench ？ (what)

  • 一个可以对web服务进行压力测试的工具
  • 最大特点，BullBench 可以读取 nginx access log 中请求，并将其发送给web服务。
  • 也可以读取自定义文件，使用正则匹配和替换，定制请求，发送给web服务。
  • 可以同时模拟15000并发度请求（具体数值受限于系统配置）
  • 和bullbench类似的软件有 webbench、tcpcopy、jmeter等，与它们相比，bullbench有自己独特的地方，比webbench功能多，比tcpcopy操作简单，比jmeter编写测试用例的学习成本更低。

代码托管地址 : (where)

https://github.com/zuocheng-liu/BullBench

为何编写这个软件？ （why）

主要原因是，我曾经在查找一个系统内存泄漏问题时，遇到了一些阻碍：

  • 线下压力测试时，要尽可能模拟线上请求
  • 理想方案是使用tcpcopy，复制线上流量，但是目前没有现成的tcpcopy环境

为了克服这些阻碍，就写一个简单的工具，先是读取nginx access log， 提取请求uri，然后模拟1000个客户端发送给Web后台。

这个工具经过再完善和变得更通用之后，bullbench诞生了。

什么时候用呢？ 以及软件的局限有哪些。（when）

使用场景：

  • 压力测试时
  • 追踪bug，复现线上问题

局限：

  • 如果没有请求日志，无法使用bullbench进行压力测试
  • 只能模拟发送HTTP GET请求
  • 不能够处理 HTTP 3XX 重定向服务
  • 其他

作者联系方式 (who)：

如何编译？ （how ）

进入源代码目录，执行make

如何使用？

执行 ./bin/bullbench -h 有详细说明和使用实例

    BoolBench 1.0

    -f <filename> 包含请求的文件，可以是nginx access log，也可以是自定义的数据文件
    -t <num>      请求文件的类型, 1 是 nginx access log, 0 其他 其他, 默认是 1
    -u <url>      请求的url前缀, 不支持 https, 比如 http://www.bullsoft.org
    -H <host>     HTTP请求头字段Host, 默认是 NULL
    -c <num>      并发请求的线程数, 默认是 1000
    -r <regex>    正则表达式,用于提取请求文件中特定的内容. 必须和参数'-t 0' 搭配。
    -o <string>   正则变量拼接后的字符串, 支持 $0-$9
    -h            显示帮助信息
实例1:  ./bullbench -f /var/log/nginx/access.log -u http://127.0.0.1:8080
实例2:  ./bullbench -f /var/log/nginx/access.log -u http://127.0.0.1:8080 -H www.bullsoft.org
实例3:  ./bullbench -f /var/log/nginx/access.log -u http://127.0.0.1:8080 -t 0 -r "[a-z]*([0-9]+)([a-z]*)" -o "/display?a=\$1&b=\$2"

一些参数（how much？ how many？）

并发线程数设置多少，依据系统情况而定。

  • 在并发线程数过高的情况下，会打开非常多的连接，常会遇到打开文件数过多的错误
  • 使用root通过ulimit设置 open files的限制，使之变大

工程师手记-将Memcached内存管理机制移植至Redis

发表于由
3

Idea 的提出

  • Redis 有其高效的异步网络框架
  • Memcached 有其高效的内存管理机制

将这两者结合在一起后，会如何呢？开始试验将Memcached内存管理机制移植至Redis。

本篇博客的姊妹篇链接： 《工程师手记-将Redis异步网络框架移植至Memcached》

调研和选型

Redis内存管理的几个缺点：

  • 使用tcmalloc 或者 jmalloc 库，这两个库封装较重，内部特性也较多。
  • tcmalloc 适合小空间分配，稍大的空间分配会有瓶颈。
  • Redis 主要是单线程运行（只在后台任务cache持久化功能处又启动了新线程）， tcmalloc 和 jmalloc 有保证线程安全，但对redis来说是不必要的功能。尤其是jmalloc，为线程安全做了很重的设计。

软件选型

  • 并不是把 Memcached 的内存管理直接替换redis的内存分配，而是使用ae-memcached的内存分配方式。
  • ae-memcached 的内存分配和 Memcached在原理上毫无不同，仅是从软件架构上对其进行重构和优化。具体参考:《AE-Memcached 优化记录》
  • 选择 Redis 2.8.24 作为移植受体

Redis代码修改和编译 / 移植方案

  • 从ae-memcached中拿出mem_cache / slab 两个类，直接移植到Redis src 目录中
  • 新建两个文件 mc_malloc.h mc_malloc.c，封装mem_cache，让其提供类似 malloc、 alloc、realloc、free的接口
  • 修改 zmalloc.c zmalloc.h 这两个文件，让其支持mc_malloc
  • 修改 Makefile ，默认MALLOC 使用 mc_malloc
  • 修改bio.c 文件，把zmalloc 和 zfree用 libc的 malloc 和 free 代替，这么做主要考虑到线程安全
  • 编译、运行

代码托管地址

给新的redis起了一个新名字mc-redis，源代码托管于Github上：

https://github.com/zuocheng-liu/mc-redis

性能测试实验

硬件

  • Redis-server 服务端 GenuineIntel 6 Common KVM processor 6 核 2.0GHZ 4G 内存
  • redis-benchmark 和服务端部署在同一台服务器上

测试方法

  • 分别运行原本Redis 和 mc-redis, 分别作为实验和对照，参数为 redis-server –port 7777
  • 启动Redis，运行redis-benchmark 测试三次。重复前面步骤，Redis共重启3次，redis-benchmark共测试9次。
  • mc-redis 的测试也使用上面方法
  • 测试命令 ./redis-benchmark -h 127.0.0.1 -p 7778 -q -d 100
  • 只观察set / get 命令的并发度

测试结果

启动一次redis，做了三组实验，数据如下：

  • mc-redis GET 62972.29 / 58275.06 / 55897.15 (requests per second)
  • redis GET 47281.32 / 62034.74 / 51759.83 (requests per second)
  • mc-redis SET 64808.82 / 59031.88 / 56915.20 (requests per second)
  • redis SET 51733.06 / 53676.86 / 56947.61 (requests per second)

结论

在刚启动时（预热阶段），mc-redis 的 set 和 get 操作，比原版redis 的并发处理能力高大约有 15%-20%。 但是稳定运行后， mc-redis 和 原版redis，性能相差较小。

AE-Memcached 优化记录

发表于由
1

优化背景和目的

  • 学习Memcached 代码
  • 将 Memcached 的代码成为自己的技术积累
  • 优化Memcache 代码，提高自己系统分析能力

源代码托管于Github上：

https://github.com/zuocheng-liu/ae-memcached

性能优化

网络模型的优化

  • 网络IO多路复用 + 单线程

  • 将 Redis 异步库 移植至 Memcached

优化动态申请内存机制

  • 使用预分配，减小系统调用 malloc、realloc、free的次数，主要出现在新建/关闭链接时，会有较多的系统调用

部分小的函数使用宏代替

优化Memcache协议命令的解析

  • 调整各个命令的解析顺序，把get 和 set 命令放到最前面

软件架构优化

软件架构优化，保证关键代码性能不变

使用宏加强代码复用

  • 重构verbose日志
  • 重构网络库
  • 重构slab

命令模式重构 Memcache 协议

  • 创建command_service类，统一管理命令的解析、处理

更深层次的抽象

将 stats 、 settings 、 logger 和全局资源进行抽象

解耦

  • 将各个模块接口化，减少模块间耦合，尤其是 slab item memcached之间的耦合
  • 依赖注入原则，增强各个模块的复用，其中mem_cache模块 settings等可以形成框架。
  • logger
  • command service

工程师手记-将Redis异步网络框架移植至Memcached

发表于由
6

Idea 的提出

  • Redis 有其高效的异步网络框架
  • Memcached 有其高效的内存管理机制

将这两者结合在一起后，会如何呢？

本篇博客的姊妹篇链接： 《工程师手记-将Memcached内存管理机制移植至Redis》

调研和选型

Memcached 的几个缺点：

  • 使用封装较多的 libevent 异步库
  • Memcached 1.2.2 版本后，开始使用多线程，而多线程上下文切换、互斥锁的竞争带来了一定的性能开销
  • 每次新建tcp 连接都进行系统调用（malloc）申请空间

对Memcached 的一项性能测试

实验验证，多线程不会对Memcached带来性能的提高

参考链接：

对Memcached 1.2.2 的一次基准测试实验

软件选型

  • 从 Redis 3.2.0 （截止此文最新稳定版） 版本中选择 libae、 libanet （ae.h、ae.c、anet.h、anet.c 四个文件）
  • 选择 Memcached 1.2.0 作为移植受体

选取这两个版本的主要原因是，作为Redis 和 memcached 的早期版本，特性较少，代码复杂度低，适合进行初步实验移植。

为什么不直接使用epoll呢？ 因为除了异步框架之外，还需要定时器的功能，而redis的异步库中已经有现成的实现。

代码托管地址

给新的memcached起了一个新名字ae-memcached，源代码托管于Github上：

https://github.com/zuocheng-liu/ae-memcached

性能测试实验

硬件

  • Memcached 服务端 GenuineIntel 6 Common KVM processor 6 核 2.0GHZ 4G 内存
  • Memcache 客户端 和服务端相同的另外一台服务器

测试方法

  • 分别运行Memcached 和 ae-memcached， 参数为 memcached -m 1024M -t 6 ， 其中原本memcached运行6个线程，而ae-memcached 是单线程
  • 使用memslap 1.0.2, 测试10W次请求，100的并发度的情况下，memcached的处理时间
  • 测试命令 ./memslap –servers=test-server:11211 –concurrency=100 –execute-number=1000 –tcp-nodelay –non-blocking

测试结果

  • ae-memcached 6.709 / 6.878 / 7.362 / 7.196 (seconds) 平均7秒
  • 原版 memcached 5.079 / 5.043 / 5.069 / 5.206 (seconds) 平均5秒多

结论

原版Memcache 处理10W条数据的时间要比 ae-memcached少很多。多线程的确会给Memcached带来性能的提升.我们前面的假想并不正确。

对 Memcached 的持续优化

本文作者不仅只把Redis的异步库移植至Memcached，还对Memcached进行了持续的优化，详细请阅下面链接：

http://it.zuocheng.net/ae-memcached-optimization-zh

敏捷软件开发 – 总结

发表于由
4

敏捷软件开发简介

  • 一套适应变化，立足于变化的软件开发方法
  • 一套被证明过的目前最有效的软件开发方法

Scrum、 XP 和 敏捷的关系

  • 敏捷是一种指导思想或开发方式（价值观）
  • Scrum和XP是敏捷开发的具体实现方法 （方法论）

敏捷和瀑布

瀑布，主要继承自大工业时代遗留下来的思想，关注流程和契约

敏捷，因互联网兴起一种软件开发思想，应变化而生，关注反馈和沟通

互联网软件开发的特点

  • 需求总是在不断变化

  • 不清楚需求最终是什么，一切需求都来自于未经验证的假设

  • 对软件系统和团队的要求，必须快速适应变化

  • 互联网时代的产品需求来源已经发生变化

  • 传统IT的软件需求来自于客户，软件开发商必须基于合约按期向客户交割软件产品。（契约）

  • 互联网应用软件，以服务提供给用户/客户，需求来源于互联网企业对用户/客户体验或服务自身的挖掘。（变化、不确定性）

互联网开发的问题

  • 什么样规模的团队最能保证效率和安全？

小团队

  • 什么时候才能确定最终的技术方案

编程的时候

软件开发方法的演化过程 （敏捷开发的推导过程）

  • 小作坊式开发

  • 传统瀑布模式（螺旋模式等等一系列模式）

  • 迭代式开发

  • 敏捷开发

Scrum 流程简介

参考维基百科

感性体验

对敏捷的反思

  • A/B 实验

需求是不确定的、易变的，原因之一是因为需求往往来自于假设，对假设的验证可以进行A/B实验。

  • 灰度发布

保证安全，减小风险。

  • 技术驱动

技术驱动能最大的激发团队成员的积极性。

问题

  • 敏捷适合小团队？

并非如此，按照敏捷的思想，团队要保持精简。若原有团队是大团队，则拆分为小团队。

安全的C/C++网络应用的开发流程

发表于由
回复

本文概要

简要介绍C/C++ 网络应用系统的特点、应用场景，简述适用于C/C++ 网络应用的开发流程。

C/C++ 网络应用系统特点

  • 高性能
  • 高吞吐量
  • 节省内存
  • 开发、测试用时多、开发效率慢
  • 调式成本特别高

C/C++ 网络系统的应用场景

  • 数据接口服务
  • 计算密集型应用，比如搜索引擎、图像处理、统计学习等
  • 特殊领域应用，只能由C/C++ 完成

开发流程的目标

由于上面提到的C/C++ 的特点和应用场景，因此开发流程要达到下面的目标：

  • 安全
  • 控制bug
  • 保证收益

开发流程

需求

因为C/C++ 系统的自身特点，在网络应用中，它们常常担当后端系统、基础服务等。在整个产品的系统架构中，C/C++系统和业务系统常常被分离开来。C/C++ 系统不直接响应来自产品的需求，只响应业务系统提出的技术升级或改造。

设计

  • 日志一定全面，Debug、info、warning、error、fetal
  • 使用参数开关来控制新加的特性，对新的特性一定要追加日志
  • 单例测试覆盖率要尽可能高
  • 对输入的安全检查一定要做到位
  • 可扩展性一定要高

编码

  • C/C++ 代码要遵守代码规范和代码标准
  • C/C++ 代码书写尽量遵从ANSI/ISO 标准
  • 不要使用生僻的语法
  • 代码可读性和可维护性一定要高
  • 一定要书写单例测试

测试

  • A/B 测试

测试环境的搭建

必须多套测试环境

  • 普通测试环境
  • 压力测试环境
  • 沙箱环境
  • 线上小流量环境

必须在每一种测试环境都测试完成后，才能发布到生产环境或在生产环境上推全流量

发布

灰度发布

工程师手记-从PHP工程师到C/C++工程师的转变

发表于由
7

本文分享一下，博主从PHP工程师变为C/C++工程师后的一些真实感受。

两句话写在前面

  • 编程语言只是工具
  • 工程师应该用正确的工具干活儿

但从我现在的经历和感受看，两句话真的不靠谱。

简单介绍转变的过程

2012年大学毕业，进入第一家公司，担任PHPer。之后两三年用的编程语言一直是PHP，即使14年中间换过工作，依然写PHP，做的都是公司后台的业务系统。

2015年，语言转为C/C++，负责公司商业广告投放系统检索端的开发。

技术方向的不同

  • PHP 关注业务的实现
  • C/C++ 关注底层

PHP程序员和C/C++程序员日常技术关注点

  • PHP 程序员关注对业务的抽象、关注系统的可扩展性，关注如何设计业务架构，使用什么样的设计模式等等

  • C/C++ 程序员更加关注系统的性能，系统的可伸缩性，关注使用什么样的工具提高性能，关注网络IO模型，数据结构和算法等等。

安全性

  • PHP 程序员关注的安全主要是避免系统漏洞和防止攻击，sql注入、XSS攻击、文件注入攻击等等， 系统安全比较重要。

  • C/C++ 程序员更关注逻辑的安全性， 比如输入输出的边界，异常处理等等，系统稳定最为重要。

PHPer 和 C/C++ 工程师何时相互欣赏?

  • PHPer 看 C/C++, C/C++ 好高级啊，底层实现都知道的那么清楚。我们了解就没有那么深啊。

  • C/C++工程师看PHP， 你们做的那么多应用好高级啊，那么复杂的金融系统，你们怎么就做出来了，如果用C来写，怎么才能写出来呀！

PHPer 和 C/C++ 工程师何时相互鄙视?

  • PHPer 看 C/C++, 你们代码怎么都是面向过程的，可读性那么低，多不好维护，抽象和复用都搞不好，软件架构乱成啥了，软件稍微大些，你们就要拆成服务。

  • C++ 工程师 看 PHP, 你们设计这么多类，代码那么啰嗦，难道不是不过度设计吗？你们写的代码性能能行吗？明明10台服务器就能满足的PV，竟然要200台！

同时有了PHP 和 C/C++ 背景之后，我的工作变成什么样子了？（以下故事基于事实，但与事实略有差异）

  • 老板：“那个项目是PHP的，你来接吧。” 我：“NO”。 老板：“只能你来接啊，我们辛亏有你啊，组里只有你会php啊，您一定要接啊！” 我：“OK。”（幽怨+无奈）

  • 猎头：“我这有PHP职位，薪水丰厚”。 我：“俺转C++了”。 猎头：“C++需求少啊，工作不好找啊”。 我：“俺还要写c++”。 猎头：“看那个PHP职位，背景待遇好”。我：“……”。

  • 某一线公司HR ：“你C++履历太短，暂时还不适合我们的职位。” 我：”……”（心里流出两行泪）。HR：”但我们公司有PHP职位啊，你来呀”。我：“俺不去了……”（秋风吹皱偶滴心）。

博客写完了， 现在感觉，开头那两句话，说的无比正确。

工程师手记-PNI

发表于由
1

PNI 简介

PNI，是PHP Native Interface的简写。它是PHP的一个扩展，可以通过它，让PHP直接调用C语言写的函数。

想法源自在百度做项目时，不时地会面临同样一个问题，PHP该如何直接快速地与其他语言交互呢？

PHP 扩展的不足

用C写PHP的扩展是常规的方法。不过使用这种方法总是要面临诸多问题：

  • 作为开发者，要去学习PHP-API、Zend-API，这是不小的学习成本，而且用C做开发测试的效率都不高。
  • 写好了PHP扩展，怎么部署呢，还要找运维工程师去讨论、去争取后才能上线。

来来回回项目进度就被拖慢了。

有如此技术痛点，就找个通用的法子吧。

调研过程

JNI 和 Python

Java 可以通过JNI调用C/C++，Python也有相应的包，比如ctypes

HHVM

稍微去翻了一下HHVM的扩展，发现HHVM有 native interface, 但稍微看了一下，却发现那只是HHVM的native interface，PHP无法使用。

这个项目，模仿JNI，就取名PNI吧

c 对动态链接库的动态调用

c 加载动态链接库及调用函数有现成的方法。

使用dlfcn.h 库中的dlopen、dlsym、dlclose三个函数就够了。

设计和实现过程

接口设计

最开始的方案，就是模仿JNI。因此在最初的实现里，PNI对动态链接库的查询，调用函数的方法都直接模仿了JNI的接口实现。测试使用时，却感觉PNI的接口非常不友好。

和Java、Python 不同，PHP是弱类型语言。JNI 可以在给函数传递参数时，参数的数据类型是已知的，但是PHP传的都是zval，类型并不可知。我把数据类型的控制交给了开发者，在PNI的扩展里，通过struct zval 中 type 字段判断，此种方案让PNI很难于被使用。

于是改进方案，在PNI里添加PNIInteger、PNIDouble、PNIChar和其他几个可以标明参数数据类型的类。

参数压栈

PHP 的函数调用后，动过dlfcn.h库，可以找到函数地址，但是如何调用函数呢？调用函数又如何传参呢？我们无法知道所调用函数的参数列表是什么样子。

由于没有找到比较好的方案，所以就借助于汇编，使用汇编模式C语言的参数压栈方法。

于是写了很多种C语言的函数，主要是参数列表不一样，总结了GCC编译器在x86_64架构CPU下参数压栈的几个特点：

  • 8、16、32位和64位整形的参数，按顺序传到64位的寄存器，当多于6个整形参数时，剩下的整形参数都压栈

  • 32位和64位浮点，都传到64位的浮点计算器，浮点参数多于6个时，剩下的浮点参数都无效

无论C函数的参数是什么样的类型，PNI都将其按64位的整形或浮点处理。

问题解决了

系统兼容性

因为参数压栈的问题，目前PNI只支持GCC编译器和x86_64架构的CPU。其他架构和编译器都没有来得及去实现。

总结

吭哧吭哧，PNI最初版本调试测试成功。

后记

如何让PNI被更多的人知道并使用，怎么做呢？（还在思考中）

  • 开源，传到GitHub
  • 融入社区
  • 在问答网站上多回答相关问题

其他方法呢？再想一下。

工程师手记-赶集易洗车后台和服务端

发表于由
2

项目简介

赶集上门洗车业务服务器端，分为两部分：

  • 为洗车APP提供服务的接口
  • 洗车业务相关的管理后台

从整个项目上说，虽是个创业项目，但需求针对性强，从洗车仅一点上切入，易于发力。

相比曾经经历一些创业项目中，产品总是摸不住方向，不知何处发力，试错成本太高，做到最后都迷茫该做什么，怎么做。还有些项目，铺开面去搞，结果摊子太大，顾及不暇。

赶集易洗车与之相比要好太多，对我来说，做这个项目感觉很舒服。负责时间：2014-11 至 2015-08

框架代码

主要开发语言是PHP。典型 LNMP 架构。

代码框架是赶集网多年积累下来的老框架，对于老框架，工程师都是能够理解的，不过还是想说一说。

  • 简易实现的路由分发
  • 没有清晰的分层概念
  • 有一套简单的DB访问工具类
  • 对其他架构系统调用封装访问很全面
  • 赶集所有频道都使用一套框架代码

总之，有优有劣。

业务代码

虽然使用了类，但仍然使用了面向过程的思维在开发。代码复用性、可扩展性比较低。由于业务简单代码耦合还不是很严重。

代码没有分层也是问题。

项目发展过程

框架的改进

赶集易洗车框架和其他MVC框架的诟病一样，表现层逻辑直接调用数据访问逻辑，并没有业务逻辑层。于是劈出一个目录，存放业务逻辑层代码。建立规范约束DB层和表现层，老的业务逻辑代码日后慢慢迁出和重构。

面向对象

老逻辑中类的作用只被用于聚合。多态和继承并没有被使用。

对DB层的再次封装

在DB访问类，由于历史原因，用起来特别不友好，也有让新人不易察觉的逻辑陷阱。

对此，我使用了Service Locator Pattern + Proxy Pattern 这两个设计模式，对原DB层再次进行封装，简化上层对DB层的调用，添加缓存的优化。之所以使用这个方案，主要是根据项目当前情况，有如下考虑：

  • 不能抛弃和重构原有的DB访问类， 因此选择再其之上再进行封装。遵循开闭原则，不对老逻辑进行改动
  • 原有DB访问类有逻辑陷阱，因此使用Proxy Pattern，把陷阱的规避放到proxy类中，优化对外的接口
  • 原有DB类，每一个数据表都对应一个DB类，全局只需初始化一次，但会在不同的地方多次调用，所以选用Service Locator Pattern，每个DB类，初始化1次便缓存起来，供之后逻辑重复使用

用了上面的方案后，代码可维护性和可读性都提高了。

展示列表的封装

后台有很多的展示列表页面，主键往往是一样的，比如都是订单的ID，但是其他的列，有的一样，有的不一样。可以看成，不同的列表页面，就是不同的列的组合。

使用Decorator Pattern 对其进行重构。这个设计模式比较简单，但是实在是特别好。在我之后的开发工作中，凡是遇到列表，开发的时间估计就能缩小一半。维护的成本则是更低。

具体业务开发

具体业务的开发，也许是最枯燥的工作，不具有挑战性，只能付出劳力。估计只有在机器人程序猿出现后才会解决这个问题。

关于团队

团队每周有分享，可怜创业项目排期紧张，团队分享没有坚持几期，后来慢慢停掉。原因我认为可以从两个方面看：

  • 随着业务压力的增大，团队给予技术成长上的提升关注也会消弱。
  • 人有惰性，团队往往也是如此。

我在团队分享3次，《地理区域和点关系计算》、《代理和反向代理》、《PNI》 ， 分享积分是团队最高的，本来有一部kiddle做奖品，团队解散后也没去要过来，哈哈。

开始写工程师手记

发表于由
回复

从12年4月大学毕业开始实习，至今工作3年半经验。

回忆这三年半，这些经验都给我带来了什么呢？不容置疑，有很多东西，但是具体有哪些呢？不好好收拾一下脑海，真就不能立刻说出来。

所以昨晚上班路上就想出了写工程手记这么一个idae，有了手记，我就不会对做过的项目有种“彻底忘记”的感觉了。自己做过什么，一看手记立刻就能回忆起来，曾经的经验、走过的陷阱、当时的思考，都可以立刻回到自己的身上。

通过工程手记，还可以记录在做项目过程中的所感和所想，以后也可以拿来回顾和反思，说不定能得到更多的东西。

总之，就是让自己以往的经历，不仅仅只是流逝的时间，只是过往的履历，一定要变成有价值的经验。

手记的内容

  • 项目简介 （what 、 when 、who）
  • 所遇问题 （why）
  • 如何做的呢？ （how）
  • 总结和反思

给自己的手记制定几点原则

  • 原公司保密的东西不以泄露
  • 从客观角度描述问题，尽可能不夹带个人感情倾向
  • 不随意否定项目、团队或个人
  • 内容保持精简，不谈无关话题

写手记的想法是怎么来的呢？

主要是源于两件事吧。

刚玩微博时，关注了易胜华律师，从他发的内容里知道他有写律师手记的习惯。他的手记里，都记录着每次办案的一些重要或关键的细节，也包括他思考的过程。看了后深感佩服，不愧是名律师啊。

在大学时，曾是学校越野队队员，队里规定每次比赛完必须要写比赛总结。总结的目的很明确，就是经过每次的比赛，都能让队员有所提高。

所以我们软件研发工程师为什么不能有手记呢？

单例测试总结

发表于由
回复

最近写了比较多的单测，对测试用例做了一下总结。          

网上也有很多讲如何写单例测试的教程和经验总结，而且都比较系统。但这里还是总结一下自己在写单例测试时总结的经验。

1. 经验总结

1).时间和对象          

只对比较稳定的代码写单测。        
从反面讲，还处于经常修改状态的代码是不稳定的代码，针对其写的单测也必然是不稳定的，随着设计和代码的不断更改，单测也需要不断更改。

2). 去除底层依赖          

对一段代码写单测时，其中提供API、IO和DB数据的类或对象应该mock掉，但对这些类也要单独写单测。        
一方面，这些类对系统环境有很大依赖，当环境出现问题时（比如API的服务、DB宕掉），单例测试将不能进行；另一方面，这些类的效率一般比较低，不mock掉会增加单测运行的时间。

3).写单测的误区        

只为覆盖率而写单测。        

因为单测覆盖率往往成为一个系统质量的考核目标，所以在写单测时，可能只为提高单测覆盖率而写单测，过少地从业务的角度去写单测。单测应该是保证系统在各种业务场景下，系统仍能正常工作的工具。行覆盖率或者分支覆盖率的提高，并不代表不同业务场景的覆盖也会提高。

2. 对以后写单测方式改进

1). 建立自己的测试样本工具，比如可以自动生成的不同角色的用户的工具。这样方便或者更能全面地对系统的业务进行自动化测试。

2). 写单测时更多地站在业务的角度，而不是代码的角度。

产品开发过程中的经验

发表于由
回复

  1. 对于文本的处理，要考虑到文本可能的来源，对于文件中文本，不仅要用trim加工，还要将原有格式去掉。比如从excel专成csv文件，会多出引号。

    1. 对于业务中的一些需求和情况，在系统中的逻辑可有可无，最好的是把逻辑加上。比如银行加密箱号是unique，在数据库中最好将加密箱号设为unique