技术管理篇2一技术选型

每个系统都会有他的生命周期，从生到死，经历少年、中年、老年三个阶段。复杂度的管理贯穿系统的整个生命周期，就像进化论的自然选择一样，不停的优化着系统，不停的断舍离，保持着系统的生命力。

系统初建的阶段，主要是完成0到1的构建，用于验证业务模式或者做最小的Demo产品。这个阶段优先考虑的就是时间和成本，就是要快。因此，这一阶段的技术选型很重要，如果选择不对，就会引入不必要的复杂度，降低研发效率。我觉得有以下两个维度可供考虑。

第一个维度是团队成员对所选技术的熟悉度。项目初期其实能找到的人也是有限的，如果成员对某个技术非常熟悉，的确就缩短了学习的成本，而且也能避免掉曾经犯过的问题。

第二个维度是各种技术方案的适合度和成本。我们得知道，没有包治百病的技术方案，所有的技术方案都有他适合的领域，而且每个方案成本也是不一的。下面分别说几个技术方案的选择。

先说一下开发语言的选择吧，我无意争论哪个语言更好，而且语言也是在不断变化中，只是说明下当下各种语言的适用场景。其实各种语言都有他适合的地方，各家公司也都会用到不止一种语言，来解决系统不同的问题。但是在系统初期，语言的选择还是很重要的。对于安卓和IOS客户端，这个没有选择的余地了，选择官方推荐的就可以。

后台开发语言选择面就比较广了，C/C++/Java/Php/Python/.Net/nodeJs等等，眼花缭乱的，一般情况下，尽量选择开源的语言平台，社区支持会好一些的，架构相对比较成熟一些，各种疑难杂症都可以获得免费的支持。我对.Net并无恶意，事实上我也是从.Net开发做起的，而且.net也已经开源，但是时间太晚，的确业内有不少公司，在业务壮大以后从.Net转其他的语言。C/C++因为对内存的有更灵活的掌控，比较适合做高并发但逻辑简单的服务或者中间件，如果是业务逻辑复杂的系统，初期不建议采用了；Java是目前非常广泛使用的语言了，社区支持丰富，几乎可以支撑全栈应用，同时面向对象的设计模式很适合拆解复杂业务，易于扩展和维护。但是框架选择太多、太复杂，用好了真不容易，入门有一定门槛；Php/Python/nodejs都是动态语言，开发非常灵活简单，虽然也支持面向对象，但不是强制，上手容易，很适合初期采用。但是一旦系统复杂度变高，太灵活也会变成问题，就是大家开发太随意，往往后期就要为这个随意买单；到底选择哪种语言，我想见仁见智吧，没有标准答案，工具没有好坏，只有适合不适合。

系统运维这块，我觉得这几年最大的变化就是云技术的兴起，云的可用性已经超过平均单个公司自己组建运维团队所能做到的可用性，而且使得运维变得足够简单，初期甚至不需要运维人员，业务规模壮大以后也可以只保留业务运维人员，同时按需来付费，这些都极大的缩减了运维成本。

而且云技术已经不单单是运维这一方面了，他通过更灵活的云端API，其实提供了各种服务能力，让我们可以快速灵活的接入，实现自己的业务需求。比如音频、视频、直播、文件存储、数据存储等等，俨然是一个API的资源库。这其实从根本上改变了业务开发的模式。在业务初期，怎么借助云的力量，接入现有的服务，快速发展业务，是非常重要的，尽量不要重复造轮子。

当然，金币总有两面，云技术也在发展的过程中，数据安全就是一个需要关注的问题，再就是一旦出现运维事故，云服务商的响应速度也是一个考验；另外，随着业务的快速壮大，按需付费的成本也会变得越来越高，直到超过自建机房的费用；同时，业务所要求的可用性可能也越来越高，第三方的响应支撑是否及时也是一个问题。这时候势必要发展私有云，代价也是很大的。当然，系统建立初期，我觉得完全可以使用公有云。

总结一下，系统初期，技术选型非常重要，一要看团队熟悉什么，二要看各种技术方案的优缺点和成本，最后，要善于借力云技术，避免重复造轮子。