飞道软件工厂

插件式开发

串讲内容

总体架构讲解

微核架构

功能通过引入原子操作来实现

原子操作使用函数实现，技术实现简单，接入不受限

原子操作彼此分离，按需引用，不会造成系统臃肿

微服务架构

服务使用http(s)协议，易于进行分部式部署。

不命令理念

我们在项目开发中总结出一套不命名的理念，即如项目名称，变量名称，文件名称，数据表名称，字段名称等等需要命名的地方均不进行命令，直接使用前缀加数字的方法，一般我们用3位到6位数字。这样解决了一些问题

  1. 中英文问题
  2. 命名困难问题
  3. 路径空格问题
  4. 代码规范问题

但也产生了新的问题

  1. 无名称没有意义，不方便开发人员查找

这其实可以通过一系列方法来弥补

  1. 建立一个文本文件用来记录页面文件名和真实名称的对应。
  2. 在代码中添加好中文注释。
  3. 数据表和字段的别名设置好

注意，因为这三项均没有强制规定，这三项容易被忽略，需要各个项目的负责人把好关。否则在项目维护的时候会有难度，反之，项目维护比纯代码维护会更加容易。一种技术能不能得到好的效果，主要还是看用它的人，而不是技术本身。

事件驱动

  1. 用户事件
  2. 机器事件

这是我们分析设计应用和进行开发的一个基础逻辑，它非常符合人的直接想法，像我进行什么动作然后系统完成一个什么样的具体功能。机器事件解释一下，它包括初始化事件或是定时器事件等非用户直接在界面上触发的事件。

函数式

原子操作使用函数实现，实现简单，学习成本低，易上手。但是纯粹的函数式过于极端，实现难度也相当大，且并不非常有必要。

按项目类型划分

  1. web
  2. 各平台小程序
  3. 原生app
  4. h5应用

web应用指通过浏览器可以访问的可以呈现图文等内容的应用，除了浏览器，不需要任何工具即可使用，而浏览器是几乎所有带操作系统的终端设备上标配的应用程序，所以它的最大的优点就是方便易用，一个超链接就可以带你到世界任意一个角落。 但也正是web应用这种优势使得web应用非常多且质量不一，浏览器给它的功能限定了一个范围（虽然html5规范出来之后这些功能得到了增强），使得web应用不能为所欲为，有一些功能就无法得以实现（比如你希望在web应用中列出你电脑操作系统中的文件），在浏览器本身的沙盒会给web应用进行这些限制，使得web应用不会危及你的电脑的系统安全。如果在以后的某一天加密传输技术完善的话，不排除可将h5功能增强到与app能力相同的可能，而彼时，app或将全面下架。小程序事实上可以看作是这种技术全面铺开之前的一种初期阶段。它是介于web和原生应用之间的一种形态。 app指独立的应用程序，直接调用操作系统api，进行界面展示和功能实现。在windows和Linux上表现为视窗或命令行程序。智能手机普及以来，android和ios成为移动应用的两大主力阵营。由于其便于携带的特性以及相对便宜的价格倍受世人青睐，已经成为当今事实上的app的主流。相比较web应用来说，app属于富客户端应用，其网络延迟小，用户体验好。但是前提需要进行软件安装和根据不同情况进行软件升级，而web应用开箱即用，零负担。

这里需要提及h5应用，其在开发方式和实现上，与web基本一致，而在界面展示上，又绝类于移动app应用。我们在技术实现时，就存在两种不同的划分方式，从而导致其技术实现方式也会有非常大的差别。对于h5应用的划分方式，需要根据其实际应用场景进行划分，不能一概而论。

按开发端点划分

  1. 前端 页面/各类app

