共计 976 个字符，预计需要花费 3 分钟才能阅读完成。
很多人都会用项目脚手架，也会跑 hello world，然后再写写简单的 todolist。但是再往下深入就难了。比如很多教程和老师都会说，大家要多问一个为什么。其实我想说多问你妹啊。我都不知道问为什么怎么多问？！比如如果我不说，很少有人会去思考和研究为什么 vue 的项目目录要如此设计，这么做好处。
先不说说别的，我们先看看 vue 的目录，一图抵万言，不墨迹。
好的项目代码结构会大大提升项目的维护性和可扩展性。同时我们可以提供友好的说明，以便其他成员理解项目和快速定位。
其实有一点比较重要，就是公共组件、工具等同类的文件，放置一起维护会比较好。而且还有个小 技巧，我们可以在搭建项目的时候，在 README.md 里面描述下该项目下的代码和文件结构。
多说无益，我这里直接给大家一个示意图，大家可以按照我给的这个项目结构组织项目。
这里我强调两点，
1. 第一点注意每一个组件的大小写。
2. 注意每个组件所用到的图片的位置。
很多人写组件的时候被命名或者大小写或者分隔符弄的晕头转向，这里我就说说代码规范。
代码规范其实是团队合作中最重要的地方，使用相同的代码规范，会大大减少我们接手别人代码时候卧槽的次数。
好的写码习惯很重要，命名习惯、适当的注释，会对代码的可读性有很大的提升。但是习惯是每个人都不一样，所以在此之上，我们需要有这样统一的代码规范。
一些工具可以很好地协助我们，像 Eslint、Tslint 等，加上代码的打包工具协助，可以把一些规范强行标准化，来获取代码的统一性。还有像 prettier 这样的工具，能自动在打包的时候帮我们进行代码规范化。
除了这些简单的什么驼峰啊、全等啊、单引双引等基础的规范，其实更重要的是流程规范。最基础的是改动公共库或是公共组件的时候，需要进行 code review。通常我们使用 Git 维护代码，这样在合并或是版本控制上有更好的体验。
但其实最重要的还是沟通，沟通是一个团队里必不可少同时很容易出问题的地方，要学会沟通方式、表达方式。
很多人觉得命名了或者项目目录了这些不重要，非得把复杂的功能实现出来才牛逼，这才是技术大牛或者脑袋上闪耀着光环的架构师的范儿。其实，项目的维护所有程序员都需要，而且要想成为一个架构师，你写的代码别人是否能看得，用着舒服，架构是否健壮可扩展，这些是基本功。你连文件目录都设计不好，我拿什么相信你能设计出来可扩展的程序？
