怎么去看待一个开发框架的好与坏?怎么去看待一个项目的好与坏?

嘿嘿嘿IT 发布于 2018/08/24 10:55
阅读 285
收藏 1

@红薯 你好,我是一名java开发程序员,想跟你请教个问题,希望你能帮忙解答一下我的疑惑:怎么去看待一个开发框架的好与不好?我现在就碰到了这个问题,我以前学习到的知识,开发步骤都是三层架构,传参及返回值都是使用实体类进行接收、操作,sql语句写到XML文件中,但现在公司所使用的开发框架使用的参数都是map,而不使用实体类,持久层框架也是使用jdbc封装之后的一套,将所有的sql都写到代码中。这样可以提高开发效率,节省开发时间。但与我所学的开发知识完全是违背的,这让我很矛盾。到底是我学错了?还是我已经落后了?

另一个问题是怎么去看待一个项目的好与坏?一个项目的好与坏和开发使用的框架到底有没有关系,我们要做一个互联网产品,一个开发框架能不能最大限度的承载用户所带来的并发量和访问压力问题?昨天开会的时候,有人说并发量与程序没有关系。这让我很不理解,因为我自己学习到的知识是有关系的,同样都是一台服务器,不同的系统架构和技术使用都是会影响到程序所能承受到压力。这怎么可能会没关系哪?我现在就搞不清楚一个项目的好与坏和开发使用的框架到底有没有关系?

加载中
1
高山流水情
高山流水情

你就想,用了这个框架开发项目,质量是不是提高了,周期是不是缩短了,加班是不是减少了...如果是!那这个框架对于项目来说就是好的框架。

 

说到底,这其实是工作经验问题,经验丰富了就能根据不同项目挑选不同的技术,例如做中小型的系统、网站、微信开发什么的我会选php,移动开发我会选原生+h5,高并发应用我会选java+各种中间件,吹牛B的时候我会选微服务、分布式、大数据、人工智能..

 

 所以不用矛盾,软件开发不是一层不变的,不是学了个ssm就包打天下。

嘿嘿嘿IT
嘿嘿嘿IT
感谢你的答案,对于项目来说,根据不同的项目类型去进行技术选型,这我明白,也很清楚。因为对于高并发的项目不可说只用一个ssm就能解决的,这我很清楚。但是我同事不清楚,他觉得高并发的项目和技术框架没有关系,到时候可以做集群、负载均衡都能解决,而且整个框架参数和返回值所使用的都是map,如果开发中用到多线程,map肯定是不能使用了。但就是说不通,而且他的开发时间比我久,我也说不通。所以现在决定还是使用他
0
红薯
红薯

选择最多人用的那个,因为你可以找到很多相应的文档,多人用也说明成熟

嘿嘿嘿IT
嘿嘿嘿IT
感谢你的回答,虽然我自己很清楚,但是我却无法去说服别人
0
嘿嘿嘿IT
嘿嘿嘿IT

好的,谢谢了

0
蓝水晶飞机
蓝水晶飞机

你们公司那种是属于一次性快餐软件,只是属于数据库层上的一层薄封装,本质还是数据库做了所有的事情。

随便招个实习生就能写,成本呢很低。

嘿嘿嘿IT
嘿嘿嘿IT
感谢你的回答。其实更多的是让我有了很多思考,因为以前自己开发代码,从不考虑为什么使用,比如一个实体类和map,为什么使用实体类,为什么使用map,以前不清楚,现在我心里也大概清楚了,以前只知道map里面能放东西,list里面也能放东西,数组里面也能放东西,但都是放东西,放的有什么不一样,为什么放的不一样?其实自己是不知道,现在也了解了一些。所以还是学到了很多东西
蓝水晶飞机
蓝水晶飞机
这种系统的后台,对技术的要求还没有对业务需求、用户体验的要求高,所以就是个典型的外观可以的山寨型充电宝“USB接口直连一个纽扣电池”哈哈哈哈哈,没内涵的东西。你不能从这个上面学到什么技术。
0
宇润
宇润

每个框架的思想不一样,用实体类的话可能创建或生成比较麻烦,map用起来比较爽,可能是为了开发效率考虑吧。但不用实体类后面的维护可能会比较累,其实各有优缺点。

一个框架也不可能满足所有项目的开发需求,你觉得哪里有不足的地方,那可能是一个新轮子诞生的好理由~

嘿嘿嘿IT
嘿嘿嘿IT
感谢你的回答,现在我们是在做我们自己公司的产品,不是外包产品,虽然这样说有点不负责任,或者不太恰当,但我们做自己的产品就不能去只考虑开发效率这一点,因为以后肯定会有公司人员变动,公司领导变动,到时候另一个人就懵了,谁来接盘谁倒霉,我个人觉得开发不是写完代码就完了,而是我写的代码,不会让我的下一位来喷我。这是我自己的感受,也不希望别人来感受我的感受
返回顶部
顶部