构建应用流程指南

这篇文章将刻意练习-持续集成，持续集成就是大方案里套小方案

Q：如何区分码农和程序员？

A：他是否尊重了程序

前言

markdown 如何可以定义变量就好了，我的一些引用就不需要反复的写，而且可以统一修改。

Variables in Markdown (opens new window) 是支持用来定义的，所以如果 VuePress (opens new window) 带了这样的解析就好了。

其实自己一直在做开发的工作，只不过自己的语言是中文，而自己的工程是Sloth 。所以在今天的节点，自己尝试梳理一下自己在构建一个应用的整体流程，其大体上的流程分为：设计、编码、交付三个阶段。

设计阶段

我对 Sloth 是打算用一生来打磨的，所以我很重视前期的结构设计。但是现在你也可能发现了，我在README 中需要用 vuepress-plugin-blog (opens new window) 对整个系统进行重构，所以，我之前的一些对于“应用的目录结构一旦设计好就不会变”的想法持有深深的怀疑。

在构建应用的所有步骤中，设计阶段是重中之重，应该花最多时间的地方。因为

• 目标的意义

  做人要立大志，做系统也要站在高的维度上来思考。我拿到一个应用，是抱着耗费自己一生的精力来打造的。所以，你会看到我对觅觅是有多么的不舍，虽然打造觅觅的时候，自己比较懈怠，但是我在觅觅的整个设计中，是耗费了心血的。尽管我的编程思维还很受限。

• 思维的展现

  这是展现你思维能力的时候。这里设计不好，后面就会编出一些坏味道，或者粗俗点讲：就是一坨屎！一堆垃圾。而我则是那个不停制造垃圾的人。我自己对自己的标准就是：大道至简。这个自己现在还没有参透，但是有一些点我一直在践行：

  • 去除冗余

    能用一个 Entity，就不用两个。因为第二个就是垃圾；

编码阶段

这个阶段，只是一种View（如何搭建博客系统）的展现，用什么语言，用怎样的流程控制。

• 编码

  有 3 年的经验

• 单元测试

  刚刚习得，自己理解到，师父告诉我，一切以需求驱动。而编写程序的目的也是从需求出发，所以测试驱动，也可以称之为需求驱动。所以这才是软件开发的王道，不至于让自己编出不符合需求的代码。

  如果自己在编写一个function或moudule的话，有以下的三个思考：

  • 消费者是谁？

    首先要站在消费者的角度出发，如何对外提供更加舒服的接口，是否符合实际需求

  • 能提供多久？

    这里可以参考已经很成熟的软件 - windows，windows的 api几乎是马蜂窝（TODO：找例证），所以我们在编写前，要问自己，这要看这个模块将来要延展多久，并且可以向后兼容。尽可能的往后面想

这样看来，单元测试，才能让你真正从消费者的角度去考虑你的代码是否合理。

交付阶段

集成测试

部署

现在的 Sloth 还只是执行 deploy.sh (opens new window) 来进行部署，而我们要实现的是持续集成