引言

筆者 2012 年做為敏捷教練入職百度，到 2018 年年底一直做為敏捷教練，在百度內部進行敏捷開發的推廣，DevOps 實施工作。在工作過程中，我被頻繁的問到以下幾個問題:

1. 敏捷/DevOps 教練是做什麼的？你能幫我寫程式碼/帶專案/做測試麼？
2. 你看我產品線的現狀，適合做 DevOps/敏捷轉型麼？
3. 我的產品線做了敏捷/DevOps/精益，到底能帶來什麼收益？
4. 回到具體的實施，我們應該從哪裡開始著手？

相信這些問題也是很多企業的 IT 主管，DevOps 推動者想問的問題。今天我就根據我自己的工作經歷來為大家分享一下我的理解和實踐:

I.什麼是敏捷教練？在百度做敏捷教練是種什麼體驗？

對於敏捷教練，好像很難有一個統一的定義。引用

CIO.COM 上一位博主的原話:

"Agile coaches help train corporate teams on the agile methodology and oversee the development of agile teams to ensure effective outcomes for the organization. They are responsible for guiding teams through the implementation process and are tasked with encouraging workers and leadership

to embrace the agile method. The agile coach’s ultimate goal is to arm agile teams with the right knowledge, tools and training so that they’ll be able to use agile to its full potential."

提取上一段內容裡的關鍵詞：一名敏捷教練的工作方式是通過激勵一線員工和領導者的教練方式，去引導團隊使用正確的知識(敏捷開發知識)，工具和培訓，從而激發團隊的真正潛力，最終能夠保證團隊的有效產出。

接下來講，在百度做一名敏捷教練是一種什麼體驗。下面這張圖是我在描述自己工作的時候經常使用的一張圖:

充電: 獲取知識:

對於一名百度敏捷教練來說，不斷的吸收新的業界知識無疑是非常重要的，紮實的理論知識是我們在產品線開展工作的重要基礎。

重要的是，只瞭解敏捷開發是不夠的，我們在產品線裡面臨的是各種各樣的角色協作，研發效率，工具甚至技術上的問題。這就要求我們首先 1.瞭解網際網路產品的商業模式；2. 瞭解產品線的主要技術棧。這樣，我們獲得了和產品線同樣的語言，能夠有互相交流的內容，也使得我們更加理解產品線當前的現狀和問題。

接下來，我們需要在自己擅長的領域建立一個完整的知識體系:

我們說 scrum、kanban、SAFe 這些敏捷開發框架是一個個的知識點，填充了產品研發過程中開發，測試，到釋出階段的管理實踐。向前到使用者訴求的挖掘，向後到服務上線後效果的分析，我們又需要掌握客戶開發，創新思維，資料分析的知識，這樣串聯起來形成了一個知識面；這樣還不夠，我們還需要深入到開發，測試，運維的體系去了解工程實踐，諸如程式碼重構，單元測試，持續交付，自動化測試等 DevOps 領域的知識，在現在的雲原生時代，我們還需要去了解雲，容器，叢集等基礎設施的知識，這樣才形成了一個知識體系。

這個體系包括了從企業 IT 基礎設施，到技術棧，到產品研發生命週期的管理實踐，工程實踐的知識。唯有這樣，我們才能從容面對產品線複雜的情況。

基於上述的原因，我們在百度內部叫做軟體工程方法團隊-- Software Engineering Team, 簡稱 SET。我們的定位是軟體工程領域的知識和實踐專家，而並非單純的敏捷開發專家。

賦能: 體現價值:

上面這張圖的右側是百度的各條產品線，我們對敏捷教練的核心要求是: 要給產品線帶來變化，提現自身的價值。多年以來，我們對於這句話的理解已經達成了共識。變化的是什麼？是引導團隊從現有狀態達到一個更高效能和效率的狀態。

我們和產品線合作的初期，產品線的需求往往只有一句話: 我覺得我這裡現在有點亂，你能來幫我看看是怎麼回事麼？做為教練，我們就需要在前期清晰的識別到哪些導致"亂"的問題並給出解決方案，並引導產品線通過一系列實踐解決掉這個問題，從而使研發團隊達到一個更高效的狀態。

