分类 软件开发 下的文章

以下是 GraphQL 在标准 REST API 技术上获得发展的原因。

正如我以前所写,GraphQL 是一种下一代 API 技术,它正在改变客户端应用程序与后端系统的通信方式以及后端系统的设计方式。

由于一开始就从创建它的组织 Facebook 获得了支持,并得到了其他技术巨头(如 Github、Twitter 和 AirBnB)的支持,因此 GraphQL 作为应用程序系统的关键技术的地位似乎是稳固的 —— 无论现在还是将来。

GraphQL 的崛起

移动应用程序性能和组织敏捷性重要性的提高为 GraphQL 登上现代企业体系结构的顶端提供了助推器。

鉴于 REST 是一种非常流行的体系结构风格,早已提供了数据交互机制,与 REST 相比,GraphQL 这项新技术具有哪些优势呢?GraphQL 中的 “QL” 代表着查询语言,而这是一个很好的起点。

借助 GraphQL,组织内的不同客户端应用程序可以轻松地仅查询所需数据,这一点超越了其它 REST 方法,并带来了实际应用程序性能的提高。使用传统的 REST API 端点,客户端应用程序将详询服务器资源,并接受包含了与请求匹配的所有数据的响应。如果来自 REST API 端点的成功响应返回 35 个字段,那么客户端应用程序就会收到 35 个字段。

获取的问题

传统上,REST API 没有为客户端应用程序提供简便的方法来仅检索或只更新它们关心的数据。这通常被描述为“ 过度获取 over-fetching ”的问题。随着移动应用程序在人们的日常生活中的普遍使用,过度获取问题会给现实世界带来不良后果。移动应用程序发出的每个请求、每一个字节的接受和发送,对终端用户的性能影响越来越大。数据连接速度较慢的用户尤其会受到不太好的 API 设计方案的影响。使用移动应用程序而性能体验不佳的客户更有可能不购买产品或不使用服务。低效的 API 设计只会浪费企业的钱。

并非只有“过度获取”是问题,“欠缺获取”同样也是问题。默认情况下,端点只返回客户端实际需要的部分数据,这需要客户端进行额外的调用以满足其数据需求,这就产生了额外的 HTTP 请求。由于过度和欠缺的获取问题及其对客户端应用程序性能的影响,促进有效获取的 API 技术才有机会在市场上引起轰动 —— GraphQL 大胆地介入并填补了这一空白。

REST 的应对

REST API 设计师不甘心不战而退,他们试图通过以下几种方式来应对移动应用程序性能问题:

  • “包含”和“排除”查询参数,允许客户端应用程序通过可能较长的查询格式来指定所需的字段。
  • “复合”服务,将多个端点组合在一起,以使客户端应用程序在其发出的请求数量和接收到的数据方面更高效。 尽管这些模式是 REST API 社区为解决移动客户端所面临的挑战而做出的英勇尝试,但它们在以下几个关键方面仍存在不足:
  • 包含和排除查询键/值对很快就会变得混乱,特别是对于需要用嵌套“点表示法”语法(或类似方法)以对目标数据进行包含和排除的深层对象图而言,更是如此。此外,在此模型中调试查询字符串的问题通常需要手动分解 URL。
  • 包含和排除查询的服务器的实现往往是自定义的,因为基于服务器的应用程序没有标准的方式来处理包含和排除查询的使用,就像没有定义包含和排除查询的标准方式一样。
  • 复合服务的兴起形成了更加紧密耦合的后端和前端系统,这就需要加强协调以交付项目,并且将曾经的敏捷项目转回瀑布式开发。这种协调和耦合还有一个痛苦的副作用,那就是减宦了组织的敏捷性。此外,顾名思义,组合服务不是 RESTful。

GraphQL 的起源

对于 Facebook 来说,从其 2011-2012 年基于 HTML5 版本的旗舰移动应用程序中感受到的痛点和体验,才造就了 GraphQL。Facebook 工程师意识到提高性能至关重要,因此意识到他们需要一种新的 API 设计来确保最佳性能。可能考虑到上述 REST 的局限性,并且需要支持许多 API 客户端的不同需求,因此人们可以理解是什么导致其共同创建者 Lee Byron 和 Dan Schaeffer(那时尚是 Facebook 员工)创建了后来被称之为 GraphQL 的技术的早期种子。

通过 GraphQL 查询语言,客户端(通常是单个 GraphQL 端点)应用程序通常可以显著减少所需的网络调用数量,并确保仅检索所需的数据。在许多方面,这可以追溯到早期的 Web 编程模型,在该模型中,客户端应用程序代码会直接查询后端系统 —— 比如说,有些人可能还记得 10 到 15 年前在 JSP 上用 JSTL 编写 SQL 查询的情形吧!

现在最大的区别是使用 GraphQL,我们有了一个跨多种客户端和服务器语言和库实现的规范。借助 GraphQL 这样一种 API 技术,我们通过引入 GraphQL 应用程序中间层来解耦后端和前端应用程序系统,该层提供了一种机制,以与组织的业务领域相一致的方式来访问组织数据。

除了解决软件工程团队遇到的技术挑战之外,GraphQL 还促进了组织敏捷性的提高,特别是在企业中。启用 GraphQL 的组织敏捷性通常归因于以下因素:

  • GraphQL API 设计人员和开发人员无需在客户端需要一个或多个新字段时创建新的端点,而是能够将这些字段包含在现有的图实现中,从而以较少的开发工作量和跨应用程序系统的较少更改的方式展示出新功能。
  • 通过鼓励 API 设计团队将更多的精力放在定义对象图上,而不是在专注于客户端应用程序交付上,前端和后端软件团队为客户交付解决方案的速度日益解耦。 ### 采纳之前的注意事项

