当前位置 : 主页 > 编程语言 > 其它开发 >

微软外服工作札记②——聊聊微软的知识管理服务平台和一些编程风格

来源:互联网 收集:自由互联 发布时间:2022-06-17
微软外服工作札记②聊聊微软的知识管理服务平台和一些编程风格前言 近期,我参加了微软某部门的知识平台整合工作,正好把微软内部的各个知识管理平台的特点做一个整理,供大家
微软外服工作札记②聊聊微软的知识管理服务平台和一些编程风格 前言

近期,我参加了微软某部门的知识平台整合工作,正好把微软内部的各个知识管理平台的特点做一个整理,供大家参考。

众所周知,知识管理服务平台其实对任何一家稍有规模的企业都是相当重要的,俗话说铁打的营盘流水的兵,在当今社会,除了在国企,任何一个人都不太可能在一家公司工作一辈子,对公司来说也是如此,你也不能指望员工能在公司里工作一辈子,很多时候因为业务调整、裁员等,人员变动变成了家常便饭。如何将员工在工作中积累的知识财富进行总结和沉淀,如何让新老员工进行知识衔接、新人能够很快地上手工作,如何避免技术骨干将技术和业务带走,都是每一个老板需要经常思考的问题。

微软在这方面也正在进行长期的试验和探索。我在上一篇文章《聊聊微软的大数据平台和一些个人看法》中说过,微软内部是一个基本上完全平等和开放的协作系统,不同的部门、员工间,虽然身处世界各地、时差不同,但是通过工作平台有着无缝和高效的工作体验。围绕着大数据平台,海量文件的相互引用,基本上是一个网状的去中心化的工作环境。因此,他们的知识也是极度碎片化的分配到了每一个工作小组(估计在微软,一、二十人的工作小组达到了上万个)。在此之前每个小组都有自己的知识管理工具和管理方式,甚至每个小组的组员都在同时使用好几种知识管理工具,这样造成了知识的散乱及不易整理,微软自己也意识到了这个问题。因此,从去年起,微软搭建了一个叫Engineering hub的知识平台(eng.ms),并且提供了一系列的工具软件,方便大家将各自的知识管理库迁移到Engineering hub平台上。

在微软,不管什么知识管理平台统称为Wiki,也就是大家所熟知的维基百科。就像百度贴吧一样,Wiki是人人参与,人人贡献力量;每个人既是知识的提供者,也是知识的消费者,这充分体现了微软平等开放的企业氛围;除了Microsoft Confidence的内容外,核心技术绝对不会掌握在某一两个人手上,因此,大家在微软,每天、每时都能够学习到新的知识,如果没有较强的学习能力,是很难在微软长久地工作下去的。

大家平时使用的Wiki,有Sharepoint, Teams, OneNote, DevOps等。

SharePoint

微软推出SharePoint已经有了20多年的历史,曾经是最赚钱的软件产品之一,它为企业打造了一个统一的门户平台和业务解决方案,将用户、团队和知识进行整合。进行SharePoint开发需要一定的专业知识,软件本身也拥有相当的复杂性。在微软内部,SharePoint也得到了最大范围的应用,并且与其他软件诸如Teams等进行了深度整合,使得其生命周期在不断地延长。在SharePoint上,文档管理和其他公司的业务知识等进行整合,具有非常大的优势。一般每个团队在SharePoint上都有自己的门户和团队文档,是大家进行学习的好地方。
SharePoint作为微软老牌的产品,其文档管理功能一直没有进行演化,还是采取类似VS Source Safe的独占签入、签出方式,这样一旦有人将文档签出,忘了签入进去,别人看到只能干瞪眼,无法对文档进行进一步修改。相对于云时代多人协同在线进行文档编辑,这样的管理方式显然是落伍了。因此,将类似于源代码管理方式的SharePiont文档管理平台进行迁移,也是很多团队正在思考和在做的事情。

image

OneNote

OneNote其实是一个碎片化的知识记录工具,类似于便签,大家把工作中的心得可以随时记录下来,供大家参考,软件本身也在标签上使用了各种颜色予以区分。OneNote结合OneDrive,可以使得文档在各个设备终端上使用。OneNote在记录一些流程、技巧方面有一些优势,但是小组内员工的个人色彩比较浓厚。经过一段时间沉淀,会发现很多当初别人记录的内容已经过时,照着步骤去做全是坑,不如不看,小组内也不太会有人去对几年前别人写的心得做整理和修正,软件本身编目的功能也比较差,系统性、完整性欠缺,所以我感觉OneNote个人作为知识记录工具还可以,用于大的团队就不是很适合了。

image

Teams

微软的Teams是个非常不错的工作协同软件,大家可以把它想象成企业微信,主要用于聊天和视频会议。微软的员工遍布于世界各地,所以选择合适的工作协同工具是非常重要的,相信在微软内部外部工作的同学,上班时间Teams和Outlook是得一直开着并盯着看的。Teams也应该不负众望,很好的担当起工作协同软件的角色。在Teams里,大家可以为工作小组开设Wiki,支持一些有限样式的富文本管理。我想微软也是在做尝试,把Wiki同聊天软件捆绑在一起。可惜的是,Teams的Wiki不支持多级目录的管理,只能记录一些少部分的内容,并且仅限于小组内部的成员观看和编辑,这样就没法把知识分享出去;如果需要让别人能访问到自己的Wiki,还需要管理员进行授权,加到讨论组里面去,所以他的功能就相对比较封闭了;从迁移的情况来看,Teams里面的Wiki是被迁移得最多的,知识相当地分散和零碎,应该说不是个很好的知识管理系统,用于记录小组内的备忘还不错。

