2014年12月加入了一个新的项目，这是一个游戏的辅助项目，其实可以认为是一个典型的互联网产品。这个综合使用了c/s和b/s两种结构。因为游戏相关的项目采用c/s是自然而然的事情，同时运用b/s结构就值得玩味了。在接手该项目b/s相关部份工作的过程中促使我开始认真思考关于一个技术团队在开发一个产品的过程中应该如何选择技术和工具的问题。
这个问题完全没有标准答案，但实际上在纷乱无章的表象背后其实还是有据可循的。首先从程度员的角度来看。毎个人其实都有尝试新技术的冲动(我所说的新技术包括新产生的技术和已经久负盛名但却从来没有机会使用的技术)，对程序员来说掌握新技术就是保持竞争力，同时还容易得到认可和赏识。所以不论是开始新的项目还是重构维护老项目，我们都要面对新技术的诱惑。
那么在面对新技术时，我主张的态度如下：
## 对于新产生的技术应该持非常谨慎的态度
新产生的技术往往有非常酷的feather, 但往往存在以下几种坑：
* 存在大量未知的BUG
* 可能存在一些没有考虑到的设计缺陷
* 版本变化频繁，而且API不兼容
* 缺少文档和说明
* 中断开发和维护
如果实在要应用这些技术应该考虑使用桥接模式将它的接口封装起来，以应对接口变化，甚至是不得以的整体替换。
## 对于行业内已经广泛使用的成熟技术也应该量力而为
对于已经较成熟但没有应用过的技术来说，主要的风险在于团队成员的学习速度。成熟的技术往往有一整套相关的配置和一些背景知识需要了解。在熟悉这些内容之前如果碰到问题的话，解决起来的时间往往很难掌握。所以面对这些相对比较成熟的技术时除了它的feather，性能之外，还应该将它的文档，资料的丰富程度考虑进来。万一发生意外的情况能否快速的找到解决方案。
我听说过的一个真实案例：由于不了解如何配置linux服务的最大连接数，导致nginx服务器无法应对几千个并发请求最终导致整个系统的吞吐量下降。技术人员当时只好暂时放弃linux+nginx的方案临时转向windows+apache。
## 新技术（知识）应该在团队内传播开来
如果经过权衡，已经决定要引入一些新技术到项目中来。那么接下来就应该要将这些新知识在团队内传播开来。首先前期调研的人在整理和分享的过程中能进一步加深对新技术的认识。其他的团队成员在学习的过程中也能从不同的角度完善整个团队对这一技术的掌握。最重要的是，如果团队中发生人事变动时，这个新技术不会成为交接后的隐在风险。