1、閱讀
剛開始泛看《建構之法》的時候，還是覺得非常難了解裡面的内容，特别是代碼部分。後來第二次拿起這本書，從第一章開始看起，慢慢了解了“軟體企業=軟體+商業模式”和對軟體工程的定義，但是更多地還是記憶了一遍，沒有明白這裡面的深意；看第二章的時候，跟着單元測試、回歸測試的、效能分析的内容自己照着書上的代碼敲了一敲，偶爾會出現bug，但是能得到書上所說的效果還是很開心的，效能分析，感覺就是代碼的效率問題，追求高效，然後接觸到了軟體工程師的一套模型—個人開發流程PSP，我也嘗試建立自己的GitHub來管理自己的源代碼。第三章就感覺在看故事了：一個軟體工程師的成長，積累問題相關領域知識和經驗、提升技能；了解通用軟體設計思想和軟體工程思想；提升職業技能；實際成果。剩下的暫時還沒看。
2、數獨
數獨介紹：（摘自百度百科）
數獨是源自18世紀瑞士的一種數學遊戲。是一種運用紙、筆進行演算的邏輯遊戲。玩家需要根據9×9盤面上的已知數字，推理出所有剩餘空格的數字，并滿足每一行、每一列、每一個粗線宮（3*3）内的數字均含1-9，不重複。
數獨盤面是個九宮，每一宮又分為九個小格。在這八十一格中給出一定的已知數字和解題條件，利用邏輯和推理，在其他的空格上填入1-9的數字。使1-9每個數字在每一行、每一列和每一宮中都隻出現一次，是以又稱“九宮格”。
解題曆程：
數獨？什麼是數獨？好的，開始百度。玩家需要根據9×9盤面上的已知數字，推理出所有剩餘空格的數字，并滿足每一行、每一列、每一個粗線宮（3*3）内的數字均含1-9，不重複，這是不是類似于以前做的找規律的數學題？然後慢慢懂了後，代碼又不懂，繼續百度，看到網上很多大神寫的部落格有關于數獨的解法，摒棄法，用整形一維數組來表示數獨的狀态，用Num（80）表示數獨的狀态（數組的下标從0開始），數獨是一個二維表格，而數組是一維數組，自己也嘗試着用這個方法去求解數獨，但是過程中遇到了自己很多不懂的概念和算法，越做心裡的狀态越糟糕，到最後自己放棄了。然後又開始用回溯法，在百度看了很多大神的回溯法解數獨，自己也開始有了思路。
工具清單：
- 程式設計語言： C++
- 程式設計IDE：Visual Studio 2015
- 效能分析工具：Visual Studio Profiling Tools
- 源代碼管理平台：Github
代碼部分：
-
#include <iostream>
#include <algorithm>
using namespace std;
int map[9][9];
bool isPlace(int count){
int row = count / 9;
int col = count % 9;
int j;
for(j = 0; j < 9; ++j){
if(map[row][j] == map[row][col] && j != col){
return false;
}
}
if(map[j][col] == map[row][col] && j != row){
}
int tempRow = row / 3 * 3;
int tempCol = col / 3 * 3;
for(j = tempRow; j < tempRow + 3;++j){
for(int k = tempCol; k < tempCol + 3; ++k){
if(map[j][k] == map[row][col] && j != row && k != col){
return false;
}
return true;
}
void backtrace(int count){
if(count == 81){
cout<<"結果："<<endl;
for(int i = 0; i < 9; ++i){
for(int j = 0; j < 9; ++j){
cout<<map[i][j]<<" ";
cout<<endl;
return;
if(map[row][col] == 0){
for(int i = 1; i <= 9; ++i){
map[row][col] = i;
if(isPlace(count)){
backtrace(count+1);
map[row][col] = 0;
}else{
backtrace(count+1);
int main()
{
for(int i = 0; i < 9; ++i){
for(int j = 0; j < 9; ++j){
cin>>map[i][j];
backtrace(0);
return 0;
}
測試資料：
8 0 0 0 0 0 0 0 1
9 0 0 0 2 0 0 0 3
0 3 0 0 5 0 0 7 0
0 0 5 0 0 0 4 0 0
0 0 4 5 0 9 6 0 0
0 0 0 8 0 1 0 0 0
0 0 0 0 0 0 0 0 0
0 4 6 0 0 0 8 2 0
0 2 0 3 0 5 0 9 0
測試結果：
PSP2.1：
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 10 | 30 |
| · Estimate | · 估計這個任務需要多少時間 | 500 | 800 |
| Development | 開發 | 100 | 200 |
| · Analysis | · 需求分析 (包括學習新技術) | 50 | |
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計複審 (和同僚稽核設計文檔) | 70 | |
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | 20 | |
| · Design | · 具體設計 | ||
| · Coding | · 具體編碼 | 400 | 600 |
| · Code Review | · 代碼複審 | 40 | 60 |
| · Test | · 測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | ||
| · Test Report | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | ||
| 合計 | 總計 | 1470 | 2140 |
執行力的了解：
執行力，我認為是内心精神要求自己行動的一種力量，每一件事情都有每個人不同的見解，同時這個見解也伴随着一定的執行力，你喜歡某件事情可能你的内心驅使就比較大，執行力就比較強，就想盡快地、高效地把某件事情做完，如果不喜歡某件事情，内心驅使就比較小，執行力就比較差，對于這件事情則是能拖就拖，能不做就不做。
泛泛而談的了解：
做事情應付了事，做表面功夫，沒有真正地去經曆經驗，解決實際問題，而隻關心一些表面上的事情如何能夠應付好，做的事情也沒有什麼深度，很多事情的意義都在于體驗那個過程，增長自己的經曆經驗我們不能夠應付了事。