为了账号安全,请及时绑定邮箱和手机立即绑定

开箱体验: Web研发从石器时代过渡青铜时代&复盘心得

分享本猿晕晕乎乎的三周时间.

近期因为一个项目在和 CDK8S 合作, 经授权闭源使用 CDK8S 提供的 Web快开框架 sculptor-boot-generator 开发过程中我的每一个毛孔都是舒爽的 (后续会详细介绍这个框架), 原来Java快开领域 不止 JHipster 构建模型上也不止 JDL, 在享受 新框架的给我带来的快感时, CDK8S 的研发理念把身在石器时代的我震撼了. 千言万语归根结底一句话 Web 已死, 我们需要能提高效率的快开框架, 更符合时代的开发理念 !

下文介绍详细经历

如果拿到一个同样的项目需求, 身在石器时代的后端开发状态…

石器时代

  • 石器时代的第一周
    1. 产品经理加班熬夜弄出来原型图&UI图zip包, 发给项目经理过边需求看看能不能实现, 并要求根据经验评估工时.
    2. 产品经理拿到评估后的工时在 禅道或者别的项目管理工具上规定截至日期, 有的还会规定明确的里程碑日期.
    3. 开发们一看被规定了明确的交付日期, 心里有点发毛, 然后开始吭哧吭哧干起来了, 后端根据原型图设计表结构. PC端,APP端,微信公众号端开始画静态页面.
    4. 大约过了两三天表结构设计完了, 开始在 前端们的要接口的催促下. 花了一天设计接口文档.
    5. 前端们 拿到接口文档开始用 JSON 模拟接口返回字段. 但是前端们并不知道页面的跳转情况. 就开始骚扰产品经理, 可能产品经理也是熬夜堆的UI方案, 没有用文字标记跳转, 细节也欠缺考虑.
    6. 快到周五了, 项目经理会过来看看每个开发的进度. 如果进度跟不上的会被暗示周末加班. 想要在家办公? 为了集中 内网用SVN, 所以 Working For Home 不存在的!
  • 石器时代的第二周
    1. 后端开始从别的项目里copy代码以及jar包. 构建一个全新的项目
    2. 前端还是在催接口联调, 后端的几个 CRUD Boy 加了几个通宵后睡眼朦胧的在写(Ctrl+C&Ctrl+V) 增删改查, 因为工期紧急自然不会考虑什么性能了. 多层For循环走起.
    3. CRUD Boy 在后期写接口的时候,发现接口文档有错误, 或许少了个参数,或许参数名不准确, 就会去开发群里发新的开发文档. 当然前端也不是没事, 都在忙着写静态页面和产品扯皮呢, 至于更新后的接口文档看不看的见就不一定了.
    4. 快到周五了, 项目经理会过来看看每个开发的进度. 如果进度跟不上的会被暗示周末加班. 想要在家办公? 为了集中 内网用SVN, 所以 Working For Home 不存在的!
  • 石器时代的第三周
    1. 后端紧赶慢赶搞完了一个重要模块. 拉上搞完这个模块的前端开始联调(踩坑) , 这个时候或许是前端的接口参数对错了, 或许是后端的代码出bug了, 但是更可能的是接口文档的参数出现变更后没有及时更改.
    2. 又到周五了, 匆匆忙忙发个版到联调环境, 将项目打成 war包, 登录 FTP 服务器, 放到 Tomcat Webapp , 然后启动 start.sh . 如果有运维的话这件事是交给运维的.
    3. 前端也打个版本出来, 丢个包给测试,
    4. 测试过来验收里程碑,美约其名 敏捷开发.
    5. 测试开始测试,发现一堆bug, 比如: 页面显示问题, 输入边界问题, 还有测试不了解需求自己给自己提的bug, 一股脑的指给项目经理, 项目经理说这些bug 先不管, 只要这个模块主要功能能跑通就行.
    6. 快到周五了, 项目经理会过来看看每个开发的进度. 如果进度跟不上的会被暗示周末加班.想要在家办公? 为了集中 内网用SVN, 所以 Working For Home 不存在的!
  • 石器时代的第N周
    1. 在周而复始的研发过程中, 逐渐做完了项目, 开始部署测试服测试, 开发们(运维)开始装 测试服的 数据库, 服务器, 静态资源服务器 等, 如果用户多还可能用 集群, 就更麻烦了.
    2. 但是终于在公司成员的努力(加班)下完成了, 当然还有一堆隐藏Bug等着呢 !
    3. 正准备给客户交付呢, 客户打电话过来商量需求变更的事情…
    4. 开发们: wsl (毕竟是外包,客户要的是结果…)

如果拿到一个同样的项目需求, 身在青铜时代的后端开发状态…

青铜时代

  • 青铜时代的第一周
    1. 产品经理和需求方协商业务, 输出需求文档(明确需求范围), 并在合同上签订变更声明, 协商通过后开始画原型图以及UE图.
    2. 交付 UI工程师开始用UI图描述细节, UI图,UE图,原型图,需求文档交付后
    3. 产品部内部 check 一遍需求, 然后交由 项目经理. 拆分需求为 需求列表并同步到 ShowDoc 指定给 开发者.
    4. 由开发者对 页面详细评估, 一个接口区分非常复杂,复杂,简单等级, 页面也是同样, 根据这种可量化的指标来控制时间. 并使用 Tapd 来分配优先级.
    5. 而项目经理则会将项目适用的架构和难点, 给攻克.
    6. 开发工具上: 使用 Maven私服管理 Jar包, GitLab 分布式管理代码, sculptor-boot-generator 根据表结构生成 CRUD 代码, 如果有特殊SDK模块则提前封装 SpringBoot Stater.
    7. 基于 PgSql 设计表结构, 有需求文档 UE图 UI图设计起来当然是轻松多了.
    8. 快到周五了, 项目经理会用 Tapd 看看每个开发的进度. 发现大家的进度都很快速, 如果有个别摸鱼党, 则可因为内网是 Git 可以选择在家办公 !
  • 青铜时代的第二周
    1. 根据 SQL 模型, 设计 yapi , 内容包括 请求Url, 请求参数, 响应数据格式(支持 mock) 大概一两天设计完成. 然后根据实际情况 check一遍参数与返回值.
    2. 前端还没有反应过来就迅雷不及掩耳的交付 yapi 开发文档, 前端直接把 baseUrl 切为 yapi, 简直何真实接口一样丝滑.
    3. 进入api开发阶段, 使用 sculptor-boot-generator 按需生成基础 CRUD 代码以及对应运营平台. 当然最优配置的框架也是生成好了的(redis缓存可选). 开发业务代码 ing
    4. 业务代码开发好了催着前端进行联调. 前端切换 yapi 地址为真实地址联调后, Tapd 上对应的需求 泳道向前游?,
    5. 快到周五了, 项目经理会用 Tapd 看看每个开发的进度. 发现大家的进度都很快速, 如果有个别摸鱼党, 则可因为内网是 Git 可以选择在家办公 !
  • 青铜时代的第三周
    1. 使以前做好的 Docker 镜像配置测试服. PgSql, Nginx, Redis 应有尽有而且还开机自启 !
    2. 因为一开始就是科学的分配任务, 当然没有特别赶时间, 代码质量相对较高, 测试并没有测试出很多bug !
    3. 使用 ShowDoc Yapi TAPD 有效的沉淀了文档, 可维护性变强好了.
    4. 开始考虑建立索引,单元测试覆盖,缓存等可优化项.
    5. 开发们在开发项目的过程中 王者荣耀又升段位了 !

复盘心得

石器时代是曾经绝望中的呼喊,青铜时代是经过修饰的理想状态, 一切并非一帆风顺, 但我们终将抵达彼岸,
既然作为复盘, 就是事后追求精进.下面细数我犯了那些错误 !

  • 架构选型上要用最能发展生产力的真正稳定技术, 而不是滞后生产力的所谓稳定技术 !
  • 因为以前没有用过 sculptor-boot-generator 简称 sbg, 但是用过类似的框架如 JHipster , 我就用 JHipster 的开发经验去套 sbg, 运行代码时发现一堆稀奇古怪的bug, 原来我没有按着文档去开发, 而且我对 sbg 的技术栈也不够了解, 就开始撸代码. 举个最大的不同, sbg 用的是 MyBatis , Jhipster 用的是 Hibernate, 后来我有恶补了 MyBatis 的知识,才慢慢走上正轨.
  • 我写 Yapi 时并没有考虑到实际需要用的 参数和返回值情况, 导致前端缺返回值, 后来还因为命名规范问题 多次改变 Yapi, 造成了不必要的联调麻烦.
  • 在写代码时我没有考虑到 多端用户多id 的情况, 多次出现 用户基本信息查询错id 的情况. 我的代码规范也存在不小的问题.
  • 在部署 Docker 时, 我配置 gitlab 的时候用到了 Docker 卷轴挂载:数据目录, 我要修改其配置的时候 直接在本机的 数据目录进行改变, 发现并无效果, 而且配置生效命令无效, 其实你要进入 Docker 里了修改后配置命令即可生效, 外面配置就需要重启Docker 容器.
  • 在联调过程中有人不断犯错请不要责怪他, 从自己身上找原因, 是不是自己接口设计的不合理, 文档不够清晰易懂, 协作开发中还有什么可以改进的地方, 思维不要被代码局限, 抱怨解决不了问题.
  • 专注一件事才能做好一件事, 时间宝贵!
  • 代码不会骗人,写代码需要认真思考之后仔细仔细再仔细 !

