1.编码习惯
Ugly is easy to identify because the messes always have something in common, but not beauty.
-- C++ 之父 Bjarne Stroustrup
代码质量与其整洁度成正比。
-- 《代码整洁之道》作者 Robert C. Martin
1.1 开发
别人眼中的软件系统犹如灯火辉煌的摩天大厦,维护者眼中的软件系统犹如私搭乱建的城中村,我们要在这座城中村里生存,一直维护这些代码,添加新功能等,要让大家生活得更好,我们写代码不仅追求正确性,还有健壮性 和 可维护性。
图1 开发 理想与现实
要点1 :语义简单明确
这是块存储 SDK 的一段代码,判断限流目标值是否合法;写代码时考虑读者,优先采取易于读者理解的写法。
bool throttle_is_quota_valid(int64_t value) { // 复杂的判断条件 // 请你在三秒内说出 value 如何取值是合法的? if (value < 0 && value != THROTL_UNSET && value != THROTL_NO_LIMIT) { return false; } return true; } bool throttle_is_quota_valid(int64_t value) { // 这是修改后的代码,value 取值合法有三种情况,一目了然 return value >= 0 || value == THROTL_UNSET || value == THROTL_NO_LIMIT; }
要点2 :简洁 ≠ 代码短
这是块存储的一段代码,它遍历回收站中的所有文件,统计每种介质上文件最早的时间戳;简洁≠代码短,复杂的问号表达式反而不如 if..else 方便理解。
void RecycleBin::Load(BindCallbackR1<Status>* done) { ...... FOREACH(iter, fileStats) { RecycleFile item; Status status = ParseDeletedFileName(iter->path, &item.timestamp); if (!status.IsOk() { ...... } item.fileName = iter->path; item.size = iter->size; item.physicalSize = iter->refCount > 1 ? 0 : iter->physicalSize; ...... // 这是修改前的代码 // earliestTimestamp[item.medium] = // item.timestamp != 0 && item.timestamp < earliestTimestamp[item.medium] ? // item.timestamp : earliestTimestamp[item.medium]; // } // 这是修改后的代码 if (item.timestamp != 0 && item.timestamp < earliestTimestamp[item.medium]) { earliestTimestamp[item.medium] = item.timestamp; } } ...... }
要点3 :提前返错
提前返错能减少主体逻辑的缩进数量,让主体代码逻辑显得更醒目。
Bad Case如下:
Status Foo() { Status status = Check1(); if (!status.IsOk()) { return status; } else { status = Check2(); if (!status.IsOk()) { return status; } else { status = Check3(); if (!status.IsOk()) { return status; } else { DoSomeRealWork(); return OK; // 四层潜套 if } } } }
Good Case如下:
Status Foo() { Status status = Check1(); if (!status.IsOk()) { return status; } status = Check2(); if (!status.IsOk()) { return status; } status = Check3(); if (!status.IsOk()) { return status; } DoSomeRealWork(); return OK; }
要点4 :利用析构函数做清理工作
利用 C++ 析构函数做清理工作,在复杂冗长代码中不会漏掉。典型的清理工作有执行回调、关闭文件、释放内存等。
Bad Case如下:
void Foo(RpcController* ctrl, const FooRequest* request, FooResponse* response, Closure* done) { Status status = Check1(request); if (!status.IsOk()) { response->set_errorcode(status.Code()); // 第一处 done->Run(); return; } status = Check2(request); if (!status.IsOk()) { response->set_errorcode(status.Code()); // 第二处 done->Run(); return; } DoSomeRealWork(...); // 第三处 done->Run(); }
Good Case如下:
void Foo(RpcController* ctrl, const FooRequest* request, FooResponse* response, Closure* _done) { // 仅一处,不遗漏 erpc::ScopedCallback done(_done); Status status = Check1(request); if (!status.IsOk()) { response->set_errorcode(status.Code()); return; } status = Check2(request); if (!status.IsOk()) { response->set_errorcode(status.Code()); return; } DoSomeRealWork(...); }
要点5 :用朴素直观的算法
这是块存储旁路系统的一段代码,它根据垃圾比对数据分片进行排序;在非关键路径上,优先使用朴素直观的算法,此时代码可维护性更重要。
void CompactTask::checkFileUtilizationRewrite() { // 此处采取朴素的排序算法,并未采取更高效的 TopK 算法 std::sort(sealedFilesUsage.begin(), sealedFilesUsage.end(), GarbageCollectionCompare); int64_t sealedFileMaxSize = INT64_FLAG(lsm_CompactionSealedMaxSize); int32_t sealedFileMaxNum = INT32_FLAG(lsm_CompactionSealedMaxFileNum); int64_t targetFileSize = 0; int32_t sourceFileCnt = 0; // 前者简单清淅,并在几十个 File 中选择前几个文件的场景并不算太慢 FOREACH(itr, sealedFilesUsage) { LogicalFileId fileId = itr->fileId; const FileUsage* usage = baseMap->GetFileUsage(fileId); const File* file = fileSet->GetFile(fileId); targetFileSize += usage->blocks * mBlockSize; sourceFileCnt++; if (targetFileSize > sealedFileMaxSize || sourceFileCnt > sealedFileMaxNum) { break; } mRewriteSealedFiles[fileId] = true; } ...... }
要点6 :用轮循代替条件变量
这是块存储IO路径的一段代码,从内存中卸载数据分片时等待在途inflight的 IO 请求返回;在非关键路径上使用简单的轮循代替精巧的条件变量同步,代码简洁且不容易出 bug。
void UserRequestControl::WaitForPendingIOs() { erpc::ExponentialBackoff delayTimeBackOff; delayTimeBackOff.Reset( INT64_FLAG(lsm_UnloadWaitingBackoffBaseUs), INT64_FLAG(lsm_UnloadWaitingBackoffLimitUs), INT64_FLAG(lsm_UnloadWaitingBackoffScaleFactor)); // 轮循等待在途的请求返回 // 请思考如何用条件变量实现精确的同步 while (!mWriteQueue.empty()|| !mReadQueue.empty()) { uint64_t delayTime = delayTimeBackOff.Next(); PGLOG_INFO(sLogger, (__FUNCTION__, "Waiting for inflight requests during segment unload") ("Segment", mSegment->GetName()) ("Write Requests", mWriteQueue.size()) ("ReadRequests", mReadQueue.size()) ("DelayTimeInUs", delayTime)); easy_coroutine_usleep(delayTime); // 退避等待 } }
要点7 :使用 timed_wait 代替 wait
在典型的生产者消费者实现中,使用 timedwait 代替 wait,避免生产者未正确设置条件变量造成消费者卡死无法服务的窘境。
pthread_mutex_t mutex; pthread_cond_t nonEmptyCondition; std::list<Task*> queue; void ConsumerLoop() { pthread_mutex_lock(&mutex); while (true) { while (queue.empty()) { struct timespec ts; ts.tv_sec = 1; ts.tv_nsec = 0; // 使用timewait pthread_cond_timedwait(&nonEmptyCondition, &mutex, timespec); } Task* firstTask = queue.front(); queue.pop_front(); consume(firstTask); } pthread_mutex_unlock(&mutex); }
要点8:用协程代替异步回调
这是块存储 BlockServer 加载数据分片的代码;用异步回调方式难以实现这样的复杂控制逻辑,用协程却能轻松实现。
// load.cpp Status LoadTask::Execute() { Status status; if (!status.IsOk()) { ... } // 串行执行下列步骤 RUN_STEP(doPrepareDirs); ...... // 十几步 RUN_STEP(doTask); ...... } // files.cpp Status FileMap::SealFilesForLiveDevice() { Status status = OK; std::vector<SyncClosureR1<Status>*> sealDones; STLDeleteElementsGuard<std::vector<SyncClosureR1<Status>*> > donesDeleter(&sealDones); // 并行 seal 每个文件 FOREACH(iter, mActiveFiles) { File* file = iter->second; sealDones.push_back(new SyncClosureR1<Status>()); Closure* work = stone::NewClosure( this, &FileMap::doSealFileForLiveDevice, file, static_cast<BindCallbackR1<Status>*>(sealDones.back())); InvokeCoroutineInCurrentThread(work); } // 收集结果 FOREACH(done, sealDones) { (*done)->Wait(); if (!(*done)->GetResult0().IsOk()) { status = (*done)->GetResult0(); } } return status; }
要点9 :在关键对象增加 magic 字段
这是块存储核心主路径的一段代码;在关键数据结构中增加 magic 字段和断言检查,能及时发现内存错误(例:内存踩坏)。
通常在下列两类结构增加 magic :
1)关键的数据结构,如 数据分片 结构 ;
2)异步操作的上下文结构,如用户IO Buffer请求;
// stream.h class Stream { public: Stream(); ~Stream(); void Read(ReadArgs* args); ...... private: // 增加 magic 字段 // 通常使用 uint32 或 uint64 uint64_t mObjectMagic; ...... }; // stream.cpp // 定义 magic 常量 // 常量值选择 hexdump 时能识别的字符串,以便在 gdb 查看 coredump 时快速识别 // 此处使用 “STREAM” 的 ASCII 串 static uint64_t STREAM_OBJECT_MAGIC = 0x4e4d474553564544LL; Stream::Stream() : mObjectMagic(STREAM_OBJECT_MAGIC) // 在构造函数中赋值 { ...... } Stream::~Stream() { // 在析构函数中检查并破坏 magic 字段,预防 double-free 错误 easy_assert(mObjectMagic == STREAM_OBJECT_MAGIC); mObjectMagic = FREED_OBJECT_MAGIC; ...... } void DeviceSegment::Read(ReadArgs* args) { // 在重要的函数中检查 magic 字段,预防 use-after-free 错误 easy_assert(mObjectMagic == DEVICE_SEGMENT_OBJECT_MAGIC); ...... }
要点10 :SanityCheck() 合法性检查
这是块存储核心模块的一段代码 StreamWriter 负责管理正在写入的Stream,它为每个写请求选择合适的 Stream 写入,并处理文件满、写失败等异常情形;曾在线下测试发现由于未添加合法性检查,导致内存踩坏的meta错误数据持久化到磁盘中,在数据分片发生迁移时,从磁盘加载错误的meta数据持续夯死,不可恢复。在重要操作前后及定时器中检查数据结构中的重要的不变式假设,这样尽早发现代码 bug 在重要的操作前后或是在定时器中执行检查。
class StreamWriter { public: ...... private: struct StreamGroup { WriteAttemptList failureQueue; WriteAttemptList inflightQueue; WriteAttemptList pendingQueue; uint64_t commitSeq; uint64_t lastSeq; }; uint32_t mStreamGroupCount; StreamGroup mStreamGroups[STREAM_GROUP_COUNT]; ...... }; void StreamWriter::sanityCheck() { // expensive checks for (uint32_t i = 0; i < mStreamGroupCount; i++) { // Check that sequence in "failureQueue", "inflightQueue" and "pendingQueue" are ordered. const StreamGroup* group = &mStreamGroups[i]; uint64_t prevSeq = group->commitSeq; const WriteAttemptList* queues[] = { &group->failureQueue, &group->inflightQueue, &group->pendingQueue }; for (size_t k = 0; k < easy_count_of(queues); k++) { FOREACH(iter, *queues[k]) { const WriteRequest* write = iter->write; PANGU_ASSERT(prevSeq <= write->seq); // SanityCheck prevSeq = write->seq + write->lbaRange.rangeSize; } } ASSERT(prevSeq == group->lastSeq); // SanityCheck } ...... // NDEBUG }
要点11 :用告警代替进程崩溃
这是块存储核心路径的一段代码,在加载数据分片时通过交叉校验对数据正确性进行合法性检查,遇到严重错误时发起电话告警,以此代替 assert,避免生产集群大规模故障时,数据分片持续调度造成整个集群进程Crash的 级联故障 。
在多租户系统中,单租户出现严重问题不应影响其他租户的服务。
在块存储,我们仅允许检查对象 magic 和线程是否正确的断言。其它断言由告警代替。
Status LoadTask::doTailScanFiles() { ...... for (id = FIRST_REAL_FILE_ID; id < mFileSet->GetTotalFileCount(); id++) { File* file = mDiskFileSet->GetFile(id); if (file->GetLogicalLength() < logicalLengthInIndex) { const char* msg = “BUG!! Found a data on disk with shorter length ” “than in map. This is probably caused by length reduction of ” “that file.”; // 记录详细的日志,包括文件名、期望长度、实际长度等 PGLOG_FATAL(sLogger, (__FUNCTION__, msg) (“Stream”, mStream->GetName()) (“File”, file->GetFileName()) (“FileId”, file->GetFileId()) (“FileLengthOnDisk”, file->GetFileLength()) (“FileLengthInIndex”, physicalLengthInIndex) (“LogicalLengthOnDisk”, file->GetLogicalLength()) (“LogicalLengthInIndex”, logicalLengthInIndex) (“MissingSize”, physicalLengthInIndex - file->GetFileLength())); SERVICE_ADD_COUNTER(“LSM:CriticalIssueCount”, 1); // 触发电话告警 return LSM_FILE_CORRUPTED; } } }
要点12 :时间溢出之一
我们当前使用的内核配置 HZ=1000,jiffies 变量每49天溢出,Linux 将 jiffies 变量初始值设置为负数,使系统启动后5分钟发生第一次溢出;让这段容易出错的危险代码每天都被执行到,这些再也不用担心出现黑天鹅事件了。
linux/include/linux/jiffies.h /** Have the 32 bit jiffies value wrap 5 minutes after boot * so jiffies wrap bugs show up earlier. */ /* * These inlines deal with timer wrapping correctly You are* strongly encouraged to use them * 1. Because people otherwise forget * 2. Because if the timer wrap changes in future you won't have to * alter your driver code. * * time_after(a,b) returns true if the time a is after time b. */
要点13 :时间溢出之二
习惯上代码中以微秒表示时间, int32 能表示的最大时间仅为 2147 秒,约 35 分钟,容易溢出;历史上块存储值班同学在处理另一个 P4 故障时,为缓解分布式集群中心管控节点压力,临时调整 flag 增加调用中心管控节点 RPC 的调用间隔。新的 flag 在运行时产生 int32 整型溢出,进程崩溃,引起整个集群级联故障,服务中断造成 P1 生产故障 ;血琳琳的教训:总是用 int64/uint64 表示时间。
要点14 :避免有歧义的函数名和参数表
这是 libeasy 的一段代码,这是基于时间轮实现的定时器,用来代替 libev timer;函数名和参数表要符合直觉,大多数使用者没空读你的注释,小部分使用者读了你的注释也看不明白。
// easy/src/io/easy_timer.h // ---------------------------------------------------------------------------------- // following interface, use easy_timer_sched from th(io thread or worker thread), // ** DON NOT support async call ** // int easy_timer_start_on_th(easy_baseth_t *th, easy_timer_t *timer); int easy_timer_stop_on_th(easy_baseth_t *th, easy_timer_t *timer);
1.2 测试
测试代码其实是产品代码的“用户”,写测试代码前考虑如何“使用”产品; 好的测试是 what,包含 given when then; 差的测试是 how,每次方法更改时都必须完全重写测试,或许需要重新考虑系统本身的体系结构。
图2 测试原则、可测性
要点1 :边界测试
以下是块存储两个历史生产Bug;关注上下限,边界条件最易出错。
TEST_F(..., SharedDisk_StopOneBs)(...) { BenchMarkStart(mOption); // for循环反复注入 mCluster->StopServer(0); mCluster->StartServer(0); // 修复前无第12行无代码,无下限检查,全部失败时Case PASS // 共享盘开盘后线程死锁必IO Hang,有测试无断言遗漏Bug导致P1故障 EXPECT_GT(mIoBench->GetLastPrintIops(), 0); EXPECT_GT(mIoBench->GetMaxLatency(), 0); // 断言检查,边界上限 EXPECT_GT(20 * 1000000, mIoBench->GetMaxLatency()); // Do something below } Status PRConfig::Register )(...) { assertIoThread(); // 修复前缺少=,导致Sever Crash if (unlikely(mRegistrants.size() >= MAX_REGISTRANT_NUM)) { LOG_ERROR(...); return SC_RESERVATION_CONFLICT; } // Do something below }
要点2 :状态/分支测试
以下是块存储两个历史生产Bug;状态流程图,影响数据正确性和服务可用性的关键路径、异常分支、状态组合需测试覆盖。
void WalStreamWriterPool::tryCreateWalWriter() { AssertCoroutine(); ASSERT_DEBUG(mIsCreating); Status status = OK; while (...) { WalStreamWriter *writer = mWalManager->CreateWalWriter(); status = writer->Open(); // 修复前无第14行代码部分,未处理Commit,失败导致丢掉WAL文件,进而丢数据 if (status.IsOk()) { status = mWalManager->Commit(); } // Do something below } void RPCController::StartCancel() { if (_session) { if (_pendingRpc != NULL) { // 修复前无第29行代码,线程Hang进而IOHang // 未测试覆盖call StartCancel before handshake _session->need_cancel = true; } else { easy_session_cancel(_session); } } else { easy_error_log(...); } }
要点3 :重复/幂等性测试
以下是块存储两个历史生产Bug;第一个如下图所示,未释放内存,长时间运行造成内存泄漏;第二个是19年遇到的一个问题,BM 在 处理 open device 时没处理好幂等问题,导致磁盘 open 成功后仍然 I/O hang ;有一些问题只有经过长时间的重复测试才能发现,关注代码中每一次重试,敏感接口的 API 幂等性需测试覆盖。
Status CompressOffsetTable::Seal() { // Do something before status = mTableFile->Seal(); if (!status.IsOk()) { PGLOG_ERROR(...); return status; } mIsSealed = true; // 修复前无第14行代码,文件写入已完成,清空缓存,释放内存 mEasyPool.reset(); // Do something below }
要点4 :兼容性测试
兼容性包含:协议兼容性、API兼容性、版本升级兼容性、数据格式兼容性;对于所有依赖的兼容性假设需通过测试自动化覆盖,兼容性问题是很难测试覆盖并且问题高发的部分,兼容性问题应该在设计阶段、编码阶段提前预防,避免兼容性问题,而非寄希望于兼容性测试来兜底。
void ActiveManager::SubmitIO( { // 【版本兼容性】 SDK 和 Server线程不对齐,旧版本SDK不支持切线程 if (UNLIKELY(GetCurrentThread() != serverThread)) PGLOG_WARNING(... "Server thread mismatch"); response->ErrorCode = SERVER_BUSY; done->Run(); } void ChunkListAccessor::SetChunkInfoAndLocations() { uint8_t flags = mFileNodePtr->fileFlags; bool isLogFile = IsFlatLogFile(flags); ASSERT( //【协议兼容性】Master 和 SDK异常场景定长误判 (isLogFile && vecChunkInfoNode[0].version <= masterChunkInfo.version) || !isLogFile); // Do something below } // 【API兼容性】 Server 和 Master的错误码不一致,数据分片反复加载/卸载 // Master侧,device_load.cpp // if(status.Code() == LSM_SEGMENT_EXIST_OTHER_VERSION)) // Server侧,device_load.cpp // return LSM_NOT_OWN_SEGMENT;
要点5 :防御性测试
系统服务上限的边界是多少?客户端无退避重试、突发大流量等造成的故障数不胜数,关注系统在最差情况下的表现,明确系统的能力边界,对系统服务边界的数学模型进行理论分析和实验验证,通过极限压测验证系统最大可服务能力符合设计预期,推荐参考 接近不可接受的负载边界。
要点6 :避免写出不稳定Case
Case不稳定真是一个让人头大问题,总结了一些不稳定的测试常见原因,希望大家记住并知行合一。
- 测试不聚焦,无脑复制粘贴,等价类测试爆炸
- 异步等待,基于时间假设,sleep 并发,未能在预期的窗口期交互
- 有顺序依赖的测试,共享某个状态
- 资源溢出,数据库链接满、内存 OOM 析构随机 core
- 析构未严格保序或者未构造
- 多线程共享资源的错误用法导致概率 crash
- 有未处理完的任务就退出
TEST_F(FastPathSmokeTestFixture, Resize) { // ... Do something ResizeVolume(uri, DEVICE_SIZE * 2); Status status = OK; do { // 状态依赖,未检查resize 是否成功,导致错误的认为是越界io处理 status = Write(handle, wbuf.get(), 0, 4096); if (status.Code() == OK) { break; } easy_coroutine_usleep(100*1000); } while(1); // ... Do something } // volume_iov_split_test.cpp TEST(VolumeIovSplitTest, Iovsplit_Random) { // ... Do something size_t totalLength = 0; // 修改前无+1,0是非法随机值,造成Case低概率失败 totalLength = rand() % (10*1024*1024) + 1 // ... Do something }
2.本地工具
2.1 Docker单机集群
对于分布式系统,能够在开发机上自测端到端的跨模块/跨集群的功能测试,极大的提高测试效率和开发幸福感。在开发调试期间,Docker集群用完即抛,拥有属于自己的无污染的“一手”功能测试集群,代码主路径必现的进程Crash均可在开发阶段发现。Docker使用极少的系统资源,有效地将不同容器互相隔离,快速创建分布式应用程序,非常适合集群测试使用。
块存储在没有 Docker 单机集群之前,测试集群级功能测试至少需要12台物理机,我们通过将块存储、盘古和女娲的服务装进容器中,实现单机 OneBox,在开发机上(物理机 /虚拟机/Docker/Mac 均可,无OS依赖),一键秒级部署和销毁一个集群,基于Docker单机集群实现Docker Funtion Test,沿用单元测试的 gtest,上手门槛低,极大的提高了测试效率和开发幸福感,Docker Funtion Test 是在代码门禁中运行,即代码提交入库之前自动触发测试,在代码入库之前,百分之百拦截必现的进程Crash问题。
图3 块存储 Docker单机集群
2.2 本地出包自助E2E
研发效能低下的团队的一个典型表现,质量强依赖全链路端到端(End-To-End,简称E2E),测试环境维护成本极高,常常因为环境污染导致无效测试,是否能够将全链路E2E测试实现白屏化,告别环境修复?
在开发期间调试,不可避免有大Size的Patch修改,代码门禁Unit Test / Smoke Test / Funition Test仅覆盖功能测试,涉及到IO性能、运维、用户态文件系统、用户态网络协议的代码逻辑修改,无法在代码门禁覆盖。面对这个问题,块存储开发者可以在开发机编译出包,测试平台白屏自助验证E2E测试,操作共3个步骤:编译上传包 → 提交测试任务 → 查看测试结果。降低测试门槛可以有效的提高测试的主观能动性,进而提高测试运行频次,当测试不再是负担的时候,大家更愿意做测试,谁会拒绝投资少收益高的事呢?
图4 测试平台自助E2E
3.单元测试
3.1 编写测试样例
对于块存储主仓库,增量代码覆盖率当前强制卡点85%,生产代码与测试代码需要同步原子提交,否则将因覆盖率不足阻塞提交,这也倒逼了大家养成测试左移的工作习惯,编写 Unit Test / Smoke Test / Funition Test 是块存储每位开发者提交代码的必备技能,团队同学柏亿曾讲过一句话,“如果我写了代码而没有加自动化Case,就相当于我做了一件华丽的衣服,又丢到了垃圾桶里,弃如敝履 ”,通过自动化门禁测试来保证系统设计、代码实现不被后续修改Break,降低系统质量风险,依赖假设足以保证,更多Good/Bad Case参考《Software Engineering at Google》的 “单元测试”章节。
图5 EBS UT/ST/FT
3.2 代码门禁说明
代码门禁(简称CI)即代码提交之前自动运行的测试,测试全量通过后方可提交,类似于函数计算,Test as a Service。代码门禁是 测试左移 的必备单品。块存储 CI 门禁基于Google 开源云原生CI框架Tekton实现,支持分布式编译和分布式测试,Kubernetes 门禁集群中的Cpu、Mem、Disk资源限制Limit,每个Case独占容器, 仅Cpu超卖,相当于模拟主频降频,增加了发现bug的概率,曾多次触发大量低概率时序bug;代码门禁包含编译构建、单元测试、冒烟测试、功能测试、代码风格检查、静态代码扫描、增量代码覆盖率卡点等检查项。在推广测试左移的近三年,块存储门禁Case数量逐年翻倍。
图6 块存储代码门禁
4.Code Review
预防胜于治疗,研究表明高效的 Code Review 可以发现70-90%的 bug,Review 作用如下:
- 提高团队代码标准,所有人共享同一套标准,阻止破窗效应
- 推动团队合作 reviewer 和 submitter 可能有不同的视角,主观的观点经常发生碰撞,促进相互学习
- 激励提交者,因为知道代码需要别人 review,所以提交者会倾向提升自己的代码质量。大部分程序员会因为同事对其代码显示出的专业性而感到自豪。
- 分享知识 submitter 可能使用了一种新技术或者算法,使 reviewer 受益。reviewer 也可能掌握某些知识,帮助改进这次提交。
图7 Code Review 可以发现70-90%的 bug
对于Submitter和Reviewer的共同建议,开放的心态,良好的互动,Submitter给到 reviewer 更多的输入后,有益于问题的挖掘。
图8 一个Review互动的优秀案例
4.1 For Submitter
要点1 :For Submitter - 一次提交不要超过400行代码
研究表明 :在一次 CR 中,Reviewer 应一次至多处理200至400行代码(lines of code)。若超过400行,人的大脑无法有效的处理,发现缺陷的能力将下降。 在实践中,使用60-90分钟来 review 一个200-400行的 patch,应该能发现70-90%的缺陷。即如果这个 patch 里面存在10个 bug,那么在 CR 阶段应该能发现7至9个。
图9 缺陷密度 vs 代码行数
要点2 :For Submitter - 做自己的第一个 reviewer
自己的狗粮自己先吃,自我Review有以下几个注意事项:
- 端正心态,reviewer 是帮你发现问题的人,而不是阻塞你提交的人
- 认真对待 description,降低Reviewer的理解成本
- 一次提交只解决一个问题,降低review的复杂度
- 如果需要做重大修改,写找 reviewer 对齐大致的修改范围,再开始写代码,避免越行越远
图10 Code Review一个Description的优秀案例
4.1 For Reviewer
研究表明 :当 Reviewer 以超过500行/小时的速度 review 代码时,缺陷的发现率会有显著的下降。建议 Reviewer 控制好自己的速度,保障好 review 质量。 建议一次 review 的时间不要超过一小时,当任务多时建议提高 review 的频率,避免持续过长时间。
图11 缺陷密度 vs 检查速度
要点2 :For Reviewer - Review 的重心
我们不可避免的需要 review 一些较大的 patch, Review的顺序:接口 > 测试 > 实现 ,reviewer 可以假设自己是该代码的使用方,该接口的定义及行为是否符合自己的预期? 如果没有时间,至少也应该看一遍接口定义, 测试代码的质量与实现的质量同等重要,不可敷衍 ,理解提交者想通过测试测哪些东西比理解测试代码的含义更重要。
要点3 :For Reviewer - Tips
- reviewer 应该尽量合理的安排自己的时间,不让自己成为 blocker,推荐每天在开始自己的工作前先 review 别人提交的代码。
- 给建议,更要给原因,帮助提交者进步
- 如果看到写得好的代码,不要吝啬赞赏的语句,提交者真的会很受鼓舞
- 对于看不明白的地方一定要提出问题,而不是轻易放过
- 不要花过多力气去理解难以理解的代码,如果一眼看不明白,第二眼还看不明白,说明这块代码需要改,很大可能过一段时间提交者也会看不明白
- 如果 patch 太大,应建议提交者分拆
- 慎重审查 .h 以及协议的修改
- 没有测试覆盖的代码没必要去看
5.分支管理
5.1 主干开发
南门:主干开发(trunk based development)是持续集成(continuous integration)的最高阶段
在开发模式上,块存储学习了微软、Google的大库主干开发方式,过去多分支开发初期并行迭代,开发周期宽松,但多分支开发很容易漏提交,块存储也曾因漏提交bugfix导致一起P1S1故障,多分支合并冲突多、迭代慢,需要长期占用多套测试环境,有限的测试资源回归频次相对少。块存储所有持续集成测试资源均集中在主干分支回归,“集中力量办大事”。
主干开发对开发者提出了很高的要求,不仅要具备有功能特性拆分的能力,而且需要确保每一次代码提交,都能够达到准上线的质量标准,这也倒闭了测试左移的编码习惯,在提交代码入库之前进行测试编码。
图12 块存储 主干开发
5.2 主干/分支发布
发布模式分两种,公有云是主干分支发布,专有云是LTS(Long Time Support)拉Release分支发布(专有云发布节奏需follow客户要求,公有云发布节奏自主可控)。主干发布,既不是目的,也不是手段。主干发布是结果,是测试能力不断提升后水到渠成的结果,块存储持续集成交付详见第八章。切勿为了主干发布而主干发布,严格控制发布变量和发布节奏,避免为了修复一个bug,引入了另一个更严重的bug,只有经过成熟的测试验证方可进行发布,欲速则不达,敬畏生产。
6.测试 & 环境
6.1 测试脚手架
除了代码门禁的功能Case覆盖之外,Feature Owner需要补充代码后置全链路测试E2E和BVT Case,大版本发布需要经过大规模故障演练的验证方可发布上线,UT/ST/FT每月回归三千多轮,对于信用分低的Case(即不稳定Case)运行轮数权重翻五倍,即每月运行上万轮,通过高频测试尽量多暴露各层面的不稳定因素,倒逼人肉环节的自动化。块存储按照不同的场景提供了多种测试脚手架进行测分级,越轻量的测试回归轮数越多,更多详细说明如下图所示。
图13 块存储 测试分级
6.2 环境标准化
对于测试环境的标准化,采用两个思路:云原生用完即抛、资源池化集中管理。
云原生隔离用完即抛 ,分三种:Docker FT、门禁、K8S E2E。Docker FT在 2.1 章节有详细介绍;门禁Kubernetes集群对开发者无感知,在3.2章节有详细介绍;K8S E2E集群 在6.1章节的表格中有使用说明介绍,不同于Docker FT,支持用户态网络协议,支持运维和监控平台等,3台物理机即可模拟12~24台虚拟集群,如集群环境污染,可半小时销毁重建,而非人肉修环境。
测试资源在测试平台集中管理,分两种:白屏测试只读环境、黑屏测试读写环境,尽量提升资源池化比例。第一种,白屏测试包含三部分:代码门禁CI集群、CD E2E每日回归环境、长时间稳定性预发环境;环境隔离只读,从而杜绝破坏宿主机、修改配置、残留进程等污染环境行为。第二种,黑屏测试即读写环境,用于开发测试联调,采用集群健康度检查工具提前发现环境污染,覆盖网络、磁盘、OS等几十个检查项,避免测试过程中反复踩坑带来的无效重复测试,如下图所示。
图14 块存储 集群健康度检查
7.缺陷管理
为什么要进行缺陷管理?由于Bug信息不对称,难追溯,开发和发布时间异步,fullmesh协同交互成本极高,且可靠性很难保证,在《人月神话》书中描述,y=x2, x 组织规模人数, y 沟通协同成本 ,指数增加。5.1小节中描述的P1S1故障发生后,团队进行了hotfix重发,消除生产风险,但由于对Bug影响集群范围疏忽,导致一个月后同样的故障重复发生,造成二次伤害,吸取教训,团队通过开发git-poison,实现bug分布式源码管理,支持追溯、查询和反馈,自动化bug发布卡点、精准召回bug中毒版本,避免bugfix漏发,降低人因失误造成的质量风险。
7.1 git-poison投毒
基于go-git实现 git-poison:简单易用的bug/bugfix追溯工具,git作为分布式版本管理工具友好地支持了多人并发的一致性问题,简单可靠,开发同学只需要记住一件事:任何时候发现有bad bug,要block预发/生产发布的,抓紧投毒!可复制性高,无论是“分支开发、主干发布“,还是”主干开发、分支发布“,均适用;不依赖于人和人之间的沟通协调,人的involve越少,出错的机会越小。
图15 git-poison投毒/解药/银针
7.2 poison发布阻塞
开发机代码仓库是poison的唯一数据生产源,测试平台和发布平台消费poison数据,实现PoisonCommit 发布阻塞机制,测试平台在填写ReleaseNote一键导入Bug/Bugfix,评估本次版本发布的质量风险,在发布平台通过“集群-模版-Bug-版本”四维度画像实现Bug追溯和查询,精准定位Bug中毒域,召回Bug版本。
图16 “集群-模版-Bug-版本” 四维度生产画像
8.持续交付
8.1 从开发到上线
在代码从开发到上线的整个生命周期存在四阶段系统强制卡点,致力于“从不做错到做不错”。自动化的价值不仅仅是节约时间,更是提高交付质量和交付效率,降低交付成本(例:工作状态上下文切换、 完成一项任务的认知负荷、重复工作量),块存储从开发到上线 Code Velocity 即 Commit-to-Prod time of = 30~45 days (pipeline) 。
质量防控的思路和疫情防控的思路很像,首先在在源头处,通过代码门禁及时发现,就像是疫情的入境检查;持续集成,每日主干回归,缩短反馈弧,就像是现在 “每3天一核酸,全员检测”,一有问题,马上定位修复。
图17 块存储 从开发到上线
8.2 分模块发布
代码库存越是积攒,就越得不到生产校验,积压越多,代码间交叉感染的概率越大,下个Release的复杂度和风险越高,流水不腐,户枢不蠹。那么,如何提高Code Velocity? 除了持续集成建设外,发布阶段也需要解除强绑定,学习微服务化的思路,实现分模块发布,通过将发布模版以模块粒度拆分,各自模块仅拥有自己模块的权限,大幅提升了权限安全管理和发布的灵活性;从发布方面解决了“大锅饭”的问题,真正的将组织层面质量责任落实到了每一个模块的Owner上。
通过微服务化,将单次版本百人协同的成本降低到十人以下,彻底告别“发大车”,各自聚焦,各行其道,互不干扰。
图18 块存储 分模块发布
分模块发布后,由于各模块的发布频次和周期不同,你追我赶,超车频繁,也带来了版本兼容性的挑战,原本设计正交的功能常常出现意想不到的兼容性Bug,块存储在实行分模块发布后屡次踩坑兼容性生产问题,其中包括一次P1故障。面对分模块发布带来的兼容性挑战,一方面,单个服务内,线上版本分裂多,通过收敛治理,全网拉齐;另一方面,多个服务间,笛卡尔积的版本组合多,测试如何覆盖不同服务不同版本的组合,昂贵的测试成本和漫长的测试时间是无法接受的,如前文所述,采用云原生的思路,通过轻量化Docker集群降低测试成本,同时提高测试效率。
图19 分模块发布后兼容性测试
9.文化实践
9.1 效率工具和方法
开发工具:工欲善其事,必先利其器。工具没有好与坏,要看你如何使用,一个高效的工具事半功倍,推荐一些日常工具:
- 开发机: 窗口操作使用Screen、tmux 保持链接不中断、 SSH远端包括iTerm2、Bash、Zsh、Fish、 编辑器包括VSCode、Vim 、调查问题Debug使用gdb、pdb、内存泄漏:tcmalloc、代码扫描静态cppcheck和动态代码扫描asan;
- Linux:Cpu/Mem资源查看使用tsar --mem/cpu/io/net -n 1 -i 1、top等、网络使用lsof、netstat、 磁盘使用iostat、block_dump、inotifywait、df/du、内核日志包括/var/log/messages、sudo dmesg、性能工具strace、perf,IO压测FIO;
- 文档类:语雀的在线UML图/流程图/里程碑方便多人共同编辑等、Teambition的项目管理甘特图、 Aone的需求管理和缺陷管理、 离线工具诸如Xmind思维导图/draw.io 流程图/OneNote。
工作方法:良好的工作方法,可以让自己的成长速度形成复利,推荐阅读两本书《直击本质》和《系统之美》,或许你可以从书中找到不同人成长速率差异的答案,这里推荐三个工作方法:
- SMART原则,我的第一任主管飞山推荐,适用场景:OKR、KPI、绩效自评
- S:Specific,具体的
- M: Measurable,可以衡量的
- A: Attainable,可以达到的
- R: Relevant,具有一定的相关性
- T: Time-bound,有明确的截止期限
- 论文学习方法,推荐先阅读大数据经典系列(例如Google 新/老三驾马车),对于存储领域同学,推荐Fast论文
- Motivation: 解决了一个什么样的问题?为什么要做这个问题?
- Trade-off: 优势和劣势是什么?带来了哪些挑战?
- 适用场景: 没有任何技术是普适的,业务场景,技术场景
- 系统实现: 组成部分和关键实现,核心思想和核心组件,灵魂在哪里?
- 底层原理: 其底层的关键基础技术,基于这个基础还有哪些工作?
- Related Works: 这个问题上还有什么其他的工作?相关系统对比?不同的实现、不同的侧重、不同的思路?
- TDD,Test-diven Development 测试驱动开发,团队石超推荐,“自从看了TDD这本书,我就爱上了写UT”,当时听完这句话驱动了我的好奇心,TDD到底一个什么神奇的方法?后来发现在《软件测试》《Google :Building Secure & Reliable Systems》《重构》 《重构与模式》《敏捷软件开发》《程序员的职业素养》……国外泰斗级程序员大叔的书里,全部都推荐了TDD。TDD不是万能药,主要思维模式是,先想清楚系统的行为表现,再下手编码,测试想清楚了,开发的API/系统表现就清晰了,API/函数/方法语义就明确了。
9.2 个人成长和踩坑
对于校招同学,职场童年最重要的是养成良好的工作习惯,身份从学生到工程师,必然伴随着成长的阵痛感,从学生思维转向职场思维,从学习驱动转向任务交付驱动,运用学校里基础知识,长期锻炼的学习思维,快速达到独立交付状态。不论任务多小,要能独立负责,交付好结果,事事有着落,承担任务,从小到中到大,从简单到复杂,从尝试型到突破型。
在工程实践方面,不再是学生时代的实验课题或者编程比赛,而是从程序到编程系统产品的转变,程序员的工作不止是编程,是把想法变成产品能力的过程。从程序到编程系统,研发成本翻3倍,包括接口设计和集成测试;从程序到编程产品,研发成本翻3倍,包括通用化、测试、文档、维护;而从从程序到编程系统产品,研发成本翻9倍,日常编码时间占比20%~30%,如若你感觉编码时间占比过少,或许是学生思维的惯性,块存储团队践行DevOps,无专职测试岗和运维岗,对于每一位Feature Owner而言,需要独立负责该Feature的 “开发 → 测试→ 发布→巡检” 全生命周期。
图20 来源《人月神话》 编程系统产品的演进
个人成长:以前和与团队同学思潜讨论过身边很牛逼的同事与大家的差距在哪?持续优秀,自我迭代,再牛逼也只是一时的,很牛逼的人能把自己当代码迭代,一个版本一个版本演进,不停loop起来,有针对性、上升式的学习和实践。夯实最基础的底层知识,融会贯通的人都是有底层逻辑的,多阅读经典。分享三条Facebook研发效能负责人推荐的高效工作方法:
- 抽象和分而治之
- 抽象,明确模块之间的依赖关系,确定API接口
- 分而治之,对子系统设计进行合理的注释,帮助代码阅读者对软件结构有更直观的了解
- 代码提交尽量做到原子,即不可分割的特性、修复或者优化,测试代码同生产代码同一个patch提交
- DRY(Don’t Repeat Yourself)
- 寻找重复的逻辑和代码,对重复内容进行抽象和封装
- 寻找流程的重复,使用脚本或者工具自动化,通过自动化提高交付质量和效率,降低交付成本
- 沉淀踩坑经验到自动化工具和平台中,独乐乐不如众乐乐,避免不同人踩相同的坑,降低无效时间开销
- 快速迭代
- Done is better than prefect,不要过度设计
- 尽快让代码运行和快速验证,不断迭代来完善
- 为了能够快速验证,本地测试成本低,缩短反馈弧
- 实现一个可以运行起来的脚手架,再持续添加内容
踩坑心得:在职场初期经常感觉自己的主管是个傻逼,往往时间会证明,自己才是那个傻逼,总结了以下三条过往工作中踩坑建议:
- 忌“太心急”,慢即是快
- 需求澄清:类似TCP三次握手,用自己理解的方式再给对方讲一遍,确认双方理解一致,对焦,避免重复返工
- 自我提问:为什么做这件事?业务价值是什么?关键技术是什么?已有的系统和它对比有什么不同?兄弟团队是否做过类似的工作?是否有经验可供参考?业务/技术的适用场景是什么?预计耗时和进度风险?
- 新人往往脚踏实地,忘记了仰望星空,只顾着埋头苦干,不思考背后的业务价值,这一锄头,那一铁锹,遍地都是坑,就是不开花,费时费力,成就感低。
- 忌低效沟通,用数据说话
- 精确地描述问题,上下文和范围,提供有效信息
- 文档是提高沟通效率的最佳方式之一,Google有文档文化,推荐阅读《Design Docs at Google》
- Bad Case:「测试CX6网卡时,IOPS大幅下降」
- Good Case:「在100g网络标卡CX6验证性能时,8 jobs 32 depth iosize 4K场景下,极限IOPS从120万下降至110万,与FIC卡相比性能存在8%差异」
- 忌“蠢问题”,学会提问
- 鼓励新人多提问,但提问的问题一定要有质量
- 关于如何提出一个好问题推荐阅读《提问的智慧》
- Bad Case:「我在编译耗时很长,我怀疑是资源不够,这种情况怎么办?」
- Good Case:「我的开发机编译耗时2小时,不符合预期,OS是centOS 7U、128GB内存、64Core,编译并发度是20核,未限制内存,编译过程使用Top查看确实20核并发,Cpu和Mem没有达到瓶颈,iostat看磁盘使用率每秒60%」
10.延伸阅读
文章的最后,推荐几本最近阅读过的书,好书读得越多越让人感到无知,“流水不争先,争得是滔滔不绝”,找到适合自己的节奏学习。
- 《编写可读代码的艺术》,豆瓣评分8.7,推荐理由:漂亮的代码长什么样、命名变量避免歧义、写出言简意赅的注释、抽取小函数让测试用例更易读等;
- 《Software Engineer at Google》,豆瓣评分8.7,推荐理由:介绍Google 软件工程文化、流程、工具,github有中文电子版;
- 《人月神话》,豆瓣评分9.2,推荐理由:被誉为软件工程圣经,与《人件》共同被称为双子星,两者是软件行业的神书,而其他书只能被称为经典,自1986年出版至今,每年销售量上万本,值得每隔1~2年反复阅读,初看不知剧中意,再看已是剧中人;
- 《数据密集型应用系统设计》,豆瓣评分9.7,推荐理由:软件开发者的必读书籍,衔接理论与实践,包括数据密集型应用系统所需的若干基本原则、深入探索分布式系统内部机制和运用这些技术、解析一致性/扩展性/容错和复杂度之间的权衡利弊、介绍分布式系统研究的最新进展(数据库)、揭示主流在线服务的基本架构等。
日拱一卒,功不唐捐,共勉。
作者:晴筱、石超、张小路