菜鸟要做架构师（一）——如何快速开发中小型系统

俗话说：不想当项目经理的程序员不是好的架构师。相信每一个有上进心的程序员，都有一个架构师的梦。最近完成了一个中小型的项目，让我有了一些感受和想法，于是决定新开一个系列——《菜鸟要做架构师》。

经常看我博客的人应该了解，我写了好几个“菜鸟”系列了。有很多人问我，你都是大牛了，怎么写博客还叫菜鸟？有人觉得太过低调了，也有人觉得这是在装B。其实呢，我是觉得自己真的还只是个菜鸟。就光拿计算机行业来说吧，就有太多太多的知识我不懂，甚至连听都没听过。记得高中有位老师说的话让我印象特别深刻，大概意思是：越是一知半解的人，往往越是喜欢高谈阔论；越是知识渊博的人，往往越觉得自己欠缺很多（哎呀，现在说这句话，有点装B的嫌疑，罪过罪过....）。所以我觉得要保持一颗谦卑的心，才能够不断的学习并提高自己，所以用“菜鸟”二字来自勉。好了，好像扯的有点远，下面咱们进入正题。

项目背景：

这个项目是给廊坊市政府做的，本来这个项目是别的公司做的，后来由于种种原因，不做了，留下一个半成品。我接手的时候，他们给了源码和数据库，还有一些简单说明。几乎没有任何需求和设计文档，经过多方联系和沟通，他们给出的答复是：没有文档！最后经过大家讨论觉得在他们的基础上继续开发，成本较高（需要弄清楚他们的代码以及数据库，他们给的库总共有四百多张表），所以最后决定重新开发。

重构：

虽然文档一无所有，好在利用他们给的源码和数据库，他们的项目还是搭起来的。可以简单的看看页面，也对一些需求有了大致的了解。也发现了一些他们前端框架存在的问题，最严重的问题就是浏览器的兼容性。经测试发现，页面显示只有在IE7和部分国产浏览器下正常显示。在其他IE版本或者其他内核浏览器，甚至是很多双核浏览器下都是那种根本没法用的程度。

技术选型：

前端框架

前面已经提到了，之前的项目在浏览器兼容性上存在着严重的问题，所以我们在选择的时候要考虑到这个因素。结合手底下开发人员的技术水平以及用户的需求，我们最终确定用dwz作为我们的前端框架。可能会有人觉得dwz不好，Ext更好怎样怎样，还是那句话合适就是最好的，杀鸡焉用牛刀。个人觉得dwz在应对中小型的项目时，还是非常不错的。首先，浏览器兼容性不错，经过我的不完全统计，dwz无论是在IE、Chrome还是FireFox的各个主流版本，都可以正常工作，各大国产浏览器也都完美兼容；还有，就是它上手比较容易，对于快速开发小型项目非常合适；当然，选择它还有一个很重要的原因，项目组的人对于dwz相对熟悉，可以快速投入战斗。

核心框架

目前最常用的也就是下面几位了：Spring、Struts/SpringMVC、Hibernate/Mybatis。一般说来Spring的入选没有什么争议，主要就是MVC框架用Struts还是SpringMVC，ORM框架用Hibernate还是Mybatis。这四个都是非常优秀的开源框架，技术上都很成熟，无论怎么组合都可以很好的完成我们需要的功能。具体怎么选择，还是的回归实际。结合开发人员的技术特长，以及相关资料的丰富程度，和遇到问题解决的成本来看，Struts和Hibernate更加适合。首先，组员对于Struts和Hibernate更加熟悉；Struts和Hibernate相比SpringMVC和Mybatis也有着更多的用户，相关社区也更加的活跃，有什么问题当然解决起来也就更容易一些。

综上所述，基础框架为：Spring + Struts+ Hibernate 。

其他

数据库方面很简单，对于中小型的项目MySQL足以，Oracle太笨重了。IDE方面，Eclipse没什么好说的。构建工具，Maven管理项目很好用，跟Ant相比，Maven也是好处多多，关于它们两个的比较就不细说了，百度一大堆。版本控制，SVN功能完善、简单易用，在局域网内做版本控制，要比Git更有优势。Web容器选择Tomcat+Jetty，Jetty主要是用于开发的时候，最终部署到服务器用的是Tomcat。部署用Tomcat一是因为他更加成熟，二是因为市政府那边的服务器环境就是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，上面说了那么多项目的情况，下面该呼应一下本文的标题了，谈谈做完这个项目我的一些感受。好了，那么问题来了：挖掘机技术... 咳咳... 不好意思，说顺口了。今天要说的是快速开发中小型系统我们应该怎么做。

快速确定需求

中小型系统通常业务不是很复杂，因此要确定需求并不难，快速画出原型，积极和客户沟通，以便快速的确定需求。需求不定后面的事情都是白扯。

合理的技术选型