无论是web应用或是app小程序应用，我们均将其称之为页面，前端开发的大部分工作进行用户界面的调优，是一款的脸面。 虽然web页面也有富客户端的方式（典型的就是spa单页面应用），但这种方式给用户体验不太好，初始加载内容过多，加载时间过长，容易造成用户的反感。但它的好处是初始加载完毕之后的操作就会很流畅，因其将加载过程集中到了首次展示之前，它还有一个最大的缺点就是不容易进行链接分享，超链接是web应用的一个非常大的优势，而富客户端往往阉割了这些。瘦客户端的好处就是单次加载快，但每个操作经常会需要再次进行加载操作，在网络差的条件下，瘦客户端的弊端非常明显。但技术的发展使我们可以结合这两者的优点，使web应用可以达到最完美的一种状态。

  1. 服务接口 RESTfulapi

如果对外提供接口，可以很方便以这种方式提供，对内则个人不推荐这样做，因为这样做进行全栈开发的话，很难与页面调用产生一种必然的联系，使逻辑更分散，从而系统开发和维护变得困难。

面向对象/面向过程编程

面向对象是软件开发思想，也是一种技术实现手段，几乎所有高级语言都有class（类）这种概念，甚至像java和c#这一类开发语言将这种思想变成了极致，可以说一切皆为类，哪怕是开发人员最熟知的Hello World。我这里只谈编码阶段的技术实现。由于类相关概念较多，造成学习难度大，成本高，事实上，像Java中的类已经抛弃掉了类的多继承这种复杂的特性，这恰恰说明了对于一种技术，我们不应过度使用，只在适合的地方使用它就好了，这世上没有单一的一种全能的技术解决所有问题。

JavaScript/Typescript这个语言有一个非常大的缺陷，就是它的类其实并不纯粹，this的陷阱也坑掉了很大一群人，但这个语言却是目前最好的（这是因为它的被支持程度是最好的）开发web和app的语言（所有小程序都选用了这种语言，不是没有原因的）虽然我们在开发过程中避免不了使用类的概念（比如组件就是类，它会有属性和方法「话说方法事实上也几乎被阉割掉了」），但我们可以使用人为的手段降低学习成本和系统维护成本，幸运的是，在我们在页面开发时代码中几乎不需要写类，页面中的组件我们也使用函数组件来实现，我们不对类进行多层的继承和派生（代码中没有类，也就不需要也不可能进行继承和派生了），我们只使用函数（有些地方被称为api）来实现系统功能（在英语中的函数function就是功能的意思）。而函数只是面向对象编程中的一个子集，它的学习成本要低得多。那么函数可以实现所有功能吗？当然可以，甚至在某些方面函数的表现更加出色。

我们并不是完全摒弃面向对象，事实上，在业务分析和开发思想上，面向对象的思想还是非常有必要的，比如前面提到的页面，它就是一个对象，但面向对象编程在一些人心目中其实就是面向类编程，需要说明的是，面向类编程属于面向对象编程，但面向对象编辑并不单纯就是面向类编程。我们在页面中还会使用各种组件，每一个组件（虽然我们用函数组件写法去写它）也都是一个对象。

next.js

任何了解过express.js的人上手next.js都不会有太大的困难，因为它们的编码方式非常相似。

路由

系统中定义的各种供前端页面（或小程序）访问的api

中间件

有些功能相对通用（比如为options请求返回cros请求头等），可将其作为中间件来使用。

ssr

  1. 静态化

    可以将某些页面静态化，即在编译阶段就将其生成为html页面，这样在浏览器请求页面时，就不需要读数据，生成html，大大加快服务器响应效率，这适用于数据不变（或在某一时间段不变）的情况，比如系统中的资讯信息。典型的还有博客文章，新闻等。

  2. 服务端渲染

    有些页面（也可能是页面中的部分内容）需要在服务端渲染成为html之后返回给浏览器（有时候它可能会是搜索引擎的爬虫），这主要解决两类问题，一是seo，一是对于低端机型加快页面的展示速度。

  3. 客户端渲染

    客户端渲染指页面中没有数据，浏览器请求到空的页面结构之后请求服务器获得数据，然后再使用这些数据生成页面的实际内容并使用dom操作将这些内容填充到页面上。这种适用于页面数据需要实时获取的情况。

