其他分享
首页 > 其他分享> > 不懂软件技术选型是做不出成功的软件产品的

不懂软件技术选型是做不出成功的软件产品的

作者:互联网

前言

图片

为什么写这篇文章是因为朋友公司的经历,朋友在一家初创公司做开发,初创必然是人少,事多,什么都做。有一天微信问我有个问题看看我有没有遇到过,我看了问题之后去原作者的github看了一下,我了个大去,最后一次commit是2017年底,而且issue上也有很多问题没有处理。这种技术怎么能用呢! 那么什么技术能作为技术选型?下面就来谈谈这个问题。

从实际出发

首先我们必须考虑现实,必须考虑公司的现状,无论是业务现状还是技术现状。公司的业务场景是否有成熟的解决方案?成熟的解决方案用了什么技术?能否解决本公司的现在的业务需要还有未来的业务扩展需要?技术团队的技术改造能力如何?对候选技术是否有很强的掌控能力?不能出现上面出了问题自己控制不住的情况。我还遇到初创公司上来就要搞各种高并发分布式的,只能摇摇头。技术不是随大流,符合当前实际才是最好的。所以当评估技术方案的时候要首先考虑这几点,从业务触发,从开发团队触发。

一定要有科学的技术选型流程

还是拿上面的例子来说吧,对不起兄弟了。老板扔过来github地址就二话不说拿来用。领导说用啥就用啥,以行政来推技术不可取。还有的看了几篇相关博客,觉得很好就拿来用,结果发现落地成本高,实施困难。只能推到重来浪费大量精力人力。或者凭感觉来选技术,微服务很火,好上上上。容器也很流行,好也上他喵的。python据说马上超过java了,好也给他用上。这种能行吗?肯定不行。没有做好技术分析,势必要栽跟头。应该如何做才是正确的呢?

平时要进行一些技术方案的研究和可行性分析,考察的维度可以粗一点,放入可观察的池子中去。对池子里的技术进行长期的技术追踪。比如orm框架 一般都是从 spring data jpa、hibernate,mybatis,甚至jooq。

如果用了陌生技术、不知名技术一定要深入、不能靠几篇博客,几个demo就拿来用。花点实践搭个原型,然后让团队核心开发成员各自分析利弊,并总结出可行性报告,择优而用。

任何技术都有不确定性,所以一定要有掌控能力。出问题能改。有兜底方案,可以再加一道保险。

经常性的技术复盘有利于团队对技术的把控,也有利于技术选型和对技术的掌控度。

结合上面几点整体的技术选型流程应该是这样的:“列出需求”->“细分需求”->“明确搜索方向”->“网络搜索”->“明确评判标准”->“分头执行”->汇总材料”->“初步选择”->“进一步调研”->“会议评审”->“最终决定”

什么样的技术可以用

我认为有这些因素考虑

技术一定是为了解决自己的问题,这个是第一位的。

最好不使用已经不流行的技术或者淘汰的技术,现在很少使用dephi了吧,struts2 也只有老平台使用了。

社区活跃的技术,出了问题解决方案就多,文档也完备。而且迭代也稳定。稳如spring,apache(ASF)等知名社区。

如果一个技术学习成本很高也要考虑,高学习成本意味着人才的可替代性比较低。

这个也是容易忽略的一方面,结合以上几方面考虑,一定要考虑该领域人才的数量。不然遇到人事变动,没有及时的补充人才。

这就是我程序开发技术选型的一些看法,分享给大家,希望对你有用,有问题可以留言讨论。别忘了关注一下哦。


标签:软件产品,技术,初创,问题,选型,软件技术,考虑,团队
来源: https://blog.51cto.com/u_15127607/2752753