<input id="ohw05"></input>
  • <table id="ohw05"><menu id="ohw05"></menu></table>
  • <var id="ohw05"></var>
  • <code id="ohw05"><cite id="ohw05"></cite></code>
    <label id="ohw05"></label>
    <var id="ohw05"></var>
  • 微軟外服工作札記②——聊聊微軟的知識管理服務平臺和一些編程風格

    微軟外服工作札記②聊聊微軟的知識管理服務平臺和一些編程風格

    前言

    近期,我參加了微軟某部門的知識平臺整合工作,正好把微軟內部的各個知識管理平臺的特點做一個整理,供大家參考。

    眾所周知,知識管理服務平臺其實對任何一家稍有規模的企業都是相當重要的,俗話說鐵打的營盤流水的兵,在當今社會,除了在國企,任何一個人都不太可能在一家公司工作一輩子,對公司來說也是如此,你也不能指望員工能在公司里工作一輩子,很多時候因為業務調整、裁員等,人員變動變成了家常便飯。如何將員工在工作中積累的知識財富進行總結和沉淀,如何讓新老員工進行知識銜接、新人能夠很快地上手工作,如何避免技術骨干將技術和業務帶走,都是每一個老板需要經常思考的問題。

    微軟在這方面也正在進行長期的試驗和探索。我在上一篇文章《聊聊微軟的大數據平臺和一些個人看法》中說過,微軟內部是一個基本上完全平等和開放的協作系統,不同的部門、員工間,雖然身處世界各地、時差不同,但是通過工作平臺有著無縫和高效的工作體驗。圍繞著大數據平臺,海量文件的相互引用,基本上是一個網狀的去中心化的工作環境。因此,他們的知識也是極度碎片化的分配到了每一個工作小組(估計在微軟,一、二十人的工作小組達到了上萬個)。在此之前每個小組都有自己的知識管理工具和管理方式,甚至每個小組的組員都在同時使用好幾種知識管理工具,這樣造成了知識的散亂及不易整理,微軟自己也意識到了這個問題。因此,從去年起,微軟搭建了一個叫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等技術,大數據平臺及和周邊的應用之間的通訊質量還是可以得到保證的。在微軟,我還沒碰到比較好的架構師,只是大家對如何協同工作以及程序健壯、穩定性方面有著一定的共識,代碼寫得特別爛的人也進不了微軟周邊;微軟地很多產品我想都是對開源產品的模仿,也就是我們俗稱的重復造輪子,然后在上面構建自己的業務系統。

    微軟外服工作札記系列
    聊聊我在微軟外服大數據分析部門的工作經歷及一些個人見解
    ②聊聊微軟的知識管理服務平臺和一些編程風格
    ③窗口函數的介紹

    posted @ 2022-06-16 21:01  thanks  閱讀(1545)  評論(5編輯  收藏  舉報
    国产美女a做受大片观看