3

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

 2 years ago
source link: https://www.cnblogs.com/thanks/p/16383551.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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

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

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

微软在这方面也正在进行长期的试验和探索。我在上一篇文章《聊聊微软的大数据平台和一些个人看法》中说过,微软内部是一个基本上完全平等和开放的协作系统,不同的部门、员工间,虽然身处世界各地、时差不同,但是通过工作平台有着无缝和高效的工作体验。围绕着大数据平台,海量文件的相互引用,基本上是一个网状的去中心化的工作环境。因此,他们的知识也是极度碎片化的分配到了每一个工作小组(估计在微软,一、二十人的工作小组达到了上万个)。在此之前每个小组都有自己的知识管理工具和管理方式,甚至每个小组的组员都在同时使用好几种知识管理工具,这样造成了知识的散乱及不易整理,微软自己也意识到了这个问题。因此,从去年起,微软搭建了一个叫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等技术,大数据平台及和周边的应用之间的通讯质量还是可以得到保证的。在微软,我还没碰到比较好的架构师,只是大家对如何协同工作以及程序健壮、稳定性方面有着一定的共识,代码写得特别烂的人也进不了微软周边;微软地很多产品我想都是对开源产品的模仿,也就是我们俗称的重复造轮子,然后在上面构建自己的业务系统。

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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK