作者： myCode

量化你团队的代码质量

在疫情背景下各大公司都有所异动，toB 的团队企业内卷也越来越明显。此时此刻如果团队中的产品又出现各种低级问题无疑是雪上加霜。本文围绕团队在产品质量攻坚工作中做的一些质量检查手段，介绍如何让你团队的代码质量可以量化，并保留最珍贵、可维护、可持续、可传承的工程化代码。

Jenkins pipeline macOS agent 报错：cmake: command not found

在一台 macOS 的 anget 中，我们的 pipeline 脚本一直报错：cmake: command not found，但实际系统中已经通过 brew 安装过 cmake。并且在系统中通过使用命令 cmake --version 也能显示正常版本。那是不是 cmake 所在的目录并不在 Jenkins agent 的环境变量中呢？为了验证这个问题我们在 Jenkinsfile 中增加一行打印当前环境变量信息的语句：

使用 Conan、CMake 组织跨平台 Qt 工程

创建 Qt 工程时，我们通常使用 Qt 提供的 Online installer 安装 Qt Creator 和 Qt 库来创建、编译、发布 Qt 项目，这对开发环境和 CI Agent 环境有较强的要求，一旦环境安装不对或者安装时缺少了一些组件，可能导致无法编译出产物。最近一段时间，Qt 也拥抱 Conan，使我们可以通过 Conan 管理 Qt 库，这样我们就可以真正实现一套 CMake 脚本来管理和发布 Qt 的应用了。以下我们将演示如何通过 CMake + Conan 来组织 Qt 工程和实现程序的发布流程。

CMake 自动安装 git pre-commit hooks

在日常开发中，我们经常通过各类 IDE 工具来自动修正代码风格，但由于部分 IDE 工具与 clang-format 配合不是特别完善，导致保存或者按下分号、冒号以后代码自动格式化导致错乱，或者格式化时间过长等问题。这在日常开发中是很难让人接受的。

那么我们有没有办法在开发过程中不去让 clang-format 自动格式化，而是在提交代码时检查一次就够了呢？答案是可以的。Git 天生提供了 pre-commit hooks 能力，允许我们预设一些检查脚本在提交前做一些检查。手动编写脚本是比较麻烦的，而且不同开发者的不同环境适配也是棘手的问题。其实早就有人想到了这些事情，pre-commit 工具就是为这个而生的。

主流编辑器、IDE 开启 clang-format 自动格式化能力

clang-format 是 LLVM 下的一款代码风格格式化工具，它支持多种代码格式化风格，如：Visual Studio, LLVM, Google, Chromium, Mozilla, WebKit。团队中也可以根据配置定义自己的代码格式化风格保存到 .clang-format 配置文件中并放在项目工程目录下提供所有项目参与者使用，但如何让 .clang-format 工作起来呢？本文将讨论各类主流编辑器、IDE 是如何让 .clang-format 配置工作并且在代码粘贴或保存时自动进行格式化。

自定义 npm 包读取外部 npm install 时传入的命令行参数

正常情况下我们安装一个 npm 包只需要执行 npm install 或者 yarn 就可以了，这基本上都是在发布环境。当我们自定义的 npm 包需要在测试阶段根据环境动态设置一些参数时就显得有些麻烦了。如果能在 npm install 时传递一些参数来提供内部 npm 包读取就会变的比较方便。本文介绍如何通过 npm install 增加的命令行参数和 .npmrc 来动态配置自定义 npm 包的行为。

node-pre-gyp 应用场景介绍及使用方法

Node.js 提供了使用 C++ addon 方案作为扩展的能力。我们可以编写 C++ 的代码来扩展 Node.js 或封装自己产品相关的能力接口为 Node.js 接口提供用户或者开发者使用。将编写好的源代码上传至 npm publish 平台，开发者通过 npm install 就可以使用你的扩展包了。但使用的前提是引入方必须要具备编译 C++ 代码的环境，比如在 Windows 下需要安装 MSVC 的编译工具链。而正常的前端开发者并不会将这些组件安装到系统里面，他们更关注的是前端业务逻辑。

