CreateArtTechnology / Blog
  • CreateArtTechnology再次进化
     13     2018-09-22 02:53:18

    引C.A.T已经建站好几年时间了,从Php到Java,从纯手撸到Spring Struts Hibernate,再到Spring SpringMVC Mybatis,进化过程可谓是从无到有,但随着自己工作经验丰富,越发觉得这样的开发模式非常难以管理,非常影响效率。
    Php开发时期的历程纯手撸代码,无任何框架,前后端耦合,数据库直连……加上本身对Php就不怎么熟悉,仅因为“对Java web开发更不了解”和“课程作业参加过Php web开发的一个模块”这样的原因才选择了Php。实际上这样的模式即使开发一个模块也非常耗时。一来开发环境糟糕过时,二来没能使用自己熟悉的开发语言和工具,很费力。Php时期的痛点:花了几个月时间,最终花了大量时间在整一些简单的功能(因为不懂,模块耦合度太高),到手一个半成品,可以说这段时间对自身能力几乎毫无提升。
    SSH开发时期的历程痛定思痛,坚决要利用好自己唯一的长处,也就是Java语言学得不错。当时SSH(Spring Struts Hibernate)这个整合框架的教程非常多,尽管没多久也算比较过时的框架了,但对于需要理解框架、解耦的新手来说仍然算得上合适的学习机会。这段时间,开发效率有了质的提升:一方面Java语言熟悉,学习较快;另一方面框架本身就是非常解放生产力的,尽管当时对于很多细节并不十分了解,但能够认识到Spring、Struts、Hibernate是做什么的,一旦用上就停不下来,对于后续的框架更换做了充足的知识储备。最后整个网站已经达到可以正常使用的地步了,好像看起来和其他那些大站也没差太多嘛!(呵呵,naive)总之当时自己还挺满意的。SSH时期的痛点:配置工作仍然繁琐,Spring需要配xml文件,Struts需要配xml文件,Hibernate的注解配置更是麻烦得不行。同时,对前端工作不太了解,前端渲染用jsp,而css和js也不知道去抄抄别人的,通常一半多的时间花在各种样式调整(强迫症)。
    SSM开发时期的历程如果说上述阶段都还是学生时期自娱自乐,那么见识过真正的生产环境开发后回头再看那坨代码,这都什么玩意?二话不说拿SpringMVC换掉了Struts,Mybatis换掉了Hibernate,整个网站重构。生产环境的开发模式只需要两点,1.开发效率高;2.开发质量稳定,至少bug少好修复。SSM大量的注解配置,节省了大量的开发时间,避免了很多容易因配置产生的问题,使得开发工作可以用最快的速度完成,迅速进入下一个迭代周期。前端方面,得益于公司的代码作为模板,也算是弄清楚了前端的渲染大概是怎么一回事,使用Velocity引擎渲染的同时也拿来了AmazeUI快速完成样式开发。这个时期可以说已经把公司学习的东西用得比较顺手了,很多事不用再各处搜索自己能搞定了。SSM时期的痛点:代码环境虽然已经到了生产标准,然而整个网站的架构、迭代模式、管理策略仍然还在石器时代。说白了,整个服务器上也就跑着一个Mysql,一个Tomcat,远没达到生产环境的目标,完全就一个单人小作坊,虽然事实就是这样,但也得有点追求对吧。更详细点说,有这几个问题:
    开发容易,发版麻烦。没有自动化部署工具,每次从tomcat的manager中上传war文件,手动重启tomcat。好歹公司的发版流程我都滚瓜烂熟的,不整一个浑身难受。前后端耦合,思维切换麻烦。一个人做前后端最难受的不是写前端代码,而是在写接口时考虑前端的实现细节。我需要一个完全的身份切换,当写接口时,可以独立开发、调试,不需要管前端。没有图片服务器,所有用到的图片直接保存在webapp子目录中,如果重新部署,可能还得把图片备份,风险太高。经常有实验性的开发Demo,没有地方保存,只留在公司电脑里,很可惜。部署时服务不可用。
    未来的C.A.T鉴于上述痛点,我个人倾向于建立与公司类似的生产环境,提高开发、迭代效率,减少管理难度,降低各种风险,并且能用最简单的方式集成更多实验性的,好玩的内容,顺带见识一下更广阔的世界。
    ......