用个人博客打造一个酷酷的工作流！

• 博客地址 交换友链ing

写在前面

每个前端都应该拥有一个自己的博客、因为它不仅仅是一个博客、更是属于自己的一个工作流、如何来理解这个问题呢、这也就是我要开发一个博客的初衷。

似乎自己也没有一个写博客的习惯、或者说觉得写得一些笔记还达不到可以发布在类似掘金这样的技术平台、但是又会在日常中用到、例如记录的一些文档或者日常、平时会保存在本地或者一些云文档上面、但是不够清晰、也会有些不方便、而且在很多种场景之下会有局限性、于是我便有了打造一个自己个人博客的想法。

今年貌似也没有做太多的东西、唯独很多人通过掘金来加到我问我要博客的源码、所以来为大家分享下自己闲暇时间开发这个博客的经历。

今年的年终总结看来没时间写了、就来一篇分享结束今年的分享吧。

静态博客

最开始的时候、为了快速去打造一个个人的博客、我选择过一些静态网站生成器类型的网站、例如hexo、vuepress、这类框架、这类博客的好处就是快、很多类似这种博客的搭建标题通常是五分钟打造一个xxxx等这样的标题、显然、这是优势、但是在很多场景之下、由于它是静态的、一些交互就不好做了、例如、文章评论、登录注册、用户交互这些方便很难实现的很灵活、虽然可以接入一些三方的插件来实现这些功能、但是都不能避免的是、他只是一个静态博客、例如发文章这种操作都必须更新重新部署、显得尤其不太方便、更多时候像vuepress我觉得拿来做技术文档更为方便、hexo的好处就是社区有很大一部分维护者、当然业开发了api可以让你自己打造一个主题或者引用别人的主题、能够做到很炫酷、这对初学者尤其有利、给初学者了一个很好的平台、这也是我当初很赶兴趣的原因、当已经有能力去开发一个个人的博客的时候、我觉得作为一名前端开发工程师为自己打造一个个人的全栈博客很有必要。

博客是干嘛的？

这个问题我觉得各抒己见，很多人觉得博客这东西就很幼稚、也觉得完全没必要自己花费精力去开发一个自己的博客、觉得现在各种云平台足够方便、我觉的这样的想法也没什么问题、但是也有很多人觉得打造一个个人博客是有用的、能够有一个记录自己的平台、完全由自己掌控、想实现任何功能都靠自己就可以完全实现、这一点就足够有吸引力、但我觉得好处不仅仅于此、博客除了和云平台一样记录自己博客之外

1. 运用自己的所学从0开发可以锻炼你的技术广度、而不是日常工作重复做
2. 做自己的产品可以有自己的思想、从设计ui到功能交互你一个人说了算、你能更全面的了解一个产品的生命周期和流程以及需要考虑的问题
3. 可以打造一个属于自己的工作流、这一点至关重要、如何理解呢？我们后面聊聊

前期准备

作为一个属于自己的项目而言呢、首先要构思出自己需要做出一个什么样的东西、以及你要做到什么程度、当然最重要的是你得知道自己为什么做、有什么用、能干什么。

作为一个前端工程师、我们在需求下来后需要去和UI设计师打交道、所以呢我们需要去画一个原型图、这里呢推荐大家使用process这个平台个人用了很久、在线可以做出你需要的东西也可以分享给他人一起使用，所以相对还是很简单的、这一点很多人可能觉得很难、其实不然、作为前端工程师天天和这些打交道、这个时候平时对设计师的不满自己都可以实现了、而且我们不需要设计的过于复杂、一个原型图就是一个前端的基础布局框架、想给自己的门面打造成什么样子呢？这个由你决定、比如常规的两栏布局、三栏布局、双飞翼布局等等、有了这样一个结构你就可以自由发挥了、UI这一点呢还是挺难的、对于前端来说咱们可以优雅的抄袭一下、作为文化人、咱们就是说借鉴一下对吧、毕竟好多时候大家都说、设计师的工作不就是抄来抄去么（手动狗头）!

技术选型

