引子​

前不久在关于 CI/CD 文章《实战 CI/CD：微软加持的 GitHub Actions，怎么用才香？》中简单介绍了一下 GitHub 的官方 CI/CD 工作流服务 GitHub Actions，用一个实际的 Python 项目例子做了演示。不过，这部分内容相对较初级，而对于一些大型项目来说，我们可能需要更复杂的工作流。而这篇文章的主要目的是帮助开发者们熟悉软件开发中的工程化部分。

本篇文章以实际的大型项目为例，介绍一下笔者的开源项目 Crawlab 在 GitHub Actions 中的 CI/CD 应用。对 Crawlab 不熟悉的读者，可以参考一下官网或官方文档，简单来说，Crawlab 就是能帮助提高数据采集效率的爬虫管理平台。

整体 CI/CD 架构​

Crawlab 新版本 v0.6 将不少通用的模块进行了拆分，因此整个项目由多个子项目依赖组成，例如主项目 crawlab 依赖于前端 crawlab-ui 和后端 crawlab-core。这样切分成多个子项目之后，各个模块耦合性降低，可维护性增加。

以下是 Crawlab 的整体 CI/CD 架构示意图。

引子​

“话说天下大势，分久必合，合久必分。” --《三国演义》罗贯中

很少有人能质疑算法（Algorithm）在现代 IT 行业中的重要地位。正是有了巧妙设计的算法，计算机才能以最小的资源和最大的效率来运行各种各样的软件程序。因此，算法非常重要，以至于不少 IT 企业在招聘工程师时对算法要求非常高。回忆一下你参加过的技术面试被要求手写快速排序的算法题吧。不少人会认为算法是高屋建瓴的东西，然而笔者却认为算法以及数据结构产生的效率增益是自然形成的，这个可以从大自然中找到答案。

从雪花开始​

我们都知道，一片雪花很漂亮，除了它明亮的外表以外，令人惊叹的还有其造型：整体像雕琢过的六边形，每个角放大来看又是新的类似雪花的子六边形。这种自相似（Self Similarity）不断 递归 （Recursion）的结构有个专业术语， 分形（Fractal）。分形在大自然中随处可见，例如树的根系和枝叶、肺部毛细血管、天然形成的海岸线，数不胜数。甚至连一块摔碎的玻璃，也能找到分形的影子。

引子​

GitHub Actions 是 GitHub 官方推出的 CI/CD 工作流（Workflow）服务，旨在减轻开源贡献者们运维负担，让云原生 DevOps 赋能开源社区。如果您不知道什么是 CI/CD、DevOps，请参考笔者之前在夜幕团队公众号写的文章《用开源软件轻松打造企业级DevOps工作流》。笔者的开源项目，例如 Crawlab、ArtiPub，都集成了 GitHub Actions。作为开发贡献者，我认为 GitHub Actions 不仅好用，而且是真香免费（这是最主要的）。希望很多不了解如何将 GitHub Actions 运用在自己的开源项目的开发者，可以从本文中得到灵感。

从官方文档开始​

对于 GitHub Actions 不熟悉的朋友，我强烈推荐你先阅读 GitHub Actions 官方文档，这里有视频介绍、快速开始、例子、概念、原理等等。如果把文档研究透了，再结合自己平时运用 CI/CD 的经验，应该可以很轻松的在 GitHub 上做 DevOps。本文所用到的相关代码，都可以在官方文档上找到对应的参考指南。

思路​

先理清一下我们想要实现什么：用 GitHub Actions 来运行仓库中的爬虫获取每日 GitHub Trending。

引子​

"开发安全可靠的应用程序的最好方式，就是不写代码。"--Kelsey Hightower

很多开发者应该或多或少听过单元测试（Unit Tests），甚至编写过，也或许对其有所了解。不过，在如今瞬息万变的环境下，单元测试似乎正在成为鸡肋。程序员们都知道它的好处，但是对其显得比较冷淡。“进度这么赶，还有什么时间写单元测试呢？”这样的话是不是听着很熟悉？

单元测试是什么？​

所谓单元测试，简而言之就是程序员编写测试代码来验证自己写的功能代码是否能按照要求运行。如果测试代码不能通过，就说明自己写的功能代码是有问题的。

这种自己测自己的方式似乎有些可笑，相当于考试时看着答案做题。然而在测试领域，这样的方式有个专业术语叫白盒测试。而白盒测试的对立术语叫 黑盒测试，也就是用其他方式来验证。单元测试属于白盒测试，而更高级的测试例如集成测试（Integration Tests）、端到端测试（End to End Tests）、UI 测试（UI Tests），都属于黑盒测试。单元测试仅仅是测试代码本身。

单元测试有什么用？​

