• 博客地址 替换友链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我感觉能够去真正的实现以下了。
替换友链

博客刚刚创立还没有太多的文章、心愿能够和大家替换一波友链，到我的博客留言即可、期待您的到来。

小九的博客