看过就忘？学完就丢？因为你没有理清编程思路！

作者 | LGD_Sunday

来源 | 慕课网（imooc.com）

前言

如果大家在平常的开发之中，遇到过在面对一个功能需求的时候，不知道从何入手，从何开始的情况的话，那么本篇文章可能会对你有所帮助。

编程思路是一个挺大的概念，如果想要完全掌握它，那么需要我们长期的积累，来把思路分析的方式变成一种本能。这是一个长期积累的过程，没有办法一撮而就。

而对于我们本篇文章来说，我们期望能够做到的是：通过本篇文章中的思路模式，来帮助大家逐步培养自己的编程思路，直到把它变成真正自己的东西。

什么是编程思路

在文章开始之前，对于什么是编程思路，我觉得还是需要进行一下介绍，以便大家都可以达成一个统一的认知。

那么什么是编程思路呢？我认为编程思路其实表示的是两个概念，也就是 编程 和 思路 。

所以说，如果要解释什么是编程思路，那么我们就需要从这两个概念上去说。

什么是编程？

首先我们来看什么是编程。对于我们这些开发人员来说，我们的工作就是编程，也就是说我们每天工作的过程就是编程。

那么我们编程的目的是什么？或者说我们通过编程想要达到的结果是什么？

有些同学可能会说，我们编程就是想要赚钱，或者我们编程就是需要完成一个程序。这些都没错，但是却并不全面。我们编程的最终目的其实就是：为了解决某个社会现有的问题。

我们通过编程，制作出一个程序，希望可以解决某个社会中现有的问题。这就是我们编程的一个最终目的。

我们给编程一个定义，那就是：

为解决某个问题而使用某种程序设计语言编写程序代码。

什么是思路？

了解了什么是编程之后，我们来看什么是思路。

我们知道编程其实就是：为解决某个问题而使用某种程序设计语言编写程序代码。 那么对于程序来说，他就是由一个一个的功能点来组成的，我们去实现每一个功能点的时候，对于这个功能点，我们去实现的一个思路，那么就是编程的思路。

那么把这两个概念组合到一起，我们来定义一下什么是编程思路。所谓编程思路就是：

为解决某个问题而使用某种程序设计语言编写程序代码，并最终得到相应结果的过程就是我们的编程思路。

对于编程来说，是否有固定的思路模式？

PS: 事例以 Vue + Vue 全家桶为技术背景。

对于大多数没有豪华学历背景的人而言，在刚刚踏入这个行业的时候（title：软件开发助理、初级软件开发工程师），面对的可能都是各种小厂，以及不专业的功能需求文档。那么当软助遭遇天坑需求，我们应该如何尽量避免悲剧呢？

明确了编程思路的概念之后，那么对于编程来说，是否有一个固定的思路模式呢？也就是说，是否有一种固定的模式，我们按照这种模式来做，那么它就可以帮助我们来把我们的思路捋顺呢？我们先来看一个事例。

假如说，公司想要开发一个商城的系统，而对于这个商城的系统来说，它存在一个购物车的功能，这个购物车的功能就是我们需要开发的功能。

而对于这个购物车的功能来说，我们现在只知道我们需要开发一个购物车，而对于该购物车它应该具备什么样的业务逻辑，我们一无所知。

面对这样一个需求，对我们来说，确实糟透了。

那么面对这么一个工作，我们应该怎么去做呢？大家设身处地的想一下，如果大家在工作中，遇到了这么一个任务，我们应该如何去做？

1. 明确功能需求

首先对于任何一个功能来说，如果我们想要去实现它，那么我们必须要做的一点就是，我们必须要明确他的功能需求。

对于该购物车功能也一样，因为目前我们所知有限，如果我们想要把这个功能去实现，那么我们就必须要明确这个功能的详细需求。

而如果想要了解他的详细需求，那么最好的一个方式就是：直接去找功能对应的产品经理去确认需求。这是最简单，最方便也是最靠谱的一种需求确认方式，通过与产品经理的沟通，我们可以准确，快速的确认功能具体需求。而如果因为各种各样的原因，产品经理无法为我们提供准确的功能需求的话，那么我们怎么办呢？

那么在这个时候，我们所能够做的，就是：结合项目的整体目的，通过市面上广为人知的类似项目的类似功能，来推断该功能的具体需求。 以商城系统的购物车为例，目前市面上有很多类似的项目，广为人知的项目也有很多，比如：淘宝、京东、拼多多等等。并且这些项目也都存在购物车的功能，通过了解这些项目的购物车功能，那么我们可以大致的推断出我们所需要开发的功能应该具备哪些能力。

