1853年，美國加利福尼亞州發現金礦，人們從世界各地涌向這里，一時形成淘金熱。一位做紡織品生意的猶太青年商人列維·司特斯（Levi strauss）靈機一動，將滯銷帆布制成幾百條褲子到淘金工地推銷，意想不到大受歡迎。這就是全世界最受歡迎的牛仔褲品牌Levis。
去挖金礦的人是否都找到了金子我不知道，但Levi因為牛仔褲大賺了一筆是事實，不然也就沒有現在Levis品牌了。
經常有人問我到底是做什么的，我說是軟件工程，然后的對話就是：那我有個APP你能幫我開發嗎？后面的對話就是各種不同頻率的無法共振~~~。后來我就開始用這個“牛仔褲”的故事來解釋，總算是可以少費點口舌了。說軟件工程買賣仔褲的，還真是挺准確的，這是wiki上對Engineering這個詞的定義：
Engineering is the application of mathematics, empirical evidence and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, and processes.
https://en.wikipedia.org/wiki/Engineering
軟件工程（Software Engineering）解決的是如何做好軟件開發（Software Development）的問題，使用來自於科學，經濟學，社會學以及日常中總結的各種方法，經驗來幫助軟件開發團隊做好軟件。說得好玄乎~~~實話實說，我也是今天才仔細琢磨了一下這個定義，翻譯過來好高大上。不過話說回來，琢磨一下自己干的事兒，這些玩意還真都用得上。
好吧，我們先來看看到底什么是軟件開發。
軟件開發的本質
軟件開發不就是把軟件做出來么？這有什么可解釋的？那我們比較一下同樣是把一件東西做出來，軟件開發和制造一輛汽車的過程有什么不同么？
最大的不同就是汽車下線以后是不能再回爐的，而軟件是要經過多次回爐才能出廠的。沒有哪個4S店允許你把車子送回廠家換個椅子啥的吧？可是你手機上的APP可是隔三差五在更新，每次更新可都是在“廠子”里從新過了一遍生產線的結果。如果你注意一下你用的app的版本，就算是你拿到的第一個版本，版本號也絕不是1.0；這意味着這個APP已經回爐了不知道多少遍了。
一個汽車工廠里面積最大的部分應該就是生產線了，在這個生產線上要完成所有零件的組裝。如果按照這個思路去看軟件開發，那么所謂的生產線就是“編譯打包”或者說“持續集成”過程。你一定要問，為啥不是寫代碼的過程？因為在代碼寫出來之前，軟件都處於設計過程，“零件”還沒成型啊！你想想，上了生產線的汽車零件還允許工人現場打磨一下，修改一下尺寸嗎？如果是這樣，這個車你敢買嗎？但軟件的生產過程中的大部分時間，以及基本上所有參與者（包括寫代碼的程序員）都在進行設計工作，都是設計師，而不是工人，真正完成裝配過程的“工人”是編譯器，CI系統等已經高度自動化的程序。
這就是為什么管理程序員不能像管理工人一樣，因為你需要他們去創造，而不是拿着做好的東西進行裝配。同時，軟件開發的本質也就決定了用管理工廠的思路來管理軟件開發是行不通的，這也就是為什么用“瀑布”模式來管理開發過程會很別扭。
那么如何做好軟件開發？那就是本文的重點，你需要一條怎樣的牛仔褲？
軟件工程的本質
先講一個關於電廠的故事，這個故事來自於
http://mindwind.me/blog/2015/02/09/%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E7%9A%84%E6%A0%B8%E5%BF%83.html#rd
記得有個給我們上培訓課的主講老師是個須發皆白的老先生，進門后掏出一堆零件放在講台上， 一盞酒精燈、一個小水壺、一個葉片、一個銅光閃閃的小電機、一盞小燈泡。 老先生往壺里倒了些水，點燃酒精燈，不一會兒水開了，從壺嘴里噴出了蒸汽，帶動葉片旋轉，然后小燈泡就亮了。
他說：這就是電廠。
他還說：如果燒的是煤炭，這就是燃煤電廠；如果燒的天然氣，這就是燃氣電廠；
如果獲得熱能的方式是核裂變，這就是核電廠；如果帶動葉片的能量來自水從高處流向低處，這就是水電廠。
老先生說：你們或許會問 “那我們看到的電廠怎么這么復雜”，答案其實很簡單， 電力項目需要復雜系統的目的，一是為了確保安全（Safety），二是為了提高效率（Efficiency）。
安全和效率就是工程技術的本質，在軟件工程中，我們對“安全”的理解會更加寬泛，可以換做“質量”。
既然開發過程的大部分處於“設計”階段，那么也就意味着在上生產線進行裝配（編譯打包）之前，軟件一直處於不確定狀態，因此傳統的確定需求，完成設計，確保100%按照設計執行的思路是行不通的。我們必須找到適合軟件開發的工程技術，這才出現了敏捷開發，極限編程，Scrum，Kanban等等；這些方法的本質都是要構建一個高度自適應的系統，以便適應這個不確定狀態，所以軟件開發中的效率問題的解決不是傳統的標准化流程的思路，而是不停變化的思路，乍聽上去會覺得一個不停變化的系統怎么會效率高呢？當然，最高效的系統一定是步調一致，統一執行的。軟件開發系統其實也是這樣，只是這個系統從一個高效狀態到另外一個高效狀態的轉換是非常快的，可以說是在隨時變化的。
解決了效率問題，我們來看看質量。什么是質量？我們再來講一個故事：
一位老者去理發店剪頭發，第一次去的時候理發店的店員非常熱情，端茶送水，幫老者洗頭，剪發，吹干，然后畢恭畢敬的送老者出門，收了30元的費用。老者很滿意，過了1個月又去了這家理發店，這次店員沒有迎來送往，只是剪了頭發，也收了30元費用。老者雖然心里不高興，但是頭發是剪了，也算是OK了。又過了1個月，老者又去理發，這次店員再次笑臉相迎，全套服務，老者很高興地走了。再過了1個月，老者又去，這次老者對着店員提了一個問題：我這30元到底買到的是什么服務？
我們再來舉個例子：全世界質量最好的汽車是豐田汽車，但你知道為啥是豐田汽車嗎？那是因為如果你買了一輛質保3年10萬公里的豐田汽車，在第4年/11萬公里的時候它出現問題的幾率比其他廠商的品牌要高！對你沒聽錯，要高！
結合這2個例子，你應該會理解質量到底是什么了？雖然作為消費者，你會覺得這個豐田車質量定義有點無法接受，但是高質量永遠不是在造萬年船，永遠是在一定范圍內定義的標准，而高質量就意味着偏差小。
軟件開發中，制定標准並持續的檢查偏差就是保證質量的思路，這里面有很多方法，如：持續集成，測試驅動開發，編碼規范，完成規范，流程規范；甚至包括自動化部署，雲計算環境的使用等都和質量相關。但是要提高質量，則在標准和檢查的基礎上還需要“持續改進”。有人問，測試那里去了，測試不是提高質量的方法嗎？其實測試只解決了“檢查偏差”的問題，要提高質量，以上3個要素缺一不可。
還有一些如微服務架構，SOA，可測試性，可部署性的軟件架構思路也都和效率和質量相關。
—
一直想寫一篇關於軟件工程的文章，可惜總是沒有提筆。昨天看了博客園的另外一位朋友的文章，覺得還是應該寫一寫，就算是一點感悟分享給大家。
這位朋友的文章鏈接在這里，推薦給大家
http://mindwind.me/blog/2015/02/09/%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E7%9A%84%E6%A0%B8%E5%BF%83.html#rd
請關注微信公眾號 devopshub，獲取更多關於DevOps研發運維一體化的信息
