公司金融开发组2017年度总结

本文主要回顾了2017年项目组的工作概况、成员构成以及当时采用的项目开发流程、经验教训和2018年改进建议。

我在2018年1月时写了此文档，并在整个分公司技术部内(不仅是组内)进行了阐述和讨论。

1. 总述

2017年项目组负责的项目：Token、ACC、文交所（WJS）、吉利钱包(Geely)，创行代付(cxdf)。
项目组成员5名

2. 2017年项目开发流程回顾

2.1. 需求分析

输入：

• 组内讨论：开发团队内部进行的需求分析讨论，确保对项目的基本要求、开发难度、技术可行性等方面达成共识。
• 跟产品讨论：与产品经理或业务方沟通，明确产品的功能需求、用户体验要求以及商业目标等。
• 多论PK：多方参与讨论，确保需求的准确性和完整性。这一环节也可能涉及对不同需求方案的优劣分析与选择。

输出：

• 需求文档：对项目需求进行详细的记录，涵盖功能需求、技术需求、非功能需求等，作为后续开发和设计的基础。
• 功能清单：列出具体的功能模块、功能点以及功能的优先级，作为开发的参考依据。
• 开发排期：根据需求和功能的复杂度，制定开发进度安排，明确开发周期、资源分配等。

2.2. 设计

输入：

• 需求文档：设计阶段的主要参考材料，确保设计符合需求文档中的功能描述和约定。

输出：

• 活动图 - 核心功能：活动图用来表示系统的动态流程，主要针对核心功能的执行流程进行描述，帮助开发人员理解功能实现的逻辑。
• 部署设计：部署方案的设计，包括服务器环境、网络架构、应用部署方式等，确保系统的稳定性和高效性。
• API设计：详细的接口设计，包含API的请求方式、输入输出参数、异常处理等，确保各模块之间能够顺畅交互。
• DB设计 - PowerDesigner：数据库设计方案，使用PowerDesigner工具进行数据表、关系、索引等的详细设计，确保数据库结构合理、查询效率高。

2.3. 开发

(1). 代码库：开发库、生产库。
代码先提交到开发库，开发库当主干开发。
需要上线时，开发库代码合并到生产库。

(2). 框架搭建
在开发初期，进行项目框架搭建，确定项目的技术栈、基础架构和开发规范，为后续开发工作提供基础支撑。

(3). 代码编写
进行checkstyle、findbugs检查(本机手动检查，Jenkins自动检查)
Jenkins持续集成：svn有更新，会主动构建部署到到测试环境。

(4). 代码review
代码提交到SVN后，使用Review Board进行代码审查。通过团队成员的审查，确保代码符合编码规范、没有遗漏的功能实现，并进行必要的优化。

(5). 构建部署
使用Jenkins进行持续集成，在每次代码更新后，自动构建并部署到测试环境，确保新版本的功能和修复能够及时验证。

2.4. 测试

(1). 网络部测试环境搭建

(2). 测试环境部署
开发人员将代码部署到测试环境中，进行初步的测试验证，确保系统的基本功能正常。

(3). 开发人员测试环境联调
开发人员与测试人员合作，进行开发环境与测试环境的联调，确保在不同环境下的功能一致性和稳定性。

(4). 测试部测试
测试部门对系统进行全面的功能、性能、安全等各方面的测试，确保产品在正式上线前不会出现重大问题。

2.5. 上线

流程：
(1). 合并到生产库
经过测试确认没有重大问题后，将开发库的代码合并到生产库，准备进行上线操作。

(2). 发布到测试环境
在生产库代码合并完成后，将代码发布到测试环境，进行最终的验证和检查。
(3). 打war包
将系统打包成可部署的war包，用于将应用程序部署到生产环境。
(4). 更新到生产环境/验证
将war包更新到生产环境，并进行验证，确保上线版本的功能和稳定性符合要求，正式投入使用。

这整个流程确保了项目从需求分析到上线的每一个环节都有清晰的步骤和标准化的操作，有助于提高项目的开发效率、降低出错概率，并确保最终产品的质量和用户体验。

3. 经验/教训

3.1. 代码、文档生成

