軟件開發究竟是怎麼一回事呢？

人生得一良友不易，友人是作數據庫DBA（運維方向）出生，對軟件開發算是沒有什麼經驗，可是最近手頭卻有點兒事讓它對軟件這件事開始有了興趣。因而就問我這個問題。我呢，水平不好，這麼大的標題丟過來，怎麼回答呢？好在友人給明確了方向：

代碼管理，版本控制，補丁管理，架構設計，模塊劃分，接口設計，報錯編碼制定，日誌設計，測試方法，安全管控，性能規劃

而後我就根據這些，做答以下，既然寫了這麼多，就拿出來和你們分享。

一、代碼管理，版本控制，補丁管理
對於單一產品的公司，其實問題就是各類迭代和這些迭代的管理。
首先是坐下來討論一下影響咱們代碼變化的因素是什麼？需求、bug，計劃內、計劃外？
傳統的軟件管理，一般會把需求分紅不少期，而後針對每一期制定版本計劃，而後按着計劃作。
可是現代軟件偏向于敏捷的管理方式，用用戶故事將需求分解成不一樣的場景，進行故事管理，而後經過迭代的方式向前，而後及時修正項目的總體目標。
回到代碼管理，我有個原則，就是你無論是需求仍是用戶故事，在你打開你的電腦開始寫的時候，就要明確你在爲何功能而coding，而後你每一次提交版本必須和你的代碼庫，task（一種集成在項目管理工具裏面的任務，你也能夠理解爲excel裏面的一行需求）一一對應。好比你今天就是作了一個接口，接口只完成一個功能，好比修改密碼。那就寫清楚你在作什麼，而後和你的需求哪些相關。簡單地說，就是每一次提交是一個原子提交。而後提交的時候，至少須要保證你的代碼是能夠編譯經過的。
版本控制呢，一般須要考慮到分支的管理和標籤的管理。其實我有一個保證它安全的好辦法，那就是不用版本控制工具。它們不如複製粘貼/壓縮包來的可靠。若是你肯定一個分支要發佈，首先你須要用版本工具進行分支發佈，而後針對分支的補丁就在上面繼續，而後適時往主分支合併。可是於此同時，請作一件事，將它們下載下來，把它壓縮起來，而後放到一個文件服務器上。而後一旦出現問題，找個文本比較工具，你一般就豁然開朗了。
補丁管理這件事，剛剛也提到過了，你真對哪一個版本出的問題，就在哪一個分支上面去改，而後適時合併，適時固然是你在差別沒那麼大的時候作是最好的。
這裏插一句題外話，敏捷的核心我我的認爲不是在怎麼說清楚用戶故事，而是你要有單元測試，沒有這個都是扯淡……固然其它也很重要，可是UnitTest是必要級別的。這也就是外包軟件行業一般作不到敏捷的一個重要緣由，由於不是那麼容易作到。

 

二、架構設計
架構設計這可不是那麼牛逼的一兩句能說明白的事情，不過有幾個我的認爲仍是比較重要的原則。
a、適度設計，其實拿捏這個度，何其難，在一我的開始看待一個問題的時候，天然就有本身的觀點在裏面，你的視角必定不是世界的中心，那麼合理拆分就能夠了，本着實用主義的精神作架構設計，一般能在成本、智力等方面都能取得一個還不錯的平衡。
b、合理，其實面向對象編程最牛逼的地方就是讓一段代碼試圖去模擬一件事的自己，這就像數據庫設計裏面的關係表同樣，它必定要表達的是正確的關係，那麼哪怕它性能上有缺陷。這些其實和什麼代碼可讀性等都是相通的。這就是爲何大部分人都認爲多線程程序會比較難，由於它一般不是人類思惟。這樣的合理設計一般從數據庫的設計上面就開始影響你整個複雜度了。這一條一般隨着架構師見識和對問題的理解程度不一樣，在項目進展的不一樣時期會有不一樣的體會，一開始合理的東西，在項目後期可能就不是那麼回事了。
上面說的都是廢話，由於不具有操做性，就是在你要作決定的時候去回想一下才有幫助。那麼有什麼規律可循呢？
其實一般咱們都是習慣帶着問題去解決它們的，好比你的性能要求很高，你要求達到一個特定的SLA，那麼你在開始選擇技術和框架的時候就要在這些方面都比較當心，而後用你熟悉而不是你似懂非懂的技術來解決，這樣就算出問題，你至少能知道怎麼去思考這個問題，而不會去懷疑那個東西不靠譜。而後就是包括全部影響這些的點，既然說的是性能問題，那麼數據庫、索引等都是須要考慮的，還有一些能夠從業務上分開的，也能夠從業務上解決，好比明明一個頁面用戶只想看到一個數值，可是你老是在頁面上帶一個大列表，而大列表恰好又查詢了一個大表，那麼這個頁面一定有問題。

 