尽管 GraphQL 具有引人注目的优势,但 GraphQL 并非没有实施挑战。一些例子包括:

  • REST API 建立的缓存机制更加成熟。
  • 使用 REST 来构建 API 的模式更加完善。
  • 尽管工程师可能更喜欢 GraphQL 等新技术,但与 GraphQL 相比,市场上的人才库更多是从事于构建基于 REST 的解决方案。

结论

通过同时提高性能和组织敏捷性,GraphQL 在过去几年中被企业采纳的数量激增。但是,与 API 设计的 RESTful 生态系统相比,它确实还需要更成熟一些。

GraphQL 的一大优点是,它并不是作为替代 API 解决方案的批发替代品而设计的。相反,GraphQL 可以用来补充或增强现有的 API。因此,鼓励企业探索在 GraphQL 对其最有意义的地方逐步采用 GraphQL —— 在他们发现它对应用程序性能和组织敏捷性具有最大的积极影响的地方。


via: https://opensource.com/article/19/6/why-use-graphql

作者:Zach Lendon 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

GraphQL 是一种查询语言、一个执行引擎,也是一种规范,它让开发人员重新思考如何构建客户端和 API 应用。

GraphQL 是当今软件技术中最大的流行语之一。但它究竟是什么?是像 SQL 一样的查询语言吗?是像 JVM 这样的执行引擎?还是像 XML 这样的规范?

如果你回答上面这些都是,那么你是对的!GraphQL 是一种查询语言的语法、是一种编程语言无关的执行引擎,也是一种不断发展的规范。

让我们深入了解一下 GraphQL 如何成为所有这些东西的,并了解一下人们为什么对它感到兴奋。

查询语言

GraphQL 作为查询语言似乎是合理的 —— 毕竟 “QL” 似乎重要到出现在名称中。但是我们查询什么呢?看一个示例查询请求和相应的响应可能会有所帮助。

以下的用户查询:

{
    user(id: 4) {
        name
        email
        phoneNumber
    }
}

可能会返回下面的 JSON 结果:

{
    "user": {
        "name": "Zach Lendon"
        “email”: “[email protected]”
        “phoneNumber”: “867-5309”
    }
}

想象一下,客户端应用查询用户详细信息、获取结果,并使用它填充配置屏幕。作为查询语言,GraphQL 的核心优势之一是客户端应用可以只请求它需要的数据,并期望以一致的方式返回这些数据。

那么 GraphQL 响应返回的什么呢?这就是执行引擎发挥的作用,通常是以 GraphQL 服务器的形式出现。

执行引擎

 title=

GraphQL 执行引擎负责处理 GraphQL 查询并返回 JSON 响应。所有 GraphQL 服务器由两个核心组件组成,分别定义了执行引擎的结构和行为:模式和解析器。

GraphQL 模式是一种自定义类型语言,它公开哪些查询既允许(有效),又由 GraphQL 服务器实现处理。上面用户示例查询的模式可能如下所示:

type User {
    name: String
    email: String
    phoneNumber: String
}

type Query {
    user: User
}

此模式定义了一个返回用户的用户查询。客户端可以通过用户查询请求用户上的任何字段,并且 GraphQL 服务器将仅返回请求的字段。通过使用强类型模式,GraphQL 服务器可以根据定义的模式验证传入的查询,以确保是有效的。

确定查询有效后,就会由 GraphQL 服务器的解析器处理。解析器函数支持每个 GraphQL 类型的每个字段。我们的这个用户查询的示例解析器可能如下所示:

Query: {
    user(obj, args, context, info) {
        return context.db.loadUserById(args.id).then(
            userData => new User(userData)
        )
    }
}

虽然上面的例子是用 JavaScript 编写的,但 GraphQL 服务器可以用任意语言编写。这是因为 GraphQL 也是也是一种规范!

规范

GraphQL 规范定义了 GraphQL 实现必须遵循的功能和特性。作为一个在开放网络基金会的最终规范协议(OWFa 1.0)下提供的开放规范,技术社区可以审查 GraphQL 实现必须符合规范的要求,并帮助制定 GraphQL 的未来。

虽然该规范对 GraphQL 的语法,什么是有效查询以及模式的工作方式进行了非常具体的说明,但它没有提供有关如何存储数据或 GraphQL 服务器应使用哪种编程语言实现的指导。这在软件领域是非常强大的,也是相对独特的。它允许以各种编程语言创建 GraphQL 服务器,并且由于它们符合规范,因此客户端会确切知道它们的工作方式。GraphQL 服务器已经有多种语言实现,人们不仅可以期望像 JavaScript、Java和 C# 这样的语言,还可以使用 Go、Elixir 和 Haskell 等。服务器实现所使用的语言不会成为采用过程的障碍。它不仅存在多种语言实现,而且它们都是开源的。如果没有你选择的语言的实现,那么可以自己实现。

总结

GraphQL 是开源 API 领域中一个令人兴奋的、相对较新的参与者。它将查询语言、执行引擎与开源规范结合在一起,它定义了 GraphQL 实现的外观和功能。