關於效率和效能我們在後面章節詳細介紹，在這裡我想表達的是: 百度敏捷教練的價值不在於做了多少次培訓，為多少個團隊引入了敏捷實踐，而在於是否能夠解決問題，提升效率和效能。對我們來說，培訓，方法，工具都是解決問題的手段，我們要關注的是結果，這是真正提現價值的地方。

沉澱: 形成方案:

最後，也是最重要的部分，是我們要把在產品線驗證過的實踐形成可複製的方案。方案中包括了工具的優化和引入，管理和工程兩方面的具體實踐，產品線的實施案例。我們意識到: 想撬動體量如 BAT 這樣級別公司的研發效率提升，只靠基於人的專家服務模式是行不通的。原因有三個:

1. 人力的覆蓋密度不夠: 我們做過一個估算，對標行業內大型公司的其它團隊，為了實現全公司的專家覆蓋密度，我們需要建一個近 100 人的專家團隊，這是一個相當高昂的成本，而同樣 100 人的業務團隊，已經可以支撐一箇中型以上的業務了；

2. 重複工作: 雖然每個產品線面臨的問題不同，但是解決方案是共通的，因此我們每切入一個產品線，往往需要將之前做的實踐在重新實施一遍。時間久了我們會恍然覺得自己就像被縛的普羅米修斯，每天重複著重生--被啄食肝臟的死迴圈；團隊會因此失去前進的動力和方向，這是非常危險的一件事。

3. 效果難以固化: 在諮詢行業有一個特色，當企業和諮詢師合作緊密的時候，往往企業會取得很好的改善效果；而當合作關係結束，或企業內外部環境發生變化的時候；企業的表現往往又開始回退。其實企業內的產品線也明白這個道理，所以我們的專家一旦投入一個產品線，就很難抽身出來。產品線出於對專家的信任和保持效果的期待，會非常抗拒我們將人員撤出。

上面三個問題形成了一個死迴圈，因為人力被分散在現有產品線，所以缺少人力投入到新產品線，人力覆蓋密度不夠。覆蓋密度不夠，導致實踐很難形成共識。難以形成共識，就需要我們不斷的靠人去引導實踐，對人力的需求就更甚。

所以我們必須將實踐中可重複的部分變成公司範圍內的共識, 通過研發工具固化下來，靠產品線自身的知識傳承去固化效果；同時也減少團隊中重複的工作；基於這樣的模式，專家團隊需要做的事情有這樣幾件:

1. 探索軟體工程的前沿領域: AI 開發和傳統服務開發有什麼區別？雲原生概念下，軟體工程又變成什麼樣？有哪些實踐發生了變化？
2. 引導產品線的多方角色識別瓶頸，達成一致，從而激發產品線自身對效率提升的訴求
3. 引導產品線跨越變革過程中的一道道門檻，實現對工程能力永無止境的訴求

綜上所述，在百度，我們一方面是最新軟體工程實踐的踐行者，一方面我們是企業研發變革的推動者，一方面，我們又是研發工具的訴求提出者。這就是百度定義的敏捷教練，或者更貼切的，應該叫軟體工程方法專家。

接下來就是今天我要重點介紹的: 關於從產品線現狀出發，識別研發效率瓶頸，與產品線達成共識的一系列招式，我將其概括為: 一個分析模型--冰山模型，一本路書--Agile fluency model

II. 問題的分層模型--冰山模型

這部分回答了前面的第二個問題: 我的產品線現狀是否適合做 devops。首先我們要引入一個概念: 冰山模型

*冰山模型是美國著名心理學家麥克利蘭於 1973 年提出了一個著名的模型，所謂“冰山模型”，就是將人員個體素質的不同表現表式劃分為表面的“冰山以上部分”和深藏的“冰山以下部分” 其中，“冰山以上部分”包括基本知識、基本技能，是外在表現，是容易瞭解與測量的部分，相對而言也比較容易通過培訓來改變和發展。

而“冰山以下部分”包括社會角色、自我形象、特質和動機，是人內在的、難以測量的部分。它們不太容易通過外界的影響而得到改變，但卻對人員的行為與表現起著關鍵性的作用。* ---- 引自百度百科

