目錄
1. 什麼是最後一公里
2. 不得不說的「敏捷」
3. 效率！= 時間短
4. 測試隨時隨刻
5. 關於測試環境
6. 理想的測試
7. 「最後一公里」的根源
８. 如何避免」最後一公里「
9. 總結
1. 什麼是最後一公里
初次接觸最後一公里這個概念，應該是在大學的計算機網路課程中。
「最後一公里」指從通訊服務提供商的機房交換機到使用者計算機等終端裝置之間的連線。而「最後一公里」問題其實也就是指由於每個使用者的位置，裝置等的不同而造成的佈線困難問題。
接下來，讓我們把這個「最後一公里」的概念延伸開去：最後一公里指的是一件事情已經進行到最後，但是還欠缺一件事，而這件事還是非常關鍵的。
在軟體世界裡，這個「最後一公里」問題指的就是滿足了功能需求，尚未投入實際執行並創造業務價值的階段。
2. 不得不說的「敏捷」
「敏捷開發」這個詞不知道從什麼時候開始被無數次地提上檯面。這個概念本身是沒問題的，當然，他的意圖是好的，思想也是好的。
錯只錯在太多人把「敏捷」的概念定位在了單獨的快上，拿到需求不去架構設計，把資料庫搭好，大家開始寫頁面。發生了需求變更，填個if，再改，加個區域性標記變數，補上乙個else if，我想這是很多公司都很常見的情況吧。
然後，leader們美名其曰「敏捷」。然後，很多「小兵」也就跟風著說，我們公司是敏捷開發。
在我看來，敏捷有很多實施手段，但最後的目標有兩點：
a. 效率 b. 迭代。
注意，我這裡說的是效率，而不是時間，那是因為敏捷解決的問題是節省從專案需求確定到最終版本的時間，而不是到beta版，或者「垃圾」版本的時間。
關於迭代，敏捷中有這樣乙個概念，叫「擁抱變化」，在我看來，變化是能夠保證敏捷軟體完善的驅動，變化驅動迭代，架構師，開發者不去假想變化，而是由實際的變化去迭代，去完善軟體，而我看來，這個才是敏捷真正的核心。
那好，接下來，我們就從這兩個角度來談「最後一公里問題」。
3. 效率！= 時間短
小學生都會了解這樣乙個公式：效率=質量 / 時間。在軟體世界，讓我們繼續來完善這個公式：
效率=最終版本的質量/∑時間，也就是說最終版本的質量除以整個該專案所花費的時間。對於專案如此，對於**也是如此。
在這裡，我還是無法免俗地反覆談測試的重要性。
4. 測試隨時隨刻
在軟體開發中，最早流行的應該是瀑布模型，然後逐漸地被螺旋模型取代，螺旋模型的核心在於：a. 每個階段的風險評估 b. 一層一層迭代。在每個螺旋生命週期中，最後一步都是測試！
其實在我看來，這個模型還是不夠完善的，測試應該是無處不在的。在我眼中，乙個理想的狀況應該是每個開發人員身旁都能配備著乙個測試人員，測試人員需要對每個公開的方法進行測試，對每乙個模組進行測試，這些不是在介面上點來點去，而是要編寫詳細的測試用例，對輸入和輸出都進行詳細的控制。
接下來，是對功能性需求的測試，這個主要是針對需求文件編寫測試用例，對模組或系統進行測試。這個是軟體公司大多數測試都在做的事情。
接下來，還有很重要的一點就是效能測試以及一些附加功能，如許可權的測試等等。
也許從眼前來看，這樣的進度效率上是慢了，但是從整個專案的進度來說，這樣來做會讓我們交付的每個版本都是乙個可靠的版本，換句話說，「增加了開發成本，減小了維護成本」。
對於某些由使用者來代作測試的做法，個人更認為是極其可笑的！這正如某個程式設計師寫了一段效率極低的**，當code-review時，他說，這是cpu太差，換個好的硬體，加記憶體，加cpu，就好了。都是非常不負責任的做法。
也許這個時候會有人說，大到微軟，小到豆瓣還搞兩個beta版呢，可是這裡不得不說一句，兄弟，你又錯了，他們發布beta版不是為了讓你點出哪個按鈕出錯誤，而是為了蒐集使用者的需求，更好地完善功能而已，改進！=改bug。
5. 關於測試環境
什麼是測試環境？我的定義是可以基本模擬真實生產環境的供開發，測試人員使用的虛擬的，不對外公開的環境。
在這裡我突出兩個要點：a. 基本模擬真實環境 b. 虛擬的環境
a否定了把本機作為測試環境。b否定了把真實環境作為測試環境。
本機的作用用於保證**的基本邏輯無誤，但是想用本機的簡單測試來作為發布的測試環境，是非常可怕的。首先，本機連線的資料庫與真實的環境一般來說都是有較大差距的，其次，本機的配置與伺服器的配置差距是很大的，用本機做出的測試的響應時間幾乎是沒有任何參考價值的。最後，很多的真實環境是本機無法模擬出來的。
對於產品公司來說，一台測試伺服器，對於網際網路公司來說，乙個測試站點的重要性都是不言而喻的。也許有些朋友認為我在說廢話，可是我們看看身邊，沒有去投入去做的公司，我想大大存在。
6. 理想的測試
在roy的文章中，提到了要把測試指令碼，安裝指令碼，配置檔案也作為產品交付的一部分。
從理論上說，我認同這樣的觀點，迭代不僅僅是對**的迭代，同樣應該包含對這些測試指令碼的迭代。
可是考慮中國大多數公司的現狀，這一點，只能停留在理論階段。
7. 「最後一公里」的根源
乙個人白手起家開公司，做了乙個軟體，功能很少，加上這個人的人手很緊，時間很急，專案做的很垃圾，但是因為功能很少，所以還看不出來，也涉及不到什麼維護的成本。軟體的銷量不錯。
但是逐漸的，這個軟體龐大了起來，這個人一想，唉，在這個基礎上加功能吧，這樣比較容易，好吧，功能還是很少，沒有問題。
這個專案越做越大，終於有一天，原來的專案已經被修得慘不忍睹了，維護成本也大得驚人了，不得不對產品進行重構了。可是這個時候，專案已經太大了，重構的成本也太大了。
這就是存在「最後一公里」問題的軟體的根源！
一句話總結，「得過且過」成全了「最後一公里」。
８. 如何避免」最後一公里「
在這裡，我只談符合中國國情的軟體行業，其實不只是軟體行業，根源在什麼？等級觀念！
我不願承認，卻不得不承認，我們都在乙個等級觀念很強的社會裡，你是老大，好吧，你說的都是對的，錯的也是對的。你說重構沒用，那就沒用；你說技術沒用，那就沒用；你說可維護性沒用，那就沒用。
我們都是小兵，我們又能做什麼呢？
在這裡解決問題的不是技術，而是乙個在企業中都會考慮的問題：牽制力！
在我眼中，cto存在的價值是什麼，明明都有ceo了，ceo是不擅長技術的，他關注的是結果，他關注的是這個產品能不能賺錢。而cto是關注技術的，這個時候不至於讓這個企業完全地朝著一條，不可持續發展的路線去發展。這就是cto對ceo的牽制力。
同樣，乙個團隊應該至少是有兩個leader的，乙個是注重技術的，乙個是注重業務的，兩人等級相同，互相牽制。這樣不至於讓整個團隊沉迷於技術的海洋中，也不至於讓整個團隊忽略技術的重要性。
關注業務的leader會知道，我們要用多少時間去做這個東西，要做什麼樣才合適。他關注的是端對端的軟體交付。
而關注技術的leader會知道，我們這樣去做會對今後產生什麼樣的影響，哪段**的變化是頻繁的，這段**我們需要重構，這個技術是過時的，我們需要用新技術去重構**。
兩個人的牽制會讓團隊達到最好的平衡點。
當然，這個只是下下策，最好的情況是廢除「等級制度」，至少在技術上廢除（待遇上廢除暫時在中國的大部分企業看來不太可能）如果可以的話。
9. 總結
寫到最後一節，回去看之前所有的文字，其實發覺都是廢話，這些道理都淺顯得很。
測試的重要性，如何建立乙個好的團隊，這都是「軟體工程」這門課的基礎理論。
可是，讀了這篇文章的各位leader們，你們還記得這些最基本的理論麼？
你的團隊還是乙個健康的發展的團隊麼？
當**出現bug時，當專案延期再延期時，當你的軟體整天被客戶追著罵時，當你責罵你手下那群無用的程式設計師時，不妨先捫心自問，這些基本的道理，你都做到了麼？
那麼，你還該做些什麼呢？
關於最後一公里
最後一公里 last kilometer 在英美也常被稱為last mile 最後一英里 最後一公里 原意指完成長途跋涉的最後一段里程，被引申為完成一件事情的時候最後的而且是關鍵性的步驟 通常還說明此步驟充滿困難 通訊行業經常使用 最後一公里 來指代從通訊服務提供商的機房交換機到使用者計算機等終端裝...
Scrum最後一公里
研發部門試點敏捷，前面的過程基本都比較正常，使用者故事，計畫會議 短迭代 站立會議 回顧會 功能驗收，基本都能正常完成，但是把產品發布出去，給生產部門使用後，總是得不到及時的反饋，總是等到系統正是開始使用後，才發現這樣問題 那樣不好用 之前推動生產部門的下的作業人員，希望他們能積極配合 及時反饋看看...
全棧最後一公里
centos的軟體安裝工具是yum 開啟終端鏈結伺服器 ssh root 39.108.162.237 檢視儲存空間 fdisk l 檢視記憶體 df h 修改埠 sudo vi etc ssh sshd config 修改儲存 wq 修改後重啟才有效果 sudo service ssh resta...