GraphQL 已经开始改变企业对构建客户端和 API 应用的看法。通过将 GraphQL 作为技术栈的一部分,前端开发人员可以自由地查询所需的数据,而后端开发人员可以将客户端应用需求与后端系统架构分离。通常,公司在使用 GraphQL 的过程中,首先会在其现有的后端服务之上构建一个 GraphQL API “层”。这使得客户端应用开始获得他们所追求的性能和运营效率,同时使后端团队有机会确定他们可能需要在 GraphQL 层后面的“幕后”进行哪些更改。通常,这些更改都是为了优化,这些优化有助于确保使用 GraphQL 的应用可以尽可能高效地运行。由于 GraphQL 提供了抽象性,因此系统团队可以进行更改的同时继续在其 GraphQL API 级别上遵守 GraphQL 的“合约”。

由于 GraphQL 相对较新,因此开发人员仍在寻找新颖而激动人心的方法来利用它构建更好的软件解决方案。GraphQL 将如何改变你构建应用的方式,它是否对得起众望所归?只有一种方法可以找到答案 —— 用 GraphQL 构建一些东西!


via: https://opensource.com/article/19/6/what-is-graphql

作者:Zach Lendon 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

本文是该系列的第三篇。

在我们的即时消息应用中,消息表现为两个参与者对话的堆叠。如果你想要开始一场对话,就应该向应用提供你想要交谈的用户,而当对话创建后(如果该对话此前并不存在),就可以向该对话发送消息。

就前端而言,我们可能想要显示一份近期对话列表。并在此处显示对话的最后一条消息以及另一个参与者的姓名和头像。

在这篇帖子中,我们将会编写一些 端点 endpoint 来完成像“创建对话”、“获取对话列表”以及“找到单个对话”这样的任务。

首先,要在主函数 main() 中添加下面的路由。

router.HandleFunc("POST", "/api/conversations", requireJSON(guard(createConversation)))
router.HandleFunc("GET", "/api/conversations", guard(getConversations))
router.HandleFunc("GET", "/api/conversations/:conversationID", guard(getConversation))

这三个端点都需要进行身份验证,所以我们将会使用 guard() 中间件。我们也会构建一个新的中间件,用于检查请求内容是否为 JSON 格式。

JSON 请求检查中间件

func requireJSON(handler http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        if ct := r.Header.Get("Content-Type"); !strings.HasPrefix(ct, "application/json") {
            http.Error(w, "Content type of application/json required", http.StatusUnsupportedMediaType)
            return
        }
        handler(w, r)
    }
}

如果 请求 request 不是 JSON 格式,那么它会返回 415 Unsupported Media Type(不支持的媒体类型)错误。

创建对话

type Conversation struct {
    ID                string   `json:"id"`
    OtherParticipant  *User    `json:"otherParticipant"`
    LastMessage       *Message `json:"lastMessage"`
    HasUnreadMessages bool     `json:"hasUnreadMessages"`
}

就像上面的代码那样,对话中保持对另一个参与者和最后一条消息的引用,还有一个 bool 类型的字段,用来告知是否有未读消息。

type Message struct {
    ID             string    `json:"id"`
    Content        string    `json:"content"`
    UserID         string    `json:"-"`
    ConversationID string    `json:"conversationID,omitempty"`
    CreatedAt      time.Time `json:"createdAt"`
    Mine           bool      `json:"mine"`
    ReceiverID     string    `json:"-"`
}

我们会在下一篇文章介绍与消息相关的内容,但由于我们这里也需要用到它,所以先定义了 Message 结构体。其中大多数字段与数据库表一致。我们需要使用 Mine 来断定消息是否属于当前已验证用户所有。一旦加入实时功能,ReceiverID 可以帮助我们过滤消息。

接下来让我们编写 HTTP 处理程序。尽管它有些长,但也没什么好怕的。

func createConversation(w http.ResponseWriter, r *http.Request) {
    var input struct {
        Username string `json:"username"`
    }
    defer r.Body.Close()
    if err := json.NewDecoder(r.Body).Decode(&input); err != nil {
        http.Error(w, err.Error(), http.StatusBadRequest)
        return
    }

    input.Username = strings.TrimSpace(input.Username)
    if input.Username == "" {
        respond(w, Errors{map[string]string{
            "username": "Username required",
        }}, http.StatusUnprocessableEntity)
        return
    }

    ctx := r.Context()
    authUserID := ctx.Value(keyAuthUserID).(string)

    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        respondError(w, fmt.Errorf("could not begin tx: %v", err))
        return
    }
    defer tx.Rollback()

    var otherParticipant User
    if err := tx.QueryRowContext(ctx, `
        SELECT id, avatar_url FROM users WHERE username = $1
    `, input.Username).Scan(
        &otherParticipant.ID,
        &otherParticipant.AvatarURL,
    ); err == sql.ErrNoRows {
        http.Error(w, "User not found", http.StatusNotFound)
        return
    } else if err != nil {
        respondError(w, fmt.Errorf("could not query other participant: %v", err))
        return
    }

    otherParticipant.Username = input.Username

    if otherParticipant.ID == authUserID {
        http.Error(w, "Try start a conversation with someone else", http.StatusForbidden)
        return
    }

    var conversationID string
    if err := tx.QueryRowContext(ctx, `
        SELECT conversation_id FROM participants WHERE user_id = $1
        INTERSECT
        SELECT conversation_id FROM participants WHERE user_id = $2
    `, authUserID, otherParticipant.ID).Scan(&conversationID); err != nil && err != sql.ErrNoRows {
        respondError(w, fmt.Errorf("could not query common conversation id: %v", err))
        return
    } else if err == nil {
        http.Redirect(w, r, "/api/conversations/"+conversationID, http.StatusFound)
        return
    }

    var conversation Conversation
    if err = tx.QueryRowContext(ctx, `
        INSERT INTO conversations DEFAULT VALUES
        RETURNING id
    `).Scan(&conversation.ID); err != nil {
        respondError(w, fmt.Errorf("could not insert conversation: %v", err))
        return
    }

    if _, err = tx.ExecContext(ctx, `
        INSERT INTO participants (user_id, conversation_id) VALUES
            ($1, $2),
            ($3, $2)
    `, authUserID, conversation.ID, otherParticipant.ID); err != nil {
        respondError(w, fmt.Errorf("could not insert participants: %v", err))
        return
    }

    if err = tx.Commit(); err != nil {
        respondError(w, fmt.Errorf("could not commit tx to create conversation: %v", err))
        return
    }

    conversation.OtherParticipant = &otherParticipant

    respond(w, conversation, http.StatusCreated)
}