我最早接觸這個冰山模型，是在 2015 年接受的一次《系統思維》的培訓課上，當時老師提到對於一個團隊來說，他的行為模式也存在著存在著易於觀測的部分，和待挖掘的深層次部分，總結起來，團隊的冰山模型是這樣的:

這個模型的四個層次分別是:

1. 現象: 可被觀測到的團隊的表現，甚至產品表現。這一部分是團隊的內，外部觀察者最容易感受到的表象，它是結果而非原因，更深層次的一些問題導致了這些表像。比如我們前文提到的"我覺得團隊現在有點亂"就是一種很常見的現象；再比如和團隊 one one 溝通的時候團隊成員的吐槽，都是可以直接反映出團隊的現象。甚至，一款產品穩定性，服務水平的波動，也是團隊現象的一種外在表現。在這個層面上，我們能夠做的是如實的記錄，現象能幫助團隊增強對問題和痛點的共識和認可。但是想解決問題，我們需要深入水下，向下挖掘。

2. 趨勢: 這個層面是對錶象的第一層解釋，當我們說到"產品質量差", 在趨勢這裡，我們需要找到質量變化的量化資料: 穩定性，BUG 資料，測試執行次數等等；當我們說"團隊交付慢"的時候，我們就要找到諸如服務釋出頻率，單個服務的交付週期等資料。

   在這個層面上，組織經常犯的錯誤有兩個: 第一個錯誤: 缺少恰當的量化的指標來說明趨勢，我們說"恰當"包括了兩層意思，第一，組織是不是有這樣的長期記錄的指標來反映趨勢: 我個人經常遇到的情況是: QA 反饋說現在 RD 提測的質量越來越差，我問道，噢，我們有最近一段時間提測打回，或者線下 BUG 的記錄資料麼？結果沒有... 那麼，即便我們開始強化自測，增加了 RD 的工程實踐，我們如何驗證效果呢？

   第二，觀測出來的指標無法指導下一步的行動: 在這一點上,設計研發效率度量指標和設計產品運營指標並無本質上的區別。指標和行動之間必須有很強的關聯關係，比如我們引導 RD 進行單元測試的實踐，那麼我們就建議 QA 去對產品 BUG 進行分析，記錄那些反覆出現的 BUG 數量，記錄由於程式碼邏輯問題導致的 BUG 數量。以此來引導 RD 更多的採納單元測試。第二個錯誤: 根據趨勢採取行動，很多團隊的管理者在觀察到資料後往往條件反射式的建立一系列的監控和控制措施，試圖扭轉趨勢。但往往無法取得很好的效果，主要是因為產生之類問題的原因還沒有找到，而監控和控制措施又需要投入成本去實施，團隊本來就不多的注意力進一步被分散到和自己本身工作沒有強相關的事情上，實踐的採納效果不好，結果也不好。

   經常有團隊問我: 你能不能幫我們設計一個變更控制流程/XXX 流程，我會建議他們，我們先找到需求變更的原因，之後找到一種不需要這個流程的解決方案，或者用更簡單的契約來代替這樣的流程。所以，在這一層面，我們需要的是設計，並長期記錄和觀察。

3. 結構: 在冰山模型中，這一部分是最為核心和關鍵的層面，也是大多數諮詢師，教練關注的層面。什麼是結構，結構是一個組織在一段時間內在多個維度的表現，一個組織的結構，在一定的觀察期內是靜態的(如果組織處在不停的調整期，我們可以認為在人事/業務/技術層面，該組織的表現就是"變化")。我們團隊經常會使用靜態結合動態的結構分析方法:

靜態分析: B.A.P.O 4 象限分析:

這套方法並不是百度原創，而是來自於《軟體產品線工程》，他講的是企業如何通過平臺和技術複用，實現高效的軟體產品研發

在實際工作中，我們通過對產品線關鍵人員的訪談，從上述 4 個象限來描述一個研發組織的整體現狀，這個 4 個象限的關係是這樣的:

• Business，也就是業務，或商業模型決定了企業的競爭態勢和業務價值流的長度，Business 部分的現狀對其它三個象限提出了要求或限制；