如果市面上也不存在类似项目的话，那么我们唯一能做的就只能是凭借自己的理解和与同事的沟通来确定功能需求了。这样做也是最被逼无奈的一种方式。

2. 开始功能开发

调研之后的购物车需求：

1. 购物车以列表的形式展示已加入的商品，每个 item 中展示商品名称、价格、购买数量，标记选中状态的 check 按钮。

2. 购物车底部展示处于选中状态下的商品总金额（商品价格*购买数量），未选中的不参与统计。

3. 在商品详情中点击加入购物车按钮，商品加入购物车，同时页面跳转至购物车页面。

4. 加入购物车时，如购物车中不存在本商品则购买数量为 1 。如已存在本商品，则在原数量上 +1 ，不展示新得商品 item 。

5. 当商品 check 状态发生变化的时候，则统计总金额数据，应实时变化。

在明确了功能需求之后，接下来我们需要做的就是对功能进行开发。在进行功能开发的时候，最大的变数就是工程师本身对于技术的掌握能力了，一个高软和一个软助因为本身对技术的掌握能力不同，那么他们在同时进行软件开发的时候，所走的路，所趟的坑也都完全不同。

那么假如我们刚刚踏入软件行业，仅掌握基础的技术能力，对所使用框架仅了解基础用法，对核心API也没有完全掌握，并且没有成型项目的开发经验的话，那么在面对这么一个购物车功能和自调研需求的“杯具”情况下，我们应该如何去着手开发呢？

对于这么一种情况，那么我们很有可能就会处于一种不知如何下手的状态，如果我们真的面对这么一种状态的话，那么我们所需要做的第一件事就是尽快突破这种状态，也就是 “写下第一行代码” 。

写下第一行代码

很多同学可能会说：我就是因为不知道怎么去写，所以才不知道如何下手，你让我写下第一行代码，我怎么去写啊。

如果面对不知如何下手这么一种情况的话，那么大家可以尝试使用“倒推”的方式对需求进行解体。

倒推：以完成之后的功能为起点，对该功能进行逐步拆解，从而分析出对于该功能应该如何实现。

如何进行“倒推”呢？我们以梳理出来的需求为例，看一下如何去进行“倒推”。

需求：

购物车以列表的形式展示已加入的商品，每个 item 中展示商品名称、价格、购买数量，标记选中状态的 check 按钮。

倒推流程：

• 根据你在前面的分析或者现有的设计图，得到购物车页面完成之后的样式。假设样式如下

• 对完成之后的 样式 进行拆解。比如既然为购物车页面，那么它必然存在一个购物车的页面组件shopping.vue。
• 在该页面之中，它存在着多个商品的 item ，这些商品的 item 重复循环展示，并且拥有自己的业务逻辑（check选择、数量变化）。那么我们是不是还需要拥有一个表示商品 item的组件GoodsItem.vue，并且在 shopping.vue 中通过 v-for 的方式，来把它循环展示。

这就是我们对第一个功能进行的倒推，那么根据我们刚才的倒推分析，我们应该如何去写第一行代码呢？

1. 首先我们需要创建两个vue的组件，分别用来表示 购物车页面 和 商品item。
2. 然后对于购物车页面来说我们就需要完成它的基础UI布局，并且使用v-for的方式，根据购物车商品数据来循环展示商品item组件。

通过这样一种方式，我们就可以完成我们的第一行代码编写。也就跳出了不知如何下手的一个状态了。

整理复杂业务逻辑

如果说在 “写下第一行代码” 中它能够帮助到你的话，那么你应该可以很快的根据 “倒推” 的方式来梳理出剩余的需求，并且至少可以完成剩余需求的大部分基础代码。

那么在完成了大部分的基础代码之后，紧接着大家可能遇到的问题就是对于项目中 复杂业务逻辑 的处理了。

我们还是以在上面整理出来的需求为例，来看一下，当我们在面对项目中 复杂业务逻辑 的时候，我们应该如何来梳理我们的编程思路。

明确目前代码：

购物车页面组件 shopping.vue ，页面中通过 v-for 循环展示商品item 组件。

需求：

购物车底部展示处于选中状态下的商品总金额（商品价格*购买数量），未选中的不参与统计。

当商品 check 状态发生变化的时候，则统计总金额数据，应实时变化。

