菜鸟要做架构师(一)——怎样高速开发中小型系统
俗话说:不想当项目经理的程序猿不是好的架构师。
相信每一个有上进心的程序猿,都有一个架构师的梦。
近期完毕了一个中小型的项目,让我有了一些感受和想法,于是决定新开一个系列——《菜鸟要做架构师》。
经常看我博客的人应该了解,我写了好几个“菜鸟”系列了。有非常多人问我,你都是大牛了,怎么写博客还叫菜鸟?有人认为太过低调了。也有人认为这是在装B。事实上呢。我是认为自己真的还仅仅是个菜鸟。
就光拿计算机行业来说吧。就有太多太多的知识我不懂,甚至连听都没听过。
记得高中有位老师说的话让我印象特别深刻,大概意思是:越是一知半解的人,往往越是喜欢高谈阔论;越是知识渊博的人。往往越认为自己欠缺非常多(哎呀,如今说这句话。有点装B的嫌疑,罪过罪过....)。所以我认为要保持一颗谦卑的心,才干够不断的学习并提高自己,所以用“菜鸟”二字来自勉。好了,好像扯的有点远。以下咱们进入正题。
项目背景:
这个项目是给廊坊市政府做的,本来这个项目是别的公司做的。后来由于种种原因,不做了,留下一个半成品。我接手的时候。他们给了源代码和数据库,另一些简单说明。
差点儿没有不论什么需求和设计文档。经过多方联系和沟通。他们给出的答复是:没有文档!最后经过大家讨论认为在他们的基础上继续开发,成本较高(须要弄清楚他们的代码以及数据库,他们给的库总共同拥有四百多张表)。所以最后决定又一次开发。
重构:
尽管文档一无全部,好在利用他们给的源代码和数据库。他们的项目还是搭起来的。能够简单的看看页面,也对一些需求有了大致的了解。也发现了一些他们前端框架存在的问题,最严重的问题就是浏览器的兼容性。
经測试发现,页面显示仅仅有在IE7和部分国产浏览器下正常显示。在其它IE版本号或者其它内核浏览器,甚至是非常多双核浏览器下都是那种根本没法用的程度。
技术选型:
前端框架
前面已经提到了,之前的项目在浏览器兼容性上存在着严重的问题,所以我们在选择的时候要考虑到这个因素。结合手底下开发者的技术水平以及用户的需求,我们终于确定用dwz作为我们的前端框架。
可能会有人认为dwz不好,Ext更好如何如何,还是那句话合适就是最好的,杀鸡焉用牛刀。个人认为dwz在应对中小型的项目时。还是非常不错的。首先。浏览器兼容性不错,经过我的不全然统计,dwz不管是在IE、Chrome还是FireFox的各个主流版本号。都能够正常工作,各大国产浏览器也都完美兼容。还有,就是它上手比較easy,对于高速开发小型项目非常合适;当然。选择它另一个非常重要的原因,项目组的人对于dwz相对熟悉,能够高速投入战斗。
核心框架
眼下最经常使用的也就是以下几位了:Spring、Struts/SpringMVC、Hibernate/Mybatis。
一般说来Spring的入选没有什么争议,主要就是MVC框架用Struts还是SpringMVC。ORM框架用Hibernate还是Mybatis。
这四个都是非常优秀的开源框架,技术上都非常成熟,不管怎么组合都能够非常好的完毕我们须要的功能。
详细怎么选择,还是的回归实际。
结合开发者的技术特长,以及相关资料的丰富程度,和遇到问题解决的成本来看,Struts和Hibernate更加适合。首先,组员对于Struts和Hibernate更加熟悉;Struts和Hibernate相比SpringMVC和Mybatis也有着很多其它的用户,相关社区也更加的活跃。有什么问题当然解决起来也就更easy一些。
综上所述。基础框架为:Spring + Struts+ Hibernate 。
其它
数据库方面非常easy。对于中小型的项目MySQL足以,Oracle太笨重了。IDE方面。Eclipse没什么好说的。构建工具,Maven管理项目非常好用,跟Ant相比。Maven也是优点多多,关于它们两个的比較就不细说了,百度一大堆。版本号控制。SVN功能完好、简单易用。在局域网内做版本号控制。要比Git更有优势。Web容器选择Tomcat+Jetty,Jetty主要是用于开发的时候。终于部署到server用的是Tomcat。部署用Tomcat一是由于他更加成熟。二是由于市政府那边的server环境就是Tomcat。不是必需再换。而用Jetty呢,是由于它以插件的形式跟Maven配合起来,能够非常大程度的提高开发的效率。
在pom.xml文件中配好,直接“Run As”执行,改动代码也能动态载入,非常方便。
基础架构的设计:
基础的结构就是Action+Service+Dao+Entity。总体的结构图例如以下:
上图是最主要的骨架,当然还会用到一些工具类什么的。那些能够统一放到tool里面。
大家都知道面向对象有几个非常重要的特性——抽象、封装、继承、多态。我们设计的时候当然也要遵循面向对象的思想。以下先来看一下每一层内部的联系吧!
Action:Action这一层,抽象出一个BaseAction,由它统一继承ActionSupport。然后把一些公共的东西封装到里面。
比如分页信息、result的返回值常量等等;
Service:Service这一层,抽象出一个BaseService。有它处理最主要的增删改查业务。其它详细的Service来继承它,比方UserService,继承BaseService以后。默认就具有了主要的增删改查,因此,它不须要再自己实现一遍。它的任务就是关注自己特有的业务,比方登录、退出。这些是UserService自己独有的业务。这样不必管共同拥有业务,仅仅关注自己特有业务的方式提高了代码复用,提高了开发效率。
Dao:Dao这一层。抽象出一个BaseDao,它跟上面BaseService的作用非常类似。负责处理对实体基本增删改查的工作。就不多说啦。
Entity:Entity这一层,事实上也是能够抽象出一个BaseEntity的,能够让它来实现序列化,这样就不用每一个实体类都实现一遍了。还能够把Id等公共属性拿出来。总之。原则就是把大家都须要的统一放到一个地方,自己仅仅管自己特有的。
开发管理:
我们的开发团队開始是四个人。后来一个开发者转到其它项目组,我们有转过两个人来。所以我们组属于四五个人的规模,管理模式採用的是敏捷开发的模式。
每天上午来了,九点开立会。每一个人说一下昨天任务的完毕情况,有没有遇到什么困难之类的。假设没有什么特殊情况,就给每一个人分配一下接下来的任务,假设有人遇到什么难题,就找人帮他解决一下,或者我帮他解决一下。然后把进度跟情况汇报给项目经理。
OK,上面说了那么多项目的情况。以下该呼应一下本文的标题了。谈谈做完这个项目我的一些感受。
好了。那么问题来了:挖掘机技术... 咳咳... 不好意思,说顺口了。
今天要说的是高速开发中小型系统我们应该怎么做。
高速确定需求
中小型系统通常业务不是非常复杂。因此要确定需求并不难。高速画出原型,积极和客户沟通。以便高速的确定需求。
需求不定后面的事情都是白扯。
合理的技术选型
需求定了。那么接下来就要考虑怎么做了。首先要确定用什么技术,选择什么框架等等。技术选型首先要看这样的技术适不适合项目,即能不能满足我们的需求。通常这一点比較easy确定;第二就要考虑这样的技术适不适合我们的团队,什么意思呢?就是说要看开发者对于这项技术的熟悉程度,是不是能立即上手。或者须要一段时间的学习,再或者须要投入比較高的学习成本。假设须要比較高的学习成本。那么也许你该考虑一下是不是有其它的技术能够取代它。当然,假设你们项目不急或者你们公司是土豪那就另当别论了;再有不要一味追求最新的技术,由于新的版本号往往伴随着新的bug,出了问题也不好解决,相同也不要选择太老的版本号。推荐选择比最新版本号低一到两个版本号的正式稳定版。
优秀的基础架构
什么是优秀的代码?非常多人都知道:易扩展、易维护、复用性强.... 那么如何做到这些呢?说实话,小弟水平一般说不太好,大抵能够概括例如以下:层之间添加接口,来减少耦合度、添加灵活性。方法与类的职责单一。提高内聚性,从而达到易扩展的目的;制定完好的代码规范,模块与关键代码语句要有较详细的凝视,完好的文档。从而提高易维护性;抽象封装公共模块,提炼与业务无关的部分。如:分页、树形菜单、上传、下载、主要的数据维护等。
从而提高代码的复用性。
项目管理
项目管理能够分为项目进度的掌控以及人员的管理安排。这两者是密不可分的,仅仅有把人管好。才干让项目平稳的向前推进。人与人之间的交往。远比跟电脑打交道要复杂的多。这次输入个“A”,他给你输出个“B”,下次你相同输入个“A”,没准他就给你输出个“C”,或者给你输出一堆乱码,甚至直接死机蓝屏了。这个事情三言两语说不清,总之就是对待不同的人用不同的方法。对于踏实沉稳的人要时不时的鼓舞。换发他的激情;对于活泼外向的人就要偶尔打击一下,安抚一下他的浮躁。
任务的安排也要依据每一个人的能力以及特长合理分配,当组员没有非常好的完毕任务时也不要急于责怪、质问,先耐心的倾听。看看到底是哪些原因所导致的,然后客观分析,找出解决方式,共同克服困难。
回头一看,发现自己居然写了这么多,说实话写这篇博客着实花了我不少功夫,这应该是我写的最长同一时候也是感受最多的一篇博客了吧。
总之能够顺利的完毕这个项目离不开大家的支持,离不开组员的努力,在此我就不一一感谢了。最后不得不单独感谢一下巨同学,假设不是他一次次的鼓舞,不可能完毕的这么顺利,遇到困难时彼此的鼓舞非常重要。加油!
你行的!