image

DevOps里面的Wiki

应该说DevOps的初衷不是用来做知识管理,他对于敏捷开发的支持、CI/CD集成方面非常完美,也是国内很多开发团队首选的源码管理工具。我们在初始化代码库的时候,可以使用它的Wiki功能,这样就默认生成了以Markdown(.md)格式的Wiki代码库;在文本中使用markdown标签,多人提交PR对Wiki进行管理。DevOps里的Wiki功能已经比较全了,Markdown本身对Wiki的支持就很好,它支持多级目录、目录搜索和全文检索,可以查看各个版本,还可发表评论、标识等;并且可以开放给其他组里的同事看,不需要额外的权限授予。所以微软的一些大数据平台包括Cosmos在内就使用DevOps中包含的Wiki功能;微软在做最后的EngHub整合的时候,也借鉴了DevOps的部分管理功能。

image

EngHub(eng.ms)

最后请出的是我们的王牌知识管理工具EngHub了,EngHub借鉴了GitHub的思想,是一个工程师(engineer)或者工程(engineering)的平台。微软为此申请了独立的专有域名,有专门的工作小组对其开发和维护。在这个平台上几乎整合了微软所有的业务条线的知识内容,有着海量的目录\分类和内容,对于在微软正在工作\工作过的员工,或多或少都会在EngHub上留下痕迹。

面对一个如此庞杂的的知识服务平台,仅依靠一两个团队是很难将他维护好的。因此,每个团队要将自己的知识贡献出来之前,就要先联系EngHub团队,申请相应的目录和密钥;在记录下代码库地址后,EngHub会以轮询的方式通过版本管理从你的代码库读入文档并转换、整合到Enghub里;他在很大程度上利用了现有的DevOps资源,将内容管理分散到每个具体的团队,又能够进行高度的统一和整合,其统筹的思路很值得我们的管理者进行借鉴。

EngHub背后的文档解析使用的是Docfx引擎(https://github.com/dotnet/docfx),微软使用的还是内部的一个专用的分支版本,目前稳定版本是2.x; 3.x都是Beta版本,和2.x有些兼容性差别,不太建议使用。EngHub网站前端使用的展现引擎竟然是nodejs技术栈的react?!,具有一些无刷新SPA的体验,希望有一天能用上Blazor 。
我当时为了把团队各方面零散的重要的知识整合到EngHub里,前前后后零零散散忙了半年,迁移了数万篇文档,几个G的内容,这些内容在EngHub上的目录结构里仅仅是一个很里层的很小的一个链接。因此可叹EngHub规模的庞大,有时间的话逛逛EngHub也是很有趣味的,前提是你要对计算机有兴趣,并且英文还算过得去。

image

微软内部的一些代码编程风格

“一直在模仿,从未被超越”对于微软来说是最恰当不过的。在技术上从来不进行头部创新,而是采取跟随者的策略,自己的企业反而在市场上始终处于领先位置,是商战里常用的一种策略,国内的企业我就不举例了。拿微软说,它的Windows图形界面抄袭MacOS,IE浏览器抄袭Netscape,后来IE、Edge纷纷被Chrome超越,又反过来用Chrome的引擎做Edge。微软内部的大数据引擎Cosmos应该是Hadoop的一个发行版本修改而来的,至今也没有开源,它运行在windows平台上,增加了对.net的支持,定制了一些功能,加强了稳定性。在Cosmos上可以使用Java、Scala、Python等语言进行开发,也可以运行Spark、YARN等作业,这不就是Hadoop套个壳么.......

在微软,使用各种语言开发的人很多,代码中使用设计模式的很少,倒是使用模板语言、DSL的比较多,比如Cosmos上运行SCOPE、为ObjectStore做定义的Bond等,都是一些模板语言+语法糖。

使用大数据平台,少不得在各个系统间相互调用,一般用的都是Azure Function、WebHook、WebAPI等。Http本身就不是可靠的的通讯协议,所以在相互调用中,会经常出现404、500错误,一般要设立重试机制。从.net core开始,微软就不再提供WCF,旧项目迁移到.net core\5\6需要第三方WCF库,协议和功能方面有着很多限制;我发现微软对SOA的热度正在冷淡,重心逐渐向微服务、容器化、SAAS、PASSS、低代码平台上转移。因为如果使用WCF、WS等SOA等技术,大数据平台及和周边的应用之间的通讯质量还是可以得到保证的。在微软,我还没碰到比较好的架构师,只是大家对如何协同工作以及程序健壮、稳定性方面有着一定的共识,代码写得特别烂的人也进不了微软周边;微软地很多产品我想都是对开源产品的模仿,也就是我们俗称的重复造轮子,然后在上面构建自己的业务系统。

微软外服工作札记系列
①聊聊我在微软外服大数据分析部门的工作经历及一些个人见解
②聊聊微软的知识管理服务平台和一些编程风格
③窗口函数的介绍

上一篇:redisson之分布式锁实现原理(三)
下一篇:没有了
网友评论