代码管理

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/NlOn7er0ixY1HO40dq5Gag 作者：孔垂亮 对于维护过多个package的同学来说，都会遇到一个选择题，这些package是放在一个仓库里维护还是放在多个仓库里单独维护，本文通过一个示例讲述了如何基于Lerna管理多个package，并和其它工具整合，打造高效、完美的工作流，最终形成一个最佳实践 背景 最近在工作中接触到一个项目，这个项目是维护一套 CLI，发到 npm 上供开发者使用。先看一张图： 项目仓库中的根目录上就三个子模块的文件夹，分别对应三个 package，在熟悉了构建和发布流程后，有点傻了。工作流程如图中所示： 使用webpack、babel和uglifyjs把 pkg-a 的 src 编译到 dist 使用webpack、babel和uglifyjs把 pkg-b 的 src 编译到 dist 使用webpack、babel和uglifyjs把 pkg-main 的 src 编译到 dist 最后使用拷贝文件的方式，把pkg-main、pkg-a、pkg-b中编译后的文件组装到 pkg-npm 中，最终用于发布到 npm 上去。 痛点 不好调试。 因为最终的包是通过文件拷贝的方式组装到一起的，并且都是压缩过的，无法组建一个自上到下的调试流程

前言 只有光头才能变强。 文本已收录至我的GitHub仓库，欢迎Star： https://github.com/ZhongFuCheng3y/3y 大年初二，朋友问了我一个技术的问题(朋友实在是好学，佩服！) 该问题来源知乎(synchronized锁问题)： https://www.zhihu.com/question/277812143 开启10000个线程，每个线程给员工表的money字段【初始值是0】加1，没有使用悲观锁和乐观锁，但是在业务层方法上加了synchronized关键字，问题是代码执行完毕后数据库中的money 字段不是10000，而是小于10000 问题出在哪里？ Service层代码： SQL代码(没有加悲观/乐观锁)： 用1000个线程跑代码： 简单来说：多线程跑一个使用 synchronized 关键字修饰的方法，方法内操作的是数据库，按正常逻辑应该最终的值是1000，但经过多次测试，结果是 低于 1000。这是为什么呢？ 一、我的思考 既然测试出来的结果是低于1000，那说明这段代码 不是线程安全 的。不是线程安全的，那问题出现在哪呢？众所周知，synchronized方法能够保证所修饰的 代码块、方法 保证 有序性、原子性、可见性 。 讲道理，以上的代码跑起来，问题中 Service 层的 increaseMoney() 是 有序的、原子的、可见的

问题： 在手机端的开发过程中，我们经常会遇见由于需求业务发生变化，导致后端的接口形式发生了变化，那么我们能不能从代码框架设计层面灵活的管理维护代码呢？ 目标：通过代码框架的设计，让开发人员能够更加好的去维护，管理每个代码的版本，让自己的项目也变得比较优美。 例如： 1：小程序的发布存在时差或者缓存，当前用户版本是1.0 你的服务端的版本可能是1.1 了，假设部分接口发生变化，会导致1.0的用户可能无法使用（如果是支付模块），让用户体验度下降 2：APP的版本更新，可能部分用户不及时更新版本，也会导致服务异常（虽然可以每次用户打开APP校验版本要求强制更新） 问题归类： 变化形式有如下2大类种，有几个小类别 接口形式发生变化 接口入参个数调整，由以前的1个，2个 变成了N个 接口请求发生发生变化，由GET换成POST 或者POST换成GET 代码层逻辑发生变化 查询的业务方法（Service层）发生 了变化 查询的数据库的Mapper 发生了变化 在开发的过程中，还有很多很多各种各样的问题，我只列举我遇见到的问题，如果有大神补充的，我也会及时更新上去。 解决思路： 针对目前列出2个大类，我自己想到了一部分自己初略的思路；（从外往内的整理思路来解决的） 问题1.接口形式发生变化时，参数个数发生了变化，这个时候，我们会使用重载的方式来通过参数的个数来控制接口不同的请求业务逻辑；