基于 git flow + gitlab 协作开发：02 解决问题

上一篇文章中我们提到了在一个周维度或者月维度发布产品的小型协作项目中，会遇到各类协作上的问题，随着发布的越来越紧凑，问题也就越来越突出。本文主要对上一篇文章中提到的问题解决方案做细化，让大家可以清楚的知道如何通过合理的 git 工作流来解决这些问题，让原来发布时的手忙脚乱不再出现。通过 git flow 我们可以对项目做一个分支模型管理：

  • master 固定，一致保持当前最新稳定的发布版本代码，在 CI/CD 建设时，你可以只在该分支做签名、公证等一系列自动化流程
  • develop 固定，这是我们日常的开发分支，所有新功能分支都将合并到该分支
  • release/* 可删，进入预发布阶段时基于 develop 创建的分支，再此基础集成，它名字可能是 release/2.8.0，release/2.9.0 等。
  • bugfix/* 可删，这种分支一般情况下基于 develop 或者 release/* 分支开出，作为简单的缺陷修复分支，最终合并到 develop 或 release/* 分支中
  • hotfix/* 可删，是对线上最新版本或长期服务版本做紧急修复时使用的分支，他不是常驻的

说多不多，说少也不少，还没有了解 git-flow 的同学可能会有点不太好理解，下面就详细介绍每个分支类型是如何在我们平时工作协作中起到重要作用的。

Qt 通过自定义 URL Scheme 给已经运行的应用传参（Windows&macOS）

在传统的应用程序设计中，我们可以看到很多通过浏览器唤起本地应用的案例，比如百度网盘、迅雷等工具，他们在浏览器访问一个非 http/https 协议开头的地址时，会自动打开其自己的应用程序并传递一定的参数。该功能的实现方式网络上有很多示例，在 Windows 和 macOS 不同平台下他们分别需要如下设置：

基于 git flow + gitlab 协作开发：01 抛出问题

很久以来，我一直在寻找一个适合小型团队独立项目的 git 协同工作流。主要原因是实际工作中很难在繁忙的迭代中兼顾真正的协同和代码质量管理。造成的现象就是在一个以月维度发布版本的产品中出现各种各样的分支、hotfix。到底哪个是主线，哪个分支修复了哪些问题、不同的分支是否与主线同步更新都是未知数。如果不叫一个从开始就参与到项目中的人给你做介绍，很难去做维护。

Qt Quick 5.15.0 Connections 新语法

过去的 Connection 连接某个对象的信号时是这样写的：

Connections {
    target: authManager
    onError: {
        busyContainer.visible = false
        buttonJoin.enabled = Qt.binding(function () {
            return textMeetingId.length >= 11 && textNickname.length > 0
        })
        message.error(result.msg)
    }
}

新的语法中可以这样写：

Connections {
    target: authManager
    function onError(resCode, result) {
        busyContainer.visible = false
        buttonJoin.enabled = Qt.binding(function () {
            return textMeetingId.length >= 11 && textNickname.length > 0
        })
        message.error(result.msg)
    }
}

对于日常开发中，新的写法有助于我们定义槽函数的形参个数和实际作用。代码看起来更容易读懂。另外 Qt 官方文档中也介绍了一些其他好处，见：Qt官方文档

如果你使用 Qt 15.5.0 版本打开了一个旧的工程并使用的是旧的写法，那么会收到一个警告：

qrc:/qml/AnonJoinPage.qml:54:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }

既然是个警告，则不影响代码继续执行。但这样的警告不得不让你重写这部分代码来适配新的语法。

Qt Quick Windows 下实现无边框窗口阴影效果

Qt Quick 中实现一个无边框窗口阴影效果的中心思想是将 Window 容器背景设置为透明的，在 Windows 容器中添加一个填满窗口的容器（如 Page、Rectangle 等），然后将这个容器设置一些边距，再给这个容器附加一个阴影效果，实现的效果如下：

注意：本文所描述的方案会有严重的性能损耗，尤其是在 2k 4k 显示器上性能损耗严重、帧率极低，如非特殊需求，建议不使用类似方案。

© 2023 - All rights reserved
Go to top