在此端点,你会向 /api/conversations 发送 POST 请求,请求的 JSON 主体中包含要对话的用户的用户名。

因此,首先需要将请求主体解析成包含用户名的结构。然后,校验用户名不能为空。

type Errors struct {
    Errors map[string]string `json:"errors"`
}

这是错误消息的结构体 Errors,它仅仅是一个映射。如果输入空用户名,你就会得到一段带有 422 Unprocessable Entity(无法处理的实体)错误消息的 JSON 。

{
    "errors": {
        "username": "Username required"
    }
}

然后,我们开始执行 SQL 事务。收到的仅仅是用户名,但事实上,我们需要知道实际的用户 ID 。因此,事务的第一项内容是查询另一个参与者的 ID 和头像。如果找不到该用户,我们将会返回 404 Not Found(未找到) 错误。另外,如果找到的用户恰好和“当前已验证用户”相同,我们应该返回 403 Forbidden(拒绝处理)错误。这是由于对话只应当在两个不同的用户之间发起,而不能是同一个。

然后,我们试图找到这两个用户所共有的对话,所以需要使用 INTERSECT 语句。如果存在,只需要通过 /api/conversations/{conversationID} 重定向到该对话并将其返回。

如果未找到共有的对话,我们需要创建一个新的对话并添加指定的两个参与者。最后,我们 COMMIT 该事务并使用新创建的对话进行响应。

获取对话列表

端点 /api/conversations 将获取当前已验证用户的所有对话。

func getConversations(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    authUserID := ctx.Value(keyAuthUserID).(string)

    rows, err := db.QueryContext(ctx, `
        SELECT
            conversations.id,
            auth_user.messages_read_at < messages.created_at AS has_unread_messages,
            messages.id,
            messages.content,
            messages.created_at,
            messages.user_id = $1 AS mine,
            other_users.id,
            other_users.username,
            other_users.avatar_url
        FROM conversations
        INNER JOIN messages ON conversations.last_message_id = messages.id
        INNER JOIN participants other_participants
            ON other_participants.conversation_id = conversations.id
                AND other_participants.user_id != $1
        INNER JOIN users other_users ON other_participants.user_id = other_users.id
        INNER JOIN participants auth_user
            ON auth_user.conversation_id = conversations.id
                AND auth_user.user_id = $1
        ORDER BY messages.created_at DESC
    `, authUserID)
    if err != nil {
        respondError(w, fmt.Errorf("could not query conversations: %v", err))
        return
    }
    defer rows.Close()

    conversations := make([]Conversation, 0)
    for rows.Next() {
        var conversation Conversation
        var lastMessage Message
        var otherParticipant User
        if err = rows.Scan(
            &conversation.ID,
            &conversation.HasUnreadMessages,
            &lastMessage.ID,
            &lastMessage.Content,
            &lastMessage.CreatedAt,
            &lastMessage.Mine,
            &otherParticipant.ID,
            &otherParticipant.Username,
            &otherParticipant.AvatarURL,
        ); err != nil {
            respondError(w, fmt.Errorf("could not scan conversation: %v", err))
            return
        }

        conversation.LastMessage = &lastMessage
        conversation.OtherParticipant = &otherParticipant
        conversations = append(conversations, conversation)
    }

    if err = rows.Err(); err != nil {
        respondError(w, fmt.Errorf("could not iterate over conversations: %v", err))
        return
    }

    respond(w, conversations, http.StatusOK)
}

该处理程序仅对数据库进行查询。它通过一些联接来查询对话表……首先,从消息表中获取最后一条消息。然后依据“ID 与当前已验证用户不同”的条件,从参与者表找到对话的另一个参与者。然后联接到用户表以获取该用户的用户名和头像。最后,再次联接参与者表,并以相反的条件从该表中找出参与对话的另一个用户,其实就是当前已验证用户。我们会对比消息中的 messages_read_atcreated_at 两个字段,以确定对话中是否存在未读消息。然后,我们通过 user_id 字段来判定该消息是否属于“我”(指当前已验证用户)。

注意,此查询过程假定对话中只有两个用户参与,它也仅仅适用于这种情况。另外,该设计也不很适用于需要显示未读消息数量的情况。如果需要显示未读消息的数量,我认为可以在 participants 表上添加一个unread_messages_count INT 字段,并在每次创建新消息的时候递增它,如果用户已读则重置该字段。

接下来需要遍历每一条记录,通过扫描每一个存在的对话来建立一个 对话切片 slice of conversations 并在最后进行响应。

找到单个对话

端点 /api/conversations/{conversationID} 会根据 ID 对单个对话进行响应。