对于 “复杂的业务逻辑” 来说，我们依然可以采用 “倒推” 的方式进行处理。同样我们依然先明确项目最终的展示效果。

这就是我们最终项目的一个展示效果。我们通过 “倒推” 的方式来把这两个需求进行一个分析。

1. 首先根据我们目前的代码，我们已经把 shopping.vue 和 GoodsItem.vue 分成了两个组件。
2. 当 GoodsItem.vue 中的 check 状态发生变化的时候，shopping.vue 中的统计总金额也会跟随发生变化，所以我们需要在 GoodsItem.vue 中去监听 check 的变化事件，当 check 的状态发生变化的时候，需要通过 $emit 通知到它的父组件也就是 shopping.vue。
3. 只有处于选中状态下的商品才会参与统计，所以我们在GoodsItem.vue的组件中通过 $emit 通知父组件的时候需要传递当前的 check 状态。
4. 而对于需求中的父组件也就是 shopping.vue 来说，它在监听到了 GoodsItem 给过来的通知之后，所需要做的就是根据携带的 check 状态来进行对应的计算了。

通过这样的一个 “倒推” 逻辑，我们就可以大体的把需求的基本实现思路给整理清楚了

功能实现中遇到不会的知识点

通过 写下第一行代码 和 整理复杂业务逻辑 这两节，相信大家已经可以初步的处理一个功能的实现了。

但是在功能实现的过程中，却很有可能会遇到各种我们不了解的 API 或者 知识点，这些不了解就很有可能会扰乱我们已经整理好的思路，并且如果一直没有解决方案的话，甚至可能会导致我们对之前的思路产生怀疑（PS: 之前是不是想错了）。

最终导致我们最后的实现并没有按照我们的思路来走，而写出逻辑混乱的代码，严重的甚至会让我们把之前的思路全部推倒重来。

那么当我们在功能实现中遇到不了解的API 和不会的知识点的时候，我们应该怎么去做呢？

当我们遇到不了解的API时

当我们遇到不了解的API时（比如我们不知道 split 怎么使用，或者我们不知道如何把字符串分割成数组），其实这只是一些小的问题，至少它并不会影响我们的整体思路。而解决的办法也有很多我们可以直接去 Google 、百度 或者直接去查他们的 API 文档，这些方式都可以帮助我们很快的去解决对 API 不了解的问题。

当我们遇到不会的知识点时

而当我们遇到不会的知识点时（比如我们不知道如何在 vue 中去进行组件之间的通讯、过渡动画、状态保存等等），这样的一整个的知识点的时候，才会有一点麻烦。

那么当我们遇到不会的知识点时，我们应该如何处理呢？我们把基本的处理方式给大家列举一下（因为对于知识点来说，太多太杂，如果通过单一事例可能会比较片面没有办法带来好的效果）。

1. 如果可以描述清楚知识点内容的话，那么可以通过搜索引擎或者技术论坛进行搜索。

2. 如果无法描述知识点内容的话，那么同样可以采取 “倒推 + 拆解” 的方式来处理。通过对一个完整的知识点拆解的方式，来把一个完整知识点拆解为多个具体步骤，然后分别在执行这里的 1、2 操作。（比如组件通讯可以拆解为：1、子组件如何通知父组件。2、父组件如何接收子组件发送的通知）

总结

最后我们回到最初的议题：对于编程来说，是否有固定的思路模式？ 经过我们本章的内容，大家想一下，这个固定的思路模式是否存在呢？

答案是存在的。整理出的具体思路模式如下：

1. 明确功能需求。无论是通过与产品经理沟通还是去做自调研，明确功能需求 都是我们进行开发变成的第一步。
2. 开始功能开发。明确了功能需求之后，我们就需要去开始功能开发。
3. 如果我们在功能开发的时候，不知道如何去入手，那么我们就需要尽快突破这种状态，也就是**“写下第一行代码”**。
4. 在 “写下第一行代码” 的时候，如果不知道如何写，那么可以通过 倒推 和 “拆解” 的方式，来帮助我们梳理思路。
5. 在当我们遇到复杂业务需求的时候， 倒推 和 “拆解” 的方式依然可以帮助到我们。
6. 而当我们按照思路编写程序的时候，如果遇到不会的知识点，不要着急否定思路，先去尝试看看有没有解决的办法。比如可以通过搜索引擎，或者对复杂知识点进行 倒推 和 “拆解”的方式来解决。

希望上面的这六个步骤可以对大家有所帮助，如果大家有任何疑问或者困惑可以留言，我们随时沟通。