• Organization，我們重點關注組織是否具備能夠滿足業務需求的能力，包括了組織能力的定義，具體人員的能力定義，具體的組織結構，組織的職責邊界。在組織維度有一個和效率相關度非常高的指標--最小產生價值的單元，如果我們講研發效率，這個最小單元的定義就是一個組織內部能夠獨立提供 IT 服務開發，部署，運維的團隊規模大小；單元的規模越小，代表企業的運作越靈活，越能應對快速的變化。在亞馬遜，這個單元的大小就是著名的"披薩團隊"。

• Architect，包括了當前服務於業務的 IT 系統的技術架構，技術選型，團隊對技術實踐的採納；Architect 要能夠賦能現有的業務，至少不要成為企業效率的瓶頸。比如微服務，高可用，上雲，DevOps 實施，研發的系列工具都屬於架構象限；

• Process，定義了產品，運營，研發，運維，測試，OP 等角色間的協同機制，在 process 層面，我們要關注的是是否流程上有缺失，或者 over process 的情況；

動態分析: 系統迴圈圖 關於系統迴圈圖的介紹，大家可以看這篇文章: https://www.sohu.com/a/236938851_114819.

我這裡拿出一個例子來，這是 18 年年初我為百度內部一個大型移動開發團隊分析版本交付週期時，和產品線共同繪製的一張系統迴圈圖。這是一個典型的增強迴圈: 一方面需求的增加導致需求間協調成本越高，另一方面團隊的技術債務開始積累，直接導致研發的工作被修改 BUG，需求溝通佔據，最後留給測試和釋出的時間越來越少，於是團隊加班越來越嚴重。研發總監找到我們希望使用更長的迭代週期，在分析了團隊的現狀之後，我提出了和他最初印象相反的方案: 應該縮短迭代週期，並且在技術，流程，組織方面實施一系列的管理和技術實踐，減少無效的溝通和流程，最終提升效率(第二張圖所示)

如下圖所示: 首先將三週的迭代變為兩週，需求批次，研發和產品的組織按照兩週的迭代來進行，主要的改進點包括:

• 技術方面: 移動端深入元件化改造，將不同業務方向間的釋出解耦；從服務端開始實施 DevOps，提升程式碼提交後的效率；每輪迭代加入一定量的技術類需求，用來清掃技術債務，提升產品效能和穩定性；
• 管理方面: 減少每輪迭代需求輸入的批量，並根據團隊的實際交付能力調整；強化需求的准入規則，提升需求質量；透明化研發過程，提升溝通效率；

團隊經過一年多的，截止到今年 Q2，已經實現了每週能夠在移動端釋出灰度版本，三週釋出一個大版本的節奏；單個需求的交付週期縮短了 20%；需求優先順序決策時長縮短了 80%；整個底層服務的 devops 實施水平位於公司內部頂尖水平。關於這個團隊的故事，可以參考這篇文章: https://developer.baidu.com/topic/show/290264 上面就是我們在組織的結構層面進行的分析方法和例項。 對分析方法感興趣的觀眾，可以關注" 百度效率雲官方公眾號"， 回覆"調研問卷"獲取基礎調研模板。也歡迎大家在討論區提出相關問題

4. 價值觀: 最深層面，也就是組織在產品研發方面秉承的共同理念。這個層面上，存在著非常簡單，但是非常根本性的判斷原則，我習慣稱之為"Ground rule"。比如: 釋出的速度優於產品的質量；大而全的產品方案好過簡單實現的 MVP； "聽領導的安排是最安全的"。這些原則就像一個組織的潛意識，它的建立，是一個組織在長期磨合的過程中形成的應激性反映。一旦團隊面臨壓力的時候，指導團隊行動的不是制訂出來的規則，而是這些"潛意識"。這就是為什麼很多團隊在業務發生變化的時候，改進工作會倒退。這樣的組織雖然在結構層面發生了改變，但價值觀層面沒有發生變化，新的原則沒有被植入進去，所以在面臨壓力的時候，又退回到了原本的表現。