三、模塊劃分
模塊劃分其實就是你把你的功能合理分拆的過程，你能把大家家的主臥、次臥、廚房衛生間拆分開，你能搞清楚爲何電商分類裏面不會把電風扇放到數碼產品裏面，就說明你掌握了模塊劃分的基本規則。這些都是縱向劃分，按照領域進行細分。
我以爲你這裏是否是想要知道的還包括分層管理，軟件是個上下疊加的層次結構，其實從你下面跑的硬件到操做系統這一層級一般被作好了，而後就是作好你的軟件的部分，因此接觸你的操做系統的一般是軟件公司給的各類框架，好比.net framework和java虛擬機等，而後就是那些架構框架，什麼asp.net、servlet等，這些都不涉及到你的業務，一般是解決了技術層面的問題，而後你如今看到的成熟的解決方案一般都從界面開始（也許是個接口，總歸和外界有個交互），而後從這一層中向下，到剛剛那層底層框架之間就須要你本身來分了。看看你是否是須要訪問數據了，好比數據庫，無論是sql仍是nosql，總歸須要去聯一下了，這裏可能是考覈你層間接口的設計能力，而後你想象你設計的接口就像插座上面的標準插口同樣，上層再也不關心下層的實現細節，若是下層有問題，讓下層去改好了。而後一層一層往上剝離，就到了你剛剛想要作的對外的那個界面了（也許是接口）。什麼三層架構什麼的，也只是對這些的一個大體歸類。
不過按你的思路，也許你的腦子裏是個VisualStudio裏面的Solution的Panel，你想知道的是一個大的解決方案中各類程序集（dll/lib）的分類方式，那麼你回到你最熟悉的Windows/linux下面好了，負責網絡的就是網絡驅動，管它怎麼實現的，我反正負責網絡的，你找我就能夠了。而後負責IO的，就負責IO就行了。程序集的劃分差很少也就是這樣的，以SSO舉例，加解密咱們會有單獨的模塊，而後作具體業務邏輯的也會有，而後一些輔助的小代碼（好比查一下ip地址啊什麼的），大概也就是這樣一點點分出去。

 

四、接口設計
上面的不少思路其實在接口設計中都是相通的，其實就是職責分明，一個接口儘可能完成一個原子操做，不要完成不少件事，除非你把它看成一件事來作。這個粒度的把握也須要思考清楚。好比修改密碼的接口，你就不要再加入重置密碼的邏輯，哪怕你背後的代碼巴不得調用同一套，也須要暴露兩個接口。接口之因此被設計出來，就說明它是相對穩定的，任何對接口的修改，都是一次玩命，原則，約定的功能是不能夠減小的，哪怕是不合理的，這個纔是接口最難的地方。就像你發佈了電燈底座接口，而後全世界都在爲你生產電燈，而後你說不行，圓的你不喜歡你喜歡方的，我改了哈，而後，你懂得，上街不要被人打。那麼接口的設計就很是須要合理，哪怕你留下一個沒有用的參數，內部你壓根不用，你寫死均可以，可是必定要合理，只有這樣，將來使用這套接口的標準程序纔不會受到影響。而後單元測試的思想就很重要了，接口永遠要保證以前測試的場景在每次升級後還能正常被跑過，不然你的接口隨時有可能產生漣漪反應。
五、報錯編碼制定，日誌設計
萬物歸本，這件事就是你肯定一個列表，而後把它吐出來的過程，Windows那麼多彈錯，無非也是一堆編碼，出了問題到kb裏面一搜就出來各類編碼了。至於這個規則是按相似手機號或郵編的編碼方式仍是按照條形碼的方案來，這個仁者見仁場景也不同，哪怕你毫無規律地來編，它們都只是起到了一個Id的做用。
這裏可能須要提到的一點，這個編碼和日誌設計一般都在一塊兒，其實在你程序須要記錄的時候，哪怕你以爲它八百年纔會發生一次，你也要須要給人一個合法的編碼和完美的解釋，那麼你就不至於當系統彈出「有錯」的時候，你一看有十幾處同樣的錯誤。我傾向於錯誤始終惟一的方式。
在現代軟件編程中，能夠藉助AOP的思路來將它們收集起來，這個思路和程序橫向切片差很少，它在代碼上的體現一般是，你的代碼明明只是作了業務邏輯，可是它自動會幫忙記錄日誌，並且能告訴你究竟是哪一個程序第幾行在什麼地方幹了什麼。固然這個也是有代價的，就像你在水龍頭上安裝了過濾器，那麼水流天然要小一點。
如今有nosql了，海量存儲變的更方便了，而後分析這件事藉助離線計算的方式，總歸是能算出來的，可是記得，必定要把信息儘量多地記錄下來。

 