? 来一波干货 !

最近一段时间我在云上使用了 Docker 搭建了一台服务器 用于生产环境, 想起当初我接触 CentOS 的时候正处于 虚拟机时代(石器时代) ,那时候容器这个概念还没有普及 只是少数大厂的宠儿, 头几年我们搭建环境都是用云厂商的定制镜像然后再执行下脚本改改配置, 得益于云计算的普及这个过程远远比 虚拟机时代 手动编译原生服务器软件安装来的轻松惬意, 在各厂随随便便 DAU 几百万的今天 我们不满足于此, Docker 容器化 的出现让 服务器软件的开发者与使用者借助 容器使工作变的更加简单, 接下来我会分享几个不错的 Docker 镜像以及以及青铜时代的在线软件.

容器与虚拟机

来自官网的 Docker 容器简介

容器是打包代码及其所有依赖项的标准软件单元,因此应用程序可以从一个计算环境快速可靠地运行到另一个计算环境。 Docker容器镜像是一个轻量级的,独立的,可执行的软件软件包,其中包含运行应用程序所需的一切:代码,运行时,系统工具,系统库和设置。

容器镜像在运行时会成为容器,对于Docker容器,镜像会在Docker Engine上运行时成为容器。不论基础架构如何,容器化软件都可用于基于Linux和Windows的应用程序,始终运行相同。容器将软件与其环境隔离开来,并确保尽管开发和生产之间存在差异,但软件仍可以均匀运行。

以上提到了 3个重要的点, 镜像 , 容器, 跨平台

  • 镜像: 这个概念相信大家都不陌生吧, 每个人使用 VMware 安装 CentOS 时都是基于 官方给出的 .iso 镜像安装的. 在 Docker 中也有 镜像这个概念. Docker镜像你可以理解为就像 SpringBoot 中的 Starter 一样, 由作者将需要用到的资源按照 spi规则打包到一个 <Dependency/> 中供你调用! 开箱即用的它让你无需考虑其中的依赖构建关系. 学到更多
  • 容器: 容器是应用程序层的抽象,将代码和依赖项打包在一起。多个容器可以在同一台机器上运行,并与其他容器共享OS内核,每个容器在用户空间中作为隔离的进程运行。容器占用的空间少于VM(容器映像的大小通常为几十MB),可以处理更多的应用程序,并且需要的VM和操作系统更少, 其实可以抽象理解为一个定制镜像 你可以进入Docker 容器修修改改(里面别有洞天) 当然如果没有做 数据挂载 的话容器被重置了你修修改改的数据就没了 学到更多
  • 跨平台: 注意是 Docker 跨平台不是容器跨平台, 意思是只要 Docker 能在这个操作系统上运行, 那么你基于 Docker 制作的镜像也可以在这个系统上跑. 比如 Java的跨平台不是 .class 跨平台而是运行 .class 的 JVM 跨平台学到更多.

✨作者推荐通过这个网站来学习 Docker 会事半功倍 -> 菜鸟教程 | Docker


GitLab