總結一下: 通過冰山模型的建立，我們對一個產品研發組織建立了從表象到根源的立體診斷；這就初步解答了文章開頭的第一個問題: 我的企業要不要實施 devops? 答: 我不要我覺得，我要你覺得。做為研發組織的管理者，你希望解決什麼問題，你希望取得多大程度的改善，這才是企業在實施 devops 之前需要全盤思考的事情。

III. 改進的 roadmap--Agile fluency model

接下來我來回答第三個問題: 我的產品線做了敏捷/DevOps/精益，到底能帶來什麼收益？對於這個問題，在一開始我也只能非常巨集觀的回答說: 提升研發效率，減少研發過程中浪費。直到我看了 Martin Fowler 部落格上的這篇文章: 《The Agile fluency model》 ，我對企業採納敏捷開發方法,DevOps，精益產品實踐的收益有了更系統化的認識。 在這篇文章裡，老馬提出了一個名為 Agile fluency 的模型，如下: 首先，這不是另一套成熟度/分級模型，根據老馬的解釋，這是一套企業實施敏捷/DevOps 的演進圖。圖上共分成 4 個領域，分別是聚焦（Focusing），交付(Delivering)，優化(Optimizing)，強化(Strengthening)。每個領域包含了一系列的管理/工程實踐，企業通過熟練掌握這 4 個領域裡的實踐，可以獲得的收益分別是:

• Focusing teams produce business value.
• Delivering teams deliver on the market cadence.
• Optimizing teams lead their market.
• Strengthening teams make their organizations stronger.

這 4 個領域沒有嚴格的改進順序，企業應該從自身的需求出發，找到最適合當前現狀的切入點。這裡我們要特別注意的是"熟練掌握"這 4 個字。不同於採納，嘗試，使用，老馬在文章中強調，一個組織如何判斷自己已經順聯掌握了某一個領域呢？即要求團隊即使面臨壓力，依然能夠按照領域中的實踐去實施，而不會拋棄掉已經習得的實踐。這和我在前面冰山模型中講述的"組織潛意識"是一個道理。

那麼，每個象限具體包括哪些實踐，企業實施後預期的收益是什麼？付出的時間成本是多少呢？文中也給了這樣一個指導: 以上圖中 Focusing 領域為例，該領域包含了諸如 scrum ,kanban 等敏捷開發的非技術實踐。團隊在這個階段應該將改進的精力投入到工作流程設計。團隊需要大概 2-6 個月(取決於團隊的迭代週期)。通過熟練掌握 Focusing 領域，團隊從交付軟體和系統進化到交付業務價值，團隊的研發過程從黑盒狀態變為高度視覺化，以及不斷改善的能力。

根據我的經驗，這是一個非常誠懇的，切合實際的描述。團隊僅僅掌握敏捷開發中的管理實踐，並不能給團隊的生產力帶來提升。敏捷管理實踐能夠保證的無外乎以下幾點:

• 圍繞業務價值組織研發流程(USER STORY BASE）
• 視覺化的研發過程及瓶頸(視覺化看板,kanban 方法)
• 小批量的，高頻率釋出(user story, iteration)

我們說，雖然釋出頻率更快，但是在企業人員能力，技術角度沒有變化的情況下。這個更快的頻率是通過減少批量來實現的，團隊本身並沒有獲得更高的生產力。

再來看 Delivery 領域，這個領域中包含了敏捷開發中的技術實踐，比如 XP 中的 TDD, pair programming 等等，我們會發現 DevOps 赫然出現在這個領域。那麼實施這些工程實踐，我們的預期收益是什麼呢? 如下圖所示:

• 減少 BUG，團隊耗費更少的精力在修復 BUG 上(CI/CD, TDD)
• 提升架構的合理性(reuse, refactoring, micro service)，減少程式碼技術債務，團隊開發新功能的邊際成本在下降
• 團隊可以根據業務的需求隨時釋出，更靈活的響應業務需求 所以，團隊想獲得真正的生產力的提升，應該在 delivery 領域發力。還是以 delivery 領域為例，企業掌握這個領域需要付出哪些成本呢？ 最大的成本是團隊的學習成本。團隊想熟練掌握 delivery 領域，就必須忍受在前期學習技術實踐時暫時性的生產力下降，但是，一旦團隊開始適應新的工作方式，生產力將獲得極大的飛躍(如下面的學習曲線示意圖)。 舉個實際的例子，在 2014 年，我曾經指導百度地圖的客戶端團隊和一部分服務端團隊實施 devops。服務端團隊的約 30 名 RD 花費了大約三個月的時間來練習書寫單元測試，介面測試，並將其在自動化流水線上執行起來，又經過了兩個月來養成快速修復構建和程式碼提交的院隊習慣。最後我們做了一下效率方面的: 在嘗試 Devops 實踐之前，這個團隊在兩週的迭代週期內，開發和測試的時間佔比平均是 1：1；嘗試 Devops 實踐之後，團隊一個迭代週期內，只需要 1 天的時間進行手工的驗證和測試，就可以釋出服務。這意味著團隊每兩週就多出至少 3 天的開發時間！這是生產力上巨大的飛躍。

再來看移動客戶端的成就，客戶端的團隊共在實施 DevOps 之前，每個版本 release 週期是 3-4 周，其中有 1 周時間 QA 要求 code freeze，完全進行測試工作；我們用了兩個月的時間搭建了自動化的移動端流水線，嘗試瞭如 robotium, espresso,capybara 等移動端的 UI 測試工具，又用了 4-6 個月不斷的補充自動化測試用例。在 15 年初的時候，三輪的迴歸測試工作可以在 3 天內完成，當時一個 QA 的經理和我說，我最大的感受是，每個月最後一週不用每天加班到後半夜了~~>_<~~。我認為，這是產品線實打實感受到的提升。

最後，這個模型裡也附帶說明了企業如何選擇自己的實施切入點: 對於業務方向多，決策過程冗長的團隊，可以嘗試從 Focus 領域切入，建立從客戶價值視角審視專案的機制。打破業務方向之間在需求優先順序層面難以達成共識的怪圈。在百度的實際工作中，我們發現往往是那些通過業務調整，在短時間內團隊規模和業務範圍急劇擴大的團隊需要先熟練掌握這個領域。

對於交付週期長，經常因為質量等問題釋出失敗的團隊，可以嘗試從 delivery 領域切入，積極的擁抱 Devops。通過減少技術債務，架構優化來提升整個團隊的生產力。在百度的實際工作中，我們發現底層的服務團隊，或者有明確的交付時間點的團隊需要儘快掌握 delivery 領域中的實踐

對於那些處在創業狀態，需要快速實現 PMF(product market fit)或者快速增長的團隊，可以嘗試從 optimizing 的領域切入，更好的理解自己所處的市場和客戶需求。我們在一部分小型的業務創新型團隊嘗試過此類實踐。

至於 strengthening 領域，我目前還沒有太多的經驗，所以就不在這裡班門弄斧了 :)

最後

總結一下，實施 devops，需要從企業自身的現狀和訴求出發。選擇那些能夠真正給自己的效率帶來提升的實踐和方法，期待有一種標準方法能夠解決我所有的煩惱，其實是欲速則不達。在文中我提到了一些分析方法和模型。我在這裡列一下:

1. Agile fluency model: https://www.martinfowler.com/articles/agileFluency.html
2. 研發現狀調研模板: 關注"百度效率雲官方公眾號" ， 輸入調研問卷，獲得調研問卷的下載地址
3. 百度工程能力白皮書: 這個是百度工程效能部 10 年軟體工程經驗的大成，定義了百度的技術分類，標準研發過程，標準實踐，實踐的度量方法和工具。同樣請關注"百度效率雲官方公眾號"， 輸入"工程能力白皮書"獲得下載地址。

   相關推薦

   &quot;我要你覺得，我不要我覺得&quot;--根據企業現狀實施DevOps

   引言 筆者 2012 年做為敏捷教練入職百度，到 2018 年年底一直做為敏捷教練，在百度內部進行敏捷開發的推廣，DevOps 實

   房東要給我漲800房租，生氣的我用Python抓取帝都幾萬套房源信息，我主動漲了1000。

   __init__ tar extend 簡單 not in 詳細 分布 obj soho 老貓我在南五環租了一個80平兩居室，租房合同馬上到期，房東打電話問續租的事，想要加房租；我想現在國家正在也在抑制房價，房子價格沒怎麽漲，房租應該也不會漲，於是霸氣拒絕了，以下是聊天記錄

   我要做網站，主機域名怎麼選？

     主機：如果選擇的主機是共享ip，在購買之前一定要檢視該ip下的網站是否有不和諧的操作被搜尋引擎列入黑名單的可能。因為共享主機的其他網站如果被搜尋引擎懲罰，你的網站將會被連帶波及。     主機的選擇一定要確保主機能夠快速、穩定、安全。這些都會直接影響你

   彩妝新品 | 我要你的時尚 永遠走在她們前面

   南樂縣 阿里巴巴集團董事局主席馬雲發表致股東的公開信表示：生意難做之時，正是阿里巴巴兌現“讓天下沒有難做的生意”的使命之時。，阿里巴巴(NYSE:BABA)今日釋出了截至2018年9月30日的2019財年第二季度財報(注：阿里巴巴財年與自然年不同步，從每年的4月1日開始，至第二年的3月31日結束)。 財報中

   spring自我提升--我要變禿，不禿不會變強

   spring個人的理解 spring是什麼，你該怎麼回答。 答：是一個輕量開源一站式框架，在三層架構中都有自己的一個技術支援。其中最重要的2個概念aop,ioc。控制反轉，面向切面。 mvc和三層架構的區別 （表示層(web層)、業務邏輯層(service層)、

   趣談網路協議---基於JSON的RESTful介面協議：我不關心過程，請給我結果

   SOAP 過於複雜，設計是面向動作的，往往因為架構問題導致併發量上不去。 RESTful 是一種架構模式，主要面向資源，提供無狀態服務，有利於橫向擴充套件應對高併發。 傳輸協議問題 傳輸協議問題—基於 HTTP。 對於 SOAP，建立一個訂單，用 POST 動作

   我和你說張俊是我兒子

   app.py # -*- coding:utf-8 -*- from flask import Flask, render_template, request, redirect, url_for,jsonify from models import Article fro

   我今年36歲，除了sqlmap我啥也不會

   近期，一句”我今年36歲了，除了收費啥也不會”火爆了朋友圈。事情大概是這樣，某收費站員工畢業就一直從事收取高速費的工作，結果近期收費站被取消了，該員工認為自己36歲了，沒有一技之長，難以找到別的工作。原話是，“我今年36了，我的青春都交給收費了，我現在啥也不會，也沒人喜歡我們，我也學不了什麼東西了“

   女朋友讓我先去洗澡，然後讓我上

   剛看見女朋友在電腦前不知道在專注地看什麼，時不時還自言自語一下，我走過去的時候，她回頭看著我，怎麼說那個眼神呢？感覺自己很像掉進了獅子口中的獵物。果然，女朋友說，你去洗澡吧，別跟我搶電腦。我等會讓你上。說完，她對我擠了一下眼。 　　讓你上。讓你上。 　　上電腦還是……女友太

   我學習的程式設計，都給我帶來了什麼？

   前言 寫這篇文章的主要的原因是什麼呢？主要是想到了自己是怎麼從一個工科專業然後轉行來做到計算機專業，這中間的酸甜苦辣，人間疾苦想分享給大家，以及學習了程式設計之後我的世界觀、價值觀的變化，希望能與大家產生共勉。 我的程式設計之路 作為一個從農村出來

   90後，為什麼我建議你不要老是加班？

   一、領導的屁股 某知名公司lT部門曾做過一個試驗：要求員工準點下班，而且下班以後，統統關掉手機，遠離工作，去享受個人生活。 試了一段時間之後，發現員工的工作效率不降反增：原本需要加班才能完成的工作，現在不加班一樣可以完成，而且完成的更好。 這樣的結果讓公司有點詫異，於是找員工座談，問：既然你們

   90後，為什麽我建議你不要老是加班？

   他還 充足 沒有 選擇 呵呵 他在 計劃 出口 報告 一、領導的屁股 某知名公司lT部門曾做過一個試驗：要求員工準點下班，而且下班以後，統統關掉手機，遠離工作，去享受個人生活。 試了一段時間之後，發現員工的工作效率不降反增：原本需要加班才能完成的工作，現在不加班

   雙十一要來了，我去廟裡給你求了一道護身符

     雙十一要來了，   小哥沒來，卻來了一個陌生電話： “王蘑菇先生，請問你是不是最近在X家網購了一套性感睡衣？我是這家網店的客服人員。您買的這套睡衣質量有問題，公司現在需要召回並退款給您。麻煩您提供一下退款賬戶……” 應該是騙子

   以爬取“我要愛死你”貴州行政區劃為例，淺析lxml中etree的用法

   lxml是python中一個非常強大的解析庫。其中的etree更是常常用來判斷網頁中某一節點是否存在，並獲取相應的文字或屬性。 一、用法詳解 1、匯入etree import requests from lxml import etree 2、獲取網頁資訊並生成etree選擇

   【挖坑埋你】我違反了保密協議，正在被通緝，我覺得我很快就會被抓走，這個祕密我不得不說了，其實人類已經在2012年12月25日世界末日滅絕的差不多了，僅存了一批科學家和不到一百個倖存者，開啟了拯救毀滅計劃，用了五年

   挖坑埋你 我違反了保密協議，正在被通緝，我覺得我很快就會被抓走，這個祕密我不得不說了，其實人類已經在2012年12月25日世界末日滅絕的差不多了，僅存了一批科學家和不到一百個倖存者，開啟了拯救毀滅計劃，用了五年...

   對於奮鬥在《資料分析》前線的同志們，這些資料我要交給你

   目錄 資料化運營 python資料分析與資料探勘 精通python設計模式 演算法圖解 白話大資料與機器學習 python金融大資料分析 網盤連結：連結:https://pan.baidu.com/s/1vvaBScl4_

   【我是程式猿，我為自己代言】 不要讓任何事情成為你不去學習的理由。

   博主個人很喜歡網購，推薦各位加微信 annalego  她可以幫大家免費找淘寶天貓內部優惠券，不管你在淘寶天貓上看到的任何商品都可以，一年省個幾千上萬塊沒問題(前提是你喜歡網購-_-!)。 博主前些天在某天貓旗艦店看上件夾克售價289元，任何人直接通過搜尋進入到這

   “媽媽，我不想學了”，你的回答改變孩子一生（悵然若失，說了一句話：“為什麼當初沒有人逼我？”。我不願意學，你就不讓我學啦！那時候我還小，我還不懂事，難道你也不懂事嗎。要做成一件事，就必須有延遲滿足的能力）

   “媽媽，我不想學了”，你的回答改變孩子一生(組圖)新聞來源: 槽值 前兩天，送孩子去書法班的時候，在小區門口看到一位媽媽，她正拽著孩子往車裡進，孩子哭著掙扎：“我不想學舞蹈了，我不去，太累了……” 媽媽怒吼著：“你今天去也得去，不去也得給我去！” 最終，孩子還是拗不過媽媽，上了車，去學舞蹈。 我不禁想

   劉強東@馬雲：你要搞壟斷，我就拉上唯品會跟騰訊在一起

   點選上方“CSDN”，選擇“置頂公眾號” 關鍵時刻，第一時間送達！ 12月18日，劉強東釋出了一條訊息稱，“面對行業壟斷和‘二選一’等不正當競爭！我們在一起！”，並配了一張五人的合影。 （騰訊、京東、唯品會高管合影，從左至右依次為唯品會COO洪曉波、騰訊董事局主席馬化騰、京東董事局主席劉

   程式設計師發飆：公司架構調整被辭退，要我寫個人原因離職，太不要臉

   臨近年底，一些公司趁著發年終獎的節骨眼上進行了裁員動作，有的良心公司會給員工賠償，但有些公司卻千方百計套路員工，期望一分錢不花辭退員工。無獨有偶，有一名程式設計師也在年底遭遇了被辭退得命運，但公司的做法令人寒心，忍不住在論壇發飆起來。 如上就是這名程式設計師發飆的全部內容：今天被公司約談離