我们一般根据数据库生成管理后台代码、dao、service层代码，但控制器代码却很少涉及。例如api接口开发，我们都是先有word格式api文档，然后根据word文档再生成相关代码。

问题在于：
(1). 文档跟代码可能不一致。
(2). api文档会在SVN、JIRA，测试人员电脑、商户电脑上等留存。一旦有变动，文档很容易过时。

解决方案：
(1) 文档即代码，可以根据代码生成文档。
(2) 定义程序可读的自描述接口定义文件(如swagger api)。测试部/客户拿到的接口文档是根据定义自动生成的。
(3) 在线文档。

3.1.1. DB

输入：DB定义
输出：
 代码：DAO、通用Service层、管理后台。

3.1.2. API

输入：swagger API （json或yaml格式）。swagger 2.0规范，建议以后升级到3.0。
输出：
 代码：控制器代码，VO（请求响应model对象）、测试代码。
 文档：API html 在线文档

3.1.3. 有UI的业务

输入：
业务:

• 流程1:
  业务名：
  URL路径：
  业务输入参数(或model)：
  业务输出参数(或model)：
  JSP页面(或其它模板)路径：
  …

输出：
 代码：控制器代码，VO（请求响应model对象）、测试代码。
 文档：在线文档

3.2. 编码规范

目前项目都是使用checkstyle做代码检查，但自从钱包项目后，checkstyle的规则我们做了以下变更：
(1). 类名最长64字符;
(2). 包名可以包含_
(3). 私有成员变量不用写注释。
(4). 私有方法不强制javadoc
(5). 静态变量不要求全大写。
(6). FileTabCharacter:源码中不允许有TAB
(7). VisibilityModifier:类成员可见性，packageAllowed、protectedAllowed修改为true
(8). 不限制返回return个数
(9). 每行最多120个字符
(10). 方法参数个数10个
(11). 成员/参数变更名最长到32位
钱包项目如果checkstyle检查不通过，在jenkins中是会部署失败的。因为是自动检查的，所以代码是符合checkstyle要求的。但老项目token、acc因为基础代码太多，就很难做到。

基础代码抽取到公共代码库中，代码通过jar进行引用，这样checkstyle只需要检查业务代码就行了，改造就相对简单。

现状：
(1). 老项目中checkstyle检查仅仅依赖人工约束是不够的？
(2). 为什么chekcstyle和findbugs没有完全用起来？
 checkstyle规则怪。
 完全实现约束成本太高。
 不是自动化检查，需要人工检查。

思路：
(1). 阿里巴巴Java开发手册v1.3.1.pdf。
https://github.com/alibaba/p3c
开发人员需装上相关ide插件。放弃checkstyle检查，改为此手册规范检查。

apply plugin: 'java'
apply plugin: 'pmd'

repositories {
maven { url "http://xxx:58081/nexus/content/groups/public/" }
}

pmd {
consoleOutput = true
reportsDir = file("build/reports/pmd")

    ruleSets = [
            "java-ali-comment",
            "java-ali-concurrent",
            "java-ali-constant",
            "java-ali-exception",
            "java-ali-flowcontrol",
            "java-ali-naming",
            "java-ali-oop",
            "java-ali-orm",
            "java-ali-other",
            "java-ali-set"
    ]
}

dependencies {
pmd 'com.alibaba.p3c:p3c-pmd:1.3.3'
}

(2). 新项目做完整约束，检查不通过不能上线(提交svn)。
(3). 抽取基础代码到公共代码库中，项目通过jar依赖。

3.3. 代码review

问题：
(1). 一个业务功能分多次提交，review时看不到完整的功能，对review造成一些困难。
(2). 代码是提交后审核，没有强制性。
(3). 代码可能都是组长进行审核，当组长时间紧张时容易造成堵积。
(4). 没有足够的测试代码，单是肉眼看有时难以发现问题。

思路：
(1). 可以尝试提交前审核。
(2). 组员互审。
(3). 核心功能可以结对编程。
(4). 尝试git
git是分布式的，可能先在本地多次提交，功能开发完成再push远程服务器。
git push时，先提交到分支，代码审核通过再合并到master。

