项目完成之后, 当然不能满足于在我们的开发环境下跑一跑. 我们可以打包发布到服务器上, 让大家一起来欣赏一下你的作品.
那么 vue 项目如何打包发布呢, 新建的项目目录下通常都有一个 README.md 的文件, 里面就描述了发布的步骤:
下面这个是 vue-cli 3.x 创建的项目中的 README.md 文件内容:
- # firstpage
- ## Project setup
- NPM install
- ### Compiles and hot-reloads for development
- NPM run serve
- ### Compiles and minifies for production
- NPM run build
- ### Run your tests
- NPM run test
- ### Lints and fixes files
- NPM run lint
- ### Customize configuration
- See [Configuration Reference](https://cli.vuejs.org/config/).
这里描述了常用的指令, 我们需要的那一条就是:
NPM run build
这运行这一条命令就可以将项目打包成一个 dist 目录, 里面只有静态 html 和 JS 文件.
打包
NPM run build
运行上面的命令, 运行完成后就可以看到项目的根目录下面多了一个 dist 目录:
打开我们可以看到一个 index.HTML, 但是你直接打开是一片空白的.
这里就需要将其托管到一个 web 容器中, 比如 iis, apache, nginx 等等, 有兴趣的童鞋可以自己搭建上述中的一个然后将打包的目录上传上去看看效果.
写在最后
这个小项目其实瑕疵很多, 包括登录后的逻辑, 发布文章时登录的验证等等, 但这个项目毕竟是一个用来熟悉 vue 框架的. 因此若羽并没有打算在这个项目上花太多功夫, 让其变成一个完整的, 简洁的, 真实可用的博客系统 (其实已经完成大半的功能了), 毕竟这样对于新手来说引入了太多不相关的因素, 不能很好的专注在如何使用 vue 上. 相信从头一步跟着文章学到这里的童鞋已经能够自己写出来一个真正的博客系统了, 除了后端接口以外, 不过这里我们可以使用 postman 的 mock 功能, 系列文章中也有相关教程.
所有文章中的接口均是来自 postman 的 mock 功能噢.
后续的文章会开始实践如何优雅的写代码了. 好的代码会增加可读性, 降低团队协作的沟通成本, 同时也能增强项目的可维护性, 可扩展性等等.
从另一方面来看, 代码能写的更好, 为什么要写的差呢?
请务必无视网络中流传的所谓代码越烂越好, 最好写到只有自己才能看得懂的地步, 才会成为公司不可或缺的中流砥柱.
这不是优秀, 不是生存宝典, 而是不负责任!!!
成为公司中流砥柱, 受部门领导和同事认可或者是更优秀的人, 不是想着取巧, 而是要真材实料 (不一定是编码能力, 比如能很好协调和同事之间的关系, 可以为领导出谋划策, 可以为团队带来欢乐, 技术提升等等).
不关从事哪一行, 都要努力让自己变得更优秀, 而不是捣乱.
代码越烂, 那么越难以和别人沟通, 如何进步? 并且团队其他人无法阅读和维护, 如何保持和同事在项目上的和谐? 以后面试时, 和面试官说曾经有一个只有你自己才能维护的系统, 自己用了多少手段让同事没办法看懂代码么? 如此作为, 实在损人不利己.
这样达到中流砥柱的背后, 不过是穷途末路后的挣扎而已. 如此行为, 谁还能信任你, 哪天埋个雷把大家都 boom 了么.
因此, 若羽在这里倡导并向大家提出建议:
为自己的代码负责, 为自己负责.
从个人的角度:
可以让自己的代码更具可读性, 不再害怕历史代码
方便的与他人交流
锻炼自己的思维, 每一个变量名, 函数名, 文件名的思考都能让自己的思路更加清晰, 每一个文件存在的位置, 让自己对于项目的结构有着更清晰的认知
这里推荐两本书:
《代码整洁之道》
《重构改善既有代码的设计》
很值得一看.
来源: https://www.cnblogs.com/By-ruoyu/p/11197274.html