六、測試方法
傳統的測試固然很是重要，什麼冒煙測試、用戶驗收測試、迴歸測試、集成測試等都很是重要。
這裏要提到的更多的是自動化測試，雖然我在項目中很難用到這一點，可是它的思想我很是認同，由於它是用代碼來測試代碼，代碼是什麼，是你經驗的積累，你找個妹子上去點一遍，點的過程就是經驗，你讓妹子點20遍也許妹子能朝你踹一腳，可是代碼一旦完成，只會愈來愈趨近精確。如今軟件工程上面對相似界面點擊這些都已經有了成形的工具，可是說實話國內軟件業掌握的還不怎麼樣。固然也由於有不少不完善。
經過持續的反覆測試，說白了無論是人仍是機器，更多的經驗和體力投入都能得到更好的效果。

 

七、安全管控
安全管控，如今安全組作的那些事情，包括用安全工具來掃描、找紅帽組織來，其實都是基於行業經驗來作到監理的角色。固然軟件開發，本質仍是一個智慧的事情，好比你家蓋房子，你知道安裝了窗戶，須要有鎖，並且鎖必須在房子裏面，不能在外面，低樓層須要安裝防盜窗，防盜窗必須比一個正常的人要窄，這些都是經驗。有不少現成的經驗，須要在程序員開始幹活以前就要掌握，其實不該該假設程序員什麼都懂，其實他們很萌的。我剛開始寫web的時候，那個時候沒有往安全方面去想，由於以前一直作的是windows界面，不一樣窗口之間無所謂安全的事情，可是作web的時候，真的作了那種除了登陸頁面以外的頁面也能夠不要登陸，敲個地址就能進去的low事兒，後來本身發現了，才從web的原理着手去了解了這樣的問題，可是這個事情，終歸是個意識和見識問題。大部分不幹壞事的人不知道怎麼幹壞事，因此你們仍是須要多學習。
而後就是一個好的基礎框架，開發規範，不少公司程序員並不太瞭解這些，可是它們也不出軌，好比單點登陸就幫他們解決了這個問題，由於架構上要求一個用戶至少是登陸的。
這裏特別要提到接口，一般不少人作完接口就無論安全了，由於它很差測，也看不見嘛，可是這一塊一般須要被重視。不過像什麼WebService的標準裏面都有一整套安全規範，固然除了大公司用以外，你們可能掌握的也很少。

 

八、性能規劃
性能，是個數學問題嗎？你先知道一共有多少的性能壓力，你把小軲轆的輪子放在卡車下面天然是承受不了的。如今比之前好多了分佈式計算讓性能從單一計算機性能瓶頸上分解出來，可是分佈式。。。。一般適用於能夠分佈式的事情。。。
其實在咱們常見的場景中，無非是web性能和數據庫性能，web性能如今你們都是用負載均衡來分開的，其實，不少時候傻逼的程序員乾的蠢事須要服務器cpu來買單的事情也很多見。性能出問題，大多出現的問題，好比耗時的程序在工做，好比網絡慢了，進行IO操做了，訪問數據庫了，跨邊界的操做一般容易致使性能問題。好比訪問內存的速度一般和訪問數據庫都不是一個量級的。那麼在一個for循環裏面訪問數據庫就是一個比較不合適的作法。那麼一次性讀取後再for也許能幫到你，固然也不是全部的場景都如此。還有就是良好的算法功底，好比一個循環的算法複雜度是O(n)，而一個哈希表的算法複雜度是O(1)，一般你們都不須要本身去寫這些，可是選擇合適的數據結構來處理問題，變得很重要。
至於你說你的服務器應該買多牛逼的，那我就不知道了，壓力測出來以後，看着買能買得起的最貴的，而後調程序去吧。