编码

了解需求
任务拆分
获取最新代码
运行测试
编码
重构
提交代码
运行测试
本地提交代码
等持续集成通过测试

SMART原则

  1. 具体的
  2. 可以衡量的
  3. 可以达到的
  4. 和其他目标具有相关性
  5. 具有明确的截至日期

编写测试用例的好处

  1. 为重构代码打下基础,如果你对代码重构有一定的了解,就会有一些体会,当我们进行代码重构时,最害怕的事情就是修改的代码会破坏已有的功能。测试在这时可以保证现有的代码功能正常。覆盖度够高
  2. 编写出长度短小的代码。复杂的代码不容易测试。拥有相当高的测试覆盖率的代码也不会过于复杂。对代码的嵌套语句都需要有相应的测试。
  3. 帮助我们找到代码中的bug,在编写单元商量试时,我们测试的用例,都是对照某一种情况下而编写的。对不同的转换都要有对应的测试来覆盖。
  4. 保证现有代码的功能都是正常的。当我修改代码时,可能就能破坏了现在有的功能,但我可能测有意识到这个问题。

测试金字塔

  1. UI测试:(功能测试,端到端测试,验收测试)只关心它在功能上是否正确,是否正常的响应对应的行为。
  2. 服务测试:测试接品层是否可以正常返回数据,第三方依赖是否会有问题。Mock Server来测试服务返回的数据是否可用。
  3. 单元测试:保证基础函数可以工作,当单元测试达到一定的覆盖率时,我们的代码就会变得更健壮。因为我们要保证代码都是可测折,代码间的耦合度都会降低。TDD会促使们写出短的代码。单元测试可以帮助我们在未来重构代码。在测有文档不完整的开源项目时,了解这个项目某个函数的用法就是查看其测试用例(Test Case)直观的理解程序的API.
2017/12/11 posted in  全栈应用开发

构建过程

编译
对于JavaScript,现代浏览器的支持程度参差不齐,需要在开发阶段使用ES6,在开发完成后需要对ES6的源码进行编译,这里大部分使用Babel去完成,Babel,通自Babel-env-parset来读取borserList浏览器数据占比,合理的进行编译。但它只负责语法层面,对于新的API你需要使用profilly。

代码风格检查
开发过程中,开发者的编码风格不相同一,通常要制定一定的规范,如4空格缩进等等,提高工程的可维护性。在这里我们一般使用ESlint来做这件事情,针对核心开发者,我们可以自定义ESlint的配置,达到团队自定一的统一。
单元测试
作为测试中最基础的也是最快的测试,这个测试将集中于测试单个函数是否正确。
功能测试
保证一个功能依赖几个函数组合在一起也是可以工作的。
Mock Server:
依赖第三方服务的时候,需要一个Mocke Server来保证功能代码可以被独立测试
集成测试
集成前端,后端,运行起最后的版本进行测试。
打包
这里只针对后端项目,包括NodeJS的项目,如果是纯前端则直接上传到CDN即可。

2017/12/6 posted in  全栈应用开发

微服务架构与实战

微服务的概念

微服务架构是一种架构模式,它提倡将单一应用程序划分成一级小的服务,服务之间互相协调、相互配合,为用户提供最终的价值。每个服务运行在其独立的进程中,服务与服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的 RESTful API)。每个服务都围绕着具体的业务进行构建,并且能够被独立地部署到生产环境、预发布环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根所业务上下文,选择合适的语言、工具对其进行构建。
<!-- more -->

微服务的的拆分

业务独立性
团队自主性
单一职责
轻量级通信
独立性
进程隔离

容器虚拟化技术

Docker是一个开源的应用容器,允许开发者将他们的应用以及依赖,打包到一个可移植的容器中,然后发布到任何装有Docker的Linux机器上。

微服务的本质

  • 服务作为组件
    • 提倡使用组件的方式,组应用模块化并为期构建相对独立的单元,传统实现组件的方式是隔离独立 的部分或抽取公的部分,构建共享库,从而达到解耦和复用。和语言相关和平台相关
  • 团绕业务组织团队
    • 提倡以业务为核心,按业务能力来组织团队,团队中的成员具有多样性的技能
  • 关注产品而非项目
  • 技术多样性
    • 倾向于采用统一的技术平台或方案来解决所有的问题,并不是每个问题都是钉子,也不是每个解决方案都有锤子。解决方案也应该具有针对性,针对不同的业务场景产出不同的技术方案。
  • 业务数据独立
    • 自主管理期相关的业务数据,提代业务数据接口集成,能够随着业务的发展,选择更合适的工具管理或者迁移业务数据
  • 基础设施自动化
    • 健康监控,错误回滚,日志分析,运维成本增加
  • 演进式架构
    • 随着业务的发展而不断发展,随着业务的需求变化而变化,单块架构系统时,会面临非常多的技术选型。
    • 单块架构设计构建一个大而全,无所不能的平台,但在技术发展如此之快的今天,单一的技术平台已经无法适应市场的快速变化,不断尝试新的架构设计。真正做到业务驱动架构,架构服务于业务。
Read more   2017/12/6 posted in  微服务架构