首页 > 代码库 > 关于系统前期选择架构的问题
关于系统前期选择架构的问题
最近在整公司之前的一个基于动量的项目,我也是第一次接触动量。第一感觉是用动量开发真的比较快。但觉得不适合程序员。开发直接基于动量后台,什么IDE都不需要。动量框架可能对于公司还是比较不错的,但是在开源码农的眼里着实是个垃圾。
动量的X宗罪
1、没有原有代码的概念,不能做版本控制
2、代码片段的概念很坑爹,但是不得不佩服动量,使得编程的技术活变得像是富士康装配工人的活。但是作为程序员我是鄙视这种东西的。但不得不说这是趋势,以后编程真的有可能像街边的装修工人扛大包的,站在街边随客户调,“java 80, python 60”。
3、动量不支持eclipse神器,作为程序员,我现在的习惯是,no eclipse will die。
4、动量的发布很坑爹,不方便。但是它支持tomcat增量发布还是比较先进的,想当年我为了实现tomcat热发布,忙了好几天。
5、动量的调试及其坑爹。垃圾。试问没有一个调试的环境怎么写代码。但是调试才是能体现程序员价值的,调试使得程序员还有那么一点点的成就感吧。所以动量有意弱化之吧。
6、动量是闭源的,动量公司那帮货的技术支持简直为0。不开源,没有技术支持,网上开发资料接近0。出点问题自己琢磨。欲哭无泪。
当然作为开源人,平时没有机会接触动量,也不屑使用之。spring核心,加上精选的外设(+mybatis +xxcache+...)所有功能自己写。
动量毕竟是平台,很多商用功能集成度很高,开发效率极高,维护成本极大。哈哈。
我是鄙视动量的,大家可以搜一下。
写到这里有点乱,我的本意是什么也忘了。总之开发之前选择平台(框架要谨慎吧,特别是市面上NB的不开源的平台,慎用之。)
关于系统前期选择架构的问题