单元测试在敏捷开发（Agile Development）中是非常有用的工具。甚至有些敏捷框架，例如极限编程（XP），就要求每一个功能必须被单元测试覆盖。在之前的文章《浅谈敏捷：你的团队在正确实践敏捷吗？》就提到过单元测试的重要性。

引子​

“据不完全统计，数据从业者的白头发占比高于同年龄段的平均值”---某数据从业者

数据（Data），这个对不少人来说熟悉而神秘的词语，似乎已成为各行各业都在追捧的图腾。管理者们喜欢看到五颜六色的炫酷报表，数据分析师们热衷于构建专业复杂的概率模型，业务员们将数据仪表盘作为自己能否完成业绩目标的指南针。最近十几年，数据行业飞速发展，诞生了大量让人望而生畏的专业名词，例如大数据（Big Data）、数据科学（Data Science）、数据湖（Data Lake）、数据网络（Data Mesh）、数据治理（Data Governance）；当然，那些“传统”的专业词汇也让人头疼，例如数据仓库（Data Warehouse）、商业智能（Business Intelligence）、数据集市（Data Mart）、数据挖掘（Data Mining）；而更可怕的事实，很多人可能还不清楚这些名词跟最近大火大热的人工智能（Artificial Intelligence）、机器学习（Machine Learning）、深度学习（Deep Learning）有什么联系。这些火热的名词背后，都是数据领域野蛮发展的必然结果。

专业医生还是算命先生？​

多年前，互联网行业蓬勃发展，而数据行业的泡沫也日益增长。数据作为互联网应用的副产物，容量巨大而又丰富，很多互联网企业一门心思想要从中获取进一步增长，这是因为很多企业家将其视为金矿，进而也让数据挖掘工程师们成为了炙手可热的明星职业。之后，更火的职业应运而生，数据科学家（Data Scientist）被称为 21 世纪最性感的职业。

数据科学家职业的火爆是由于它要求多方面的经验能力：

• 编程能力：至少要用 Python 或 R 进行数据清洗、分析、建模
• 数理统计：熟练掌握概率论、微积分、离散数学等专业学科知识
• 业务知识：对相关业务领域的市场、流程、宏观趋势有深刻理解
• 沟通能力：能将分析结果以普通人类能够理解的方式表达出来

引子​

任务调度（Task Scheduling）是很多软件系统中的重要组成部分，字面上的意思是按照一定要求分配运行一些通常时间较长的脚本或程序。在爬虫管理平台 Crawlab 中，任务调度是其中的核心模块，相信不少朋友会好奇如何编写一个任务调度系统。本篇文章会教读者用 Go 语言编写一个非常简单的任务调度系统。

思路​

我们首先理清一下思路，开发最小化任务调度器需要什么。

• 交互界面（API）
• 定时任务（Cron）
• 任务执行（Execute Tasks）

整个流程如下：

我们通过 API 创建定时任务，执行器根据定时任务标准定期执行脚本。

引子​

“今天加一下班把这个需求做了吧，老板催得很急。”--某时某厂某项目经理

敏捷，这个曾经作为灵活速度的代名词，在过去 20 年里逐渐发展成为 IT 界中被程序员们时常挂在嘴边的看似深奥的专业术语。敏捷开发（Agile Development）作为很多开发团队的项目管理框架首选，因为其简单、灵活，更重要的是它字面上暗示着 “快”。想一想无数码农为了赶进度而无偿加班吧。

敏捷 = 快速交付？​

当你的开发团队遭遇项目延期、产品质量降低、士气低下以及客户关系恶化时，你的朋友或许会推荐你使用敏捷开发：“嘿，兄弟。我听说最近敏捷挺火的，你可以试一下。” 但是，当你在团队中推行敏捷一段时间后，你很可能会发现它并不好使：产品发布后依旧大量的bug、无穷无尽的加班、源源不断的最高优先级需求。在与老板的日常会议中，老板问你：“听说你们正在用敏捷来提升交付效率，很棒！所以我下周能看到之前给你提的重要功能吗？”

“敏捷就是快速交付”，这是很多敏捷实践者中最大的误区。其实，敏捷并不一定意味着快；相反，它还会引入更多额外工作，从而可能导致更慢的交付功能。对，你没看错。严格意义来说，敏捷会降低交付速度。例如，极限编程（XP，敏捷框架之一）要求为每一个功能编写单元测试，这会引入 1-2 倍的额外代码。

前言​

今天下英雄，惟使君与操耳。--曹操《三国演义》