有个原型之后就是技术选型了，这一点呢就得因人而异了、毕竟每个人的技术栈是不同的。作为一个博客项目、我考虑到后期会做其他的迭代可能会加很多东西、于是我决定把它分为三部分来做。

• 前台显示页面：博客展示页、对外输出的页面、这里是给别人看的
• 后台管理系统：这个用于管理博客、当然这个管理后台可以多个通用
• 后端项目开发：用于API接口的提供开发、提供博客需要的能力

前台页面技术栈使用的nuxt[一个vue的服务端渲染框架]、之所以要用nuxt是因为vue或者react这种单页面的项目无法被百度蜘蛛爬取到、也就没有了收录、所以选择了服务端渲染。

后台管理系统使用了vue3开、vue3已经出来很久了、公司上没有使用上、个人项目当然可以来尝尝鲜了、这里呢我觉得后台管理系统无关紧要、对于每个前端开发都应该是轻车熟路了。

后端这块儿当然是选择前端最容易上手的NodeJs了、这块儿东西相信大家都会了、框架选用了NestJs这个框架也是刚刚接触、但是在Github上面项目非常火热、所以选择了这个框架。

部署这块儿呢使用了docker+gitlab这一套比较常见的体系、因为个人项目为了方便自己管理和部署、也是搭建了自己的私有Gitlab。

项目结构

当我们已经考虑完技术栈之后、我们就要在大脑构思项目的整理底层设计交互了，这个东西我们通常需要一个思维导图来画出来了、这里依然推荐process这个工具很全、可以画很多东西、基本能用到的都有。

• 推荐process 注册地址

在初期、我们不必把项目想的过于复杂、我们可以尽量拆分开功能、做到第一层就好、知道需要做个什么东西、而不必深究我们能不能实现、需要用什么技术栈等等。

初期有了这个思维导图我们就发现好像清晰了很多、做什么、怎么做、是不是就有一目了然的感觉了、当然这个也不是一下就能想到的、个人建议呢就是在睡前这个时间点去思考自己做一个什么东西、闭上双眼的时候可以想的更加清晰、效率也更高、我也习惯在每天晚上睡前去想想第二天的工作安排实现思路、一些理清楚也就自然而然睡着了、第二天也会事半功倍了。

项目开发顺序

这一点我觉得大多数人可能也不大一样、这里只是分享一个个人的观点、日常来说、如果你是前端、其实一般节奏会晚于后端。

• 一个是考虑到接口的对接会以后端为准、后端给到了我们才能对接
• 二是当我们不接触到后端的时候没办法只能等到后端实现才能去做

当你自己全栈的时候、顺序就由你来掌控、你可以倒叙来干、前端写完了再去做后端都可以、因为字段都是你来定义、交互也是你设计的、这一切你都了然于心。

但我个人习惯的是同时开发、前端对比于后端的乐趣其中一点在于所见即所得写的代码可以马上得到反馈、有种掌握之中的感觉、这也是对比后端而言快乐的一点、个人觉得同时开发的好处在于联调错误会很快、亦或是讲出了一个流程错误、我可以两边同时更改、这一点感觉体验蛮好、同时开启两个项目、也不会有太多问题、当然这里实则有些废话了、每个人的开发习惯不同、全看自己了。

进入开发

进入开发之后的场景就回到了我们所熟悉的领域、就是日常接需求开发需求、相信大家如果到了这步都会得心应手了、到了这里呢我们开始进入开发、相对于技术来讲、个人的技术还是相对浅薄不能给大家很好的技术指导、更多的是想分享一下个人的项目经历而已、希望大家手下留情。

这里就个人博客的一些开发提供一点思路和一些开发过程中遇到的坑、希望大家遇到的时候可以少一些坑趟、仅此而已。

前台页面开发

• 框架 : nuxt

要开发一个完整的项目所需的小的技术点还是很多的、我们就不一一罗列了、我们就开发思路而言来说说要做的事情

• 项目目录

  .
  ├── Dockerfile                          *docker部署配置
  ├── README.md                           *项目说明文档
  ├── app.html                            *主页
  ├── assets                              *静态资源
  ├── components
  │   ├── base                            *基础组件封装
  │   ├── chat                            *聊天室组件封装
  │   ├── kit                             *基础组件配套组件
  │   ├── layout                          *布局组件
  │   └── page                            *页面级别组件
  ├── configs
  │   ├── env.development.js              *测试环境配置文件
  │   ├── env.production.js               *生产环境配置文件
  │   ├── index.js                        *配置文件导出
  │   └── sitemap.js                      *网站地图
  ├── layouts
  │   ├── chat.vue                        *聊天室布局
  │   ├── default.vue                     *默认布局
  │   └── error.vue                       *错误页面布局
  ├── nuxt.config.js                      *全局配置文件
  ├── package.json
  ├── pages                               *页面开发
  ├── plugins
  │   ├── api-repositories.js             *Api接口封装
  │   ├── axios.js                        *axios全局请求
  │   ├── baidu.js                        *百度统计
  │   ├── directive                       *各种指令封装
  │   ├── element-ui.js                   *element-ui引入
  │   ├── format.js                       *全局时间格式化方法
  │   ├── socket.js                       *socket-io
  │   ├── storeCache.js                   *store仓库本地缓存
  │   └── svgIcon.js                      *全局svg图标注册
  ├── server
  │   ├── index.js                        *项目启动文件
  │   └── pm2.config.json                 *pm2启动配置
  ├── static                              *favicon robots等文件
  ├── store                               *vuex
  ├── gitlab-ci.yml                       *gitlab-ci 配置文件
  └── stylelint.config.js
  ​

nuxt框架的语法沿用了vue、但是也会在一些地方稍有不同、这里为大家总结一些方便大家更快入手。

• 在vue中的router路由是通过自己配置、在nuxt中则是约定式路由、这一点类似于egg、会根据文件夹的目录帮你生成路由、我们就无须去配置路由了、他的规则是按照pages目录生成一个目录树接口的路由、对于一些动态路由则是_的匹配方式进行匹配
• axios接口请求也有所不同、首先需要注意的是nuxt的配套axios的包是nuxtjs-axios而不是我们正常vue使用的那个模块、nuxt的所有配置都是以注入式的方式加入的、如上目录树的plugins的形式、这一点和koa很类似、洋葱圈的链式调用形式、一般我们需要在plugins里面配置好、通常是导出一个函数、函数的参数便是context上下文、里面携带了我们需要用到的所有东西、这里大家可以打印看看、然后再去nuxt.config.js里面的plugins中进行引入、最后还需要在modules中注册这个模块、自此这个模块就可以正常使用了、需要注意的是、各个插件的引入因为是链式调用所以是有顺序的、例如封装接口的时候我们要在这之前引入axios、否则我们是拿不到的、再引入中间件后才会在ctx的全局对象上面挂载这个中间件、所以我们引入也是按照顺序来的、一些css的引入也需要注意、使用ui框架的时候需要注意这个问题。

