• 我是怎样成长为系统架构师的


     

    来这家公司从事信息化工作已经也有三个年头了,有必要对这三年的工作和成长以及不足之处做一个总结。在此之前,从2001年開始学习JAVA,那时候用Struts的开发的企业也不多,而我在的做项目的企业当时已经自己开发了Struts的高速开发平台,专门做对日软件外包的项目,在这家公司工作,培养了我JAVA基础知识,软件project的认识以及项目管理的知识。随后博士毕业后去了一家外企做了4年的IT系统集成研究,主要用Eclipse Plugin搭建研究项目的验证的Prototype,期间研究了SOA,SSH,LDAP,Web服务发现等技术。

     

    刚来这家公司的时候,领导决策要将系统做重建开发。项目的详细情况是:我们拥有了成熟的业务功能,仅仅要将老的系统的功能照搬到新的系统中,因此,对于老的系统进行了一次整理和分析,分析了合理的地方,也分析了不合理的地方,不合理的地方,希望在新系统中进行改进,但原则上,数据库表结构不做大的修改,以免将给将来系统迁移带来重大困难。当然,因为随着企业的业务的发展,会有新的需求,但大部分的需求都是没有改变的。

    在项目的成员实力方面,没有的是

    1.熟悉JAVA的开发者。

    2.J2EE项目的经验。

    有的是:

    1.IT项目的开发、測试和维护经验。

    2.数据库系统开发经验。(事实上非常重要的,数据库系统对于企业应用来说,数据也是非常关键的,拥有这样面的经验,为项目的兴许开发提供了不少的经验支持)


    在项目的初期阶段还碰到了技术选型的问题,依据应用的特点,终于选择了C/S三层结构,并选用标准的EJB 3.0作为中间层,採用成熟的商用中间件server,这样就攻克了ORM,数据持久化等问题,这样便确定了技术方向,这对于没有经验的团队来说,也是艰难的。


    上述便是我团队的情况的简要概况。项目总是要做的,由于领导决策了啊。先看上述两个问题我们是怎样解决的。

    1.针对开发团队没有JAVA的开发经验,进行培训,由我亲自操刀。培训为期15天,从开发环境熟悉,到JAVA基础知识,上午半天讲知识,下午上机练习。

    2.针对没有J2EE的项目经验。

    整个项目就我一个人有过J2EE的项目经验,可是我曾经没有做过J2EE项目的架构师至少没有做过如此大型项目的,我仅仅是做过J2EE项目的开发(B/S的,而本次项目是client)并了解软件project、面向对象的设计、设计模式等。怎么办?我们是这样解决的,请老师。专门请了老师来讲架构设计知识。这还不够,我们花钱请人做架构设计。但仅仅是做架构设计,生成一个架构说明书后,离架构的工作还非常远,还有非常长的路要走,而在合作公司做好架构设计后,他们的工作也就基本结束了。后面的架构方面的工作,基本上是由我来做的。我说说我都做了什么事情。

    1)依照架构说明书,将整个架构环境搭建起来。

    2)开发一套便于开发者开发的开发框架。

    3)设计了SwingMVC模式,并开发实现。

    4)开发了整个系统的基础组件,为了实现架构中的复用的原则,这个非常重要。

    5)负责整个系统的权限的管理,这个非常重要,跟各个模块都有关系。

    6)负责开发的编码规范的制定,包含JAVA的编码的规范,同一时候还有质量属性方面的编码的规范。

    (7)整个系统的异常处理、日志、错误验证等机制的设计和开发;

    (8)第三方系统和工具的集成,如报表系统,浏览工具的集成等;

    上述,仅仅有(1)是现成的。其他的都是详细的架构方面的工作。非常多人,都以为,架构师嘛,不就是高高在上的,待在象牙塔里给开发者发号施令的人吗?事实上不然,架构师须要每天跟开发者在一起,一起写代码,一起工作,一起交流。

    回想起,在搭建高速开发框架的过程中,开发者在开发的过程中,提出了非常多有意义的改进的意见,直到今时今日,我们还在改进,仅仅有开明的架构师,才可以设计出好的系统,好的基础组件。当然没有意义的,也被筛选掉的,架构师必需要有这种决断力。

    SwingMVC模式就不说了,可能每一个团队对于该项设计都会有所不同。

    说说怎样实现组件的复用,要实现组件的复用,必需要鼓舞开发者复用已有的组件以统一界面风格以及降低工作量。那么,就要告诉开发者,眼下我们的系统有哪些基础组件,他们都是怎么样使用或调用的。有了这些,开发者自然就肯用了。

    关于编码规范,可能非常多人认为这是项目开发中的小事情,事实上不然,某位架构大师说过,架构无小事,编码规范的运行不力,直接影响到整个项目的代码质量,甚至影响质量。比如,要求不要出如今循环,要释放对象,尽量用StringBuffer等。在编码规范的运行的难度是,不是说你有没有规范,而是你的规范有没有被运行。那么怎样使得你的规范被运行呢?

    这就须要架构师的耐心和沟通能力了。在整个项目的开发过程中,架构师始终要保持与开发者的沟通,苦口婆心地说,编码规范的重要性。时间长了,开发者养成了好的习惯,架构师也就省心了。

    依据上述经验,我做个总结。

    1.经验是能够复制的,当您没有这方面的人员时,最好请求专业或外援,并培养自己的人员,同一时候有吸收的学习。

    2.架构师是整个团队的技术领导,须要具备领导能力。

    3.架构师须要较强的沟通能力,须要与项目的各个方面的人员进行沟通,与项目经理沟通,帮助项目经理制定合理的开发计划;与需求分析员沟通,了解系统的关键需求和非功能性需求;与开发者沟通,使得架构设计可以被真正运行;另外还有与项目经理、物理架构负责人沟通等等。

    4.架构师须要编写代码,这样使自己积累很多其它的代码经验,加深理解设计模式,可以帮助自己对于整个项目更加熟悉,同一时候可以回答开发者在开发过程中出现的全部的问题,树立个人威信。

    5.架构师需要有较强的IT知识和广博的知识面。IT的知识更新很快,如今云计算等的出现,必定要淘汰一部分架构师,因此,架构师要保持生命力,必需要不断地学习。

    6.架构师要懂业务知识。架构设计要满足系统的需求。我尽管刚到公司不久,但因为之前积累了非常多业务相关的知识,经过短期的学习,也掌握了业务知识。

    7.不要怕做事情,我在整个系统的开发过程中,我的开发量是别人的三倍还多,但我收获的,则也是三倍还多的经验。

     自己的不足之处:

    1.有时候会着急,当规范强调了10遍,还是没有得到非常好的运行时,就開始没有耐心了。

    2.须要加强沟通能力,将自己的想法可以推销出去。

    3.须要在很多其它的业务领域知识方面得到高速的增长。

     

    下一步的目标

     

    1.系统理论地学习架构知识,使得知识更加固化,以进一步使得架构设计更加科学和有调理;

    2.通过广泛地阅读学习企业信息化的各个方面的知识,包含ERPSCM,营销管理,企业战略,企业管理等,每年看书或阅读文章至少100本或篇;

    3.熟悉企业的业务流程,与企业不同层次的人员多多地进行交流,多学习,多沟通;

    4.多交朋友,多向朋友学习与交流。

  • 相关阅读:
    osip2 代码分析
    批处理命令——call 和 start
    在VS2010 VC++项目中引用Lib静态库(以Openssl为例)
    Gerrit 代码审核服务器的工作流和原理
    crucible VS gerrit
    领导者/追随者(Leader/Followers)模型和半同步/半异步(half-sync/half-async)模型都是常用的客户-服务器编程模型
    半同步半异步I/O的设计模式(half sync/half async)
    高并发系统设计
    通过Nginx反向代理之后客户端验证码session不一致造成无法验证通过的问题解决
    使用Nodpad++正则替换
  • 原文地址:https://www.cnblogs.com/mengfanrong/p/4250847.html
Copyright © 2020-2023  润新知