我是如何开发一个项目的
Posted 看，未来
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了我是如何开发一个项目的相关的知识，希望对你有一定的参考价值。
碎碎念
鉴于这个毕设已经重写第三遍了，我觉得有必要写这么两篇来指导一下我自己了。
第一篇是《我是如何开发一个项目的》，从我浅薄的项目开发及带队经验总结，并以这第三次毕设作为实战指导，写好之后可以为以后做项目起一个指导作用。
第二篇是《我的毕设实战指南》，目前毕设的业务是定在了“仿12306”，不出意外不会再变了。第二篇将总结以往和这两次的失败经验，老老实实的把项目分析做好，不能再重来了呀，真的要吐了呀。。。
明确为什么要开发这个项目是很重要的
1、明确为什么要开发这个项目是很重要的，可能有的人会说：我在公司，老板让我做，我就做呗，想那么多，拿多少钱干多少事儿。这是一个想法。可能有的人会说：这是我的课设/毕设，不做等着挂科，到时候毕不了业怎么办？这也是一个想法。为什么我要第一步把这个环节提出来呢？因为这涉及到了动力问题。
听说过一个词，叫“始乱终弃”吗？错误的开始终将导致悲惨的结局。例子很好举，我毕设选的第一个业务是秒杀系统，但是后来发现这个业务太单一了，于是一周之后转变了。转为了学生管理系统，但是后来我发现，我做这个项目的初衷是想着后面横向拓展为那种可以支撑大流量的系统，那明显这个业务模型又是不行的。这次我单体架构都写好了，又转型了。目前转为了“仿12306”。
这次停下来，是因为CentOS系统崩溃了，把我东西全搞么了，逼迫我停下来思考。
项目组长首先要自己想清楚在这个项目对于自己的意义是什么，然后要指导组员一起想明白这个项目到底是为了什么。这可以根据团队的属性来自由选择思考方式，
有的团队比较沉默，坐下来来个茶话会就解决了。有的团队思维比较迸发，就坐下来来个头脑风暴。有的团队比较年轻，那就来一波团建呗。这里可以吸收别的领域的声音，听不同的思想，可以有助于自己和团队成员打开眼界。
至于我为什么要写这个项目，在第二篇里面写。
需求分析
这个环节嘛，自己做项目的时候是需要自己考虑的，比较自由一些，当然，也比较容易跑偏了。自己做项目的话这些东西都是需要自理的，一开始没有选好的后果算是体会过了。
然后周期也很重要，在这次的毕设项目上，刚开始我想的是反正有大把时光，慢慢磨，总会磨出来的，然而结果就是一天拖着一天，而且目标实在太庞大了，就导致后面看着就怕了。
其实这里就涉及到一个以前没有遇到过的问题了，时间太多导致定的目标太大，目标太大导致无从下手，最后导致放弃（好吧，不是第一次遇到这个问题了，只是以前没有去解决而已。我记得之前就有一个学生管理系统的项目，设计了1.0版本，后面就只剩一个需求分析书了。。。）要解决这个问题，就需要下一步的策略了：
项目设计之螺旋式上升
胃口太大导致后面吃不下去，饭要一口一口的吃嘛，先来个1.0版本，然后一个一个版本的迭代上去，最后完成一个“庞然大物”。
我记得这是我做“学生管理系统”那个项目的时候去请教老师，老师看了我繁琐的设计图之后说的。
现在想想，那点业务还是 hold 住的，只是一开始框架设计的太复杂了。而且身边没人，，，，
一开始要把心中所想的几个版本都画出来吧，不然做着做着就忘了最初是怎么想的了。
每个版本应该对应一定的工期，划分清楚才不至于懒散乱套。
“备忘录模式” 开启
我发现这个思想是那么的优秀，那么的正确！！！
一份环境，至少要两份备份。
一份代码，至少也要两份备份。本地一份，github一份。本地那份方便随时查阅，github那份防止你系统突然崩溃了。哎，一把辛酸泪。
此外，在对代码进行修改的时候也要做好备份，一旦测试崩溃了还能复原。
测试做在前
每个模块都应该有它自己的测试机制，写一部分就测一部分，不要等到最后都写完了来测试报了一把的错，单体架构的时候这样玩玩也就罢了，多花点时间还能调的过来，多线程一上，横向扩充一把，到时候哪里崩了都不知道。
先写这些吧，要去画图了，以后有新的感悟再添加。
以上是关于我是如何开发一个项目的的主要内容，如果未能解决你的问题，请参考以下文章