func getConversation(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    authUserID := ctx.Value(keyAuthUserID).(string)
    conversationID := way.Param(ctx, "conversationID")

    var conversation Conversation
    var otherParticipant User
    if err := db.QueryRowContext(ctx, `
        SELECT
            IFNULL(auth_user.messages_read_at < messages.created_at, false) AS has_unread_messages,
            other_users.id,
            other_users.username,
            other_users.avatar_url
        FROM conversations
        LEFT JOIN messages ON conversations.last_message_id = messages.id
        INNER JOIN participants other_participants
            ON other_participants.conversation_id = conversations.id
                AND other_participants.user_id != $1
        INNER JOIN users other_users ON other_participants.user_id = other_users.id
        INNER JOIN participants auth_user
            ON auth_user.conversation_id = conversations.id
                AND auth_user.user_id = $1
        WHERE conversations.id = $2
    `, authUserID, conversationID).Scan(
        &conversation.HasUnreadMessages,
        &otherParticipant.ID,
        &otherParticipant.Username,
        &otherParticipant.AvatarURL,
    ); err == sql.ErrNoRows {
        http.Error(w, "Conversation not found", http.StatusNotFound)
        return
    } else if err != nil {
        respondError(w, fmt.Errorf("could not query conversation: %v", err))
        return
    }

    conversation.ID = conversationID
    conversation.OtherParticipant = &otherParticipant

    respond(w, conversation, http.StatusOK)
}

这里的查询与之前有点类似。尽管我们并不关心最后一条消息的显示问题,并因此忽略了与之相关的一些字段,但是我们需要根据这条消息来判断对话中是否存在未读消息。此时,我们使用 LEFT JOIN 来代替 INNER JOIN,因为 last_message_id 字段是 NULLABLE(可以为空)的;而其他情况下,我们无法得到任何记录。基于同样的理由,我们在 has_unread_messages 的比较中使用了 IFNULL 语句。最后,我们按 ID 进行过滤。

如果查询没有返回任何记录,我们的响应会返回 404 Not Found 错误,否则响应将会返回 200 OK 以及找到的对话。


本篇帖子以创建了一些对话端点结束。

在下一篇帖子中,我们将会看到如何创建并列出消息。


via: https://nicolasparada.netlify.com/posts/go-messenger-conversations/

作者:Nicolás Parada 选题:lujun9972 译者:PsiACE 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

两者之间的区别在于开发完毕之后发生的事情。

早期,软件开发并没有特定的管理流程。随后出现了 瀑布开发流程 Waterfall ,它提出软件开发活动可以用开发和构建应用所耗费的时间来定义。

那时候,由于在开发流程中没有审查环节和权衡考虑,常常需要花费很长的时间来开发、测试和部署软件。交付的软件也是带有缺陷和 Bug 的质量较差的软件,而且交付时间也不满足要求。那时候软件项目管理的重点是长期而拖沓的计划。

瀑布流程与 三重约束模型 triple constraint model 相关,三重约束模型也称为 项目管理三角形 project management triangle 。三角形的每一个边代表项目管理三要素的一个要素: 范围、时间和成本。正如 Angelo Baretta 写到,三重约束模型“认为成本是时间和范围的函数,这三个约束以一种确定的、可预测的方式相互作用。……如果我们想缩短时间表(时间),就必须增加成本。如果我们想增加范围,就必须增加成本或时间。”

从瀑布流程过渡到敏捷开发

瀑布流程来源于生产和工程领域,这些领域适合线性化的流程:正如房屋封顶之前需要先盖好支撑墙。相似地,软件开发问题被认为可以通过提前做好计划来解决。从头到尾,开发流程均由路线图清晰地定义,沿着路线图就可以得到最终交付的产品。

最终,瀑布模型被认为对软件开发是不利的而且违反人的直觉,因为通常直到开发流程的最后才能体现出项目的价值,这导致许多项目最终都以失败告终。而且,在项目结束前客户看不到任何可以工作的软件。

敏捷 Agile 采用了一种不同的方法,它抛弃了规划整个项目,承诺估计的时间点,简单的遵循计划。与瀑布流程相反,它假设和拥抱不确定性。它的理念是以响应变化代替讨论过去,它认为变更是客户需求的一部分。

敏捷价值观

敏捷由 敏捷宣言 Agile Manifesto 代言,敏捷宣言定义了 12 条原则(LCTT 译注:此处没有采用本文原本的简略句式,而是摘录了来自敏捷软件开发宣言官方的中文译本):

  1. 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  2. 欣然面对需求变化,即使在开发后期也一样。
  3. 经常交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  6. 面对面沟通是传递信息的最佳的也是效率最高的方法。
  7. 可工作的软件是进度的首要度量标准。
  8. 敏捷流程倡导可持续的开发,责任人、开发人员和用户要能够共同维持其步调稳定延续。
  9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  10. 以简洁为本,它是极力减少不必要工作量的艺术。
  11. 最好的架构,需求和设计出自自组织团队
  12. 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

敏捷的四个核心价值观是(LCTT 译注:此处译文同样来自敏捷软件开发宣言官方):

  • 个体和互动 高于流程和工具
  • 工作的软件 高于详尽的文档
  • 客户合作 高于合同谈判
  • 响应变化 高于遵循计划

这与瀑布流程死板的计划风格相反。在敏捷流程中,客户是开发团队的一员,而不仅仅是在项目开始时参与项目需求的定义,在项目结束时验收最终的产品。客户帮忙团队完成验收标准,并在整个过程中保持投入。另外,敏捷需要整个组织的变化和持续的改进。开发团队和其他团队一起合作,包括项目管理团队和测试团队。做什么和计划什么时候做由指定的角色领导,并由整个团队同意。

敏捷软件开发