对于在 IT 圈摸爬滚打多年的程序员来说，如果要问国内最主流的后端编程语言，我相信大部分会说 Java。这并不意外，因为 Java 存在了 30 多年，有着庞大的用户规模和生态体系，在软件工程领域似乎有着绝对霸主地位。但是，古人云：“得民心者得天下。” 用户最多的编程语言不一定是最受开发者们喜欢的。根据 StackOverflow 2021 年在 82,914 名开发者中做的关于编程语言满意度调查，喜欢 Java 的占比只有 47%，已经排到 20 名开外了，仅高于 PHP、C、COBOL。另一方面，我们从调查结果可以看到，有着 “山寨版 Java” 之称的 C#，反而在开发者心目中满意度达到了 62%，比 Java 高 15%。虽然 C# 的满意度跟 Rust、TypeScript 差距还比较大，但可以看出 C# 作为 Java 的替代编程语言，在开发效率、部署便捷性、文档完善度等方面已经逐渐占据优势。笔者因为工作的原因，在平时开发中使用 C# 和 Java 开发了不少项目，因此对它们之间的相同点、不同点以及优势、劣势有一定了解。笔者认为，C# 相对于 Java 来说更受开发者欢迎是有一定道理的，因为它的开发体验很好。

限于篇幅原因，整个 C# 的原理及实战介绍（即为何推荐用 C# 构建大型后端应用），将被拆分为一系列文章，该系列将从语法特性、开发模式、生态体系、部署构建等维度深度分析 C# 这门 “年轻” 的编程语言，并以跨平台框架 .NET Core 为例介绍如何用 C# 构建大型后端应用。

本篇文章是 C# 系列文章的第一篇，主要在语法特性方面介绍 C# 的一些现代语法特性，以及它们是如何提高开发效率的。

前言​

A bad plan is better than no plan.

坏计划也好过没有计划。--彼得·蒂尔《从0到1》

在软件开发工程中，很少会有单打独斗的程序员。这是因为现代较常见的软件项目通常都非常复杂，所要求的人力、资源、时间也比较多，仅由一个开发者来完成大型软件项目无异于 “愚公移山”。因此，软件开发通常离不开团队协作和项目管理。所谓项目管理（Project Management），简单来就是有序的组织、规划、执行并完成项目中各个任务的一种方法论。当然，实际项目管理的范畴还远不止这些，通常还会涉及资源调配、优先级制定、进度追踪等。它是工业革命的产物，也是现代管理学的分支，它能够大幅提高工程完成效率以及成功率。本文讨论的主要是软件项目管理，相较于传统的建筑工程、机械工程等项目管理有很大的不同。早期的 IT 项目管理来自于建筑工程等传统项目管理方法论，在信息时代早期扮演了重要的角色，大幅提高了软件开发和协同效率。然而，随着 IT 行业高速发展，消费者产品需求瞬息万变，市场形势变得越来越不确定（Volatile），传统的软件项目管理模式已经不能再满足软件开发需求。因此，现代软件开发模式，例如敏捷开发（Agile Development），应运而生，成为了很多互联网企业的首选。

传统项目管理模式（例如瀑布流）有什么弊端？现代项目管理模式（例如敏捷）又有什么改进？我们是否应该完全摈弃瀑布流模式，全面拥抱敏捷开发？作为一个程序员，是否应该掌握一些项目管理知识以及相关工具？作为一个团队领导，应该如何制定项目管理流程保证开发效率和质量？如果读者有类似上述问题的疑惑，本篇文章将为您详细分析和解答。

传统方法论​

前言​

城外的人想进去，城里的人想出来。-- 钱钟书《围城》

随着容器编排（Container Orchestration）、微服务（Micro Services）、云技术（Cloud Technology）等在 IT 行业不断盛行，2009 年诞生于 Google 的 Golang（Go 语言，简称 Go）越来越受到软件工程师的欢迎和追捧，成为如今炙手可热的后端编程语言。在用 Golang 开发的软件项目列表中，有 Docker（容器技术）、Kubernetes（容器编排）这样的颠覆整个 IT 行业的明星级产品，也有像 Prometheus（监控系统）、Etcd（分布式存储）、InfluxDB（时序数据库）这样的强大实用的知名项目。当然，Go 语言的应用领域也绝不局限于容器和分布式系统。如今很多大型互联网企业在大量使用 Golang 构建后端 Web 应用，例如今日头条、京东、七牛云等；长期被 Python 统治的框架爬虫领域也因为简单而易用的爬虫框架 Colly 的崛起而不断受到 Golang 的挑战。Golang 已经成为了如今大多数软件工程师最想学习的编程语言。下图是 HackerRank 在 2020 年调查程序员技能的相关结果。

那么，Go 语言真的是后端开发人员的救命良药呢？它是否能够有效提高程序员们的技术实力和开发效率，从而帮助他们在职场上更进一步呢？Go 语言真的值得我们花大量时间深入学习么？ 本文将详细介绍 Golang 的语言特点以及它的优缺点和适用场景，带着上述几个疑问，为读者分析 Go 语言的各个方面，以帮助初入 IT 行业的程序员以及对 Go 感兴趣的开发者进一步了解这个热门语言。