“全栈”工程师笔记/记一个完整的项目流水账

　　引语：相信很多人都自认为自己是个全栈工程师，不管有没有验证过，我也不例外。心中总有一种傲气，事情都能做，只是做得好不好，时间够不够的问题！所以，对很多事情，我其实是一点不怕的，随着时间的推移，人总是应该要进步的，去做一些没做过的事，才对得起成长二字！
　　刚好上上个月，公司有一个新的项目需求，需要做一个全新的系统，但是看起来也不难，所以任务就交给了我。我可以说我是这个项目负责人吗？应该是可以的！但是，最开始就已经存在了一些坑，等着我去跳，比如过需求的时候，我却不在场！总体算下来，流程是这样的：

　　一、过什么项目需求？
　　　　需求肯定是要过的。
　　　　1. 要做什么？
　　　　2. 哪些能做，大概要多久可以做好？
　　　　3. 哪些不能做，为什么不能做，替代方案是什么？ 
　　　　4. 功能的必要性，哪些功能是必须的，哪些是可选的，哪些是多余的，以后的方向是什么？
　　　　 整理过需求后，大概就知道整个项目是什么样的了。

　　二、写什么计划文档？
　　　　由于是公司内部使用的平台项目，说什么不需要美观之类的，全部的基础就只有一些抽象的原型图，其他的全部工作就交给开发人员（最开始就只有我本人，后来加入了一位多年开发经验的大师兄），因此在我计划里写了，静态页面模板编写：3天。
　　　　因为只有我本人干，所以，在写项目计划文档的时候，我只管按照我的个人意愿，就把时间给评估上去了（这最后被证明是自己给自己挖了大坑），各种功能，我几乎都以1天2天或0.5天来算，功能点也是写得比较抽象。因为毕竟，计划这东西，就是一拍脑门想出来的事。
　　　　最后，把计划发给领导时，领导说，开发时间太长，能不能再短一点（我当时几乎是崩溃的，因为我已经尽量把时间压缩了）。其实我也理解，领导的意思是尽快完成。
　　　　基本上所有的计划都会被一定程度上的延后，所以，领导让你早一点的意思，其实基本上也是让你按照这上面的时间来完成。
　　　　计划就是你做事的证据，不可大意了！

　　三、划分什么模块？
　　　　这一块严格来说，很多项目基本算不得是一个流程的，至少我这个项目算不得，因为，其实就几个字就描述清楚，扯那么多干嘛呢，哈哈哈。。。

　　四、设计什么数据库？
　　　　这个是非常重要的环节，如果把这一块做好了，会给以后的工作减轻不少压力，如果没做好，后面将导致各种问题，尤其在不是你一个在做事的时候，又会增加许多的沟通成本！
　　　　设计的基本原则就是，看需要些什么信息，有哪些信息是公用的，会在哪里产生其他效果，详细参照需求文档，适当考虑扩展性！
　　　　这个环节，一定要让领导过一下的，他知道的比我多，考虑的点和我也不一样，关键是，最后出事了，也算是心里有个底，毕竟领导自己看过了！
　　　　然而，很奇葩的是，对于这个重要的环节，我几乎只花了不到一天的时间就完成了！

　　五、搭建什么框架？
　　　　由于公司不让使用外面的框架，而且其他项目的代码，目录结构混乱，所以决定使用内部框架，进行构建系统。但是，内部框架还明显不成熟，就连一个像样的帮助文档都没有，唯一的一个帮助文档是框架目录中的一个readme.md,使用了极为简单的文字描述了功能。
　　　　不过，最终，我还是看懂了他的框架，并顺利使用到项目中，当然，继承框架的一些东西，改掉不好的以适应项目或者个人习惯，这是必须要做的工作。并将需要使用的插件，目录，扩展都给弄好！这样以后，只要往既定的目录下写自己的代码，修改即可，相对来说，结构还是很清晰的！
　　　　把前几天写好的静态页面嵌入代码中，这样，整个项目就算有了真正的样子了！
　　　　把最基本的验证一类的工作做在这里，可以不实现具体功能，但是位置一定要预留！
　　　　使用到的东西有：内部PHP框架、bootstrap、Jquery、Jquery.form.js、My97Date、validform、layer、cron、Redis、微信接口、内部通信接口...