GitLab 是一个用于仓库管理系统的开源项目,使用Git作为代码管理工具,并在此基础上搭建起来的web服务。安装方法是参考GitLab在GitHub上的Wiki页面 , 它集成了许多用于软件开发和部署以及项目管理的基本工具:

  • 使用版本控制在存储库中托管代码。
  • 使用功能齐全的问题跟踪器跟踪新实施的建议,错误报告和反馈。
  • 组织和发行委员会的优先次序。
  • 使用Review Apps查看合并请求中每个分支的实时预览更改中的代码。
  • 使用内置的持续集成进行构建,测试和部署。
  • 使用GitLab Pages部署个人和专业静态网站。
  • 通过使用GitLab容器注册表与Docker集成。
  • 通过使用GitLab价值流分析跟踪开发生命周期。
  • 了解更多

下载 GitLab Dokcer 镜像

docker pull gitlab/gitlab-ce:latest

执行Gitlab构建命令

执行前注意事项

  • -v 需要根据实际卷轴情况创建 目录(PS: 命令行参数不会自动创建目录).
  • –hostname clone url 前缀域名, 如果需要被外网正确访问则添加.
  • –restart 容器运行中退出时(不是手动退出),自动重启
docker run -d  --hostname gitlab.xxx.com -p 1443:443  -p 1080:80   -p 1022:22  --name gitlab  --restart unless-stopped  -v /root/docker-volume/gitlab/etc:/etc/gitlab  -v /root/docker-volume/gitlab/log:/var/log/gitlab  -v /root/docker-volume/gitlab/data:/var/opt/gitlab  gitlab/gitlab-ce:latest

注释版

docker run -d \       # 后台运行 -d
        --hostname gitlab.xxx.com \ # 指定 clone url 前缀域名
    -p 1443:443 \          # 将容器内443端口映射到主机1443,提供https服务
    -p 1080:80 \           # 将容器内80端口映射到主机1080,提供http服务
    -p 1022:22 \           # 将容器内22端口映射到主机1022,提供ssh认证服务
    --name gitlab \         # 指定容器名称
    --restart unless-stopped \      #容器运行中退出时(不是手动退出),自动重启
    -v /var/lib/docker/volumes/gitlab-data/etc:/etc/gitlab \       #  将本地/var/lib/docker/volumes/gitlab-data/etc挂载到容器内/etc/gitlab
    -v /var/lib/docker/volumes/gitlab-data/log:/var/log/gitlab \   # 将本地将本地/var/lib/docker/volumes/gitlab-data/log挂载到容器内/var/log/gitlab
    -v /var/lib/docker/volumes/gitlab-data/data:/var/opt/gitlab \  # 将本地将本地/var/lib/docker/volumes/gitlab-data/data挂载到容器内/var/opt/gitlab
    gitlab/gitlab-ce:latest 

NGINX

因为镜像中自带了NGINX, 所以我没有使用 NGINX 容器化, 下面介绍用 NGINX 做 gitlab 容器的 二级域名 HTTPS转发, 望举一反三.

GitLab HTTPS 的配置转发.

  • 首先你需要在 阿里Y上 [申请免费的DV证书], 当然如果你有通配符证书的话可以跳过这一步…

  • 其次确保你的NGINX 是可以被外网访问的,(运行NGINX并开放安全组以及端口), 排查工程中有可能是 [NGINX-DNS]出现了错误导致无法访问.

  • 在阿里Y 域名控制台 添加 二级域名映射(其他云厂商也是同理)

  • 配置你的 NGINX文件, 添加 443端口以及(80转443)配置 (修改 todo 为部署域名并保证你的NGINX版本为 1.14.2及以上).

 # https 配置
 server {
    listen 443 ssl;
    server_name www.todo.com;

    #设置长连接
    keepalive_timeout   70;
        
    #HSTS策略
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        
    #证书文件
    ssl_certificate     ./ssl/www/todo.pem;
    #私钥文件
    ssl_certificate_key ./ssl/www/todo.key; 
    access_log /data/todo/access_nginx.log combined;
    root /data/todo; 
    index index.html index.htm index.jsp;
    #error_page 404 /404.html;
    #error_page 502 /502.html;
   
   #定义算法
   ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4";
 
   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
   #禁止服务器自动解析资源类型
   add_header X-Content-Type-Options nosniff;	
   #防XSS攻擊
   add_header X-Xss-Protection 1;
   #减少点击劫持
   add_header X-Frame-Options DENY; 
   ssl_prefer_server_ciphers on;

  }

# 80转443
server { 
    listen 80;
    server_name gitlab.todo.com;
    rewrite ^(.*)$ https://${server_name}$1 permanent;
} 
  • 修改你的NGINX gitlab https 监听转发配置
