這裡的軟體，可以是個小程式、小工具，可以是個框架、元件，也可以是個系統。

1 軟體的理想

對很多開發人員來說，需求是個比較籠統、模糊的概念。如果不在開發運維的過程中，多揣摩多思考，那麼需求這個東西就會變的越來越陌生，甚至覺得不那麼重要，不那麼相關！

那麼到底需求是什麼？

我說——需求，是軟體的理想！“做人如果沒有理想，跟鹹魚有什麼區別！”同樣，軟體也應該有軟體的理想，沒有理想的軟體連鹹魚都不如，會成為一坨si，一坨開發人員“煩”，運維人員“怕”，使用者“罵”的一坨si！

2 客戶需求是衡量軟體的最低標準

既然，談到了理想，那麼什麼樣的理想？誰關心這些理想？

有圖可見，軟體系統的利益攸關方為： 開發人員、運維人員、客戶；軟體不單單是客戶的軟體，還是開發人員的親兒子，運維人員的好兄弟！在軟體系統產生之前，每一方對其都應該是有期待、有幻想的，這些期望和幻想便是軟體的理想，就是需求！

某次年會上，一位銷售舉杯向研發敬酒，說，“我們的工作是向客戶撒謊，而你們的工作就是讓謊言成為現實！”這時，搞運維的小夥伴們搖著頭，一臉憂傷。賣掉軟體，只不過是萬里長征的第一步，部署，更新，升級，故障修復，問題分析，效能評估，等等等等，路還遠著呢！

為什麼要提devops，就是因為很多人懈怠了、麻木了，以為滿足客戶需求就萬事大吉了！

要知道，需求 ≠ 客戶需求！客戶需求是衡量一個軟體的最低標準！

軟體的理想，應該是客戶滿意，運維放心，開發喜愛，大家好才是真的好！

3 做一名高尚的開發人員

開發人員是個集合概念，由一個個的程式設計師組成。相對於軟體來說，“開發人員”這個集體並沒有想象中那麼穩定，今天A走了，明天B來了，那麼就要進行“知識交接”。常常是，軟體還在賣、在不斷擴充套件、在運營，可開發軟體的程式設計師卻是換了一茬又一茬。另外 A 開發了 X 模組，有了bug，可能需要 D 來分析排查，那麼 D 就要理解 X 的邏輯和機制，這裡也涉及到“知識交接”。後續，可能又 C 負責系統的重構，那麼 C 就要對系統的前世今生有個徹徹底底的認識！

A 希望搞“敏捷”，去文件化，什麼設計文件、架構圖、介面模型的，統統簡化，手裡拿著一份客戶需求，不管三七二十一，就是幹！什麼單元測試，老子的程式碼不用測！什麼，想了解細節，統統去看程式碼！“我死之後，管他媽的洪水滔天！”這是很多程式設計師的心裡寫照，因此命名不講究，風格不統一，註釋很敷衍，文件殘缺不全，設計時毫無原則 。。。。

B、C、D 統統懵逼，齊聲說——我們的軟體應該是有理想的！我們應該做一名高尚的開發人員！有理想、有追求、有節操，為偉大的共產主義事業，奮鬥不息!

易理解很重要！

在開發過程中，程式設計師應該多向開源軟體看齊，開源軟體有很多好的原則、習慣、正規化，尤其是在易理解性上。當我們在閱讀和學習開源軟體時，我們對它有什麼期望呢？希望有詳細的文件，比如，設計文件，介面文件，模型文件，最好哪位大神再寫點《xxx原始碼分析》的文章，設計文件最好深入淺出，圖形並茂，最好有範例，等等等等。使用或學習某些元件、框架後，常常會說，xxx好重啊，難懂，沒資料啊，太難用等等。所有這些期望或評價，都關乎軟體的可理解性！

子曰：己所不欲，勿施於人。在軟體開發時，同時應該做到“己所欲，施於人”。

        1 缺陷處理時的開發人員；
        2 接手後續開發任務的開發人員；
        3 學習軟體系統的新員工；
        4 自己；

如果，前期為了趕進度，特別忽視軟體在可理解上的重要意義，那麼後期任務交接、缺陷處理和功能擴充套件的時候，必將付出血的代價。

易擴充套件是一個循序漸進的過程，可能還要與重構相結合，是不斷髮現設計或結構上的問題，不斷優化的過程。就像網站的結構一樣，從單伺服器，到業務儲存分離，再到分散式，是在需求的驅動下，慢慢完善。易測試，也是軟體開發中至關重要的一面。

4 運維人員的憂傷

毫不誇張的說，運維幾乎佔了軟體整個生命週期的全部，相較之下，開發不過是“十月懷胎”。一個軟體，會是長命百歲，還是少小夭折，運維期很重要！

部署、配置、更新、升級，統計、評估、業務跟蹤、問題定位！如果在開發時，沒有站在運維的角度去思考、去設計，那麼這樣的軟體對運維人員來說將是災難。這裡的運維人員，不單單是一線的技術，還包括後臺的研發，研發將會被無窮無盡的bug搞的懷疑人生！

在運維人員眼中，怎樣的軟體才算好軟體呢？

易管理：部署方便，配置靈活，最好能提供多種模式，有“一鍵式”的傻瓜模式，也有高階模式，用起來很有成就感的那種！快速恢復的能力，當出現故障的時候，能及時恢復！

易度量：有時跟現場技術交流時，常常聽到，“慢”、“卡頓”，等等定性的，主觀的詞彙，為什麼呢？就是因為軟體自身是不可度量的。是io瓶頸，還是cpu瓶頸，負載到底多大？介面使用率，資源佔用率，這些資訊必須是軟體自省的。只有這樣才能提高運維的效率。

比如，二八定律，系統介面，無論是對外介面還是內部介面，肯定有些是頻繁被呼叫的，有些甚至從來都沒被用過，那麼介面使用率就很重要，對後續優化，介面重構，都很有意義！

易分析，其實運維過程中，大部分的工作就是分析，包括系統診斷，問題檢測，日誌系統，業務跟蹤系統，效能評估系統，資源統計系統。這些模組都不是必須的，但是有的話就會非常利於運維！

5 客戶不懂軟體

客戶： 可用性，可靠性（穩定，安全，好用不貴），易用性

可用性，就是滿足客戶的功能性需求，解決客戶的現實問題！是對軟體開發人員最樸素、最坦誠的要求，恰如“女的，活的”這般的相親需求。

可靠性，要求軟體穩定、健壯，安全，正確，不要太嬌貴了，有點壓力就down；也不要太馬虎了，時不時就給點錯誤資料；更不能太隨便了，門戶大開，對非法入侵毫無抵抗力！

易用性，是個相對高階的需求了，是種主觀的、體驗式的、卻又極其重要的衡量標準。為什麼大家更喜歡用支付寶，而不是各大銀行的app客戶端？

總結

本文主要是作為一個引子，來更接地氣的說明什麼是需求，有那些重要的需求。關於如何去完成這些需求，是一件非常複雜，困難的事情，網路上有很多資料，資源，用來說明如何實現擴充套件性？如何實現可維護性？易用性等等。只有結合自己的工作經驗，與有針對性的思考，才能把網上的技術分享變成自己的知識財富！

接下來，我也會結合自己的理解逐個去總結。

本文借鑑博主為墨城之左的部落格文章。