软件项目开发流程 需求分析 ----》 概要设计 ---》 项目计划 ----》详细设计---》编码测试 -----》 项目测试 ----》调试修改 ---》项目发布----》后期维护 >需求分析 ： 确定用户的真实需求 　　>>1. 确定用户的真实需求，项目的基本功能 　　>>2. 确定项目的整体难度和可行性分析 　　>>3. 需求分析文档，用户确认 >概要设计：对项目进行初步分析和整体设计 　　>>1. 确定功能模块 　　>>2. 进行可行性分析 搭建整体架构图 　　>>3. 确定技术思路和使用框架 　　>>4. 形成概要文档指导开发流程 >项目计划 ： 确定项目开发的时间轴和流程 　　>>1. 确定开发工作的先后顺序 　　>>2. 确定时间轴 ，事件里程碑 　　>>3. 人员分工 　　>>4. 形成甘特图和思维导图等辅助内容 >详细设计 ： 项目的具体实现 　　>>1.形成详细设计文档 ： 思路，逻辑流程，功能说明，技术点说明，数据结构说明，代码说明 >编码测试 ： 按照预定计划实现代码编写，并且做基本检测 　　>>1. 代码编写 　　>>2. 写测试程序 　　>>3. 技术攻关 >项目测试 ： 对项目按照功能进行测试 　　>>1. 跨平台测试 ，使用测试 　　>>2. 根据测试报告进行代码修改 　　>>3. 完成测试报告 >项目发布 　　>>1.项目交付用户进行发布 　　>

api:http://flywaydb.org/getstarted/firststeps/api.html 1. 引言 想到要管理数据库的版本，是在实际产品中遇到问题后想到的一种解决方案，当时各个环境的数据库乱作一团，没有任何一个人（开发、测试、维护人员）能够讲清楚当前环境下的数据库是哪个版本，与哪个版本的应用相匹配，如何升级到与新版本的应用相匹配。 想到管理数据库版本时，先是心底形成了一个初步的解决方案，大致是通过数据库中的某张表来记录数据库表结构的历次更新与对应版本，在每次数据库表结构调整时除了提供库表更新sql ，还必须提供更新记录与对应版本的sql，以帮助维护数据库版本信息，并在遇到问题时提供相关的排查依据。 后来据此思路在网络上搜索了一把，结果搜到Liquibase （另一款开源数据库版本管理工具）。在学习了解Liquibase 的时候，经高手介绍又了解到了Flyway 这个项目的存在。经过一番了解，最后我们选择了Flyway ，主要原因是Flyway 支持sql 脚本，而Liquibase 只支持XML 方式的数据库表结构定义，虽然在新的版本中号称在XML的数据库表结构定义方式中支持了sql 脚本。 虽然Flyway 的中文文档近乎为零，英文文档也凤毛麟角，但它却是我们最理想的数据库版本管理工具，它不但支持sql 脚本，还支持Java 代码直接操作数据库

持续集成之代码质量管理-Sonar [三] Sonar 介绍 Sonar 是一个用于代码质量管理的开放平台。通过插件机制， Sonar 可以集成不同的测试工 具，代码分析工具，以及持续集成工具。与持续集成工具（例如 Hudson/Jenkins 等）不同， Sonar 并不是简单地把不同的代码检查工具结果（例如 FindBugs， PMD 等）直接显示在 Web 页面上，而 是通过不同的插件对这些结果进行再加工处理，通过量化的方式度量代码质量的变化，从而可以方 便地对不同规模和种类的工程进行代码质量管理。 在对其他工具的支持方面， Sonar 不仅提供了对 IDE 的支持，可以在 Eclipse 和 IntelliJ IDEA 这些工具里联机查看结果；同时 Sonar 还对大量的持续集成工具提供了接口支持，可以很方 便地在持续集成中使用 Sonar。 此外， Sonar 的插件还可以对 Java 以外的其他编程语言提供支持，对国际化以及报告文档化 也有良好的支持。 Sonar 部署 Sonar 的相关下载和文档可以在下面的链接中找到： http://www.sonarqube.org/downloads/ 。 需要注意最新版的 Sonar 需要至少 JDK 1.8 及以上版本。 上篇文章我们已经可以成功的使用 git 进行拉去， Sonar 的功能就是来检查代码是否有 BUG。除了

一、 无服务器（Serverless）计算是什么 云计算涌现出很多改变传统IT架构和运维方式的新技术，比如虚拟机、容器、微服务，无论这些技术应用在哪些场景，降低成本、提升效率是云服务永恒的主题。过去十年来，我们已经把应用和环境中很多通用的部分变成了服务。Serverless的出现，带来了跨越式变革。Serverless把主机管理、操作系统管理、资源分配、扩容，甚至是应用逻辑的全部组件都外包出去，把它们看作某种形式的商品——厂商提供服务，我们掏钱购买。过去是“构建一个框架运行在一台服务器上，对多个事件进行响应”，Serverless则变为“构建或使用一个微服务或微功能来响应一个事件”，做到当访问时，调入相关资源开始运行，运行完成后，卸载所有开销，真正做到按需按次计费。这是云计算向纵深发展的一种自然而然的过程。 Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态（Stateless）、暂存（可能只存在于一次调用的过程中）计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作云端或本地的服务器或运行时。Serverless真正做到了部署应用无需涉及基础设施的建设，自动构建、部署和启动服务。 国内外的各大云厂商