这是我参与『第五届青训营』伴学笔记创作活动的第 1 天。
设计是很重要的一部份，在我看来它与编程是密不可分，紧密结合的。
传统的编程IDE和我们掘金上看的文章都是一维形式的排布下来；而设计则能够给我们提供二维视角，这是有助于我们思考的。
可以说，一维形式的阐述可以锻炼我们的重点把握能力。比如写一篇技术文章，一个知识点有时会牵连出许多其他的知识点内容，这些多出来的知识点内容可以让我们对目前的知识点形成一个更深刻的认识。但是，这部分的内容如果多了，就会造成原文章的知识重心发生偏移，给人凌乱的感觉。
有人会说，可以用文章摘要，或引文的形式。所以我现在阐述的情况你可以理解为是有多条独立的对主体文章中某一部份内容进行阐述的情景。简单来说，移到文章主题的左右两边，不对文章主体展示部分做修改添加，自然不会对文章内容的阐述起影响。左右两边的补充内容选择看与不看就行了，但它们的存在往往能帮我们对原文章内容理解起到帮助，只要它们是有效的。
这时我们常要做像是代码中的逻辑抽离环节的工作。这种逻辑抽离我视为就是一种内容的管理和隔离（好像说了等于没说）。可以说就是如何写好文章。如何将文章内容主旨清晰，简洁的描述出来。它也是一门学问，需要思考。
个人编程经历而言，会出现以下场景：
直接上手编程，不对内容进行预先设计，走一步是一步，想着动手编程带动自己进行思考，因为一时也不知道该怎么起手，就想着先动手做着吧。然后就遇上了 函数和变量命名规范的问题。有时为了抽象，整理代码内容结构，我们需要在抽象层面多起一层来管理下层代码。虽然写代码的过程中我能想到新出现的层的命名规范，但是在上下文查找的过程中，会耗费不可忽视的一部份时间。另外，随着复杂度提升，和代码重构的需要，且我们容易从代码层级结构中最接近底层的部分开始创建函数，声明变量等操作，导致命名规范会有不止一次的层级提升。累积起来，就是相当费时间的了。所以我建议养成设计视图编程的习惯，当然，这也是需要一定程度的技术基础养成的全局视角。
现在我基本了解前端常规的大部分基础工作流程中会用到的代码。并在一次事先进行对函数与函数需要做的内容，变量名的拟定工作进行实践的过程中尝到了甜头。我对函数需要做的内容有所理解，避免了我翻看代码上下文进行修改所花费的时间。不过，当另外我之前没考虑到的模块加入时，还是会受到一定的影响，避免这个影响需要我有更宏观的视野。另外，受到函数式编程的思想，我可以考虑从设计思想上进行研究和思考，比如遵循像函数式编程中纯函数的编程思想。完全不受外界影响，能够独立存在的模块！我在遵循这一设计思想，努力践行。另外，前人智慧可谓，比如范畴论对函数式编程的影响。
同时，因为在一开始就进行设计的思考，当我足够能用图阐述我代码需要进行的工作后，这些图本身的自述性也代替臃肿繁多的文字，用图其更能体现出内容结构和内容关键的优势，替我向他人阐述我的工作内容，并且阐述得很好，它更容易让人抓到我工作内容的重点，因为不同部分的内容已有其自己的区分度，所以才容易突出重点。
另外，项目中有不少内容，比如埋点系统等等，除了我们事先考虑到这点之外，如何将负责埋点的API和我们的DOM节点进行绑定，API的实现形式是什么样的？我们现有的应用，这单块的组件组织形式是否与API的设计形式契合，这些都需要提前进行设计。除非它像纯函数一样，能方便添加，不影响原内容。但问题是：HOW？，这需要我们有良好的设计能力，技术积累。如果我们的技术水平还不能达到规定时间内想出这个设计，那么提前设计整体框架，对我们团队是相当重要的，我们需要设计，来减少我们因为接口连接不适配而造成返工而消耗的时间。在我之前的项目实践中，这是反复出现，难以忽视的点。
同时，设计图也有助于我们与他人进行讨论。一些天才，或者熟练工，我们假设他们无论对于任何数量级的事例都能一个不拉的把握住，不需要图也可以进行工作，它们在脑海里已经有了它们工作需要进行的事项。当他们和我们讲述一些内容的时候，对于一个或多个事项需要做的内容，我们可能是能明白他们在讲什么的。但是，当事例涉及的层级多了，讲述的事例多了，我们一般人或许就要难以把握这些事例之间的关系了。这时，一个天生具有对多层级关系表述能力的示意图就很有帮助了。