敏捷软件开发需要自适应的规划、演进式的开发和交付。许多软件开发方法、框架和实践遵从敏捷的理念,包括:

  • Scrum
  • 看板 Kanban (可视化工作流)
  • 极限编程 Xtreme Programming (XP)
  • 精益方法 Lean
  • DevOps
  • 特性驱动开发 Feature-Driven Development (FDD)
  • 测试驱动开发 Test-Driven Development (TDD)
  • 水晶方法 Crystal
  • 动态系统开发方法 Dynamic Systems Development Method (DSDM)
  • 自适应软件开发 Adaptive Software Development (ASD)

所有这些已经被单独用于或一起用于开发和部署软件。最常用的是 Scrum、看板(或 Scrumban)和 DevOps。

Scrum 是一个框架,采用该框架的团队通常由一个 Scrum 教练、产品经理和开发人员组成,该团队以跨职能、自主的工作方式运作,能够加快软件交付速度从而给客户带来巨大的商业价值。其关注点是较小增量的快速迭代。

看板 是一个敏捷框架,有时也叫工作流管理系统,它能帮助团队可视化他们的工作从而最大化效率(因而变得敏捷)。看板通常由数字或物理展示板来呈现。团队的工作在展示板上随着进度而移动,例如从未启动到进行中,一直到测试中、已完成。看板使得每个团队成员可以随时查看到所有工作的状态。

DevOps 价值观

DevOps 是一种文化,是一种思维状态,是一种软件开发的方式或者基础设施的方式,也是一种构建和部署软件和应用的方式。它假设开发和运维之间没有隔阂,他们一起合作,没有矛盾。

DevOps 基于其它两个领域的实践: 精益和敏捷。DevOps 不是一个公司内的岗位或角色;它是一个组织或团队对持续交付、持续部署和持续集成的坚持不懈的追求。Gene Kim(Phoenix 项目和 Unicorn 项目的作者)认为,有三种方式定义 DevOps 的理念:

  • 第一种: 流程原则
  • 第二种: 反馈原则
  • 第三种: 持续学习原则

DevOps 软件开发

DevOps 不会凭空产生;它是一种灵活的实践,它的本质是一种关于软件开发和 IT 或基础设施实施的共享文化和思维方式。

当你想到自动化、云、微服务时,你会想到 DevOps。在一次访谈中,《加速构建和扩张高性能技术组织》的作者 Nicol Forsgren、Jez Humble 和 Gene Kim 这样解释到:

  • 软件交付能力很重要,它极大地影响到组织的成果,例如利润、市场份额、质量、客户满意度以及组织战略目标的达成。
  • 优秀的团队能达到很高的交付量、稳定性和质量;他们并没有为了获得这些属性而进行取舍。
  • 你可以通过实施精益、敏捷和 DevOps 中的实践来提升能力。
  • 实施这些实践和能力也会影响你的组织文化,并且会进一步对你的软件交付能力和组织能力产生有益的提升。
  • 懂得怎样改进能力需要做很多工作。

DevOps 和敏捷的对比

DevOps 和敏捷有相似性,但是它们不完全相同,一些人认为 DevOps 比敏捷更好。为了避免造成混淆,深入地了解它们是很重要的。

相似之处

  • 毫无疑问,两者都是软件开发技术。
  • 敏捷已经存在了 20 多年,DevOps 是最近才出现的。
  • 两者都追求软件的快速开发,它们的理念都基于怎样在不伤害客户或运维利益的情况下快速开发出软件。

不同之处

  • 两者的差异在于软件开发完成后发生的事情。

    • 在 DevOps 和敏捷中,都有软件开发、测试和部署的阶段。然而,敏捷流程在这三个阶段之后会终止。相反,DevOps 包括后续持续的运维。因此,DevOps 会持续的监控软件运行情况和进行持续的开发。
  • 敏捷中,不同的人负责软件的开发、测试和部署。而 DevOps 工程角色负责所有活动,开发即运维,运维即开发。
  • DevOps 更关注于削减成本,而敏捷则是精益和减少浪费的代名词,侧重于像敏捷项目会计和最小可行产品的概念。
  • 敏捷专注于并体现了经验主义(适应、透明和检查),而不是预测性措施。
敏捷DevOps
从客户得到反馈从自己得到反馈
较小的发布周期较小的发布周期,立即反馈
聚焦于速度聚焦于速度和自动化
对业务不是最好对业务最好

总结

敏捷和 DevOps 是截然不同的,尽管它们的相似之处使人们认为它们是相同的。这对敏捷和 DevOps 都是一种伤害。

根据我作为一名敏捷专家的经验,我发现对于组织和团队从高层次上了解敏捷和 DevOps 是什么,以及它们如何帮助团队更高效地工作,更快地交付高质量产品从而提高客户满意度非常有价值。

敏捷和 DevOps 绝不是对抗性的(或至少没有这个意图)。在敏捷革命中,它们更像是盟友而不是敌人。敏捷和 DevOps 可以相互协作一致对外,因此可以在相同的场合共存。


via: https://opensource.com/article/20/2/devops-vs-agile

作者:Taz Brown 选题:lujun9972 译者:messon007 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

我将在本系列的第二篇中深入研究由多个文件组成的 C 程序的结构。

第一篇中,我设计了一个名为喵呜喵呜的多文件 C 程序,该程序实现了一个玩具编解码器。我也提到了程序设计中的 Unix 哲学,即在一开始创建多个空文件,并建立一个好的结构。最后,我创建了一个 Makefile 文件夹并阐述了它的作用。在本文中将另一个方向展开:现在我将介绍简单但具有指导性的喵呜喵呜编解码器的实现。