• 我们日常使用图标呢一般svg居多、但是nuxt默认是没有svg-loader的、这里需要我们自己配置、配置文件也放在nuxt-config.js的build中，类似这样

  build: {
      extend(config, ctx) {
        const svgRule = config.module.rules.find((rule) => rule.test.test('.svg'))
        svgRule.exclude = [path.resolve(__dirname, 'assets/icons/svg')]
        config.module.rules.push({
          test: /.svg$/,
          include: [path.resolve(__dirname, 'assets/icons/svg')],
          loader: 'svg-sprite-loader',
          options: {
            symbolId: 'icon-[name]'
          }
        })
      },

  为了对svg图标进行变色、我使用了vue2-svg-icon、在这中间也遇到了点坑、这个组件的导出在vue的项目中是默认导出src/icons里面的所有图标、对其进行注册、而nuxt里面是没有这个目录的需要自己手动创建、并且需要注意的是、在这里也遇到个坑、在nuxt中并不区分文件名的大小写、当你给前一个文件改名后、给新的文件改为之前的名、这个时候的文件依然指向前一个文件、我们可以看到每次启动成功根目录是有一个.nuxt的编译文件的、这个文件是有缓存的、很多时候会有迷惑性错误就是他产生的、如果遇到不理解的、不妨删除.nuxt然后重新启动试试。

• 在nuxt中是有两个环境的、因为是ssr服务端渲染、所以打印的时候你会发现、会打印两次、意味着代码在两个环境都执行了、所以在mounted中获取dom节点依然报错都是因为它产生的、我们需要判断环境属于浏览器才可以进行获取、例如：

  process.browser && console.log('这是浏览器环境')

• layout布局组件、这个针对vue的spa项目而言、我们通常只需要一个根节点app、假如我们在app页面做了一个三栏布局的管理端、那么就意味着我们在其他页面的router-view都会在这个页面渲染、不能改变这个布局样式、nuxt的layout便是解决这种场景、给你提供多个节点、然你自己选择挂载在哪个节点下面渲染、使用的时候只需要在页面组建中添加此配置项即可。
• 数据请求、很多数据我们希望在界面渲染前就拿到、而不是类似spa页面渲染之后再请求数据、或者同步进行、nuxt提供了asyncData来进行这个操作、可以在这里请求数据、并且是早于组建渲染的、也就意味着在这里肯定无法拿到dom也需要注意、而且注意文档说明、只能在页面级别组件下使用、也就是pages下的第一层、在普通的组建中就算写了也不会执行。同时组件级别也有一个API可以使用Fetch、这个大同小异了。
• 使用nuxt的一大关键点是需要seo所以在开发中应该注意这个问题、后面再来详细讲讲这块儿

nuxt看似简单、实则也会有许多坑需要走、很多vue的包nuxt并不能支持、在使用前需要注意、这里只是总结的一小部分、可能还有很多想不起来、如果您还有问题、欢迎到评论区留言、看到并且我能帮到您的会为你解答。

前台的部分就简单的为大家总结这么多了、很多东西做完之后也就忘记了、如果后续自己再遇到会补充、前台的东西很多地方也需要考虑性能、这里就先不总结了、后续有时间再来讲讲性能优化。

后台管理系统

• 框架：vue3.x + vite

博客的后台管理系统其实个人觉得并没有太多可以说的、相信每个前端都对这块儿很熟悉、因为或多或少总会接触到后台类的东西、这里个人的见解呢回到最初的观点、博客是博客、单不仅仅是博客、我们打造一个博客的后台管理并不难、我希望有更多有创意的想法在这里实现、我想为自己打造一个工作流、前台的项目可以孵化多个、但是后台我觉得个人集成一个就好了、通用一个也足够了、在这里除了博客、我们可以管理很多东西、管理日常工作、学习进度、自己的任务排版等等、这些东西很多后续也可以为大家说说我的个人看法。

• 针对于vue3目前生态其实已经很成熟了、这个早很早之前个人也做过总结了、可以看看之前的文章文字长文带你全面掌握vue3、
• 后台管理的东西我觉得可以更多的是一个思路的分享，技术上我觉得似乎没身份好分享的东西了。

后端模块开发

• 框架： nestjs
• 技术栈： Redis typeorm mysql socket-io......

使用NodeJs来写后端相信对大多数前端工程师都是能最节约成本、快速上手的方式、当涉及到后端开发的时候、我觉得后端更需要注重项目规范、整体逻辑、如果有时间为自己定义一个好的项目规范模板我觉得很有必要、其二就是后端的项目在开发前尽量慎重一点、尽量做到思考全局再动、很多东西在之后再去插入可能不是很友好呢、所以能在开发前绘制一个思维导图很有必要。

还是首先看看项目基础目录吧：

.
├── Dockerfile                      *docker编排文件
├── README.md                       *项目说明文档
├── nest-cli.json                   *配置文件
├── package.json
├── pm2.conf.json                   *pm2配置文件
├── pnpm-lock.yaml
├── src                             *开发文件夹
│   ├── app.module.ts               *根模块
│   ├── cache                       *缓存Redis
│   ├── common                      *公共文件
│   ├── config                      *配置文件 包含所有配置
│   ├── constant                    *常量文件
│   ├── decorator                   *自定义装饰器
│   ├── filters                     *管道过滤器
│   ├── guard                       *权限验证
│   ├── interceptor                 *统一返回格式和错误全局拦截
│   ├── lib                         *扩展库 cdn文件存储等等
│   ├── main.ts                     *入口文件
│   ├── modules                     *模块
│   ├── swagger                     *swagger文档
│   ├── tasks                       *定时任务
│   ├── templates                   *服务端渲染模块 邮箱注册
│   └── utils                       *自定义工具库
├── test                            *单元测试
├── tsconfig.build.json
├── tsconfig.json
├── utils
└── views
​

这是我的个人nest项目的目录、可能每个人有所初入、大致呢是这些功能、NestJs号称是Node中的springboot框架、目前来说非常火热、在Node的框架中、目前在Github上的上升率很高、作为一个接触过express、koa 、Egg、Hapi等框架的用户来说、我还是很喜欢这个框架、项目规范相对约束挺高、依赖注入反转这样的形式在代码阅读起来会很清晰、mvc的分层也很好、还是挺方便的、根据官网文档走一遍、基本就能搭建好基础项目了。
关于后端这块儿也是一样为大家分享下NestJS遇到的坑已经需要注意的问题很一个博客的思路吧，首先还是需要画一个简单的思维导图用于项目整体开发和你能预想到要开发的功能及其实现。

这是前期就应该有个大概预期的、后期可以可能还加了一些东西、我们在初期也可以先不用考虑的太细、心中知晓会遇到多少问题和场景即可、然后按照顺序依次开发即可。

一个个人项目在基础搭建开发时候应该把一些基础服务先考虑到了、做一些预设、当然我们也应该有一套属于自己的基础模板用于快速开发、而不应该每次都去重新从0开始、这样就会过于浪费时间了。

基于NestJs也没有过多的分享可以给到大家、对于代码层面的东西感觉这里段时间也很难概括到位、还是为大家来分享下这个框架中的一些相对重要的模块、希望使用这个框架的小伙伴可以用得上。

• 对于偏底层一点的框架express、koa这类封装度不高的框架、相对来说封装度不高、很多东西需要造轮子、企业级的开发更是拥有很多不同的规范、很难统一、在高灵活开发的情况也也加大了对开发的要求、而对于NestJs这种类型的框架和目前国内用户多点的EggJs来讲差不多、属于便应用层的框架、本身为你提供了许许多多的轮子供你使用、权限认证、路由处理、错误处理等等东西你想要都能方便拿来使用、同时呢框架本身就自带了很多规范性，MVC的分层也很清晰、在NestJs中、依赖注入，pipe，guard，interceptor等机制，基本覆盖各种开发需要，开箱即用、减少很多时间、同时NestJs对于TS的支持度很高、个人对TS研究很少、但是接触的过程中依然能感觉到其规范性更强、语法提示、报错机制也相对非常舒服、在开发阶段也是可以规避很多错误、从框架层面、个人觉得NestJs是可以轻松应对企业级的开发的、完全值得学习一下、这种Aop模式和Java非常相似、对于Java开发者相信来学习这个也会非常快速上手。
• 第一点权限认证、NestJs提供了Guards、Guards 是一个注解式的守卫, 他描述了所修饰的控制器的访问限制是什么。他应该实现 CanActivate 这个接口。 Guards 有一个单一的职责就是决定请求是否能被路由处理。在这之前我们在前端视角中遇到的最多权限认证便是JWT、也就是Jsonwebtoken、我们常说的token、这个呢一般是会加在请求头里的Authorization、实际上还有一个和它非常相像的东西是Authentication、两者非常相似、一个是代表你是否拥有访问身份、没有就会遇到我们常用的401、而另一个则是403、Guards便是负责这个事情的、和前端的路由守卫一样、可以全局使用、也可以局部使用、官方文档中有提到两种、可能还没有太深入学习、个人觉得倒是没有那么好用、感觉有些事情也不太方便、对于企业级别项目、如何这样去控制权限就会显得过去的繁琐、也有点太过于柯里化了、一般个人觉得类似于这样的服务、最后有一套单独的权限系统、通过RPC调用的方式去处理比较合适、这个过程放在哪里呢、可以自定义一个Guard守卫用于全局、在这里拿到token通过解析token在这一层全局做权限认证处理、在这里接入RPC去调用通用权限认证模式也非常方便、官方文档中的那种形式我个人觉得反而有点麻烦了。
• 第二点路由及参数校验、这里的路由和koa、或者express这些大同小异、一个目录树下去依次叠加、但是参数校验这里、NestJs内置了一个管道验证概念ValidationPipe、这个模块呢会结合class-validator、class-transformer一起使用、有什么用呢、我们通常去校验来自客户端的参数会有各种方式、在NestJs需要配置Dto来验证、这一点类似于Java会通过你定义的Dto来进行校验、并且在校验前可以帮你做一些入参转换、什么意思呢、假如我们需要的是一个数字1但是客户端传来了一个字符串1、如果我们不做处理、就会给客户端抛错出去、在这里我们可以通过class-transformer直接把他转换为Number类型避免到多余的步骤、当然这只是一个简单的例子、实际场景下这样的形式确实大有可为、并且节省很多事情、Dto是你定义的规则、并且可以配合Swagger使用、这一点类似于我目前公司使用的Hapi框架加Joi验证这样的模式。对比而言我觉得NestJs的分层更为清晰、每一层的业务功能抽离的各位透彻、可读性很高。
• 第三点我们常用的Swagger文档在这里集成也十分简单、首先引入@nestjs/swagger包、文档有基础配置、第二步直接在main.ts中直接引入使用即可、这里会接口Dto去展示不同接口的验证参数、在接口层需要通过装饰器、例如@ApiTags标识接口、在Dto中使用@ApiProperty来对接口做解释。也是非常好用并且方便的。
• 第四点参数返回、每个后端项目一般都会有一个统一返回格式、不管成功或者失败、我们需要在返回的时候做数据统一拦截处理格式、对于前端而言类似我们的axios的处理一样、统一处理错误或数据。NestJs提供了NestInterceptor拦截器供我们使用、拦截器提供了很多功能、这些功能是受面向切面编程Aop的启发、这一层我们就可以做很多事情、对数据重组、对错误分类、对code码重写等等、这些功能在express这类低集成度框架大多是需要自己手动处理的、在这里我们使用起来更为方便、也只需要两部、第一步创建一个这样的拦截器、第二步在全局引入使用即可、其实不仅仅是拦截器、大多数的集成功能都是这么使用。
• 第五点多环境区分、通常后端项目也有所谓的.env环境配置文件、但是有人问我为什么process.env.xxx拿不到值、这里需要注意的是、在前端环境很多东西实际是框架帮我们做的、我们可以直接这么拿、而在后端中、我们是需要手动去申明这些文件的路径的、一般可以使用类似dotenv这样的库来解决这个问题、否则我们是读取不到。第二点就是一般我们会对敏感信息进行抽离配置到一起的、例如数据库配置、cdn地址、Redis地址等等这样东西、如果一般代码放在私有的的Git还好、如果放公共平台、记得这些东西需要保密、大多这种配置文件一般会通过磁盘挂载的方式放入部署的目录的、这样会相对安全。
• 第六点关于Websocket这种双工通信、我在项目里使用了封装度更高使用更方便的socket-io、虽然两者本质不是一个东西、但是实现功能方面来看差不多相同、对于这种双工通信他和Http的接口是不会共用一个IP端口的、也就意味着他其实是独立于Http之外的、也就需要自己独有的权限认证、对于他走之前的全局通道就不合适了、这一点需要明白、他就是一条需要重新验证的接口、一般可以在初次连接的时候把token带入请求头进行校验、这样验证、同时在部署的时候也需要注意、如果是docker这种部署就需要对外暴露两个端口。而且如果使用Pm2来部署会发现他会使用四个进程运行项目导致出现四个socket的接口这一点需要注意、会出现连接一个ws接口却不在一个房间、要考虑pm2这种部署产生的种问题。
• 第七点关于后端项目的安全、这一点作为一个前端开发确实考虑很少、jwt只是做了一层基本的认证的、很多时候框架也会带很多安全校验、但是我们在业务侧依然要考虑很多问题、例如限制文件传输大小、一天传输的数量大小、一个用户的评论条数限制、防爬虫、图片防盗链、作为前端可能考虑的远远不够、这个也是以后个人需要深入考虑的问题、但是当你写后端项目的时候一定要有安全意识、很多东西不加以限制是会被恶意攻击造成大量损失的。

关于后端项目的见解很少、也不够深入、也是大致为大家分享下关于NestJs的一些基础、个人还是很喜欢这个框架的、可以为大家推荐下可以尝试下、有问题欢迎加我的vx一起进群讨论。

项目部署

一直以来前端对于部署了解较少、如果自己不去实操的话这块儿确实是个盲点、而且对于前端项目而言部署其实非常简单、可以给大家分享几种前端部署的方式。

• 码云[gitee]的Git pages可以免费部署、把项目名改为自己的名、然后去设置选择这个服务可以0成本部署前端项目、这里很简单、如果有需求的朋友可以看看。Github同理也可以。
• 使用cdn、其实前端项目就是几个静态文件、我们可以直接上传到类似腾讯云的这中对象存储中可以直接访问、这种方式非常简单、对于不懂部署又想自己的网站可以被别人看到的时候不妨可以试试。
• 如果不想太小白、想稍微接触一点点部署知识而自己又不知道怎么操作的时候、我们可以去安装一个服务器控制面板、宝塔、这个工具相信很多人也接触过、到服务器安装之后就会有一个后台了、这个官网安装写的很详细可以尝试、当初还在学校的时候、作为小白最开始接触到的部署就是他、这个东西的教程也很多、如果前端对于部署知道不多、不妨试试这个。
• 还有很多部署方式nginx、或者基于jenkins的、基于docker的这些CICD配套也是很多公司所使用的。

部署的方式相对来说比较多元化、个人项目使用的是docker+gitlab来进行部署的。CICD的大致流程都差不多、通过Git的hooks来通知服务器拉取最新代码、然后进行打包部署、这是一个基础流程、在这之间也可以加入很多其他流程、代码什么、测试覆盖率、一些检测、分支、缓存、等等东西都可以在中间的链路加入、涉及CICD的东西相对还是挺多、有时间专门可以为CICD做一篇总结。

项目后期规划

在之前我是没有写博客的习惯的、也觉得自己文笔不好、很难有好的东西产出、能让人理解起来轻松、但是后来想想、文章是给别人看的、也是给自己看的、在写的过程中就能发现很多问题、之前写过一些不是很好的文章依然会有人来添加询问一些东西、让我觉得写东西这件事情是值得的、能被人认可也是一种成就感呢、这是一种双赢、于是才有了来设计一个个人博客的想法。

我一直觉得博客也是一个工具网站、不仅仅只是对文章的分享和记录、他可以记录大而全的可以分享的文章、也可以记录小而精湛的日常笔记、很多东西是为了自己方便、没有必要过于花哨、但是一定要使用、看过很多大佬的博客、相对看起来没那么花哨。

单纯的文章还不足以满足工具网站的需求、所以后续会在博客中加入更多日常可以使用的工具。

• 个人书签迁移、打造自定义的书签管理和导航页、Goole书签虽然好用方便、但是由于网络问题有时候并不是很方便、不如迁移到自己的博客、实现相同的功能并且不担心会不方便迁移、同时拥有一个个人的导航页、自定义的搜索习惯和搜索历史我觉得依然也是可以优化很多必要场景。
• 个人工具网站整合、不管前端开发或者后端开发、我们都有许多自己平时用到的工具网站、例如一些简单的Json序列化,图片压缩转换,文件转换等等这些小工具、我觉得有时间的情况下不妨自己尝试自己去实现、如果觉得这些事情不值当没意义、就收录别人的网站、至少要自己在用的时候更为方便的找到。
• 个人工作流、作为一个自律性不高的人、我常常会因为一些别的事情打乱自己的学习工作节奏、做事拖拉、考虑明年做一个electron开发的个人工作学习管理进度表，希望能直观的知道自己接下来的安排、时间规划、而不是有时候很杂乱的时间线导致效率不高。这一点目前已经在着手准备了、后台管理可以持续集成各种功能、这些额外工单只需要自己不断扩展即可。
• 打造网站子站独立于博客之外的一些对外工具类网站、很多人不明白网站是怎么赚钱的、也不知道盈利方式、其实这一点也确实在前期不用考虑、我们可以做一些工具类网站、很多人对这些网站其实依赖度很高的、做一个这样的网站其实也并不难、我们需要做的就是持续更新并且拥有一个这样的网站可以做seo网站推广、导流、通过这样的方式为自己导流、在有了流量之后、赚钱的方式就多元化了、很多优秀的博主都拥有自己的公众号、小程序、这些大佬都很厉害、平时我们看到的一些公众号推文就是收入来源之一、其实很多事情坚持做我觉得都是会有机会的、这也是我今年想尝试的事情。

如何打造一个个人的工做流

这一点来讲纯粹是我个人看法、我觉得很多人是不赞成的、但是我确实乐于做这种事情、很多事情我觉得自己日常工作需要的东西比较杂乱、导致自己做什么事情都很碎片化、老是不能合理利用好自己的时间、以至于效率偏低、出现每天晚上填TAPD日报的时候突然忘记了自己今天到底干了啥、日常工作中总会有插入的需求、日常自己的学习也总有进度、没有一个记录经常容易忘记、所以我才有了这样的想法。

完善博客功能、也就是上面的项目规划、开发一个electron桌面端工具管理自己所需要的很多东西、学习进度、学习规划、任务等等、也可以把日常工具搬上来、后台管理持续做一些集成配置、我们可以加入一些短信提醒、邮件提醒、或者公众号提醒、各类 操作来加深自己固有的学习方式、这些看似无意义的事情实则可以对像我这样自律性不高的人提高很多效率、很多时候不想学习的时候看看自己的任务列表还有这么多事情、也就能坚持下去了。

这个话题可能过于宽泛且对于很多人并没有实际意义、但是我觉得就目前而言对我还是很实用的、目前这流程还不够完善也很难总结的全、当你实际进入开发的时候就会有许许多多的点是你想要的并且实用的东西出现了。

写在最后

这次的分享很多东西过于广泛且缺少实际场景、只是给大家提供一个思路、很多人热爱自己开发博客、也有很多人觉得博客幼稚且毫无意义、但是我觉得、作为一名程序员、博客也是一份你的简历、很多东西不仅仅要会用也得会写、会总结、会记录、要学的东西太多了、回过头来很多你写过的东西都不一定记得住、如果你的大脑就是一台电脑、是不是也可以再加个固态呢、存更多的东西、整理更好的脉络、有一个好的习惯一定可以在很多时候事半功倍、再者来说、当你在做这些事情的时候、不是已经遇到了许许多多的问题并且解决了么。

2022新的Flag

今年的一年过的很快、但是也有很多的收获、但是远远还达不到自己的预期、新的一年来新的flag希望能在明年的这个时间来一一兑现。

• 按照上面的规划打造一个个人完整的工作流让自己可以更加高效。
• 提高博客质量、在之前的文章中很多都是心血来潮短时间写出来的文章、缺少文章质量、缺少思考、包括文笔也缺少很多东西、所以新的一年希望可以高产且高质量。
• 关于工作、不管怎么看、工作一定是第一位、在工作上要打破目前的固有化、希望自己能在了解业务之后寻找新的方向处于业务考虑、发挥一个前端开发的必要性、能够推动一些新方向的项目落地。
• 养一只猫、一直有这个想法却没有实现、2022我觉得可以去真正的实现以下了。

交换友链

博客刚刚创建还没有太多的文章、希望可以和大家交换一波友链，到我的博客留言即可、期待您的到来。

小九的博客