在軟體開發過程中的各種不同活動有：
1、定義問題
2、需求分析
3、規劃構建
4、軟體架構
5、詳細設計
6、編碼與高度
7、單元測試
8、整合測試
9、整合
10、系統測試
11、保障與維護
常見的軟體隱喻可以分為以下幾種：
1、寫**就像寫信，讀**就像讀**。這種隱喻具有一定的侷限性
2、建立軟體類似播種和耕作。（比喻不夠恰當，比寫信好點，但是沒能體現出過程）
3、培育軟體，增量開發，一天增加一點。就像養育動物一樣。以增量方式進行設計、編譯和除錯。通過外在的增加或吸收而逐漸生成或變大。（比較恰當的隱喻）
在進行增量開發時，我們先做出軟體系統的乙個盡可能簡單、但能執行的版本。它不必接受真實的輸入，也無須對資料進行真正處理，更不用產生真實的輸出。它需要的僅僅是乙個足夠強壯的骨架，支撐起未來將要開發的真實系統。對於你標誌出的每一項功能，可能僅需要呼叫虛假的類。這個最基本的起點，就像牡蠣開始孕育的那顆細小珍珠。建造軟體就像造房子，盡可能地把房子設計好，就能省去後期的好多麻煩。知道有哪些現成的東西，如容器類，科學計算函式，資料庫訪問元件等。哪些東西需要定製，以讓自己的房子更高階。
前期準備
在實現乙個系統之前，需要理解「這個系統應該做什麼」以及「它該如何做到這些」，以下幾點可以幫助更好的理清系統：
1、訴諸邏輯
在開始做乙個大專案之前，應該為這個專案制訂計畫。
2、訴諸模擬
如果你正為某個高度迭代的專案做計畫，那麼在開始構建之前，你需要針對要構造的每一片段，先弄清楚哪些是最關鍵的需要和架構要素。（迭代開發法：這種方法的「計畫、需求、架構」活動與「構建、系統測試、質量保證」活動交織在一起）
3、訴諸資料
發現錯誤的時間要盡可能接近引入該錯誤的時間。缺陷在軟體食物鏈裡面呆的時間越長，它對食物鏈的后級造成損害越嚴重。
一條很有用的經驗規則：計畫好預先先對約80%的需求做出詳細說明，並給「稍後再進行詳細說明的額外需求」分配一定的時間。然後在專案進行過程中，實施系統化的變更控制措施——只接受那些最有價值的新需求。另一種替代方案是：預先只對最重要的20%的需求做出詳細說明，並且計畫以小幅增量開發軟體的剩餘部分，隨著專案的進行，對額外的需求和設計做出詳細說明。
問題和需求的先決條件
對系統要解決的問題做出清楚的陳述。問題定義應該用客戶的語言來書寫，而且應該從客戶角度來描述問題。通常不應該用計算機的專業術語敘述。
需求詳細描述系統應該做什麼，這是達成解決方案第一步。充分詳盡地描述需求，是專案成功的關鍵，它甚至很可能比有效的構建技術更重要。
在構建期處理變更
1、確保每個人都知道需求變更的代價。如客戶想到乙個新功能就要新增時，可以從「成本」和「進度」上勸說。如：咦，這聽起來是乙個不錯的主意。不過由於它不是需求文件裡的內容，我會整理乙份修訂過的進度表和成本估計表，這樣你可以決定是現在實施還是過一陣子再說。
2、建立一套變更控制程式。如果有一套變更控制程式，那麼你只需要在特定時候處理變更，而客戶知道你打算處理他們的提議。
3、使用能適應變更的開發方法。演進交付是一種分析階段交付系統的方法。你可以建造一小塊。從使用者獲得一點反饋，調整一點設計，做少量改動，再多建造一小塊。關鍵在於縮短開發周期，以便更快地響應使用者的需求。
4、注意專案的商業案例。有些需求作為功能特色來看是不錯的想法，但是當你評估「增加的商業價值」時就會覺得它是個糟透了的主意。
第十一天 回歸之前所學重點
確認網路擁有阻止策略 systemctl stop disabled firewalld 確認遠端服務正常開啟 systemctl start restart status 服務名稱sshd 補充 nat模式實現其他使用者訪問虛擬主機 埠 埠對映 修改ip位址 埠 僅主機模式 優勢，系統安全性極高，...
從頭構建Linux系統 之 前沿
早在1998年，我就開始了學習和理解linux之旅，現在已逾十年。當時我第一次安裝了linux並且立即迷上了其背後的概念和哲學思想。我曾經使用過很多不同的發行版，但是最後都放棄了。按照它們的方式，它們都是偉大的系統。這裡沒有對或者錯，它逐漸變成了個人的喜好。當有多種選擇的時候，漸漸你會發現不是單一的...
檢視某個分割槽之前所有的資料 騰訊大資料面試真題彙總
1 筆試部分 1 有一表名t sh mtt netdisk log，從表名可以看出該表是什麼業務的，是什麼週期粒度的表。2 怎麼檢視表結構，表建立語句？怎麼檢視表有哪些分割槽？怎麼檢視分割槽對應hdfs路徑？怎麼計算某個分割槽的資料量大小？怎麼計算某個分割槽的檔案總數？3 有一hive sql，怎麼...