随想2018·冬

自国父施以革命,立法民主与科学;后经更迭,舶来马列思想;几经调整,终成毛中特。国为新体,人着新装,弃糟粕,存精华。然固疾难除者,官僚与虚伪自大者也。穷而麻木不仁,达则骄奢横行。固西学而未习其髓,革新而未拔其根。谓“路漫漫其修远兮,吾将上下而求索”。

商业的本质:参与者之间的等价交换

商业的本质是什么?我个人认为商业的本质是:参与者之间的等价交换。

关于这个问题,曾一度提出并反驳了如下的假设:

1.是对人力、财物和信息的整合。——无法成为商业的特性,而且财物不是必要元素。

2.像“商朝人”一样,不从事生产,而是提供物品流通。——能区分其他行业(农业、工业等)与商业的根本差别,到信息时代多了信息,以后时代也不清楚会多啥。

3.是交换——交换只是动词,无主体,交换本身又有公平的、不公平的、强制的。

4.是人与人之间的交换。——企业与个人也可以,以后机器人与机器人之间也可以,现在已有的自然界,其实也有商业行为。

最后形成“参与者之间的等价交换”的假设。——这里包括了主体(参与者)、隐含的客体(被交换的东西)与动作(等价交换)。

其中包含了几层意思:

1.广泛的主体,包括自然人、法人、未来某种智慧形态,以及已经存在的自然界的生灵(可以分析寄居蟹的换壳行为)。

2.广泛的客体,包括价值符号(货币)、物品(物物交换)、信息,以及未来任何有形无形的东西。

3.公平原则、自愿原则、诚信选择,参与方(可能是多方)能够通过交换,满足各方需要。

4.等价不是等价值。

再议复利

复利可谓是人类最伟大的发明之一。它以指数增长的魔法棒(72法则)使个人财富快速增值。

但这些财富真的是价值对等的财富吗?人类生产力真的可以满足应对复利的指数增长吗?这些都需要更有权威的全球数据给予证实。

而我更想说的是,线性增长的人类生产力如何应对指数增长的复利。——那就是信贷,人们说是向银行借钱,其实在向未来的自己借钱。只有这样,货币的数量才能满足一定周期内的复利利益要求。信贷有借就要有还(当然也有人会毁约,特殊情况下,还会出现全社会的毁约或者国家间的毁约),这就造成了经济的波动(需要减少未来的支出而弥补现在的信贷与复利利息)。

 这里不是说复利不好,而是希望能让大家意识到其耀眼光环下的弊端。任何事物都有两面性。

 以上为个人一家之言,还望指正。

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项目中选定。

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

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