如何成为架构师系列：技术选型2

    随着业务发展，团队又碰到新的技术选型问题。

    一是客户端选型。

    二是qml和qWidget之争。

    三是web选型。

    客户端选型：

    当时团队已经接了Windows客户端和Android客户端的项目，售前部同事也多次提了IOS客户端的需求，所以我们面临着客户端选型的问题。

    当时，我们已经完成了一个基于Windows客户端的大项目，平台用的是Qt；Qt是支持Android开发和IOS开发的，但肯定没有Android和IOS的原生支持好，一方面界面效果受限，另一方面在以后的复杂项目中可能会存在“坑”。而组建一个Andoid团队和IOS团队比较耗资源；Andorid还好，我本人做过Android项目；IOS团队里却没人接触过，虽然学起来不难，但经验积累也需要时日。

    所以当时我提出了两个概念：一是瘦客户端，一是Qt一体化。

    所谓瘦客户端，是借鉴Web开发的思路，将大部分的数据、逻辑放在服务器端，客户端只负责界面绘制。这样一来客户端编程变得简单，我稍微带一带同事就能解决Android和IOS客户端的原生编程问题。但如果在客户端分成三个分支，在代码维护及升级方面是个大问题。所以我接着提出了Qt一体化。

    所谓Qt一体化就是用Qt来编写所有类型的客户端。也有弊端：一方面对基于Qt的android和IOS项目没经验，担心出问题；另一方面对Qt界面在Adnroid和IOS上的效果和优化担心。

    这次选型历时较长，经历了一些波折，最后的结果是Qt一体化的方案胜出，瘦客户端方案暂时搁置。理由如下：

    1、根据调研，我们的项目大部分在界面效果上的要求不会过高。对于要求高的UI展现我准备单独立项，做一个“可视化”平台。鉴于可视化平台并不紧迫，所以就暂时放弃了Androi和IOS原生语言。

    2、经过对瘦客户端的评估后我认为难度较大，不如搭建一个普通客户端平台同时建一套Web机制。建完Web机制后如果有需要，再通过远程调用等方式在Android和IOS端开始做瘦客户端的工作。

    

    qml和qWidget之争。

    qml和qWidget之争出现在客户端选型之前，事后总结这是一次错误的选型。

    最初我们选择了qml，一是qml这种类似xml的方式和android类似，qml也能更好的支持移动端;二是qml技术相对较新，大家觉得有挑战性一些。

    但qml的使用过程一直不太顺利。在qml和cpp的交互，qml各页面的值传递、消息传递等方面，我们不得不解决一个又一个传统图形界面编程不会遇到的问题；雪上加霜的是qml在网络上可用的教程、资源偏少，无疑减缓了问题解决的速度；更糟糕的是qml平台本身，在编辑器方面有缺陷，不利于编程和调试。

    压垮qml的最后一根稻草是MVC设计模式。在当时的项目中，由于用户需求特别复杂，客户端的逻辑也比较复杂。为了支撑这些逻辑我决定采用比较重型的MVC架构，取代原定的MV架构作为客户端编程的基本框架。但qml的技术特性导致在qml中实施传统的MVC架构非常麻烦，代码散乱，追踪也困难。

    最终我们还是舍弃了已经用了两个来月的qml，为此不惜重构客户端所有代码。事后想想qml设计的目标是为了支持移动端快速的图形编程工作，本就不适用于复杂的Client端情形；而选用qml能更好支持移动端的想法当时也缺乏调研，事实上qWidget也同样可以支持移动端而且能同时支持客户端；最重要的，以我们团队的能力和规模不应贸然去尝“新螃蟹”，资源不允许。

     最后一个选型事件是web技术的选型。

    当时的需求是：从无到有建立支持我们业务的webService，这个WebService将运行在内网；在此之后建立一个运行在外网的产品运维网站，最后是建立一个“云系统”。云系统之所以引号，是因为这是一个广泛概念上的云系统，短期内不需要用到诸如openStack方面的技术；但也比传统的网站复杂一些。

    最终的结果，我们采用了springMVC+themeLeaf+html5+Bootstrap的方案。

    这个技术选型结果有古老保守的部分，也有相对新鲜激进的部分。但形成该体系的原因，其实无非老生常谈：需求和团队现状。

    我们最首当其冲的需求是为一套管理系统建立web端，以此搭建一套BS架构，作为公司传统CS架构的补充。既然是服务于管理系统不是服务于大的网站，那对性能的要求就不高。

    团队方面，除了我本人，团队其他人都没有web开发经验，因此会倾向一些较为简单且较为成熟的技术，比如著名的SpringMVC。又因为短期来说我们web开发的工作量不多，专门为此养一个或几个js前端工程师得不偿失，我便起了让一名熟悉qss的技术同事和一名稍微了解html5的同事写前端的想法。由于JavaScript技术比纯html5复杂不好上手，因此选了themeLeaf+Html5。最后为了对Html5做一定限制和规范，挑中了BootStrap框架。

    从以上三个示例来看，对于这种20来人的应用开发型团队，技术选型无非是需求+团队现状+经验。而且很多时候选型的优劣并不由某个技术的先进性或者单纯的“好坏”决定，而是技术方面和非技术方面的共同权衡。最后，身为部门的Leader哪怕再忙，也要亲自去摸摸自己选型的技术的底，并且根据这些基础搭建一个基础框架再让其他同事上手。对于小团队的技术Leader来说，他本身的攻坚能力是非常重要的；如果不对自己选好的框架足够熟悉并总结出规范性的东西交出去，你难以轻易看到其中一些问题。如果你都发现不了问题，其他同事更难以发现，等到后期需要修正框架，代价就大了。