前言：假设你具备了开发所需要的知识，有一天你灵光一闪，脑子里有了个绝好的主意，你需要做个web项目来实现它，而它又是一个独立的项目，你可能会放到公司层面上开发，也可能随便找朋友来帮忙，亦或者是一个人实现这个项目，本文说的就是一个人做一个项目的时候的切入点和注意点。
一. 三思而后行
当你被自己的想法激起心中豪情的时候，一定要按下心情，冷静的思考一下，思考点包括以下几个部分：
这个web项目所需要的知识和能力是否在自己所掌握的范围内，这个是技术前提，如果项目本身技术复杂度过高，那么你在开发的时候所面对的压力就非常大，而且挫败感也很高，项目很容易夭折。
项目的需求能否清晰描绘，这一点非常重要，因为只有你能细致的把一个项目拆分成一条条需求，你才能对所有的技术实现点有个预估，也才能对项目所需要的时间做个预判。关于这点最好是自己花一个架构图去理清思路。
项目是否值得做，这个是个预防针，实际上很多时候个人项目都是拍脑袋想出来的，由于刚开始没有想好就一腔热血，一上来就开个项目工程文件开始啪啪啪的写代码，很容易做着做着就没有动力了，最后有一天突然觉得这玩意也没啥意思，于是草草的扔了，虎头蛇尾的情况太常见了。
技术选型怎么做，是做一个网站还是做一款app或者是多平台的，后端用什么语言来搭建，需要使用什么框架，这些选型需要在心中有底，我建议做项目的时候选用自己最熟悉、生态最丰富的语言和框架，除非你只想练个手，否则不应当用冷门的。
所以项目未动，思考先行是必须的，通过仔细的思考我们可以判断自己所谓的“灵感”是不是伪灵感，而自己又能否适应开发期的单调枯燥，这些需要慎重对待，不能掉以轻心。
二. 产品需求清单
经过仔细的思考之后，依旧觉得项目可行的话，那么就应该进入“产品经理”的角色，作为一个人的项目，产品需求倒未必只能是一个人思考，也可以找朋友等人探讨，征求一下别人的想法之类的。
产品需求需要确保每一步都能执行，所以理论上越详细越好，在你思索产品的时候，你应该对界面上所需要的具体元素有清晰的认知，而且还对它牵扯到后端的功能如何组织和拆分。
在产品需求阶段，也是你把项目原型丰富的阶段，这个时候其实至关重要，很多时候你会发现你真正想要的和你原本打算要的已经完全不同了，最开始的打算可能根本行不通，同时你也有可能蹦出新的灵感，这些又会对原有的产品需求做或大或小的更改，说不定还会推翻原有的需求。
基本上到这个时候，原本的激情已经逐渐平淡，理智重新归位，但对产品未来的期待感还是很强，这时候你需要考虑的情况实际上是非常多的，也是你容易失眠的阶段，所以应当好好调整心态。
做产品需求的时候，你可能需要几个流程图，依赖图这些对功能的划分，多使用脑图软件来构思自己的产品，也尝试思考流程是否能简化，站在用户的角度下使用是否方便，哪些功能是主要的，哪些是次要的。
如果觉得文字描绘不清晰的话，你也可以自己做几张原型图出来，注意这不是高保真图，只是让你自己弄明白这个产品的某一页或者某一块，不应当把心力花在细节上。
总之在这个阶段，应该有大局感，而且也应当仔细打磨自己的想法，如此三番之后要给自己定下个初稿，因为你之后的时间很有可能会蹦出很多个想法，扰乱原有的安排，所以你需要在前期有个原则坚持住，以防心不定而一事无成。
三. 界面的设计
web项目的一个重要部分就是界面，它可能指的是浏览器前端，也可能指的是某个手机平台的UI，我们这个时候需要花些心力在设计方面，包括UI的设计和交互设计。
由于大部分开发者很难有良好的设计感，如果有设计师朋友的话也可以请他们帮忙，否则的话可以多去一些设计网站(比如dribbble)，多收集一些美观大方、符合自己要求的界面，从而形成对自己项目的认识。
如果有能力做高保真界面的话，那么请一定要做，不要觉得做高保真界面的图片是浪费时间，不要因为你觉得写html/css更省事就直接开敲前端界面了，你在做图的时候所思考的和你敲界面代码所思考的其实并不是一回事，前者会让你更加着重设计感，而后者更偏向于实现。
在这个期间里需要多观察观察别的网站/应用的界面，找出那些自己喜欢的，然后询问自己哪部分是自己喜欢的，如果放在自己的项目是否可行，能完整表达我们之前的需求元素么？
很多人在做单独项目的时候，前期花在界面设计上的时间极少，都是脑子有一个大概，然后边写代码边脑补界面样子，写着写着就走了样，最后弄出来的界面是混杂的，看上去很乱。
3.1 界面设计建议
· 如果自身不是专业设计，就不要采用复杂的界面，那么设计界面的时候请走扁平化，一个web页面/app 页面的颜色请尽量保持两到三个，并维持一个主色调，其他的使用同类色系。
· 如果是手机app，那么请和平台推荐的设计方向保持一致，比方说如果是ios app，那么应当参照ios的原生应用来做设计，而如果是android app，那么请使用material design的规则，不要妄图利用相同的设计做不同平台的app，容易变乱。你使用原生的平台设计，就算设计感不强，也不会显得杂乱无章。
· web界面的设计应该有自己的特点，我知道很多做单独web项目的人喜欢用开源的web前端框架，比如bootstrap、amaze UI这些，虽然节省心力，但是做出来的界面大同小异，容易疲劳，浏览器上的界面和手机app不一样，它屏幕更大，可以表现的也更丰富，如果实在要用开源web框架的话，也要尝试换换色系之类的。
· 心态要好，大多数的时候自己设计的界面，是挺难看的，别因为这事挫败了做项目的积极性，也别想一口气做出来个美轮美奂的UI闪瞎大家的眼，毕竟不是职业的设计师，不要和自己怄气。
3.2 界面实现
在界面基本定稿的时候，这时候我们可以来正式实现界面了，我们之前技术选型的时候应该考虑到前端需要用到哪些技术，比如说做web界面的时候，是否需要做成one page application，是否需要使用前端库等等。
web前端现在环境变化非常大，已经由原来的做页面转成应用化了，所以配套的工具也变得多、杂、繁了，选型的时候还是需要注意选自己熟悉的，生态圈好的，在这一点上，框架上有vue、react、angular比较知名，我个人比较喜欢vue，它上手还是蛮快的，如果想做应用式的web产品可以选用。
android app的客户端如果你以前使用非android studio来编写的话，那么这个新项目就换用android studio吧，它已经足够好用了，在做界面开发的时候，推荐使用那些大热的开源组件，比如说fresco、rxjava、retrofit、gson这些，可以节省大量心力，组织代码的话使用MVP或者MVVM模式也能让新项目变得容易维护，推荐使用，之前我也写过一篇关于MVP应用的文章：Dagger2的应用——MVP+Retrofit+RxJava
如果你写的是ios app的话，不要在语言上（OC或者swift）来犹豫，事实上这两门语言都能很好的完成一个app的构建，而且还可以混合编程，同样的，在开发app的时候请大胆使用开源库，比如masonry、reactivecocoa或rxswift，cocoa touch原本的MVC模式也很清晰明了。
如果自己想实现多平台的web应用，可能会使用react native这类工具来完成app开发，说实话比起原生语言开发app，它对web开发者来说更友好一些，如果有RN相关经验的可以尽情尝试。
现在不管web开发还是app开发，都可以把前后端切断，让后端作为数据输出方，不过有时候我们的web项目可能需要对SEO友好，所以可能需要花心力在同构上面，也就是在前端和后端都维护相同的路由和相同的模板渲染，代价也是比较大的，当然也可以像传统开发那样完全由后端render view，具体情况自己考虑。
四. 后端接入
后端开发牵扯非常广，所以我们不太可能是把前端做完了再做后端，一般情况下，做前端和做后端是交叉并行的，这一点其实是在模拟团队合作的情况，只不过身兼多职。
后端这边我依旧推荐选型的时候选择自己最熟悉的，如果熟悉某款框架的话，那么尽量用框架，后端开发的语言并没有什么限制，可以在下面几种语言里选择：
传统语言：Java 、C# .Net
传统脚本语言：php、python、ruby
新兴语言：node.js、golang
用来作死的：C/C++
一般情况下，我推荐脚本语言来开发web应用的后端，前几年ruby on rails框架流行的时候，带来了非常快捷的开发方式，随后其他语言也都相继出现很方便的web框架，其中有大型框架，也有微框架，具体的抉择可以看一下我之前的文章：除夕乱谈web微框架，从koa说起
一个重点是我们可能要考虑数据库的问题，需要对常见的数据库很熟悉，并且能够合理的抽象出schema，以及合理的建立索引，多表之间如何联合，这些都是和需求紧密相关的，只有深刻理解了自己的需求，才能做好这些事情。
后端开发的时候建议使用ORM，如果框架自带ORM的话那就用框架自带的，如果不自带可以选用社区开源、生态圈丰富的ORM，需要注意有些ORM本身bug比较多，坑也多，只能多踩踩才知道。
我们刚开始可能只是简单的增删查改，不过随着加入用户体系、身份验证、权限划分、内容过滤等等需求之后，就可能需要你合理的规划好控制器的代码，我建议大部分情况下做成一条条service，然后做串联调用。
后端开发要注意网络安全，用户身份的存取，内容数据的插入，文件的上传这些容易出问题的地方都需要格外注意，不要因为自己做的小就图省事，弄个满是安全漏洞的网站，还不如不上线。
缓存机制其实对于并发高的时候效果很明显，在设计后端的架构时候，也应当考虑到哪些部分可以用缓存代替，我们常用的memcached或者redis都是缓存利器，非常建议配合使用，不要在意你的网站是个小网站。
有时候需要考虑定时任务或者异步任务队列，这个时候我们可以选一些好用的工具，比如说用redis、开源MQ或者是专门用来做任务的任务调度器之类的，我之前写过一篇关于任务队列和任务调度器的文章：浅谈任务队列和任务调度
后端开发注意主次，有的时候增加或者修改一个功能，其实牵扯到不只一块区域，所以尽量保证抽象层次要高一些，代码耦合也要低一些。
有些页面是用来获取数据的，而有些是用来处理数据的，我们对这些部分要分开出来，也可以采用RESTful这种API 设计的架构，把功能抽象成资源，转而对资源进行增加或者修改。