当读过我的《如何写一个好的 C 语言 main 函数》后,你会觉得喵呜喵呜编解码器的 main.c 文件的结构很熟悉,其主体结构如下:

/* main.c - 喵呜喵呜流式编解码器 */

/* 00 系统包含文件 */
/* 01 项目包含文件 */
/* 02 外部声明 */
/* 03 定义 */
/* 04 类型定义 */
/* 05 全局变量声明(不要用)*/
/* 06 附加的函数原型 */
   
int main(int argc, char *argv[])
{
  /* 07 变量声明 */
  /* 08 检查 argv[0] 以查看该程序是被如何调用的 */
  /* 09 处理来自用户的命令行选项 */
  /* 10 做点有用的事情 */
}
   
/* 11 其它辅助函数 */

包含项目头文件

位于第二部分中的 /* 01 项目包含文件 */ 的源代码如下:

/* main.c - 喵呜喵呜流式编解码器 */
...
/* 01 项目包含文件 */
#include "main.h"
#include "mmecode.h"
#include "mmdecode.h"

#include 是 C 语言的预处理命令,它会将该文件名的文件内容拷贝到当前文件中。如果程序员在头文件名称周围使用双引号(""),编译器将会在当前目录寻找该文件。如果文件被尖括号包围(<>),编译器将在一组预定义的目录中查找该文件。

main.h 文件中包含了 main.c 文件中用到的定义和类型定义。我喜欢尽可能多将声明放在头文件里,以便我在我的程序的其他位置使用这些定义。

头文件 mmencode.hmmdecode.h 几乎相同,因此我以 mmencode.h 为例来分析。

/* mmencode.h - 喵呜喵呜流编解码器 */
  
#ifndef _MMENCODE_H
#define _MMENCODE_H
  
#include <stdio.h>
  
int mm_encode(FILE *src, FILE *dst);
  
#endif /* _MMENCODE_H */

#ifdef#define#endif 指令统称为 “防护” 指令。其可以防止 C 编译器在一个文件中多次包含同一文件。如果编译器在一个文件中发现多个定义/原型/声明,它将会产生警告。因此这些防护措施是必要的。

在这些防护内部,只有两个东西:#include 指令和函数原型声明。我在这里包含了 stdio.h 头文件,以便于能在函数原型中使用 FILE 定义。函数原型也可以被包含在其他 C 文件中,以便于在文件的命名空间中创建它。你可以将每个文件视为一个独立的命名空间,其中的变量和函数不能被另一个文件中的函数或者变量使用。

编写头文件很复杂,并且在大型项目中很难管理它。不要忘记使用防护。

喵呜喵呜编码的最终实现

该程序的功能是按照字节进行 MeowMeow 字符串的编解码,事实上这是该项目中最简单的部分。截止目前我所做的工作便是支持允许在适当的位置调用此函数:解析命令行,确定要使用的操作,并打开将要操作的文件。下面的循环是编码的过程:

/* mmencode.c - 喵呜喵呜流式编解码器 */
...
   while (!feof(src)) {

     if (!fgets(buf, sizeof(buf), src))
       break;

     for(i=0; i<strlen(buf); i++) {
       lo = (buf[i] & 0x000f);
       hi = (buf[i] & 0x00f0) >> 4;
       fputs(tbl[hi], dst);
       fputs(tbl[lo], dst);
     }
   }

简单的说,当文件中还有数据块时( feof(3) ),该循环读取(feof(3) )文件中的一个数据块。然后将读入的内容的每个字节分成两个 hilo 半字节 nibble 。半字节是半个字节,即 4 个位。这里的奥妙之处在于可以用 4 个位来编码 16 个值。我将 hilo 用作 16 个字符串查找表 tbl 的索引,表中包含了用半字节编码的 MeowMeow 字符串。这些字符串使用 fputs(3) 函数写入目标 FILE 流,然后我们继续处理缓存区的下一个字节。

该表使用 table.h 中的宏定义进行初始化,在没有特殊原因(比如:要展示包含了另一个项目的本地头文件)时,我喜欢使用宏来进行初始化。我将在未来的文章中进一步探讨原因。

喵呜喵呜解码的实现

我承认在开始工作前花了一些时间。解码的循环与编码类似:读取 MeowMeow 字符串到缓冲区,将编码从字符串转换为字节

 /* mmdecode.c - 喵呜喵呜流式编解码器 */
 ...
 int mm_decode(FILE *src, FILE *dst)
 {
   if (!src || !dst) {
     errno = EINVAL;
     return -1;
   }
   return stupid_decode(src, dst);
 }

这不符合你的期望吗?

在这里,我通过外部公开的 mm_decode() 函数公开了 stupid_decode() 函数细节。我上面所说的“外部”是指在这个文件之外。因为 stupid_decode() 函数不在该头文件中,因此无法在其他文件中调用它。

当我们想发布一个可靠的公共接口时,有时候会这样做,但是我们还没有完全使用函数解决问题。在本例中,我编写了一个 I/O 密集型函数,该函数每次从源中读取 8 个字节,然后解码获得 1 个字节写入目标流中。较好的实现是一次处理多于 8 个字节的缓冲区。更好的实现还可以通过缓冲区输出字节,进而减少目标流中单字节的写入次数。