taro

统一客户端开发模式，learn once, write everywhere.与之同级别产品remak和uniapp.

详细技术点讲解

运行环境

  1. docker

    某些基础服务需要启动一些服务，使用docker我们可以非常方便地完成这些工作。

  2. nodejs

    客户端的脚手架全部基于nodejs的，我们一般不用关注其内部实现。

    服务端next.js的东西也是跑在nodejs里的，所以，不论是开发环境还是运行环境，都需要有nodejs的支持。

  3. npm

    执行的一些命令是在npm的package.json中配置的，依赖的原子操作也是在package.json中记录的，了解npm有利于进行开发工作。

开发环境

  1. vscode多行编辑，配置，提示，自动完成
  2. vscode扩展插件
  3. 命令行（开发，编译，代码提交等等）

开发语言

TypeScript简介

函数

函数function,本意就有功能的意思。一个应用就是各种各样功能的组合体。

函数名

参数

返回值

this

JavaScript两个最严重的缺陷

  1. this问题

    this的问题在于在Typescript/JavaScript中，this有可能是任何东西，不一定是调用者。

  2. 弱类型

    弱类型是无法维护大型复杂项目的一个很大的原因。依靠代码规范虽然能避免一些问题，但依然很难进行大型复杂项目的开发。

接口

接口是一种对数据（事实上不一定是数据，之所以这里把它限定到数据这一层，是因为只有在这一层它最有用，而其它场景应该尽量避免去用这经。）的组成结构的描述，是强类型语言的一个比较重要的特征。

组件

  1. react

    react和vue的差别并不算太大，但react中的模板相对vue来说要好得多，vue中的模板就是普通字符串，无法做到类型的检测（相当于从TypeScript回到了JavaScript）。学徒有幸同时进行过两种不同方式的开发，对于两种不同的组件开发方式有比较深的感悟。因其技术本质实际上都在走向大同，我更加关注两个方面：1. 可复用的组件库。2. 代码的可维护性。相比较而言，react稍胜一筹。

  2. 页面组件

    一个页面相当于一个大的组件，当然这个组件中可以引入其它的组件，比如header,footer等。

  3. 项目内公共组件

    一个项目中经常会用到一些公共组件，比如上面提到的header和footer部分，以及有些项目中会有左侧菜单栏等，都可以将其制作为公共组件，在需要的页面中引用该组件。

  4. 公共组件

    还有一些组件，比如按钮，日期，甚至省市区选择器等，其实也可以封装成为公共组件，供多数项目进行复用，当然，编写公共组件要比项目中的组件的要求要严格得多。

api编写

  1. http请求

    1. taro框架中封装的APIrequest，同时支持多种平台。，也可在项目中对它进一步进行封装，以达到在项目中方便复用的目的。
    2. web类型项目中，发出ajax请求使用fetch即可。
    3. 在web项目中，为了达到更优的性能，我们还会使用到swr，减少对服务器的重复请求。

  2. 跨域

    web项目中基本不存在跨域问题，在进行各种app的开发时，即使我们有时候最终终端产品不包括h5，但在项目开发时，h5页面是开发效率最高的（有些调用原生页面不在此例，仍然必须在各平台开发工具中进行调试），所以我们在项目中，会在h5平台下进行大量的开发调试工作。这时，因为h5页面相当于是纯前端的应用，调试使用的端口与后端开发使用的端口不一致，至少在开发阶段，就需要进行跨域访问。

  3. 数据库操作

    我们编写后端api时，绝大多数业务逻辑是数据库操作。

  4. 身份验证，权限

    用户身份验证有多种方式：手机验证码，用户名密码，邮箱，第三方授权等等。

组件库

  1. taro组件库
  2. taro-ui

  3. 其它组件库

    只要是没有dom操作的react组件库都可以使用。这是因为在小程序等端点，是没有真实的dom可以操作的。

api/原子操作

  1. taro api
  2. 原子操作