需求定了，那么接下来就要考虑怎么做了。首先要确定用什么技术，选择什么框架等等。技术选型首先要看这种技术适不适合项目，即能不能满足我们的需求，通常这一点比较容易确定；第二就要考虑这种技术适不适合我们的团队，什么意思呢？就是说要看开发人员对于这项技术的熟悉程度，是不是能马上上手，或者需要一段时间的学习，再或者需要投入比较高的学习成本。如果需要比较高的学习成本，那么或许你该考虑一下是不是有其他的技术可以代替它。当然，如果你们项目不急或者你们公司是土豪那就另当别论了；再有不要一味追求最新的技术，因为新的版本往往伴随着新的bug，出了问题也不好解决，同样也不要选择太老的版本，推荐选择比最新版本低一到两个版本的正式稳定版。

优秀的基础架构

什么是优秀的代码？很多人都知道：易扩展、易维护、复用性强.... 那么如何做到这些呢？说实话，小弟水平一般说不太好，大抵可以概括如下：层之间加入接口，来降低耦合度、增加灵活性，方法与类的职责单一，提高内聚性，从而达到易扩展的目的；制定完善的代码规范，模块与关键代码语句要有较详细的注释，完善的文档，从而提高易维护性；抽象封装公共模块，提炼与业务无关的部分，如：分页、树形菜单、上传、下载、基本的数据维护等。从而提高代码的复用性。

项目管理

项目管理可以分为项目进度的掌控以及人员的管理安排。这两者是密不可分的，只有把人管好，才能让项目平稳的向前推进。人与人之间的交往，远比跟电脑打交道要复杂的多。这次输入个“A”，他给你输出个“B”，下次你同样输入个“A”，没准他就给你输出个“C”，或者给你输出一堆乱码，甚至直接死机蓝屏了。这个事情三言两语说不清，总之就是对待不同的人用不同的方法。对于踏实沉稳的人要时不时的鼓励，换发他的激情；对于活泼外向的人就要偶尔打击一下，安抚一下他的浮躁。任务的安排也要根据每个人的能力以及特长合理分配，当组员没有很好的完成任务时也不要急于责备、质问，先耐心的倾听，看看究竟是哪些原因所导致的，然后客观分析，找出解决方案，共同克服困难。

回头一看，发现自己竟然写了这么多，说实话写这篇博客着实花了我不少功夫，这应该是我写的最长同时也是感受最多的一篇博客了吧。总之能够顺利的完成这个项目离不开大家的支持，离不开组员的努力，在此我就不一一感谢了。最后不得不单独感谢一下巨同学，如果不是他一次次的鼓励，不可能完成的这么顺利，遇到困难时彼此的鼓励很重要。加油！你行的！

from: http://www.cnblogs.com/liushuijinger/p/4086371.html

菜鸟要做架构师（一）——如何快速开发中小型系统相关推荐

菜鸟要做架构师（二）——java性能优化之for循环
完成同样的功能,用不同的代码来实现,性能上可能会有比较大的差别,所以对于一些性能敏感的模块来说,对代码进行一定的优化还是很有必要的.今天就来说一下java代码优化的事情,今天主要聊一下对于for(wh ...
菜鸟要做架构师——java性能优化之for循环
https://blog.csdn.net/liushuijinger/article/details/41546347
重读《从菜鸟到测试架构师》-- 测试专家的第一步
无论是大学毕业的第一份工作还是工作多年后重新入职新公司,我们都不可避免的会遇到上班第一天,在这第一天的时间里我们需要完成领设备.装系统等准备工作,当然,不可或缺的还有新人培训,这本书的第一章也直白地使 ...
重读《从菜鸟到测试架构师》-- 前篇
自从购买了<从菜鸟到测试架构师>之后,很认真的将这本书从序开始的每个字都看了一遍,也在书上边边角角做了笔记,再次重读这本书,也将这本书中阐述的概念,以及一些自己的理解将记录在博客园及微信公 ...
做人、做事，做架构师——架构师能力模型解析
引子究竟是什么让你在同一个位置上--例如程序员或技术负责人--工作了三年.五年或者更久,而仍然得不到任何的发展空间?你觉得自己已成为技术圈中的大牛,并信心满满地去拿明天就要颁发的某某大奖,然而却仍然 ...
旧文重发：做人、做事，做架构师——架构师能力模型解析
这篇文章发表于<程序员>2008.04期.其中有关模型图参见: http://blog.csdn.net/aimingoo/archive/2007/06/26/1667508.aspx ...
架构师的工作都干些什么？！想做架构师必看
转载自架构师的工作都干些什么?!想做架构师必看之前有网友说想看架构师升级的文章,所以写了本文.先给本文中架构师做个定义:第一,能力上达到(似乎是废话),第二,公司肯承认,不仅能给架构师的头衔,更 ...
程序员怎么在短时间内从菜鸟到高级架构师
(向贴吧大神致敬,个人觉得里面我看过的书籍挺好的,献给新手) 面试一般涉及类容: 说道面试及笔试题,一般不外乎Java语言基础.Java语言高级.UML和OO和模式.数据库.测试.数据结构和算法.管理 ...
《从菜鸟到测试架构师》简要总结（1）----新人培训
<从菜鸟到测试架构师>简要总结(1)----新人培训已经看完了这本书,基本是偏向于基础理论的,包含的范围很广,可以作为一个测试工作内容的了解!并对以后的实践有所指导, ...

菜鸟要做架构师（一）——如何快速开发中小型系统

菜鸟要做架构师（一）——如何快速开发中小型系统相关推荐

最新文章

热门文章