/* mmdecode.c - 喵呜喵呜流式编解码器 */
...
int stupid_decode(FILE *src, FILE *dst)
{
  char           buf[9];
  decoded_byte_t byte;
  int            i;
    
  while (!feof(src)) {
    if (!fgets(buf, sizeof(buf), src))
      break;
    byte.field.f0 = isupper(buf[0]);
    byte.field.f1 = isupper(buf[1]);
    byte.field.f2 = isupper(buf[2]);
    byte.field.f3 = isupper(buf[3]);
    byte.field.f4 = isupper(buf[4]);
    byte.field.f5 = isupper(buf[5]);
    byte.field.f6 = isupper(buf[6]);
    byte.field.f7 = isupper(buf[7]);
      
    fputc(byte.value, dst);
  }
  return 0;
}

我并没有使用编码器中使用的位移方法,而是创建了一个名为 decoded_byte_t 的自定义数据结构。

/* mmdecode.c - 喵呜喵呜流式编解码器 */
...

typedef struct {
  unsigned char f7:1;
  unsigned char f6:1;
  unsigned char f5:1;
  unsigned char f4:1;
  unsigned char f3:1;
  unsigned char f2:1;
  unsigned char f1:1;
  unsigned char f0:1;
} fields_t;
  
typedef union {
  fields_t      field;
  unsigned char value;
} decoded_byte_t;

初次看到代码时可能会感到有点儿复杂,但不要放弃。decoded_byte_t 被定义为 fields_tunsigned char联合。可以将联合中的命名成员看作同一内存区域的别名。在这种情况下,valuefield 指向相同的 8 位内存区域。将 field.f0 设置为 1 也将会设置 value 中的最低有效位。

虽然 unsigned char 并不神秘,但是对 fields_t 的类型定义(typedef)也许看起来有些陌生。现代 C 编译器允许程序员在结构体中指定单个位字段的值。字段所在的类型是一个无符号整数类型,并在成员标识符后紧跟一个冒号和一个整数,该整数指定了位字段的长度。

这种数据结构使得按字段名称访问字节中的每个位变得简单,并可以通过联合中的 value 字段访问组合后的值。我们依赖编译器生成正确的移位指令来访问字段,这可以在调试时为你节省不少时间。

最后,因为 stupid_decode() 函数一次仅从源 FILE 流中读取 8 个字节,所以它效率并不高。通常我们尝试最小化读写次数,以提高性能和降低调用系统调用的开销。请记住:少量的读取/写入大的块比大量的读取/写入小的块好得多。

总结

用 C 语言编写一个多文件程序需要程序员要比只是是一个 main.c 做更多的规划。但是当你添加功能或者重构时,只需要多花费一点儿努力便可以节省大量时间以及避免让你头痛的问题。

回顾一下,我更喜欢这样做:多个文件,每个文件仅有简单功能;通过头文件公开那些文件中的小部分功能;把数字常量和字符串常量保存在头文件中;使用 Makefile 而不是 Bash 脚本来自动化处理事务;使用 main() 函数来处理命令行参数解析并作为程序主要功能的框架。

我知道我只是蜻蜓点水般介绍了这个简单的程序,并且我很高兴知道哪些事情对你有所帮助,以及哪些主题需要详细的解释。请在评论中分享你的想法,让我知道。


via: https://opensource.com/article/19/7/structure-multi-file-c-part-2

作者:Erik O'Shaughnessy 选题:lujun9972 译者:萌新阿岩 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

本文是 Python 之禅特别系列的第二篇,我们将要关注其中第三与第四条原则:简单与复杂。

Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y plus rien à retrancher.

It seems that perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away.

“完美并非无可增,而是不可减。”

—Antoine de Saint-Exupéry, Terre des Hommes, 1939

编程时最常有的考量是与复杂性的斗争,只想写出让旁人无从下手的繁杂代码,对每个程序员来讲都算不上难事。倘若未能触及代码的简繁取舍,那么 《Python 之禅》 就有了一角残缺。

简单胜过复杂 Simple is better than complex

尚有选择余地时,应该选简单的方案。Python 少有不可为之事,这意味着设计出巴洛克风格(LCTT 译注:即夸张和不理性)的程序只为解决浅显的问题不仅有可能,甚至很简单。

正因如此,编程时应当谨记,代码的简单性是最易丢失,却最难复得的。

这意味着,在可以选用函数来表达时不要去引入额外的类;避免使用强力的第三方库往往有助于你针对迫切的问题场景设计更妥当的简短函数。不过其根本的意图,旨在让你减少对将来的盘算,而去着重解决手头的问题。

以简单和优美作为指导原则的代码相比那些想要囊括将来一切变数的,在日后要容易修改得多。

复杂胜过错综复杂 Complex is better than complicated

把握用词的精确含义对于理解这条令人费解的原则是至关重要的。形容某事 复杂 complex ,是说它由许多部分组成,着重组成成分之多;而形容某事 错综复杂 complicated ,则是指其包含着差异巨大、难以预料的行为,强调的是各组成部分之间的杂乱联系。

解决困难问题时,往往没有可行的简单方案。此时,最 Python 化的策略是“ 自底向上 bottom-up ”地构建出简单的工具,之后将其组合用以解决该问题。

这正是 对象组合 object composition 这类技术的闪耀之处,它避免了错综复杂的继承体系,转而由独立的对象把一些方法调用传递给别的独立对象。这些对象都能独立地测试与部署,最终却可以组成一体。

“自底建造” 的另一例即是 单分派泛函数 singledispatch 的使用,抛弃了错综复杂的对象之后,我们得到是简单、几乎无行为的对象以及独立的行为。


via: https://opensource.com/article/19/12/zen-python-simplicity-complexity

作者:Moshe Zadka 选题:lujun9972 译者:caiichenr 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出