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

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

  一、过什么项目需求?
    需求肯定是要过的。
    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谁想出来的,所谓的线上测试,不过是对自己产品的不信任,我们再一次在线干起了测试的工作。但是,至少可以可以向上上面的领导交差了吧!

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

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

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

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

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

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

posted @ 2016-05-14 11:44  阿牛20  阅读(1978)  评论(2编辑  收藏  举报