java开发,maven多模块项目管理的喜与恼

谈到java开发的多模块组织,我不禁乐道于maven的强大与高效,以至于在上一年进行前端规范化工作时,还时不时地拿gulpmaven进行对比。

谈到maven就不能不谈ant,早些年代的java库管理多是ant方式,项目需要什么jar包,就往项目的lib文件夹下塞,包出现了冲突解决起来比较费劲。Maven的方式叫做反应池,在项目中只需要一个pom.xml文件就可以管理包的依赖关系,而且可以通过视图能清晰地看到层次依赖关系,便于包冲突的分析与解决。而依赖的jar包文件放在当前用户的.m2文件夹下,打包时,又自动把依赖包组织起来。

Maven除了优秀的库依赖管理与插件依赖管理(这里暂时不多介绍),还有一个优秀的特性——项目模块依赖管理——这使得一个大的项目可以任意拆分成多个相对独立的原子功能(可以是业务功能点也可以是工具类库)。在实际工作中,我通常把工具类库打包成jar,把组织级别的业务功能点打包成war作为微服务。

Maven-module多模块组织固然有如此大的优势,但刚开始过度的原子化分割,是的项目后期维护出现了一定的难度:

一、前期技术储备不足,在eclipse中使用时,每次更新jar模块后,都要maven install下,把jar模块安装到本地库里。但这个问题是,随着项目模块的增加,没修改几行代码就要执行次这个命令,很耗费时间。当然,后期找到了正规的解决方法,但偶尔出现的问题,还是使得团队成员退回install方式。

二、后期维护成本较大。模块过多而且依赖复杂的后果就是,牵一发而动全身。有的功能,管理后台依赖了,会员也依赖了,一次改动,如果测试补充分,很容易添加新的bug.

三、新的团队成员上手难。复杂的项目结构,无疑为新成员设定了很高的门槛,光分析一个业务逻辑就好跨越好几个jar

根据以上几点,我把全公司的项目模块归类为两大类。一个是组织级别的框架模块,一个是项目级别的项目模块。框架模块可以成为项目前期技术选型的素材,优秀的项目模块又可以完善框架模块。两者相辅相成,当然两个都是通过maven-module的形式进行管理。

在业务系统中,在单体模式(这个项目就是一个war)与之前过度分割的原子模式之间进行折中。把整个项目定义为一个pom项目(maven项目有三种类型pom/jar/war),进行项目依赖库与插件的版本控制;每个业务端(比如,管理后台、商家后台、会员中心等)作为war模块,每个war模块相对独立,如果出现业务交集,通过前端调用不同war的接口进行整合,每个war模块所依赖的库或者插件都从父级的pom项目中选定。

业务系统中引来的工具类,在项目阶段审核后提交到框架模块的工具包里统一管理。业务系统中可重用的服务(如:登陆、鉴权、工作流等),则在框架模块中进一步抽象成为微服务。

一个项目的完成,不仅仅是交活收钱,对于公司来说,更大的财产是组织过程资产的积淀。

为科学正名

如今“专家当道,科学横行”。经常看到某某专家在互联网、地方电视台发布这样或者那样的科学新突破,并通过散布这些虚假消息以获取利益。

“弘扬科学精神,破除封建迷信”的口号,一直被大力宣扬。在不考虑其时代背景与政治背景的情况下,此口号的实施却略显空洞。

一、旧事物未必迷信,新事物未必科学

从刚开始带有政治色彩的反对封建时代的一切,到现在挖掘中国历史文化的瑰宝,已经逐步认识到中华文明源远流长、博大精深。

中医曾一度被以科学为依据而发展起来的西医认为是“巫术”,直到神经学、免疫学的深入研究,才逐步通过科学地方式解读出中医里“气血”“经络”等玄之又玄的概念,并初步理解其与疾病之间的关系。通过大数据分析不同药物组合对不同体质患者的作用效果,将有望为中药的奇特搭配在疾病治疗方面的数据依据。

儒学、易经也曾被当做封建时代留下的糟粕,但在社会基本稳定后,儒学在稳定政权、维护国家利益方面起到重要作用。至于易经,旨在阐明天地万物(也可以认为古人眼中的宇宙)的运作规律,只是有些说法尚不能通过科学严谨的方法进行证明。

现在流行着这么一套炒作流程“专家甲有观点A-专家乙反对甲的观点甲乙撕逼大战官方专家发布观点”。对于这类事件,有的人已经见怪不怪,有的人跟着汹涌澎湃。其实,是我们“太迷信科学”了!

一直以来,人类社会都是“少数人的勤快换来多数人的懒惰”。少数人的勤快指的是,深究事物的本质,发现事物的运作规律;多数人的懒惰指的是,直接使用少数人的结论或者劳动成果服务或者指导自己的生活。这本来是无可厚非的,但在这个信息急速膨胀的时代,不乏有人为了私利,虚构“科学结论”,迷惑诱导懒惰的多数人。

二、科学总是从正确走向错误

先放下“骗子专家”不谈,科学本身是一个结论从正确走向错误,却又不断完善探索方法与过程。对的,科学是方法、是过程,而不是结论!

牛顿(被誉为“站在巨人肩上的巨人”)不可不谓之伟大。他在经典力学、高等数学领域做出突出贡献。但在近代更微观、更宏观的物理学领域却被质疑与挑战,小爱当之无愧的坐上了物理学最前沿的第一把交椅。不过我相信,小爱的相对论理论也会在不远的将来被推翻(确切的说应该叫完善)。