深入理解学习Git工作流（git-workflow-tutorial）
https://segmentfault.com/a/1190000002918123

Gerrit代码审核工作流
http://www.worldhello.net/gotgit/05-git-server/055-gerrit.html

3.4. 自动化

3.4.1. 开发自动化

代码生成。

3.4.2. 测试自动化

单元测试
自动生成测试代码/自动测试。

如何做好单元测试？
(1). 自动做（jenkins）。
(2). 每次运行的结果都是一样。
(3). 尽量不依赖DB和网络。

3.4.3. 运维(部署)自动化

Jenkins+Ansible
目前是自动构建部署到测试环境，但缺少对环测试境的监控。

上线自动化，对目前开发来说是：自动打生产包，并发布到指定位置。

3.5. 公共代码

问题:
(1). checkstyle、findbugs难实施。
(2). 为什么TLS1.2通讯包，需要所有项目做这么大的动作。
(3). 底层代码因为分散于各个项目中难优化改进，如加密机通讯代码加上负载均衡代码。

思路：建立公共代码库

(1).	通用库
字符串处理
金额处理
时间处理/转换
字节处理
(2).	加解密（已建）
RSA
3DES
AES
Base64
(3).	加密机 （已建）
hsm
(4).	通讯库
http
ftp
tcp
(5).	其它…

作用：
(1). 复用公共代码。
(2). 容易对主项目做CheckStyle和Findbugs。
(3). 易于优化公共代码。

公共代码库svn:
svn://xxx:3699/commons

3.6. 标准化

作用:
(1). 跟着社区走。
(2). 不重复造轮子。
(3). 能充分利用社区工具:代码生成、gradle等。

清单：
(1). 敏捷开发
(2). 项目目录结构
maven
(3). 代码API
swagger
(4). spring

3.7. 主动学习

我们不是技术驱动型公司，业务线也比较混乱。

在急流中，你可能会被推着走。但在公司你想要有所成长，主动学习是一个比较关键的因素。

包括两块：工作之内，工作之外。

3.7.1. 工作之内

(1). 业务
是否深入了解过各个业务线？它们的主要是解决什么问题？业务上有什么约束？自己能不能抽象总结出来？

(2). 核心系统
公司的核心系统有哪些？这些系统是如何架构的？
核心系统关键业务流程有哪些？
数据库表是如何设计的？
自已是否可以重写(如用Spring+MySQL)？

(3). 开发流程
公司的开发流程是？
需求分析、设计、开发、部署上线是怎么做的？有哪些工具、技术在其中发挥作用？是否有明确的流程规范？
相对其它公司有什么不同？
当前流程存在的问题？
如果采用敏捷如何改进？

(4). 文档编写能力
word、excel、ppt文档编写功能。
你的文档编写能力决定了你的发展高度。

文档的重要性：在技术开发过程中，文档不仅是记录知识的工具，更是沟通的桥梁。无论是需求文档、设计文档，还是API文档、用户手册等，它们都在项目的各个阶段起着至关重要的作用。
文档写作技能：良好的文档编写能力可以帮助你清晰地传达技术方案、问题、思路，并确保信息在团队内部高效流通。无论是Word、Excel、PPT，都需要掌握一定的技巧，尤其是能把复杂的技术细节以清晰、易懂的方式呈现出来。文档的编写能力在一定程度上决定了你在团队中的发展空间，能够影响到你的职位晋升和跨部门沟通的效率。

3.7.2. 工作之外

(1). 我一直认为开发人员必须要学习的三个方面：开发，运维(Linux)、DBA（MySQL）。
技术之间是相辅相成的。你的高度决定于你对于自己的定位。
技术的多样性：对于开发人员来说，不仅要精通代码编写，了解常用开发框架，还需要熟悉系统运维和数据库管理。技术是相辅相成的，熟悉Linux系统的使用，可以让你在开发中更高效地进行调试、部署和监控。

(2). 技术变更太快。技术趋势：移动互联网 -> 大数据 -> AI/物联网。
5G网络到来，数据量会进一步迸发，AI/物联网会有自己的一席之地。

ios开发
tensorflow学习
机器学习

