标签：io 使用 sp on 问题 cti 代码 时间 管理
最近公司一个研发团队把使用一段时间的新型技术框架重新调整到了以前的成熟技术框架，个人也是颇有感触，系统开发中我们是使用新技术还是使用成熟技术？
这里的新技术不是指市面上刚刚出来的技术，而成熟技术也并不一定是很老的技术，指的是在团队级别或组织级别已经广泛使用的技术。这个问题的答案无疑是因人而异的，很多技术人员的Mindset中，普遍认为使用新技术来解决问题是一件有挑战和成就感的事情，所以会找一些理由来推动新技术的使用，这固然不是什么坏事，但能够推动新技术的开发人员往往身居一定管理职位，我们换个角度从管理上讲，事情可能就没有那么简单了。
新技术必定是有一定的好处，不然没有人会想着要去推广，例如这个团队尝试使用vertx、thrift等技术体系来达到性能上的优化。这些技术确实很新颖而且被证实是高效的，但问题在于此时此景，我们需要这些技术吗？这是第一个问题，第二个问题在于，使用vertx这种基于reaction模式的新式程序开发方式、基于thrift的idl代码生成和管理方式，以及使用基于js的前端controller层的书写方式都与使用springmvc、dubbo等团队既有技术有本质性的不同，如何确保团队对这些技术都有统一的认识和了解，如何确保团队开发的协作效率也是这个团队不得不面临的问题。
讲到这里，实际上就是在从团队管理的角度看问题，这个团队放弃新技术而重新选用成熟技术的根本原因在于团队的现状以及团队成员对这种新技术抱有一定的顾虑，觉得技术虽好但团队理解消化、代码维护、系统的运行现状等还是有一定障碍，影响了团队当前的高效运作，所以作出了这个决定。
新技术的提出者和成熟技术的回滚者都是这个团队的成员，通过沟通和协调作出这一决定个人认为是团队成熟的一种表现。当然随着软件系统自身的发展和团队成员水平的提高，可能在将来的某一时间点会再次把新技术的引入提上日程，那时的结果应该也是团队应该深思熟虑之后作出的决定。
标签：io 使用 sp on 问题 cti 代码 时间 管理
原文地址：http://blog.csdn.net/lantian08251/article/details/41490665
