缘起

• 在任何一个大厂，譬如H司、Z司，都有自己的软件开发平台。陆续接触过一些软件平台，略有所得，记录于此。
• 本系列文章，不会去关注具体的平台实现，仅关注平台设计的一些考虑、建议、准则等。

何为平台？

给平台下一个定义比较困难，但可以用下面的方式来定义这个概念：

• 平台不是底层的OS，如Andriod、 Linux这种；
• 平台不是上层应用，如ftp客户端、http服务器；
• 平台和底层的OS、上层的应用有着密切的联系；
  粗略的讲，掐头去尾，平台就是中间这段，平台基于依赖底层的OS，同时为上层业务开发提供基础设施，如定时器、进程抽象、日志等，相当于提供了系统的骨架、脚手架。

平台之利

研发效率

• 随着IT及互联网行业的发展，IT相关行业竞争日益激烈，开发周期也变得越来越短，研发效率变得更加重要。
• 如果没有平台，则每个产品开发都需要从0开始，那么在产品竞争中自然落于下风；而有了平台这个脚手架，对于研发人员快速实现产品功能，会起到巨大的助力作用。
• 平台也可以去除一些研发过程中的浪费，比如几个模块都需要日志输出，如果分别搞一套日志框架或调试命令，是否太过于浪费了？

经验保留

• 无平台之前，各人都是单兵作战，一些大牛虽然自己做的某个功能或框架非常NB，但是换个产品，换个人，就都不存在了，需要重新开发。而一旦该大牛毕业了，他的这套思想或实现就慢慢流落民间了。
• 有了平台之后，可以把一些牛人的想法或设计的框架纳入平台的范畴，后续即使大牛走了，其之前设计的思想或框架被保留下来，这样对公司的损失也会相应降低。

维护成本

• 没有平台的产品，一个需求，一千个人做，有一千个实现方案。有了平台之后，基本上千篇一律。
• 比如进程间通讯，可以有N种方式，维护起来非常困难。如果平台实现了进程间通讯的话，业务不需要太关注具体的底层实现，故障机会也降低了。

统一界面

• 平台为产品提供了统一界面，比如所有的日志输出都时同一个格式，所有进程注册都是一个模式，这种模式非常利于新人上手干活，无需关注底层细节。

平台之弊

大象跳舞

• 平台是一把双刃剑，平台一旦建立起来，随着产品需求的日益增加，平台只能日益臃肿，大象还能跳舞吗？

锤子与钉子

• 有了平台之后，什么需求、产品都会往平台上去靠，这样是否合理？是否平台限制了我们的选择、或左右了我们的价值观？

个人发展

• 平台对于公司而言，可能的确有巨大的价值，从某种意义上而言，抹平（或缩小）了人与人的差距，但对个人技术的提高，却不是一件好事。
• 有软件平台的开发，相当于用拐杖走路，走的多了，扔开拐杖是否依然会走路呢？

小结

• 本文简单说明下平台的概念，存在的利弊等，后续将继续探讨平台设计的具体问题，敬请期待。

如本文对你有些许帮助，欢迎打赏或通过内文链接购买书籍：
支付宝打赏方式及我的购物小店

cs