Part 1
雖然是作業，但是我也准備好好地評估一下自己的能力，看看自己到底有多菜雞，好給自己一個響亮的耳光來督促后面的自我學習！所以我就好好地給自己評估下（參照第二次作業的內容）：
| PSP2.1 Content | Chinese/中文 | 我的技能需求 | 耗時 |
|---|---|---|---|
| Plan-Estimate | 計划-任務時間 | 幕布-思維導圖 | 2 |
| Devolopment-Analysis | 開發-分析需求 | 博客園作業指導 Github_Readme.md | 2 |
| Devolopment-Spec | 開發- 設計文檔 | 簡書 | 2.5 |
| Devolopment-Review | 開發-設計復審 | ||
| Devolopment-Standard | 開發-代碼規范 | Qemu調試 | 1.5 |
| Devolopment-Design | 開發-具體設計 | 閱讀老師示例代碼 | 0.5 |
| Devolopment-Coding | 開發-具體編碼 | Mac_sublime C編碼 | 5 |
| Devolopment-Code Review | 開發-代碼復審 | gcc代碼（語法）調試結合Github實時更新 | 1 |
| Devolopment-Test | 開發-測試 | Ubuntu下Qemu測試 | 3 |
| Record Time Spent | 記錄用時 | ||
| Test Report | 測試報告 | 簡書，博客園博客作業總結 | 1.5 |
| Size Measurement | 計算工作量 | PSP評估 | 0.5 |
| Postmortem | 事后總結 | 簡書 | 1 |
| Process Improvement Plan | 提出過程改進計划 |
從上面的不合理的時間分配可以看出來，我真的還只是一個寫程序的而不是寫軟件的，那些很基本的流程里面我缺了很多，基本上是想到什么就寫什么。 用GitHub也不是為了團隊合作，只是為了版本控制和方便多台電腦之間切換工作環境。
結合上面的一些自我認知，以及《構建之法》的PSP體系介紹，我有如下的一些關於工作需要的能力的認知：
| 技能 | 需求 | 學習路徑 |
|---|---|---|
| 精修的編程語言 | C/C++、Python、Java、Javascript、PHP、Ruby、Shell、C#等任選 | C/C++、Python |
| 標准庫的學習 | 很多輪子已經做好了，我們學會用就好了，公司需要對常用標准庫和一些新型的框架要多認識 | C/C++11標准庫，Python Flask等框架 |
| 調試 | 能夠用常用的IDE進行單步測試，代碼Debug等調試任務 | Xcode單步測試、《C++ Primer》 |
| Debug | 能找出錯誤進行修正 | 暫未定計划 |
| 科學上網 | 很多代碼的錯誤最開始都是在國外出現解決辦法，所以要能溝通世界 | Shadowsocks、SSH反隧道流量、VPN |
| 畫UML圖 | 能夠把需求變成圖形，促進更好的溝通 | 幕布-思維導圖、流程圖-Visio |
下面是基礎能力，與技能不同，這些是永不過時的！！
| 基礎能力 | 推薦學習路徑 |
|---|---|
| 軟件工程的認識 | 《構建之法》《編程之美》 |
| 算法數據結構 | 牛客網、Letcode、算法導論 |
| 效率 | 知識管理、效率軟件--印象筆記+幕布 |
| 編程能力 | 一萬小時定律 |
| 搬輪子能力 | Github、碼雲、Stack Overflow |
| 造輪子能力 | 由於情景是初入職，暫不考慮 |
| 硬件認識、計算機組成 | 這些是不可避免的，要想做高端的程序員，你連你最好的合作伙伴都認識不徹底，怎么可能？ |
- 在構建之法的第三章中有說到考級之路，我在大二大三分別將計算機等級考試全部考完（下圖中是我的四級成績）。
- 另外也已經注冊了中國計算機學會的學生會員，准備參加近期的CCF能力認證（學生會員會費50，330的報名費可以減到180，想要報考的強推買會員），我的導師給我的任務是280分，有點虛，但是聽前輩說不是很困難。我盡力而為。
- 前陣子也想去參加中級軟件設計師的資格認證，但是因為那個時候還要考研，所以就停下了腳步。后來保研了已經錯過了報名時間。我准備看看大四下能否參加，好取得更多的能力認證！
Part 2
瀑布模型（Waterfall）
優點：
-
1. 強調開發的階段性，各階段具有順序性和依賴性 ，各個Part分模塊，格子封裝，暴露接口，然后耦合在一起組成一個整體
-
2. 強調早期調研和需求分析，推遲編碼實現的觀點，在《構建之法》第二章的PSP對比大學生和軟件工程師的時候。可以發現，實際的操作中更注重於前期准備和后期的完善，對於編碼，不僅僅是由於豐富的資源庫，也是因為有了幾年的工作經驗可以迅速的編碼。所以現實中使用模型比較多。不論是模型帶動工程師，還是工程師推動模型發展，兩者之間的聯系都是固定的!
-
3. 提供了一個摸板，這個摸板使得分析、設計、編碼、測試和支持的方法可以 在該摸板下有一個共同的指導。相同的模板下，方便后來的工程師閱讀前輩寫下來的模塊。另外也方便任務的交接，同時還可以更方便的借用網絡上開源的庫，這些都是模型化設計模型的優點。
缺點：
-
1. 文檔驅動，用戶無法及時了解產品的情況。因為很多程序員甚至不知道自己寫的代碼的全部部分，API接口的使用使得更多的源代碼對於程序員不可見了！所以經過程序員的手，到達用戶手中之后就更別說了。很多時候出了問題基本就沒法找到具體的“事發”地址。對於后期的維護十分麻煩。這是犧牲了底層構建，實現迅速開發的代價。
-
2. 依賴早期調研和需求分析，很難適應在許多項目開始階段必然存在的不確定
性。 因為畢竟是模型開發，很多時候為了追求速度會采用一些現成的代碼。這樣必然存在兼容性問題。而且具體的功能需要對應的模塊實現。比較依賴於初期的調研，不然后期修改很麻煩。 -
3. 流程單一，必須要完成前一階段的任務，才能進行下一階段，開發過程中的 成功經驗無法用於本產品。 瀑布模型這兒特點很僵硬，無法實現並行開發。
-
4. 測試在后期引入，對於系統存在的重大缺陷，如果在可執行程序評審之前沒有被發現，將可能造成重大損失。 求取速度所必須付出的代價！！
總結來說，基於模型的設計真的是一種對勞動力的巨大解放，讓我們可以站在巨人的肩膀上安心的搬運輪子來建造自己的寶馬，比如說，代碼自動生成，文檔自動化圖形化設計這些，都能夠給工程師，設計人員帶來巨大的便利。但是，這種情況下如果沒有Bug那還好說，但是一旦有了Bug並且沒被發現，那就一定是深層次的Bug，這樣的一個設計，在推廣開來后所要付出的代價與前期開發代價之和，要遠遠的大於一步步開發自身的設計的方法，但是從頭開始添磚加這種事情也只有大公司背得起，互聯網公司如果不能迅速的開發出想要的功能，拿不到風投，那就可能夭折，所以說，基於模型的設計利弊皆有，但是目前從實際情況來看，還是利大於弊的。
另，附《構建之法讀書筆記》如下：
正文之前
首先，說句實話：真的寫得好，讓我情不自禁就給我的學長推薦了，讀完緒論我就有預感，我會放下我手頭讀的如痴如醉的《C++ Primer》，轉而把這本構建之法讀完我再回頭讀，因為作為一個跨院保研到計算機的人，我目前最不缺的是時間和技巧的學習。但是我極度的缺乏一種思想的錘煉，我現在是披着機械人的皮，走到了機械的十字路口，一年后准備拐彎到計算機去！所以我還有這足夠的時間去培養我自己的思想，讓我成為一名合格的程序員，而非是“碼農”！
正文
不得不說鄒欣老師這本書非常合我的胃口，所以一上手，就再也停不下來了。首先在第一版前言中給的那四個形象，我覺得就非常的有意思，直接把《構建之法》這本書與一般的編程手冊什么的區別開來了。另外致謝部分，我看到了浙江大學計算機學院的陳越老師，這是我非常喜歡的一個MOOC上的老師，她的數據結構真的是讓我受益匪淺。倒數第二段：“最后要感謝我的家人，他們容忍我一個人在廚房里對着電腦長時間發呆，有時還給我煮綠豆湯喝”。 這句話瞬間將老師從一個高高在上的作者拉近到了我們生活中的層面來。讀這本書，就沒有那種被填鴨式教育的感覺，反而是仿佛與老師一起在黑暗的夜里，敲着字，聽着歌，享受着別人煮給自己的綠豆湯，那是多么的一種幸福呀！
然后當看到老師對當代教育體系中的師生關系有如此深的研究的時候，我感覺非常的慶幸，也帶點遺憾！慶幸的是：終究還是有很多人是在乎學生與老師之間的關系，把寓教於樂這種崇高的理念貫徹到了生活中，遺憾的是並不能在老師手下學習，反而是在老師口中說的那種傳統的，刻板的教學方式中度過了我的大學三年。不過其實我覺得老師描述的學生與老師的關系就好比是健身學員與健身教練之間的關系，這一點，還是要有一點補充：我們學生必須要取得一定的學分，獲得一定的成績，然后才能畢業。但是由於你在健身學員這個關系中是處於消費者模式，也即是上帝模式，所以說你是完全可以不理會教練不去上課的，雖然最后你獲得的只是一個生了巨多累贅的身心，但是沒有人會追究你的責任，而教育體制不一樣！你如果畢不了業，那么你就獲得不了任何的肯定了。當然，如果健身房這種地方還有畢業證書這一說，那當我沒說
我十分同意，老師在書中說的給授課老師和助教的建議。另外我發現我們《實時控制軟件設計》這一門課，老師或多或少的遵守着鄒歡老師說的這一套規定。比如說簡明公開的規則，課堂打分制度，以及很有可能會掛的危險，另外還有各種成績的加權計算，或多或少都有着這本構建之法中推薦的方法的影子。另外也有循序漸進激勵和不斷總結階段性成果等先進優秀的理念。首先 個人博客Github賬號，這兩點我們課堂老師貫徹的非常徹底。還有就是，對於打醬油的同學絕不姑息，這一點我覺得做的非常的好。“這門課不水”，這是我在陳志平同學的博客的評論里面看到的。我覺得用來總結這門課是最好的啦。期待我們后面也會按照更多的鄒歡老師推薦的教學制度來。還有我很喜歡老師總結的這一句：**我們學生所需要的環境，是一個自然的、有批判精神的、學習的環境。還有就是在第13頁中：“有些系領導會說沒有資金支持助教，這是無能的借口，非不能也，是不為也”。我覺得這句話，諷刺中帶點幽默，相當有趣。
Chapter 1
要點如下表所示：
- 程序=算法+數據結構
- 軟件=程序+軟件工程.
- 軟件企業=軟件+商業模式
畫張圖就清晰多了：
具體來說是讓我認識到了以下幾個概念：源代碼管理，配置管理，質量保證，軟件測試，需求分析。程序理解，軟件維護，服務運營，合稱為軟件的生命周期。另外"將軟件與程序分隔開來的就是用戶體驗 " 這個理念，直接將我們平時寫的代碼無情的歸類到程序，心累。
軟件系統是把系統的、有序的、可量化的方法應用到軟件的開發、運營和維護的過程。包括：需求分析、設計、構建、測試和維護這幾個過程。
軟件一般具有下面幾個特性：
-
復雜性（所以錢多話少，因為沒時間、特別忙）
-
不可見性（對於大多數人來說計算機部分硬軟件）
-
易變形（每個bug都是一頓大餐）
-
服從性（成就感的來源）
-
非連續性（。。。）
在軟件開發的四個不同階段：玩具階段，業余愛好階段，探索階段，成熟的產業階段。我現在大概處於玩具階段到業余愛好階段之間更偏向於業余愛好階段。希望可以盡早的度過業余愛好階段，進入探索階段，成熟產業階段，那肯定是工作以后的事了。
另外由於我明年就要去計算機學院博士生，而且走的領域大概就是計算機體系結構/雲計算/網絡安全這三個里面選一個(體系結構可能性比較大)，我這才知道原來體系結構是偏向於實踐的領域，我之前一直以為計算機體系結構是要構建計算機的底層，抽象於硬件，但是低於或等同層於操作系統。想不到居然是偏實踐的領域啊！！！對於計算機科學與軟件工程，我一直以來都是用研究與應用兩個觀點來區分，現在看來倒是與老師的觀點不謀而合。
第一遍讀老師的書並沒有太深太大的感觸，所以只能通過練習來加深印象。迫於時間所限，我寫了第一題。至於博客什么的早就有了。版本控制軟件，我一直以來都只知道GitHub。貌似還有GitLab吧。還有第六題的Dijkstra這個人，他不是圖的廣度優先算法里面的締造者嗎？他這個名字當年考研的時候深惡痛絕的抄了幾遍才記下來！
//第一題，用於給小朋友隨機發放四則運算的題目（vector是之前的，不管不管）
#include <iostream>
#include <string>
#include<vector>
#include <ctime>
#include <stdlib.h>
using namespace std;
void Cal(int a,int b,int c)
{
switch (c)
{
case 0:
cout<<a<<" +"<<" "<<b<<" ="<<" ";
cout<<a+b<<endl;break;
case 1:
cout<<a<<" -"<<" "<<b<<" ="<<" ";
cout<<a-b<<endl;break;
case 2:
cout<<a<<" X"<<" "<<b<<" ="<<" ";
cout<<a*b<<endl;break;
case 3:
cout<<a<<" /"<<" "<<b<<" ="<<" ";
cout<<a/b<<"···"<<a%b<<endl;break;
}
}
int main()
{
srand((unsigned short)time(0));
int num=10;
while(num--)
{
int a=rand()%50+1;
int b=rand()%20+1;
int c=rand()%4;
Cal(a,b,c);
int delay=10000;
while(delay--)
{
}
}
return 0;
}
Chapter 2
第二章的內容，大部分我都能看懂，但是連在一起之后就是似懂非懂。大概是因為我沒有真正的負責過一個軟件的設計與開發以及維護吧！畢竟我是一個大部分時間都在寫程序而不是軟件的人哪！！而且我的本命語言是C++/C以及Python。對於接近硬件底層的C#不是很了解。而且對於用集成工具平台，我也沒經驗。大多數時候都是用編輯器編寫之后，再用gcc或者是mingw來編譯。不過在2.2后半段提到的效能分析工具，這個我大概有了一點想法，說不定可以自己寫一個！但是時間比較緊迫，所以這先不寫了。我應該只能寫一個代碼注入的效能分析。其實很簡單嘛，在每一個大括號后面加一個對全局變量的自增操作。那么就可以直接用全局變量來統計這個函數調用的次數。另外，在2.3個人開發流程中了解到的那個PSP概念，讓我有了一個對軟件開發的整體流程的觀念，一定程度上彌補了我先天不足的缺點。這個部分我后面還會繼續再看。另外，對於大學生和軟件工程師兩個群體的調查，我發現確實工程師在需求分析以及測試兩方面明顯要花更多的時間。至於原因，那是顯而易見的：軟件工程師不只是玩玩而已，他們要對用戶負責，而大部分的大學生都是自娛自樂，屬於自high型。而且大學生代碼編輯能力普遍不夠，所以說更多的時間都會花在代碼編寫上的。
第二章，實踐部分，我也就寫個題目來鞏固一下吧。
// wc.exe 只能統計行數，單詞數目，字符數目
#include <iostream>
#include <string>
#include<vector>
#include <ctime>
#include <stdlib.h>
using namespace std;
int main()
{
string s;
getline(cin,s);
int word;
int line=1;
int alpha;
for (int i = 0; s[i]!='\0'; ++i)
{
char &c=s[i];
if (isalnum(c))
++alpha;
if (c==';' || c=='\n')
++line;
if (isalnum(c)&&(!isalnum(s[i+1])))
++word;
}
cout<<"一共有 "<<line<<" 行，有 "<<word<<" 個單詞，有 "<<alpha<<" 個有效字符"<<endl;
return 0;
}
另外在2.4.1里面我也有了幾個算法的想法。
-
首先輸出一個整數數組中子數組最大的值。
- 1、 這個的話直接使用一個對數組的循環遍歷，遇到負數就跳過不管
- 2、 遇到正數就直接加到一個累加器中
- 3、 最后輸出就可以了。
-
字符串操作。
- 4、 我們可以用字符串類型來定義一個接受這個字符串字面值。
- 5、 保守的辦法是直接用下標配合字符串類型的求字符串長度內置函數size()，循環遍歷從string[s.size()-i-1開始輸出]
- 6、 另外一個稍微冒險一點辦法，因為沒有實現所以不敢說對不對：那就是用迭代器。從尾指針開始一路往回讀，不知道能不能實現。當然，如果用指針直接指向s[s.size()-1]然后用指針的自減操作讀到begin()的話那確實可以！
正文之后
讀書完畢，關電腦，睡覺~~ 咦 先把作業交了！！