技術的價值
寫在前面
幾個月之前，偶然看到了老莊的一篇博客——《如何評價一個新技術 》，討論了 docker 是一個什么級別的發明：
上次與霍炬聊天，霍炬提到他在跟陳皓抬杠，陳皓認為 Docker 與 Java 是一個級別的發明，第二年就吸引了所有熱門公司的加入。而霍炬認為這太夸張了，畢竟就是個配置管理器嘛。而我的評價，可能會比陳皓的更高，我認為 Docker 比 Java 的級別還要高。而且，這與有多少公司參與無關。甚至可以反過來說：因為 Docker 極為重要，才會有那么多的公司，在第一時間加入進來。
</blockquote>文章看過以后最大的感受就是——道理還沒說透，當時我發了一條微信朋友圈用來備忘：
看來還是要寫篇文章才能討論 docker 的價值，先說個基本思路——分析這個問題，至少要從“人與人的協作方式”這個角度來談才算到位，docker 對此的改變甚至超過 java，起碼達到 linux 的水平......詳細討論五一后再寫。
</blockquote>然而真打算寫點東西的時候，卻發現這個問題是個大坑，如果從頭講起并交代細節，那遠不是一篇文章能涵蓋的，加上我又是個懶惰的人，所以拖延至今。
不過，討論的困難主要在于建立一個客觀合理的評估框架，因此本文的很大篇幅都是在做這件事，歡迎讀者對這個評估框架本身提出意見，當然，如果讀者沒有耐心，也可以跳過前面幾節，直接看最后一節。
</blockquote>明確重點
我們從一個問題說起——分析一個技術的價值，應該怎么入手？
我們所說的價值，其核心是商業價值（在現代社會，所有的價值最終都會由市場從商業角度來體現），而商業活動是否成功，無非是兩個角度：
- 尋找正確的市場需求
- 用低于同行的成本效益比在競爭中獲勝
</ol>技術對角度二的意義很好理解，因為它可以幫助提升效率或者降低成本。不過，技術對角度一也有幫助——本質上，商業活動是一種對未來需求的預測，但是我們并不能真的未卜先知，而先進的技術可以幫助我們盡早而廉價的實現一個商業雛形，便于盡早獲得市場的反饋。
因此，這兩個角度中，技術的作用都是在提升效率或者降低成本。
ok，現在明確討論重點——
- 提升效率
- 降低成本
</ol>效率問題
說到效率，會有一些人想到軟件的執行效率，然而這不是我關注的地方。
軟件的執行效率最多只是用戶要關心的非功能需求，而且它的影響只是一部分軟件和系統（甚至對這些軟件和系統而言，也不是所有用戶都關注執行效率），不是全局性質的問題。
而另外一種效率——生產效率則不然，這是影響所有軟件和系統研發的問題，是全局性的（這也符合我們上面對商業成功的討論）。當然，在軟件和互聯網企業，我們說的生產效率一般就是研發效率。
因此，能夠直接提升研發效率的技術就顯得特別有價值。例如：語言的自動內存管理減輕了程序員的工作量，以及各種抽象技術成倍甚至在數量級上減少了開發同樣功能所需的代碼行數，這些都是很好的例子。
Docker 在這方面能做什么呢？無能為力，因為這不是 Docker 的發力點。
Docker 這種技術，不能直接提升研發效率，它的價值是間接體現的，重點在對研發流程上各環節的優化整合。
記得剛用 Rails 的時候我震驚于它的開發效率，曾經和前公司（不是阿里）老板有過一次討論（老板是做技術出身，對研發很了解）。
這次討論中，老板和我一起分析了一個功能從需求到用戶使用的各個環節。最后我意識到，軟件開發環節只是所有工作的一部分，即使這塊提升效率，對總時間的提升比例也并沒有我想得那么大。
這并不是說 Rails 這樣的技術沒有用，但是，這確實啟發我考慮研發的整個流程，從這個角度看效率才能更全面，判斷才更清楚。
</blockquote>本系列前幾篇文章中已經提到過，開發、測試、運維三個主要環節存在信息不一致的情況，Docker 對此有比較好的解決辦法。現在我們從提升研發效率的角度再看這件事，你會發現，解決了信息不一致的問題以后，下一步改進的重點會很自然的加強研發測試。
因為之前的開發沒有動力做太多的測試，沒有條件進行更大粒度的測試，更不可能推進自動化聯調，而由于 Docker 的出現，開發一方面需要了解線上環境，另一方面則可以借助新的變化直接進行原來只有測試才會進行的一些大粒度的自動化測試，更由于已經轉變為 devops，線上變更變得更簡單可信，上線周期也能得到壓縮。
測試前置的結果就是提升研發流程整體效率，線上變更周期縮短更是能顯著影響軟件特性的交付效率。
上面說的內容很容易會讓人想到“精英團隊”、“全棧工程師”甚至是“個人代替團隊”這些話題，不過也有人對此不感冒，因為并不是任何時候我們都能用小團隊解決問題，有些場景的分工是不可避免的，這時候我們有可能借助技術來提升個體的工作效率嗎？
很遺憾，分工導致的單個成員效率下降是個普遍規律，理論上就不太可能用技術的手段改變它。
不過，對于分工的場景，技術卻能在另一個方面發揮價值——降低邊界上的開銷，也就是我們下面要說的——
成本問題
說起成本，人們一般都會想到機器、房租、員工工資等等，但是這些東西要么差別不大，要么不會成為競爭優勢（因為借鑒起來比較容易），所以不是關鍵。真正可以成為企業核心競爭力的成本，是企業為了發揮每個人的價值而需要付出的代價。
有時，企業通過技術革新可以降低某些方面的成本——比如優化算法降低機器數量，但是這里的競爭優勢并不是機器成本，而是企業的持續創新能力，說白了，是員工持續的創造力，因此我把這種競爭優勢歸為員工能力，此時的關鍵依然是發揮員工價值。
</blockquote>企業是什么？是將一個一個思想不同、看法各異、技術習慣不同的人凝聚起來的組織，而人與人的相互配合、密切協作，往往需要一些（廣義上的）管理手段，這都需要人力物力投入，另外，某些管理手段還會對個人生產力產生壓制，這些是要付出的代價，在經濟學上一般稱之為“管理費用”。
這個“管理費用”基于一個根本問題——“一個企業用什么方式將人凝聚起來”，回答這個問題會受限于每個企業的不同風格（也有人稱之為企業文化），很難借鑒和仿效，因此可以成為企業的競爭優勢。
</blockquote>聽起來這是個純粹的組織和管理問題，其實不然，人與人之間的協作，最大的困難就在于邊界不清，信息費用高昂，而這是技術可以有所發揮的地方。
這包括縱橫兩個方面：
- 縱向：軟件研發的鏈路上，至少包括三個主要環節——開發、測試、運維，分工以后，這些環節之間的扯皮和信息不暢就是增加管理費用的一大原因，因此標準化這些環節，將有機會降低溝通成本，提升溝通效率
- 橫向：即團隊協作，軟件和系統擴張的過程中必然發生團隊分裂，這時就會產生團隊間信息不充分的問題。這個問題甚至比縱向更嚴重，因為至少從目前看來，縱向的問題還有全棧團隊這條路可以走，而橫向基本無解，如果能夠降低這個費用，那么總的管理費用將被有效控制。
</ul>小結
根據上面的分析，我們可以簡單把技術在軟件系統開發中的全局性價值歸納為三條：
- 整合流程，減少生產環節，提升個人的控制范圍，以提高單個人在總流程上的生產效率
- 標準化流程上各環節之間的協作，降低溝通成本
- 減少橫向團隊間需要傳遞的信息，降低溝通成本
</ol>對比幾種技術的價值
基于上面的討論框架，我們下面看看幾種技術：
強調一下，一個技術的價值是多樣的，在其發展的不同階段還會有變化，而本文目前討論的僅限于“全局性”的和主要發展階段中體現的價值。
</blockquote>Java (tm)
java 的全局性價值來自于它的跨平臺能力，當它出現以后，程序員可以很容易在 windows 上開發一些運行在 linux 上的軟件系統。
關于跨平臺
其實很多語言都可以進行某種角度的跨平臺，但代價不同(比如c/c++需要重新編譯)，而且在 java 之前，幾乎所有的語言都遇到不同 OS 的庫不同的情況，這為跨平臺設置了很大的障礙。
java 是第一個“一次編譯，到處運行”的工程語言，并且自帶的 jdk 與平臺無關（由于 jni 很難用加上 java 社區語言純潔性的文化影響，各種第三方的 java 庫也是平臺無關）
</blockquote>在 java 出現的年代，windows 平臺上有很多優秀的 IDE，形成了對其它 OS 平臺的壓倒性優勢，加上 windows GUI 對新手的友好性，很多人的工作平臺都是 windows。而另一方面，unix/linux 在 server 端的優勢也很明顯，這使得研發工作和軟件運行的基礎平臺產生了割裂。
在此背景下，java 的跨平臺就導致了一個結果——整合了（在 windows 上進行的）開發活動和（在 linux 上進行的）運維活動。
但是 java 平臺一開始沒能做到跨語言，因此對橫向的團隊協同幫助有限（協作主要局限在同樣采用了 java 技術棧的團隊間，基于 J2EE 應用服務器規范，適用范圍較窄），所以 java 的全局性價值僅僅是第二條。
GNU/Linux
通常所說的 Linux 應該是包括 GNU 的（Linux 內核補上了 GNU 計劃的短板），不過我們這里簡稱為 Linux，它使得各種 UNIX 的差異逐漸退出市場，在服務端領域，程序員只要開發兼容它的代碼即可。
各種 linux 發布版也會有差異，但是這些差異已經不是難以克服的了。
</blockquote>這個變化的好處是，不同的服務端開發團隊可以比較容易的交流，本團隊培養的工程師理解其它團隊的線上環境也簡單了很多。
此時，Linux 的價值是體現在上述全局價值的第三條。
接著，Linux/GNU 進一步發展，甚至在一部分程序員群體中開始成為主要工作平臺，對于開發、測試、運維三環節開始有了一體化支持的征兆，這樣讓 Linux 的價值又擴展到了上述的第二條全局價值。
然而這個價值要打折扣——
- 各種服務端技術雖然都使用 Linux 作為基準的 OS，但是運維和管理方法還是有很多差異，導致有時橫向協作還是會有影響。
- 使用 Linux 作為開發平臺的程序員還是比較有限，而且有一部分工程師并沒有掌握這個平臺，用 Linux 做桌面并沒有改善對測試和線上環境的熟悉程度，因此各環節的溝通成本依然較高。
</ul>因此總的來說，Linux 占據了全局價值的后兩條，但有不足。
docker
說到這里，其實已經不必再對 Docker 浪費過多的筆墨，它算是秉承了 Linux 的靈魂。同時，它的標準化為多應用協作提供了方便，多應用背后是多團隊，這就在實質上是為團隊間合作建立了方便之門，因此，它先天就占據了全局價值的后兩條，并且比 Linux 做的還要好。
與此同時，Docker 提升了個人的能力覆蓋范圍，由于線上和開發環境有可能一致，因此工程師可以用較低的代價實現 devops，這一點對應了全局價值的第一條。
因此我們的結論是，Docker 的價值不是在于某個點上的突破，它改變的是人與人之間的協作方式，這包括：
- 個人：Docker 提高了個體戰斗力，使個人有可能結合云技術實現以前需要多人完成的工作，消除部分協作。
- 縱向：Docker 對軟件研發三環節建立了協作基礎，通過標準化，環節之間的扯皮被降低，節省了溝通成本，提升了溝通效率。
- 橫向：由于 Docker 對各種技術棧提供了統一的管控方式，降低了團隊間協作成本。
</ul>綜上，最后再重復一下我的結論——
Docker 研發的價值超過 java，起碼達到 Linux 的水平
</blockquote>來自: www.jianshu.com本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！