人类历程不是一成不变的,所以一个时代的“科学结论”无法完全适用于下一个时代的“研究领域”。正如牛顿的经典力学理论完全可以适用于他的时代以及其后将近三百年的物理领域,但却无法适用于近代的高能物理学。——这不得不说是时代的束缚。

但有一点是可以肯定的,用独立思考与实验数据架构的探索方法与探索过程,将一步步完善科学理论大厦。

2017年内部变革意见与建议

一、变革目标

以提高项目开发效率为核心,用规范化、可量化项目开发与管理技术,保证项目的可控性与高质量;增强员工专业技能,提高团队整体竞争力;促进内部良性竞争,活跃技术氛围;增加公司资金积累与技术积淀。

二、现状与痛点

a) 旧框架的尴尬处境

之前的旧框架对于公司初期提高项目开发效率的确起着至关重要的作用——使用门槛低(低到基本上只要有是java入门级别的就可以独立开发一个功能模块)、开发速度快。

如今,旧框架已成“鸡肋”——虽说开发效率很高,但系统界面风格老旧且不易扩展、代码质量差。个人分析有以下几个原因:

1、框架对第三方技术的封装违反了不污染源代码与适配的原则,造成框架对extjs的依赖版本极其严格,却又无法兼容其新特性的致命弱点。

2、框架仅由一人维护且脱离实际项目应用场景,仅进行bug修改,缺乏框架的统筹设计与持续升级

3、框架的使用降低了使用人员的技术门槛,但在缺乏规范性培训与基础技能培训的环境中,框架的优势很容易被劣质代码所引起的不可维护性与低性能所冲淡。

a) 新开发模式无法积淀

2015年起所使用的新型开发模式按说应该在一年半多的使用经验中进行了归纳与总结。但由于在项目中一味尝试新技术(有的技术其实已经过时并淘汰)却浅尝辄止,无暇也无法进行新架构的积淀。

不过,还好在在各种“尝新”的过程中,血淋淋的教训告诉了我们:

1、只注重业务功能的堆积,而不注重系统的性能与可维护性,产品上线之日就是产品死亡之日。

2、企业不是实验室,一味“尝新”的代价可能是断送一个企业的前程。

3、任何成果都要以文本的形式进行总结并进行最大范围的分享。没有总结的成果不算“组织过程资产”

4、执行力!执行力!还是执行力!从上到下不要抱着得过且过的态度做事。不要懒,项目没有文档只有代码没啥用。不要怕,非正式沟通(电话、即时聊天等)与正式沟通(邮件)都不可少。不要拖,遇到问题及时沟通,该与干系人交涉的就去交涉。 继续阅读2017年内部变革意见与建议

Hello 2017,Saybye 2016(一)平凡而不平淡的2016

公元20161231日 济南 霾

已是公元2016年最后一天,掐指算来离开母校也有两个半年头了,距离28周岁也仅有两年的时间了。在这个青黄不接的尴尬季节,也在这青黄不接的尴尬的年龄,好好反思下自己,总结下过往,计划下未来,看来是有必要的了。

一、平凡而不平淡的2016

春去冬来又一年,2016已是最后一天。借假期休息之日做个年终总结也是不错的。与往年一样,没有太大的变故也没有太多的惊喜,三百六十天无非舍与得、恩与怨。

虽说如此,还是有三件事值得回味的:休养生息、爱情遭遇战与事业心觉醒。虽皆因果报应,但都值得总结反思、借鉴提高。

a) 休养生息

工作两年,凭着没头没脑的冲劲,的确在职业技能方法有所提高,但身体却发出了警告。——肠易激症导致的腹泻持续了近一年之久。——脾气倔(坚毅的性格是有副作用的)且饮食不规律的朋友一定要注意下额!

前前后后,西药中药吃了一堆,也总是治标不治本。后来看些心理调节的书,听些心理疏导的读物,改善饮食结构(以清淡易消化食物为主,少食多餐,杜绝生冷油腻、重盐、重口味,避免饭后零食与水果),症状明显减轻。给敏感的神经、脆弱的消化系统多一些休养生息的时间吧。

适当的户外锻炼也是重要的,只是济南——你懂得。

b) 爱情遭遇战

幸福来得太突然,可惜没有太长久。半年的时间,一直在分分合合、吵吵闹闹中进行磨合,不过最后相互突破了对方的底线。

可能太长时间习惯一个人去面对一个人的问题;两个人的问题,更多的是需要充分的沟通,而不再是一个人去解决。

缘分来之不易,且行且珍惜。

c) 事业心觉醒

口口声声说着做事业,却用打工的心态去做事。工作上遇到了波折,首先做的就是隐忍(放弃自己的声音),逼急了就撂挑子走人(最终的反抗)。在这个平台这样,换了其他平台(可能会更好,管理更完善)也未必一帆风顺。

没有哪个平台是为自己量身打造的,与其碰运气般去寻找合适的平台,不如与志同道合的人一起去打造这个平台。

抱怨过、反抗过,但这都不能解决现实的问题!放松心态,先确认平台与自己的基本价值观与基本规划是否一致,如果这一点不能保证,可能真的需要换个环境了。每个平台都不会与自己的预期一模一样,当遇到问题时,自己更多的应该是站在“缔造者”而不是“参与者”的角度思考。—— 不管这个平台是自己倾尽心血一手打造的,还是作为后来人进行修缮的。——把自己的事业与平台事业绑定在一起。

成就他人就是成就自己,成就平台也就提高自己。