server {
        listen 443 ssl;
        server_name gitlab.todo.com;
        ssl_certificate     ./ssl/gitlab/todo.pem;
        ssl_certificate_key ./ssl/gitlab/todo.key; 
        location / {
                proxy_redirect off;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_pass https://127.0.0.1:1443;
        }
        access_log /data/todo/gitlab_nginx.log combined;
}

Yapi

YApi 是高效、易用、功能强大的 api 管理平台,旨在为开发、产品、测试人员提供更优雅的接口管理服务。可以帮助开发者轻松创建、发布、维护 API,YApi 还为用户提供了优秀的交互体验,开发人员只需利用平台提供的接口数据写入工具以及简单的点击操作就可以实现接口的管理。

  • 基于 Json5 和 Mockjs 定义接口返回数据的结构和文档,效率提升多倍
  • 扁平化权限设计,即保证了大型企业级项目的管理,又保证了易用性
  • 类似 postman 的接口调试
  • 自动化测试, 支持对 Response 断言
  • MockServer 除支持普通的随机 mock 外,还增加了 Mock
  • 期望功能,根据设置的请求过滤规则,返回期望数据
  • 支持 postman, har, swagger 数据导入
  • 免费开源,内网部署,信息再也不怕泄露了
  • 了解更多

Yapi 暂未推出官方Docker镜像, 推荐使用 -> docke-YApi | DockeCompose

需要注意的地方

docker-YApi 默认 YAPI_CLOSE_REGISTER 为 true, 不支持新用户注册, 你可以使用 yapi-plugin-add-user 插件闭环注册 (ps: 4GB内存以下不建议安装插件). 当然如果你希望有游客参与到你的项目中来可以默认为 false !

  • 说句题外话, Yapi 确实比写接口文档清爽, 还支持 Swagger 批量导入 Yapi, 批量接口测试 等特性 (缺点: 改接口内容太过方便, 这点我已经被吐槽过很多次 2333 :)
  • 总结: 在线的api文档能减少因为信息传递而产生的工作量, 总之爱了 !

ShowDoc

ShowDoc是什么

  • 每当接手一个他人开发好的模块或者项目,看着那些没有写注释的代码,我们都无比抓狂。文档呢?!文档呢?!Show me the doc !!

  • 程序员都很希望别人能写技术文档,而自己却很不希望要写文档。因为写文档需要花大量的时间去处理格式排版,想着新建的word文档放在哪个目录等各种非技术细节。

  • word文档零零散散地放在团队不同人那里,需要文档的人基本靠吼,吼一声然后上qq或者邮箱接收对方丢过来的文档。这种沟通方式当然可以,只是效率不高。

  • ShowDoc就是一个非常适合IT团队的在线文档分享工具,它可以加快团队之间沟通的效率。

  • 了解更多

我主要使用 ShowDoc 做数据字典设计以及各类开发文档的沉淀. 理由同上 减少因为信息传递而产生的工作量 ,没有文档的项目 3个月之后你就不认识它了 ?太真实了 …

推荐安装官方的 Docker -> ShowDoc | Docker

PostgreSQL

  • MySQL 的用户群体性好于 PostgreSQL,特别是国内,更加容易上手。但是 PostgreSQL 从体验上最大优势就是插件以及带来的各种可能。
  • 两者的基准压力测试工具不同,很难说测试数据对比是公平的,如果是通过 Java 代码测试同配置的 CURD,非极限情况下,两者使用感受上差距不大。
  • PostgreSQL 在做统计分析上可以借助各种函数、语法进行支持,所以在数据分析上有优势
  • 借用知乎上的一句总结 PostgreSQL 我觉得很合适:PostgreSQL 是一专多长的全栈数据库:在可观的规模内,都能做到一招鲜吃遍天
    • 所以,作为中小企业我觉得完全可以依赖 PostgreSQL,特别是求活阶段的企业

Tapd

专业版支持主流的敏捷产品研发模式和方法论(如Scrum/XP),结合腾讯互联网产品研发的特色,帮助产品团队以敏捷迭代、小步快跑的研发方式进行产品规划、项目管理、质量跟踪等研发管理工作,帮助团队更好更快完成产品交付并发布上线运营。

专业版包含需求、迭代、故事墙、缺陷、报表、文档等6个核心应用,还支持通过移动端管理工作。

点击查看更多内容
1人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消