(3). 除java外，值得投入更多时间去学习的语言： python/go。
python：Python不仅适用于AI和机器学习领域，还是一种非常流行的工具语言。学习Python对于运维开发、自动化脚本编写等非常有用。它也是数据分析、人工智能以及大数据领域的主流语言。
go：天生并发、服务器编程、网络编程等。

4. 2018年优化改进

4.1. 主要内容

(1). 自动化：
自动化是2018年优化的核心之一，涵盖了多个领域，目的是提升开发和运维效率，减少人为操作的错误。具体来说，自动化体现在以下几个方面：

• 代码自动生成：通过自动化工具或脚本，生成项目中的部分代码（如基础框架、常用模块等），减少开发人员的手动编码工作，避免重复劳动。例如，使用模板生成常用的CRUD操作代码或服务接口代码。
• 文档自动生成：通过工具自动生成需求文档、接口文档、架构设计文档等，确保文档内容与代码同步更新，减少人工维护文档的成本。常见的工具如Swagger（用于API文档）和Javadoc（用于代码注释生成文档）。
• 开发测试自动化：实现单元测试、集成测试和UI测试的自动化，减少手动测试的时间。Jenkins等持续集成工具可以用于自动化构建、自动化部署和自动化测试，确保每次提交代码时都能自动验证系统功能。
• 构建（打包/部署等）自动化：利用Jenkins、GitLab CI等工具自动化构建流程。代码提交后，自动触发构建、打包（如生成war包或docker镜像）、部署到测试环境等操作，提升部署效率和稳定性。
• Web版本自动生成工具：

(2). 采用git代码库。
Git 替代了SVN成为主流的代码管理工具，尤其是多团队开发时，Git更具有分支管理和并行开发的优势。通过Git代码库，团队能够更高效地进行协作，处理代码冲突和版本控制。
二部（开发团队）可能采用不同的Git版本库管理策略，适应不同项目的需求，如通过分支策略（Git Flow）或标签管理（Release Tags）来进行版本控制。

(3). 编码强规范。
(4). 使用公共代码库。
项目中使用共享的公共代码库（比如通用工具类、基础框架、公共组件等），提高了代码复用性，减少了不同团队或项目之间的重复开发。公共代码库能够帮助新项目快速启动并保持一致性。
对于常用功能模块，开发团队通过维护内部的公共库，提升了代码的标准化和协作效率。

(5). Spring boot 、Spring Cloud使用。
Spring Boot：通过Spring Boot简化了Spring应用的开发，减少了配置工作，并提升了系统启动速度。开发人员能够通过Spring Boot框架快速搭建微服务应用，专注于业务开发，而无需过多关心框架的配置。
Spring Cloud：Spring Cloud为微服务架构提供了统一的解决方案，涵盖了服务发现、负载均衡、配置管理、断路器等功能。通过Spring Cloud，项目能够更好地实现分布式架构和服务治理。
(6). 人人都是MySQL DBA。
对于MySQL数据库，开发人员需要熟悉数据库的结构、查询优化、索引设计、事务管理等基本知识，保证系统在高并发情况下能够保持稳定的性能。
(7). 敏捷开发。

4.2. PMP / 敏捷开发

4.3. 设计

代码即文档：项目逐步倡导”代码即文档”的设计理念。通过自动化工具（如Swagger）生成API文档，将API说明集成在代码中，确保文档与代码同步更新，避免文档滞后于代码版本。
API设计：设计过程中，API的说明集成在代码中，或通过工具如Swagger先设计API文档，再根据API文档生成相关的代码（如Spring Boot的Controller类）。
数据库设计：MySQL数据库的设计和优化是开发过程的重要一环，要求每个开发人员具备一定的数据库管理技能，尤其是在查询优化和性能提升方面。通过合理的数据库架构和索引设计，保证数据库系统的高效性。

4.4. 开发

敏捷
Spring Boot / Spring Cloud

4.5. 运维

上线自动化：上线过程的自动化进一步减少了人工干预的时间和错误

这些优化和改进可以使得项目开发更加高效、稳定和敏捷，同时提升了团队的协作能力和代码的可维护性，适应了日益复杂的业务需求和技术挑战。

– end –