　　六、写什么主要功能？
　　　　根据业务需求，首先把主要的功能给实现了，让页面动起来。其实，大部分的需求，都只需要通过增删改查，就可以完成效果，但是复杂的逻辑，还是需要仔细屡屡的。
　　　　主要功能实现后，还需要其他各种基础数据辅助，把这些环节给做出来。
　　　　在这期间，遇到了一些有难度的问题，发现时间不够用，领导也发现了，偶尔会来催一下项目进度，最后，让那位大师兄加入其中，辅助完成任务。如果没有他的加入，我想，这个项目真的要延后很多了（尽管他加入后，也有一定程度的延后，所以，领导毕竟是领导，他才是掌舵人）。
　　　　前面写的计划，其实在这个时候是不太起作用的，因为之前很多功能点都没有评估到，在这时候加进来，只有自己默默加班赶上，说多了，就是无能！

　　七、做什么脚本辅助（消息处理）？
　　　　需求中，需要服务器中进行处理一些工作，完成后通知到数据库及相关人员，所以，需要写相应的脚本去做这些工作，主要为配全redis进行队列接收，另一个定时脚本隔几分钟执行一次，定期处理消息队列的东西。这个工作在我本地来说，相对是不容易操作的，因为需要模拟服务器处理的工作，完了之后再进行通知，再进行定时脚本执行，如果我是在linux环境下进行开发，那这也是ok的，然而我是在windows下开发...
　　　　把这一步做完以后，基本上大的东西就算做完了，这里要注意的就是并发和锁的问题，你能不能允许同时执行多个实例，得考虑清楚。

　　八、页面优化，项目部署
　　　　把主要功能实现以后，可以好好再去调一下页面了，当然，几乎所有的工作都是在之前做的，但是这个时候，最好还是要有这么个过程，算是检查一下也是可以的！连接到测试服务器，进行自己测试的阶段，服务器也已经部署完成！

　　九、转接测试，迅速更改
　　　　项目进度没有及时到位，但是，我还是将工作推进到下一步了，转接给测试人员。当然，有幸我遇到一个好测试，他绝对算得上半个开发了，没有他的监督，这个项目怎么敢上线，一方面，测试在测试功能，另一方面，我们加班加点，把问题解决，这个时候的工作推进还是挺不错的，只是，自己的bug列表里面，添加了许多的记录，多得你都不敢想！
　　　　但不管过程如何，最后的荣耀始终是有的，在上线的那一刻，所有的bug都不是问题了，哈哈哈。。。

　　十、产品介入测试
　　　　测试通过之后，产品才算是正式介入到检验中来，虽然个人觉得这怎么也有一种，事不关已高高挂起的感觉，但是事情也就这样吧。再一次有人介入，项目又再一次进入快速更改状态，但是都已经不那么多事了，改起来也非常快。进度快速推进！

　　十一、线上删档测试
　　　　删档测试，这TM谁想出来的，所谓的线上测试，不过是对自己产品的不信任，我们再一次在线干起了测试的工作。但是，至少可以可以向上上面的领导交差了吧！

　　十二、正式上线
　　　　终于，上面催得急了，赶紧上线，上线，上线。终于可以回家睡大觉了，那一晚，真的睡得很爽。。。

　　十三、补设计文档
　　　　忙着开发的事，一直没时间写文档，做完之后，把这东西补上，否则，新来的人怎么看？？

　　十四、监控措施
　　　　没有监控措施的系统，是不信任的，出了问题你都不知道，这可不是一个有经验的人干的事，不过晚点补也是可以的，毕竟这东西也有一个完善的过程！

　　十五、后续功能
　　　　本以为把东西做到这里，就算差不多了，但是，明显后续工作还有很多，比如功能增加（干），比如数据压力变大（分表分库集群），比如与其他系统的对接（接口），我拭目以待。。。

　　本项目其实算一个小项目，但是，从最开始的一无所有，到最后系统形成，几乎所有地方都介入，这个我不知道算不算全栈的表现，至少也算是之前没有的体验吧。以前都是跟着大牛们做事情或者拿现有的系统进行更改，很多基础的东西，都不用你来做，如果一直这样，我想，经历不能算是完整的！

　　随着时间的推移，故事还在继续，用时间经验填写的故事，才够真实，至少对于自己来说，是这样的！