成为技术老大技术管理篇2一技术选型

发表于:2018-4-24 10:24

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:铁棍山药    来源:简书

  每个系统都会有他的生命周期,从生到死,经历少年、中年、老年三个阶段。复杂度的管理贯穿系统的整个生命周期,就像进化论的自然选择一样,不停的优化着系统,不停的断舍离,保持着系统的生命力。
  系统初建的阶段,主要是完成0到1的构建,用于验证业务模式或者做最小的Demo产品。这个阶段优先考虑的就是时间和成本,就是要快。因此,这一阶段的技术选型很重要,如果选择不对,就会引入不必要的复杂度,降低研发效率。我觉得有以下两个维度可供考虑。
  第一个维度是团队成员对所选技术的熟悉度。项目初期其实能找到的人也是有限的,如果成员对某个技术非常熟悉,的确就缩短了学习的成本,而且也能避免掉曾经犯过的问题。
  第二个维度是各种技术方案的适合度和成本。我们得知道,没有包治百病的技术方案,所有的技术方案都有他适合的领域,而且每个方案成本也是不一的。下面分别说几个技术方案的选择。
  先说一下开发语言的选择吧,我无意争论哪个语言更好,而且语言也是在不断变化中,只是说明下当下各种语言的适用场景。其实各种语言都有他适合的地方,各家公司也都会用到不止一种语言,来解决系统不同的问题。但是在系统初期,语言的选择还是很重要的。对于安卓和IOS客户端,这个没有选择的余地了,选择官方推荐的就可以。
  后台开发语言选择面就比较广了,C/C++/Java/Php/Python/.Net/nodeJs等等,眼花缭乱的,一般情况下,尽量选择开源的语言平台,社区支持会好一些的,架构相对比较成熟一些,各种疑难杂症都可以获得免费的支持。我对.Net并无恶意,事实上我也是从.Net开发做起的,而且.net也已经开源,但是时间太晚,的确业内有不少公司,在业务壮大以后从.Net转其他的语言。C/C++因为对内存的有更灵活的掌控,比较适合做高并发但逻辑简单的服务或者中间件,如果是业务逻辑复杂的系统,初期不建议采用了;Java是目前非常广泛使用的语言了,社区支持丰富,几乎可以支撑全栈应用,同时面向对象的设计模式很适合拆解复杂业务,易于扩展和维护。但是框架选择太多、太复杂,用好了真不容易,入门有一定门槛;Php/Python/nodejs都是动态语言,开发非常灵活简单,虽然也支持面向对象,但不是强制,上手容易,很适合初期采用。但是一旦系统复杂度变高,太灵活也会变成问题,就是大家开发太随意,往往后期就要为这个随意买单;到底选择哪种语言,我想见仁见智吧,没有标准答案,工具没有好坏,只有适合不适合。
  系统运维这块,我觉得这几年最大的变化就是云技术的兴起,云的可用性已经超过平均单个公司自己组建运维团队所能做到的可用性,而且使得运维变得足够简单,初期甚至不需要运维人员,业务规模壮大以后也可以只保留业务运维人员,同时按需来付费,这些都极大的缩减了运维成本。
  而且云技术已经不单单是运维这一方面了,他通过更灵活的云端API,其实提供了各种服务能力,让我们可以快速灵活的接入,实现自己的业务需求。比如音频、视频、直播、文件存储、数据存储等等,俨然是一个API的资源库。这其实从根本上改变了业务开发的模式。在业务初期,怎么借助云的力量,接入现有的服务,快速发展业务,是非常重要的,尽量不要重复造轮子。
  当然,金币总有两面,云技术也在发展的过程中,数据安全就是一个需要关注的问题,再就是一旦出现运维事故,云服务商的响应速度也是一个考验;另外,随着业务的快速壮大,按需付费的成本也会变得越来越高,直到超过自建机房的费用;同时,业务所要求的可用性可能也越来越高,第三方的响应支撑是否及时也是一个问题。这时候势必要发展私有云,代价也是很大的。当然,系统建立初期,我觉得完全可以使用公有云。
  总结一下,系统初期,技术选型非常重要,一要看团队熟悉什么,二要看各种技术方案的优缺点和成本,最后,要善于借力云技术,避免重复造轮子。

相关文章
成为技术老大技术管理篇1一技术管理管理什么

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号