思考:应该引入更多的语言还是更少的语言去设计API呢?

在阅读朱赟的书《跃迁 - 从技术到管理的硅谷路径》时,其中一张有这么一道思考题『API的签名是设计语言无关的,那在设计中引入更多的语言还是更少的语言去实现不同的API呢?优点和缺点各是什么?』在这里谈谈我的思考。

先说优缺点,优点是能根据API的业务不同,去选择特定的语言来优化业务,缺点则是管理成本和风险的增加。

对于小团队来说,我认为使用更少的语言来实现API是最有利的选择。尽量少的编程语言,能使团队的资源更集中,而且这个时候,较单一的技术栈更方便管理。比如我在刚开始做目前的产品的时候,包括我整个项目就三个研发,我负责iOS和API接口的研发(使用WCF),A负责Android研发,B负责Web研发(ASP.NET MVC)。从主要编程语言来说团队有三种语言C#、Java、Objective-C(暂不算JavaScript吧😆)。这样合作半年后,A也开始负责部分API接口的研发,B也能处理Android的BUG,团队每个人除了自己的主力语言外,同时也掌握了另一门语言,在人员配置上形成了一定的补充。倘若在三人小团队中,不加限制的疯狂引入编程语言,譬如Go、Python、Erlang、C++等等,造成的最终结果是项目难以维护,毕竟能同时掌握这么多语言,并能在项目中不留坑的人实在少见。

对于大团队,更多的思考应该在合适的技术(语言)用在合适的业务上。同时团队也有足够的人力来维护、扩展项目。所以在技术(语言)的选择上可以相对的大胆一些。并且多技术栈的发展,能有效规避技术栈没落的风险。

avatar

Code4Cocoa

A ThoughWorker