標籤: 銷售文案

多線程實例——遍歷文件夾分割文件識別文件內容

需求：遍歷文件夾下的所有pdf文件，對每個pdf文件根據二維碼進行分割，再對分割后的文件的內容進行識別。

可以拆分為以下幾個關鍵方法：

1.GetFileList方法：遍歷文件，獲取源文件動態數組（這裏假設3個文件夾，每個文件夾下有3個文件，則源文件個數為9），耗時忽略不計

 1 static List<string> GetFileList(string strFilefolder)
 2         {
 3             List<string> list_file = new List<string>();
 4 
 5             for (int i = 0; i <= 2; i++)
 6             {
 7                 for (int j = 0; j <= 2; j++)
 8                     list_file.Add("File" + i + j);
 9             }
10 
11             return list_file;
12         }

View Code

2.SplitProcess方法：分割原始pdf文件，識別二維碼（假設耗時500ms），將一個pdf文件分割為N（這裏假設個數為6）個子文件

 1 static void SplitProcess(string sourcefile)
 2         {
 3             Console.WriteLine("SplitFile Start:" + sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));            
 4             for (int i = 0; i <= 5; i++)
 5             {
 6                 //模擬分割單個文件的過程，花費500ms
 7                 Thread.Sleep(500);
 8                 string split_file = sourcefile + i;
 9                 Console.WriteLine("file ready:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
10                 RecognizeProcess(split_file);
11             }
12             Console.WriteLine("SplitFile Completed:" + sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));            
13         }

View Code

3.RecognizeProcess方法：識別子文件的內容：加載識別庫，設置識別參數，截取識別區域圖像，圖像處理（如縮放，降噪，灰度轉換等），識別（假設耗時5000ms）

1 static void RecognizeProcess(string split_file)
2         {
3             //模擬識別的過程，花費5000ms
4             Thread.Sleep(5000);
5             Console.WriteLine("ocrFile Completed:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
6         }

View Code

單線程處理：

 1 static void Main(string[] args)
 2         {
 3             Console.WriteLine("Enter Main" + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
 4             string strFilefolder = "";
 5             OcrProcess(strFilefolder);
 6             Console.WriteLine("Main Completed" + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
 7             Console.ReadKey();
 8         }
 9 
10         static void OcrProcess(string strFilefolder)
11         {            
12             List<string> list_sourcefile = GetFileList(strFilefolder);
13             list_sourcefile.ForEach((sourcefile) =>
14             {
15                 Console.WriteLine(sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
16                 //這裏對文件進行分割
17                 SplitProcess(sourcefile);
18             });            
19         }

View Code

這個單線程處理的執行結果我們可以預估一下，應該大於 9 * 6 * （0.5 + 5） = 297 秒。

實際結果：

……

開始時間 2020-06-17 15:22:28 6104 結束時間 2020-06-17 15:27:26 1541

由於是線性處理，整個過程耗費的時間約5分鐘，所以必須要進行優化，所以考慮用多線程來提高效率。

優化方向：

1.多線程，使用Task并行對源文件進行分割

 1 static void OcrProcess(string strFilefolder)
 2         {
 3             List<Task> tasks = new List<Task>();  
 4             List<string> list_sourcefile = GetFileList(strFilefolder);
 5             list_sourcefile.ForEach((sourcefile) =>
 6             {
 7                 Task task = Task.Factory.StartNew( () =>
 8                 { 
 9                     Console.WriteLine(sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
10                     //這裏對文件進行分割
11                     SplitProcess(sourcefile);
12                 });
13                 tasks.Add(task);                
14             });
15             Task.WaitAll(tasks.ToArray());
16         }

View Code

……

開始時間 2020-06-17 15:51:54 5458 結束時間 2020-06-17 15:52:35 3144

整個過程耗費的時間約41秒，優化效果明顯。

2.每分割出來一個文件，開啟子線程，進行識別

 1 static void SplitProcess(string sourcefile)
 2         {
 3             List<Task> tasks = new List<Task>();
 4             Console.WriteLine("SplitFile Start:" + sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));            
 5             for (int i = 0; i <= 5; i++)
 6             {
 7                 //模擬分割單個文件的過程，花費500ms
 8                 Thread.Sleep(500);
 9                 string split_file = sourcefile + i;
10                 Console.WriteLine("file ready:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
11                 Task task = Task.Factory.StartNew(() =>
12                 {
13                     RecognizeProcess(split_file);
14                 });
15                 tasks.Add(task);
16             }
17             Task.WaitAll(tasks.ToArray());
18             Console.WriteLine("SplitFile Completed:" + sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));            
19         }

View Code

……

開始時間 2020-06-17 15:58:59 2591 結束時間 2020-06-17 15:59:28 9051

整個過程耗費的時間約29秒，運行時間進一步縮短。

然而，最後再思考一下，如果把多線程發揮到極致，理想狀態應該是多少秒執行完畢？

以源文件sourcefile=File00為例，

第一個分割子文件split_file=File000，ReadyTime 500ms，Ocr Completed Time 應該為5500ms

第二個分割子文件split_file=File001，ReadyTime 1000ms，Ocr Completed Time 應該為6000ms

第三個分割子文件split_file=File002，ReadyTime 1500ms，Ocr Completed Time 應該為6500ms

第四個分割子文件split_file=File003，ReadyTime 2000ms，Ocr Completed Time 應該為7000ms

第五個分割子文件split_file=File004，ReadyTime 2500ms，Ocr Completed Time 應該為7500ms

第六個分割子文件split_file=File005，ReadyTime 3000ms，Ocr Completed Time 應該為8000ms

File00 Split Completed！

每一個源文件（sourcefile）被逐個分割為6個拆分子文件（split_file）並識別完成，都需要8000ms時間，如果使用線程同步的話，那麼後續源文件也同步被分割並識別完成。

所以，理想情況下，應該是8秒，而與29秒差距太大了，應該還有優化空間！

3.怎麼優化？向什麼方向優化？我們不妨不用Task，回歸到Thread本身來試試。

可是Thread運行時沒有Task.WaitAll()這樣的控制方法，因此，我們還要引入WaitHandle和ManualResetEvent來進行多線程管理。

 1 class Program
 2     {
 3         static void Main(string[] args)
 4         {
 5             Console.WriteLine("Enter Main" + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
 6             string strFilefolder = "";
 7             OcrProcess(strFilefolder);
 8             Console.WriteLine("Main Completed" + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
 9             Console.ReadKey();
10         }        
11 
12         static void OcrProcess(string strFilefolder)
13         {            
14             List<ManualResetEvent> split_waits = new List<ManualResetEvent>();
15             List<string> list_sourcefile = GetFileList(strFilefolder);
16             list_sourcefile.ForEach((sourcefile) =>
17             {
18                 Thread m_thread = new Thread(() =>
19                 {
20                     ManualResetEvent mre = new ManualResetEvent(false);
21                     split_waits.Add(mre);
22                     Console.WriteLine(sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
23                     //這裏對文件進行分割
24                     SplitProcess(sourcefile);
25                     mre.Set();
26                 });
27                 m_thread.Start();
28             });
29             WaitHandle.WaitAll(split_waits.ToArray());
30         }
31 
32         static void SplitProcess(string sourcefile)
33         {
34             Console.WriteLine("SplitFile Start:" + sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
35             var ocr_waits = new List<EventWaitHandle>();
36             for (int i = 0; i <= 5; i++)
37             {
38                 //模擬分割單個文件的過程，花費500ms
39                 Thread.Sleep(500);
40                 string split_file = sourcefile + i;
41                 Console.WriteLine("file ready:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
42                 ManualResetEvent mre_child = new ManualResetEvent(false);
43                 ocr_waits.Add(mre_child);
44                 Thread m_child_thread = new Thread(() =>
45                 {
46                     Console.WriteLine("m_child_thread enter:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
47                     RecognizeProcess(split_file);                    
48                     mre_child.Set();
49                     Console.WriteLine("m_child_thread after set:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
50                 });
51                 m_child_thread.Start();
52             }
53             WaitHandle.WaitAll(ocr_waits.ToArray());
54             Console.WriteLine("SplitFile Completed:" + sourcefile + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));            
55         }
56 
57         static void RecognizeProcess(string split_file)
58         {
59             //模擬識別的過程，花費5000ms
60             Thread.Sleep(5000);
61             Console.WriteLine("ocrFile Completed:" + split_file + DateTime.Now.ToString(" yyyy-MM-dd HH:mm:ss ffff"));
62         }
63 
64         static List<string> GetFileList(string strFilefolder)
65         {
66             List<string> list_file = new List<string>();
67             for (int i = 0; i <= 2; i++)
68             {
69                 for (int j = 0; j <= 2; j++)
70                     list_file.Add("File" + i + j);
71             }
72             return list_file;
73         }
74     }

View Code

……

開始時間 2020-06-17 15:28:17 2397 結束時間 2020-06-17 16:28:27 9151

整個過程耗費的時間約10秒，運行時間與理論的8秒已經十分接近（因為Thread創建以及運行時需要切換上下文，Console.WriteLine都有一定的耗時，PC性能好的話應該更接近8秒），可以說目標已經達成。

Tips:

ManualResetEvent初始狀態為false表示不將線程信號量初始值置為signal，線程會自動往下執行，執行Set()方法時，將線程信號量置為signal。

WaitHandle.WaitAll(split_waithandle1,split_waithandle2); //一直等待，直到split_waithandle1,split_waithandle2信號量均被置為signal才會往下執行。

不足之處：

開啟Thread要受到系統的限制，所以本例線程數必須考慮操作系統線程最大值限制。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

2020-11-09

模式識別與機器學習筆記專欄之貝恭弘=叶恭弘斯分類決策（一）
目錄
- 1. 貝恭弘=叶恭弘斯公式
- 2. 最小錯誤率貝恭弘=叶恭弘斯決策
- 3. 最小風險貝恭弘=叶恭弘斯決策
這是模式識別與機器學習筆記專欄的第一篇，我會持續更新。

在所有的生活場景中，我們無時無刻不在進行着模式識別。比如你看見迎面走來一個人，根據他的長相來辨認出他好像是你一年前某個活動小組的組長，然後你開始決策要不要和他打個招呼。或者你走進水果店，把西瓜拍了個遍來決定最後買哪一個。或者你突然被捂上眼睛，聽着背後人的聲音來辨別是不是你的親愛的。

模式（pattern） 可以理解成某種特徵，也就是你可以獲取到的某種原始數據，而 模式識別（pattern recognition） 就是根據輸入原始數據來判斷其類別並採取相應行為的能力。它對我們至關重要，但我們常常希望可以有機器幫我們來做這個工作，讓機器執行預定的程序來進行分類從而決策。比如一個短信攔截系統，幫我們分辨哪些是騷擾短信，哪些是有用的信息。

在這個問題上，貝恭弘=叶恭弘斯決策理論是最最經典而基本的分類方法了。那麼，何為貝恭弘=叶恭弘斯分類決策？

1. 貝恭弘=叶恭弘斯公式

首先，我們熟悉的貝恭弘=叶恭弘斯公式

\[P(\omega_i|x)=\frac{p(x|\omega_i)P(\omega_i)}{p(x)} \]

在模式識別問題中，用 \(d\) 維向量 \(x\) 來表示希望分類對象的特徵，它一般是從傳感器獲取，並且抽象化出來。\(\omega\) 來表示可能分類的類別。\(\omega_i\) 對應着第 \(i\) 類，如果是一個兩類問題，\(i=1,2\) ，如果是 \(c\) 類問題，則 \(i=1,2,…,c\)

\(P(\omega_i|x)\) 是由特徵 \(x\) 預測的結果，也就是后驗概率，\(p(x|\omega_i)\) 是類條件概率，或者叫似然概率，就是特徵 \(x\) 這個隨機變量分佈情況，它是取決於類別 \(\omega\) 的狀態的。\(P(\omega_i)\)是類先驗信息，是根據先前知識經驗給定的，並且因為總共就c類，所以很容易得到\(\sum^{c}_{j=1}P(\omega_j)=1\)。\(p(x)\)是歸一化因子，並不重要：

\[p(x)=\sum^{c}_{j=1}p(x|\omega_j)P(\omega_j) \]

目的就是使得所有后驗概率之和為1。

貝恭弘=叶恭弘斯公式提供了一個后驗概率的重要計算依據：從似然概率和先驗概率得到。

2. 最小錯誤率貝恭弘=叶恭弘斯決策

首先簡化問題為二分類問題，比如短信分類問題，\(\omega=\omega_1\) 是將短信分為有用短信，\(\omega=\omega_2\) 是將短信分類為垃圾短信。假設我們現在對這兩類的先驗概率和特徵 \(x\) 的類條件概率分佈都知道了。那麼通過一個短信提取到的特徵 \(x\) ，就可以利用貝恭弘=叶恭弘斯公式計算后驗概率，也就是對可能的兩類做出的概率判斷。

\[P(\omega_1|x)=p(x|\omega_1)P(\omega_1)\\ P(\omega_2|x)=p(x|\omega_2)P(\omega_2) \]

很自然的來比較后驗概率來進行決策，哪一類的后驗概率大，就判定為哪一類，先驗是給定的，歸一化因子不重要，實質上比的就是類條件概率分佈。
- 現在引入一個錯誤率 \(P(error|x)\) 的概念，對一個\(x\) ，算出了 \(P(\omega_1|x)\) 和 \(P(\omega_2|x)\)，假如我們讓\(\omega=\omega_1\)，也就是判定為第一類，把這條短信判斷成有用的，那麼我們判斷正確的概率就是 \(P(\omega_1|x)\) ，而判斷錯誤的概率就是\(P(\omega_2|x)\)。寫成公式：
\[P(error|x)= \begin{cases} P(\omega_1|x)& \text{如果判定為}\omega_2 \\ P(\omega_2|x)& \text{如果判定為}\omega_1 \end{cases} \]
- 我們希望我們判斷的錯誤率更小，因此我們得到判決規則：
如果\(P(\omega_1|x)>P(\omega_2|x)\)，判定為 \(\omega_1\)；否則判定為 \(\omega_2\)

——這就是最小錯誤率貝恭弘=叶恭弘斯決策，也就是哪一類后驗概率大，判為哪一類
- 寫成似然概率和先驗概率的形式：
如果\(p(x|\omega_1)P(\omega_1)>p(x|\omega_2)P(\omega_2)\)，判定為 \(\omega_1\)；否則判定為 \(\omega_2\)

3. 最小風險貝恭弘=叶恭弘斯決策

下面把判決規則升級一下。

再回想一下短信分類的問題。假如預測成有用短信和騷擾短信的后驗概率接近的時候，這時候誤判的可能性還是比較高的。如果誤判，可能會把有用的分成垃圾，把垃圾短信分成有用的。可以想象這兩者的錯誤率是此消彼長的，但對哪種的錯誤率容忍度更高呢？把有用的分成垃圾的看起來更加難以接受。這時候可能就希望那種模稜兩可的情況還是判定成有用的好。那麼如何來體現這種對錯誤率容忍度的不同呢？下面就引入損失函數。

對每一種判斷以及真實情況定義一個損失函數\(\lambda(\alpha_i|\omega_j)\)，以下面的兩類問題為例

\(\lambda(\alpha_i\vert\omega_j)\) \(\omega_1\) \(\omega_2\)

\(\alpha_1\) 0 1

\(\alpha_2\) 2 0

\(\omega_j\) 表示要分類對象的真實類別是 \(\omega_j\) ，\(\alpha_i\) 表示要採取的行為，即判定為 \(\omega_i\)

以短信分類為例，假如真實是\(\omega_1\) ，有用短信，採取\(\alpha_1\) ，判斷為有用，也就是判斷正確了，可以定義損失就是0。假如真實是\(\omega_2\) ，垃圾短信，採取\(\alpha_1\) ，判斷為有用，也就是判斷錯誤了，可以定義損失函數為1。假如真實是\(\omega_1\) ，有用短信，採取\(\alpha_2\) ，判斷為垃圾，同樣是判斷錯誤了，而這種錯誤我們的容忍度更低，那麼可以定義損失函數為2。
- 由損失函數乘以對應的后驗概率\(P(\omega_j|x)\) 並求和，得到風險函數\(R(\alpha_i|x)\)
\[R(\alpha_1|x)=\lambda(\alpha_1|\omega_1)P(\omega_1|x) +\lambda(\alpha_1|\omega_2)P(\omega_2|x)\\ R(\alpha_2|x)=\lambda(\alpha_2|\omega_1)P(\omega_1|x) + \lambda(\alpha_2|\omega_2)P(\omega_2|x) \]

理解起來就是：\(\alpha_i\)行為的風險=每種 \(\omega\) 情況下採取\(\alpha_i\)行為的損失x是這種 \(\omega\) 的后驗概率
- 與最小錯誤率貝恭弘=叶恭弘斯決策相對應的，這時候使得風險函數最小就行了，判決規則寫成：
如果\(R(\alpha_1|x) < R(\omega_2|x)\)，採取行為\(\alpha_1\) ，也就是判定為 \(\omega_1\)；否則採取行為\(\alpha_2\) ，也就是判定為 \(\omega_2\)

因此決策的方式就是採取風險\(R(\alpha_i|x)\)最小的行為\(\alpha_i\)——這是最小風險貝恭弘=叶恭弘斯決策
- 把\(\lambda(\alpha_i|\omega_j)\) 簡寫成\(\lambda_{ij}\) ，並把類條件概率和先驗概率代入，得到判決規則：
如果\((\lambda_{11}-\lambda_{21})p(x|\omega_1)P(\omega_1) < (\lambda_{22}-\lambda_{12})p(x|\omega_2)P(\omega_2)\)，採取行為\(\alpha_1\) ，也就是判定為 \(\omega_1\)；否則採取行為\(\alpha_2\) ，也就是判定為 \(\omega_2\)
- 還可以寫成似然比的形式：
如果\(\frac{p(x|\omega_1)}{p(x|\omega_2)}<\frac{(\lambda_{22}-\lambda_{12})}{(\lambda_{11}-\lambda_{21})}\frac{P(\omega_2)}{P(\omega_1)}\) ，採取行為\(\alpha_1\) ，也就是判定為 \(\omega_1\)；否則採取行為\(\alpha_2\) ，也就是判定為 \(\omega_2\)

這樣寫的好處是，不等式右邊的損失函數和先驗概率都是給定的，是一個常數，左邊就是似然概率之比，所以只需要算出似然概率之比就可以進行分類預測
- 另外，如果採用如下0-1損失函數的時候，最小風險貝恭弘=叶恭弘斯決策就會退化成最小錯誤率貝恭弘=叶恭弘斯決策
\(\lambda(\alpha_i\vert\omega_j)\) \(\omega_1\) \(\omega_2\)

\(\alpha_1\) 0 1

\(\alpha_2\) 1 0

\[R(\alpha_1|x)=\lambda(\alpha_1|\omega_1)P(\omega_1|x)+\lambda(\alpha_1|\omega_2)P(\omega_2|x)=P(\omega_2|x)\\ R(\alpha_2|x)=\lambda(\alpha_2|\omega_1)P(\omega_1|x) + \lambda(\alpha_2|\omega_2)P(\omega_2|x)=P(\omega_1|x) \]
- 如果是多類情況
\[R(\alpha_i|x)=\sum^c_{j=1}\lambda(\alpha_i|\omega_j)P(\omega_j|x) \]

決策行為\(\alpha^*=argminR(\alpha_i|x)\) ，也就是採取的行為\(\alpha_i\) 是使得風險\(R(\alpha_i|x)\) 最小的那個\(\alpha_i\)

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※FB行銷專家,教你從零開始的技巧
2020-11-09
印度學者：中國築壩正破壞喜馬拉雅生態

摘錄自2018年8月27日中央社報導

印度新德里政策研究中心戰略研究教授切拉尼（Brahma Chellaney）表示，喜馬拉雅生態系統日漸脆弱，雖然在這一地區大規模資源濫採的國家都應受到譴責，「但沒有一個國家像中國，對喜馬拉雅造成如此嚴重的破壞」。

切拉尼撰文寫道，亞洲的未來與喜馬拉雅山的關係緊密，但人類卻大規模建設水壩且肆無忌憚地開採資源，破壞當地生態系統，其中中國透過築壩改造天然河流，卻有愈來愈多工程引水項目集中在國外，而非內部河流。以喜馬拉雅冰川地區來說，目前中國造壩已覆蓋近3/4的青藏高原。

針對中國行徑，切拉尼還指出2點，一是中國想在青藏高原乾旱的北部和西北部製造人造雨，外界擔心此舉會吸走喜馬拉雅其他地區（西藏的降雨集中地）的水分；另一是中國大肆開發礦產資源，如開發銅礦的行動已汙染藏族的Pemako（隱藏的蓮花地）地區。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

2020-11-06
德鐵挑戰氣候目標 2030年減碳50%、使用70%綠電

環境資訊中心記者陳文姿報導

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

2020-11-06
大力發展再生能源，希臘渡假勝地蒂洛斯將成地中海首座綠能島

摘錄自2018年8月21日科技新報報導

希臘小島蒂洛斯（Tilos）可說是愛琴海著名渡假勝地，擁有豐富環境生態與優美的海洋景致，而近期該島將透過裝置量達 200KW 太陽光電與 800KW 風能，進一步成為地中海首座 100% 再生能源供電的綠能島嶼。

蒂洛斯島希望能透過綠能達成電力自給自足。目前技術人員則正最終測試再生能源系統，預計將在 2018 年下旬全面上路，屆時該渡假小島將可透過裝置量達 200KW 太陽能、800KW 風力發電與儲存容量（storage capacity）為 2.4MWh 的儲能系統達到 100% 綠能供電。

該島將採用 NaNiCl2 熔鹽儲能系統，可在日照強和風大情況下儲存綠能多餘電力，並於夜間與旅遊旺季等需求量大、發電量較低時釋出電力並維持電網供電，而為提升微電網管理系統，住家與企業也會安裝智慧電錶來計算用電尖峰的時間。

歐盟執行執委會表示，蒂洛斯將成為地中海第一個電力自主的再生能源島嶼，且由於大多海島都難以跟歐洲大陸電網相連，歐盟也打算將蒂洛斯再生能源計畫應用於其他島嶼。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

※教你寫出一流的銷售文案?

2020-11-06
對馬克宏很失望法環境部長請辭「不想再騙自己」

環境資訊中心綜合外電；姜唯編譯；林大利審校

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※FB行銷專家,教你從零開始的技巧

2020-11-06
從民眾走向大公司德國能源轉型面臨十字路口

環境資訊中心記者陳文姿報導

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

2020-11-06
澳洲政壇川普化總理因支持減碳下台

環境資訊中心綜合外電；姜唯編譯；林大利審校

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

2020-11-06
加州議會通過法案 2045年前100%清潔能源

摘錄自2018年8月30日世界日報報導

加州州議會29日準備將一項畫時代的法案送交州長簽署，這項法案規定，加州在2045年前將電力供應全面變為清潔能源，不再使用煤和石油發電，100%改用太陽能、風力和其他再生能源。

由州參議會議長德利昂提出的SB100號法案，先獲州參議會通過，29日再獲州眾議會以43票對32票通過；州眾議會進行了修改，所以須再送回州參議會通過，就可以送交州長簽署。州議會今年的會期，將於本周結束，所以SB100估計可於周末前送交州長。

加州的公用事業公司包括太平洋瓦電和聖地牙哥瓦電，都反對SB100。美西各州石油協會和其他組織也反對。

布朗州長對SB100保持沉默，沒有說是否簽署，雖然他是加州反暖運動的先鋒。明年可能接替布朗做州長的紐森，曾說要以100%清潔能源作為加州的目標，但是他也沒有對SB100表態。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※FB行銷專家,教你從零開始的技巧

2020-11-06

\(\lambda(\alpha_i\vert\omega_j)\)	\(\omega_1\)	\(\omega_2\)
\(\alpha_1\)	0	1
\(\alpha_2\)	2	0

\(\lambda(\alpha_i\vert\omega_j)\)	\(\omega_1\)	\(\omega_2\)
\(\alpha_1\)	0	1
\(\alpha_2\)	1	0

如果你對自己有要求 | “回顧，再出發”——記2020軟工提問回顧與個人總結

回顧，再出發

項目	內容
這個作業屬於哪個課程	2020春季計算機學院軟件工程(羅傑任建)
這個作業的要求在哪裡	提問回顧與個人總結
我在這個課程的目標是	完成一次完整的軟件開發經歷並以博客的方式記錄開發過程的心得掌握團隊協作的技巧做出一個優秀的、持久的、具有實際意義的產品
這個作業在哪個具體方面幫助我實現目標	為自己一學期的努力畫上句號對下一個階段的展望

作業要求：

鏈接到以前提問題的博客

請嘗試對自己曾經提出的問題進行解答，並闡明，是如何通過看書，實踐，或者討論弄清楚的。

是否原來的問題還不明白？如果有，請分析。

是否產生了新的問題？如果有，請提出。

軟件工程這門學問有很多 “知識點”，這門課強調 “做中學” – 在實踐中學習知識點。

請問你們在項目的需求/設計/實現/測試/發布/維護階段（一共6 個階段）中都學到了什麼“知識點”，每個階段只要說明一個知識點即可。

結合自己在個人項目/結對編程/團隊項目的經歷，談談自己的理解或心得。

序

2020年3月3日下午16:48，在博客園發表了本學期軟件工程的第零篇博客——停下來，回頭看 ——記2020BUAA軟工第一次作業-熱身！，1萬5千字的長文收穫了1256次閱讀和6個評論，其中ScalersTalk作者Scalers專門註冊了博客園在我的評論下方留言回復2500字，令我備受鼓舞，還有鄒欣老師和寶玉老師的建議我牢記在心，mio4學長的經驗之談也對我很大啟發。懷着對所有閱讀過我的文章和評論我的文章的人的感激，踏上了軟件工程的學習道路。

2020年3月8日臨晨2點56分，發出了軟件工程這門課正式的第一篇博客——初窺構建之法——記2020BUAA軟工個人博客作業，這片博客中都是在閱讀完鄒欣老師的《構建之法》后，對書中存疑的地方提出的問題，並加入自己的思考和理解。這片博客收穫了594次閱讀9條評論，有其他學校的軟件工程老師，還有仰慕已久的SivilTaram學長在我的博客下留言。最令我沒有想到的是，負責鄒欣老師的《構建之法》和吳軍博士的《浪潮之巔》出版的周筠老師聯繫了我，加了我的微信，帶我走進了大神們的世界，周筠老師的群聊中有吳軍博士，有輪子哥，還有各行各業的優秀人士，看着他們在群里的討論愈發能夠感受到自己所學和認識的狹隘，除了自己的學習之外，還需要更多的與優秀的人的交流，在交流中增長自己的眼界。為了完成這篇博客，我將《構建之法》每一個章節都進行了閱讀，書中還有很多博客的鏈接我也大多點開來看，對於提出的問題也事先在網上做了充分的調查和搜尋，給出了自己的理解和嘗試性的解答。雖然一周的閱讀時間很短，但是這個過程真的十分漫長，看完《構建之法》感覺自己在理論上已經開始嘗試着從軟件工程的思維去思考問題。特別是對PM的章節，除了書之外還搜索了很多地方關於Program Manager和Product Manager的區別，並嘗試着將自己代入體驗。

2020年3月10日下午18:59，發布了“深度評測官”——記2020BUAA軟工軟件案例分析作業，對候選素材中最難啃的OCR識別表單的開源工作進行了測評，做第一個吃螃蟹的人，後面總結了經驗推廣開來，陸續也出現了幾篇OCR的測評，收穫了1754次閱讀，成為了後面團隊開發時的產品介紹。在這次作業中，開始體會軟件之間的差異，開發軟件需要側重什麼，什麼樣的軟件是一款優秀的軟件。

2020年03月21日，我和我的組員拼裝成了一個團隊，並給我們的團隊發布了第一篇博客——“介紹一下自己吧”——記2020BUAA軟工團隊介紹和採訪：

我們是 BUAA軟軟軟件工程小隊 ，簡稱 軟軟軟，但是大家也可以看到我們的博客的 TITLE 是 HARD_CORE_SE，指的是 “硬核的軟件工程” ，軟軟軟其實是希望我們遇到硬核的軟件工程也可以 化硬為軟，直面困難，在我們的眼裡沒有硬核二字，一切困難在團隊面前都是紙老虎！
雖然我們都沒有大型的工程經驗，是一直拼裝起來的軍隊，但是我們相信通過我們團隊的配合一定能夠在軟件工程這門課中發揮出色，不只是取得成績，而且能做出像樣的、能流傳的、實用的項目出來。

雖然當時我們還沒有選好題目，但是我們核心的目標已經確定——做出像樣的、能流傳的、實用的項目出來。

2020年4月1日，我們團隊發布了項目選擇博客——“媽媽再也不用擔心我忘交作業了！”——記2020BUAA軟工團隊項目選擇，結合本學期的疫情分析了同學們的痛點，決定開發一款幫助同學規劃提醒日程的Web應用，而我作為想出這個點子的人，對這個應用有什麼頁面，有什麼功能，能夠實現什麼最為清楚，因此成為了團隊的負責人。

2020年5月5日，修復完所有的Bug、走過不知道多少次流程，我們確定首次公開發布我們的產品——DDLKiller，一款專門面向北航本科生設計的日程提醒助手，並在朋友圈，班級微信群，QQ群等小範圍內進行推廣：

從後台統計數據來看，發布第一天註冊用戶達到77人，第二天達到148人，僅僅使用两天的時間就已經超額完成預期的100人，並且從反饋來看，同學們對這一款簡潔美觀、功能強大的日程管理助手非常滿意，並且积極給我們提供反饋意見，幫助我們在Beta階段做的更好。

第一次發布說實話是非常忐忑的，我們熬了無數個夜晚，開了無數的視頻會議，做了無數次測試的軟件，突然開放給大家，不知道大家是喜愛，還是無感，我們當天晚上守在後台，看着註冊登錄的日誌，看着註冊的人數一個一個往上漲，一個一個開始新建事項，使用我們的功能，守到過了午夜1點仍然沒有異常，我們的心才放了下來，大家相互鼓勵，洗洗睡了。

2020年6月2日，又經過一輪的迭代，我們發布了Beta版本的DDLKiller，雖然是6月2日發布，但是用戶們早已體驗過新的功能，結合很多人性化的新功能進行二次推廣，用戶量達到240人，相比Alpha階段增長90人。後來經過最後一次項目展示答辯，我們的軟件工程這門課程，結束了。

但DDLKiller還沒有結束，就像我們UltraSoft – Beta – Postmortem事後分析中所說的：

BUAA – UltraSoft – 軟軟軟小組 2020春大三下學期的軟件工程，全劇終。

但我們DDLKiller的故事還在繼續，不要走開，馬上回來

我們還留了兩個功能沒有實現，我們感受到了大家對客戶端和小程序的呼聲，我們希望在自己的大學生涯中，甚至在未來的生活中，依然繼續使用這款我們親手打磨，親手建設的產品，說實在的，我們還挺不捨得的。雖然在專業人士的眼中看來這個實現非常簡單，可能一個前端大神两天就能做完的事情，一個後端大神一天就能寫完的東西，我們卻花了整整一個學期。

可是，我們在這個學期裏面不是學習的如何寫前端，如何使用Vue，不是學習如何寫後端，如何使用Django，我們團隊的賬號發表了39篇博客，技術博客都是在我們的個人賬號中發表，這說明什麼，團隊博客中所記錄的，是實實在在的軟件工程。那一篇篇設計與規劃、Scurm Meeting、發布說明、測試報告、項目展示、事後分析，是DDLKiller像一個新生兒一樣，成長的記錄。

我們學會了團隊成員之間如何高效合作，我們學會了如何使用Github、Gitee管理團隊項目，我們學會了使用MockPlus設計產品原型，我們學會了如何權衡需求和實際。確實專業的工程師照着我們的網站實現一個是很快，但是他可能很難做到從0到1的過程。他沒有進行痛點的分析，他不知道用戶真正需要什麼，他沒有一個需求和實際使用之間的權衡，他的開發確實了團隊協作的樂趣。

說實話剛開始團隊開發的時候我還是不習慣多人協作，覺得一個人做完了事就可以省去交流的時間，後來我才發現不是我不會開發，是我不會交流。我們團隊後期自研創新的交流方式非常高效，一個石墨文檔把鍋和坑明確到人，每個人不需要問自己需要干什麼，還可以干什麼；一天十幾個小時在線的騰訊會議，有問題直接進來說，語音來的總比打字快，共享屏幕來的總比截圖直接。大家高效交流之後整個難度就下來了，只要說好了誰負責開發什麼模塊，最晚什麼時候需要驗收，還有不懂的我們共享屏幕聊，幾乎不會產生歧義或者推鍋的情況出現。作為一個PM我的體會最深：在Alpha階段的前期由於缺乏有效的溝通，PM和組員都很累，每個人都有點不清楚自己要干什麼，我知道大家要干什麼卻不能很好布置下去，每天群里的提問和回答帶來的卻只有效率的低下，我也想着自己一個人做好就算了，要那麼多人干什麼，但也發現自己越是想全部做完做好越是什麼都做不完做不好。這是一段非常難忘的經歷，是軟件工程這門課提供給我的，給了我一個在步入社會前體驗社會毒打的經歷，幸好是在課內體會到的，不至於“死”得太慘。

回首望去，覺得這學期很長，也不知道是不是疫情在家的緣故，還是無窮無盡的騰訊會議的緣故，雖然只過了3個月，但是感覺自己做了很多事情一樣。3個月後再看自己的第一篇博文，確實有了些不一樣的體會。

回答自己

在初窺構建之法——記2020BUAA軟工個人博客作業中，我提出了七個小問題，其實在當時已經回答的差不多了，但現在有了一定的軟件工程經驗之後，又有了一點小的看法。

問題一：是否真的沒有銀彈

“把重點放在質量上，生產力將隨之而來”，這是Jones的觀點。基於這個觀點我當時提出了這樣的觀點：

我之所以對銀彈是否存在持有懷疑態度是因為在大環境下，有一些本可以提高的生產力沒有提高，還有很多團隊會出現文檔與實現分離的情況，出現進度卡在某一個人負責的環節的情況，這些情況都是我們會在後續的團隊編程中可能會遇到的，所以我覺得現在就應該思考，如何在團隊中破除沒有銀彈的詛咒，提升團隊的整體水平和能力。

我們團隊的生產力就有一個拐點，從一開始的效率低下到後來的慢慢摸索再到後來形成體系之後組員們心照不宣。是否真的沒有銀彈？我們組可能找到了自我協作的方式，充分將每個人的能力在其崗位上發揮，做到了效率的最大化和能力發揮的最大程度，整體生產力得到了提高，是否一定程度上找到了銀彈？

其實大家都在尋找屬於自己的“銀彈”，我看到每個小組都有自己組內的成熟的管理機制和協作方法，大部分是Github的Issue和Pull Request，還有一個Github的看板，還有一些在線文檔。並沒有說Github上面使用的管理方式就比石墨文檔更有技術，我們團隊覺得上Github的速度太慢，石墨文檔就能很好的解決我們的問題，也可以定位到人，還有具體的任務細節：

Beta階段開發明顯更加得心應手一些，外加Gitee上面的清晰的Issue和Pull Requests：

無論是對內的石墨文檔還是對外的Gitee，都對我們的實際開發極大提高了生產力。

問題二：如何選擇合適的團隊模式

當時鄒欣老師給到我的回答是：

想請教老師和助教，業餘劇團模式的具體形式能夠結合助教的經歷或是老師的觀察給一個更加清晰的講述嗎？

就是大家可以選擇各種角色來扮演，在下一個項目中，又可以有全新的分配方式。
你們就是用‘業餘’ 時間來開發的，比較適合這樣的模式。

在實際的開發中，我們確實也是業餘劇團的模式，大家先分好了大方向，前端和後端，然後分配一個模塊的任務吧，如日曆視圖、課程視圖等，如數據庫、爬蟲等，在實際的開發中，主體上不太發生改變，在細分的任務上比較靈活自由。特別是在Alpha發布之後，項目已經成型，大家已經不再限制於模塊的開發，細化到功能的開發，比如要實現一個快速創建的功能，可以在日曆中，也可以在日程列表中，兩個都進行添加。甚至前端的同學可以來優化一下後端的代碼，後端的同學學習一下前端的實現，都是“互通有無”的。

問題三：每日例會的效果如何？

在這個問題下面我當時又提出了一個問題：

敏捷開始是否是一個偽命題？

當時找到了Vczh輪子哥的回答：

敏捷不是一群開發者對着甲方的第一版需求猛做幾天，而是在做的過程中始終和甲方進行有效的、不間斷的溝通，來幫助甲方更加清晰地認清自己的需求，也幫助整個團隊確定一個當前的完成進度，也就是一個迭代中的需求分析和驗收。

經過兩輪的迭代和20餘次的Scrum Meeting，感受到了一些敏捷開發的意義：雖然我們沒有甲方，但是我們自己就是自己的甲方，我們不斷反省和思考着自己需要什麼功能，自己不需要什麼功能，認清自己的需求，掌握團隊的進度，不斷驗收。

每日例會一開始是拒絕的，我們在Alpha階段還弄錯了例會的時間，導致缺少兩篇，覺得這些東西在Github上都有，為什麼還要記錄呢？後來其實發現每日例會重要並不在於記錄，其一在於每日隱隱地督促着每一個成員，“今晚要彙報，自己做了什麼？”；其二在例會，一個常規的，團隊的固定“節目”，有例會才像是一個成熟的團隊而不是一個個散兵，在例會中大家可以找到歸屬感，大家可以有問題在例會中大膽提出來，有什麼想法提出來大家一起實現，有什麼功能其實沒有什麼用大膽刪去，例會還是一個平台，提供給大家自由說話、表達意見和想法的平台，在例會中每個人都有說話的權利，每個人的話都能被所有人所聽見，這是我理解的每日例會的意義。至於效果，見仁見智吧，我們團隊的例會效果我還是比較滿意的，大家都有準時參与，都敢說，都是為了我們DDLKiller更好的發展去說。

問題四：為什麼除了微軟很少見到Program Manager

當時我其實沒有找到這個問題合適的答案，也是遺留了下來，自己作為這個學期軟軟軟團隊的PM，無論是Product Manager也好還是Program Manager也好，談一下自己的看法。

很多地方都在吐槽產品經理，說產品經理不管需求是否能夠實現，產品經理是程序員的天敵諸如此類，無非就是在說產品經理不動技術，只懂調研和分析需求。作為我們團隊的PM，我也參与了調研，我也確定了產品的需求，但我也在我的崗位——後端、部署、測試上工作，所以當我有新的需求的時候，作為一名程序員，我也會要麼憑藉自己的經驗對需求的實現難度進行預估，要麼根據已經實現了的功能對需求進行預估。比如臨時加入一個消息中心，我其實也是從前端小白到了解了一點前端的知識，我知道這個功能並不麻煩，前後接口一設置分別實現就行了，所以大膽的安排了下去這個臨時的任務，我得力的組員也很快完成了，經過我的連接和測試，一天內用我們的“業餘”時間就上線了這個功能，提供了極大的便捷。

至於為什麼除了微軟很少見到Program Manager，希望我能夠親身去微軟和其他公司體驗一下吧。

問題五：對於小團隊而言小強地獄是否可行？

“小強地獄”聽着特別可怕，但其實在我們的實際開發中沒有太多遇到，首先是代碼總量不大，經過幾次定位就可以找到問題所在；其次是我們保證了合併進入主分支錢經過“充分”的測試，這裏的充分之所以打上引號是因為100%的充分並不存在，就像我們的同步課程中心的爬蟲核心功能，在我們團隊的幾個人的賬戶上測試都沒有出現問題，結果小範圍的內測立刻炸鍋，趕忙修復然後加大內測的範圍，在幾輪的測試都無誤之後我們才正式上線功能，這也是為什麼我們發布比較晚的原因。

我們團隊也並沒有測試這個職位，大家前端和後端自己先測試自己的代碼，然後連接的時候再測試連接的代碼，不需要不參与開發的人去讀代碼，只要提供充分的測試樣例就行了。小團隊連開發都人數有些不夠，在項目的尾期設置專門進行覆蓋性測試的測試人員即可，這種開發方式在我們的項目中並沒有出現什麼大礙，所以小強地獄這種東西，只是一個提出來的權衡feature和bug的模式，每個團隊可以根據自己的實際情況進行調整。

問題六：迷思之六：技術的創新是關鍵？

我們的項目有創新嗎？可以說有：我們使用郵件給用戶進行提醒，只要有網就能收到提醒；也可以說沒有，有一部分的用戶是被我們的美觀的界面吸引過來的，可能並沒有使用郵件的功能，而且其實我們的產品有類型的原型——Microsoft的ToDo。但是我們創新性地將同學們的所需以一個更好的形式呈現了出來，進行了高度集成再展現的過程，這也不失為一種創新。

我們在開發的時候想過創新嗎？說實話我沒有。用戶在使用到這樣一款產品的時候會主動想到有什麼創新嗎？可能也沒有。無論是開發者還是使用者，大家都在關注一樣東西——是否解決痛點。我們可能從來沒有想過郵件提醒是一種創新，靈感來源於博客園的作業提醒，我們想的是如何解決用戶沒有在日程的DDL前被提醒的痛點，郵件只是解決這個痛點的一個可行方式罷了。

我不是在否認創新的重要性，只是在說有的軟件可能目的不在於創新，也能夠贏得大家的喜愛。新鮮感固然是好東西，但是新鮮感不能持久，當新鮮感褪去，用戶是否還會對我們的產品滿意？是否會選擇其他更具有新鮮感的東西？這些是根據用戶的需求是否被解決所決定的，也是一個產品的核心部分，真正被考量的部分。

問題七：最難的問題——排座次

當時提出這個問題時，還是太嫩了，其實排座次在實際執行起來是整個開發中最簡單的事情，就像鄒欣老師說的，有的人想得60分有的人想得90分，根據大家的Pull Requests和實現的功能的工作量就可以看出來。我們團隊的成員大家都非常积極，甚至主動找我領取任務，所以在最後的打分大家都差不多；其他組比如NAG2020就可以看到，其中有一名成員就是想拿60分的，兩個階段的貢獻分都是最低，代碼貢獻也是最少，自然就給了最少的分數。

使用Gitee、Github等項目管理軟件之後，每個人的积極程度、活躍程度、項目的貢獻量都一目瞭然，所以排座次的問題，客觀公平公正得到了解決。

新的問題

疫情之下，我們體驗到了全新的軟件工程，可能我們是唯一一屆在線上開展軟件工程這門課的學生，我們線上開會，線上協作，線上發布，線上展示。Work From Home 成了疫情中主流的工作方式。之前看到Vue的開發團隊就是分佈在世界的各個角落，線上交流和協作維護，他們已經形成了一種十分成熟的WFH的工作方式。

試想，在WFH是否會成為未來的發展方向？特別是對於程序員而言，WFH其實可以在不影響開發的前提下能節省很多的時間，如通勤等等，很多大公司已經或者開始嘗試WFH，包括美國的巨頭Google、Facebook、Twitter等等，請問老師和助教覺得，本學期的WFH與之前學期的線下軟工有什麼區別，有意料之外的提高嗎？

“做中學”

需求階段

學會取捨：衝刺只有兩周，而且我們是業餘開發，所以不可能將所有的功能都實現，甚至在Alpha階段我們僅有的反饋中有一項是希望在課程列表中加入測試模塊，這個想法在Beta設計與規劃前是列入到了Todo List中的，然而在Beta設計與計劃實際的權衡中我們將其丟棄了，替換為了課程的通知，因為通知使用的更多，幾乎每門課都有，而測試只有少量的一兩門課有。

設計階段

顏值即正義：一款顏值高的產品不一定是最好的但一定是最吸引用戶的，我們的Web程序也是因高顏值吸引了不少用戶，大家對於課程中心陳舊的排版感到視覺疲勞的時候看到我們的產品會眼前一亮從而想要體驗，這是在推廣階段特別重要的一點。

實現階段

考慮可擴展性、注意代碼風格：以我負責的後端爬蟲來說，從開始時的只爬取課程作業和課程資源到迭代中加入爬取課程通知再到期末季中爬取考試日程安排，這幾樣東西應該做到合理歸類與分離，以免造成代碼太過臃腫接手的人難以及時上手。

測試階段

回歸測試和覆蓋測試的重要性：在發布新功能時，要一併考慮到舊有功能是否正常運行，我們在迭代中就遇到這樣的問題，比如在Beta階段我們支持了重複日程的提醒，向日程中加入了字段 repeat，然而我們只測試了常規的添加日程，沒有考慮下方的快速添加日程和模板添加日程，導致發布之後出現內部錯誤，檢查日誌才發現錯誤所在然後緊急修復。如果每個新功能在發布的時候都能夠有回歸測試則可以避免這一問題。

發布階段

漸進式發布：當一個應用的新功能準備發布的時候，會進行一些測試，比如灰度測試，即選取一小部分用戶可以體驗到該功能，其他用戶維持原來的功能不變，以查看新功能的運行效果和用戶反饋意見，在我們的開發中，我們有多台主機可以進行訪問，所以會先使用其他主機的ip訪問使用“內測版本”的DDLKiller，然後過一段時間再發布。在Alpha的正式發布前我們也做了小範圍的內測，讓一些自己的舍友和朋友先使用，看看有沒有問題，還有么改進的地方，確實內測找出了一些問題，幫助我們在正式發布的時候減少很多事情。

維護階段

文檔文檔文檔：經驗教訓是有心東西一定要以文字的形式在文檔中呈現，首先是提高了團隊內部的溝通效率，大家不用反覆詢問可以直接查閱文檔，其次是積少成多，為後面接手的同學做充足的準備。特別是前後端分離的團隊開發，只要文檔維護得好，直接事半功倍，反之事倍功半。

理解、心得

個人項目->結對項目->團隊項目，是一個課程組有意設計的一個遞進的關係，在這一點上我覺得羅老師和任老師班級的軟工做的最好，相比於歐陽老師班級的個人項目直接到團隊項目，我們中間有一個過渡期，很多人其實在過渡期的時候就知道自己想要干什麼了，大致可以分為前端和後端了，這樣一來在團隊中的項目分工也簡便了很多。

在個人項目中，我們實現了一個求交點的程序，沒有頁面显示，只有命令行的交互；在結對項目中，我們加大了求解交點的難度，同時用圖形化的界面將交點的位置呈現在了眼前；在兩個衝刺，前後兩個月的團隊項目中，我們分工更加細緻，實現了一個軟件。一步步走來，感覺越來越難了，但是也越來越簡單了。難在項目確實更大，從技術上來說難度確實增大了；簡單在我們不是一個人在戰鬥了，我們身邊從沒有人到一個人再到一群人，集體的力量是不容小覷的，每個人都有自己擅長的部分，這一點感觸特別深。在團隊中，一個人花了很久不能解決的事情，丟出來大家都积極主動伸出援手，一起將困難啃下來；在這個學期學習是在很累的時候，也是我們團隊的成員陪伴着我，在此感謝陪我熬夜最多的Kkkk，有時候大家就算不需要說話，只要會議室裏面有人，心靈就能得到慰藉——“我背後還有一個團隊”。

在團隊項目中，我既是PM又是後端開發，還負責部署，這個工作可能比有的團隊PM只負責文書麻煩一些，但也暴露出來了一人多職的缺點。由於Alpha階段對時間的理解錯誤外加新項目開發難度大，導致Scrum Meeting有一兩次開會了但是沒有及時記錄導致會議紀要缺失的情況，還有就是寫完代碼之後沒時間寫文字了於是產生拖延，這一部分應該專人來記錄會好一些。在團隊項目階段確實學習到了很多新知識，無論是Django開發還是NGINX部署，都需要啃官方文檔，特別是NGINX和Uwsgi的兩個官方文檔還有不清楚的地方需要自己解決，在五一的五天假期連肝五天才總算把前後端連接和服務器部署徹底啃下來，終於在五一假期的尾聲進行小面積的推廣。這也讓我對網絡與系統這一方面產生了興趣，在暑假期間我會嘗試涉獵一些分佈式和網絡編程相關的內容，如果感興趣的話希望有機會往這方面發展下去。若是因軟件工程這門課能夠找到我自己的真實興趣所在，也是太值得了。

作為PM，特別感謝我的軟軟軟團隊的隊友們，包括Alpha階段結束之後轉走的Dz，一樣非常感謝。是你們一起幫助我完成了我的一個想法，讓他不再是一個想法，成為了一個真正能夠使用，大家都可以使用，甚至受到好評的一款軟件。其實DDLKiller是我實在找不到一款可以提醒我日程的軟件下的“被迫選擇”，想要一款DDLKiller這個念頭在我剛開學的時候就有了，當時和舍友嘗試了Tower協作也不好用，嘗試了Microsoft的Todo也不好用，自己又開發不了，但是居然在團隊開發中被我們做出來了，和我預想的完全一致，甚至某些功能超出預期。是你們讓我第一次體會到想法到實現的喜悅，第一次切身體會到代碼的魅力，第一次感受到團隊的強大，體會到1+1+1+1+1+1+1>7。DDLKiller就是我的軟軟軟團隊的孩子，離不開每一個人的付出。

我們在第一篇自我介紹中說到：

雖然我們都沒有大型的工程經驗，是一直拼裝起來的軍隊，但是我們相信通過我們團隊的配合一定能夠在軟件工程這門課中發揮出色，不只是取得成績，而且能做出像樣的、能流傳的、實用的項目出來。

至少在我自己看來，我們已經成功了。

最後想說的

大概的都說的七七八八了，若是要用幾個詞語總結這學期的軟件工程課程的話：

魔幻、刺激、充實、欣慰

在每次的個人作業前面老師都讓我們寫下這門課程的目標，我寫的是：

完成一次完整的軟件開發經歷
並以博客的方式記錄開發過程的心得
掌握團隊協作的技巧
做出一個優秀的、持久的、具有實際意義的產品

現在看來，我都已經做到了：

一次完整的軟件開發經歷：從使用MockPlus畫出草圖，到真正用網址就能訪問
博客團隊的開發：39篇團隊博客就在BUAA軟軟軟件工程小隊中
團隊協作的技巧：我們甚至自研了石墨文檔+騰訊會議的創新性協作方式
優秀的、持久的、具有實際意義的產品：DDLKiller——懂你的日程管家

從UltraSoft – Beta – Postmortem事後分析中摘取一段話出來：

如果下一年有學弟學妹問我：軟件工程哪個老師的課好？

我會如實回答：如果你對自己有要求，如果你想這個學期不碌碌無為，如果你想學期結束收穫滿滿，如果你想逼自己一把，選擇羅傑、任健老師的班級吧。過程會很痛苦，你會看到別人都在玩的時候你在寫博客，你會看到別人開發的時候你在寫博客，你會看到別人只開發一次就結束的時候你在寫博客，你在開例會，你在Beta階段開發，但是當你的博客得到了老師的認可，得到了助教的讚賞，得到了《構建之法》作者鄒欣老師的點評，得到了輪子哥Vczh對你的提問的親自回復，得到了《持續行動》《刻意學習》作者Scalers為你特地開賬號的留言，你會感覺，這一切都值了。

慶幸當初的自己沒有聽到負面的評論就退縮，堅持選擇了羅老師和任老師的班級，做出了像樣的東西。我確實心裏吐槽過博客，用心寫真的很累，每次博客能花上3～5個小時，每次都是動輒上萬字，但是確實寫完之後獲得了有意義的評論和建議心裏特別舒服，讓我受寵若驚的是第一次的Scalers為我註冊博客園賬號留言7500字，讓我感覺到自己的博客沒有白費。自己也是北航面向對象課程的助教，也能夠一定程度上理解老師和助教的良苦用心，很多東西學生在做的時候是會不理解甚至罵出聲的，但是做完之後又是另一種感受了，老師和助教只能委屈成為暫時的惡人，逼着同學去思考，逼着去寫下文字，逼着做看不到短期利益的事情，等待着一切都結束時候的理解。

軟件工程這門課雖然結束了，但我們的軟件開發依然在繼續，回顧，為的是更好的出發。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

※聚甘新

2020-11-05

標籤: 銷售文案

1. 貝恭弘=叶 恭弘斯公式

2. 最小錯誤率貝恭弘=叶 恭弘斯決策

3. 最小風險貝恭弘=叶 恭弘斯決策

回顧，再出發

序

回答自己

問題一：是否真的沒有銀彈

問題二：如何選擇合適的團隊模式

問題三：每日例會的效果如何？

問題四：為什麼除了微軟很少見到Program Manager

問題五：對於小團隊而言小強地獄是否可行？

問題六：迷思之六：技術的創新是關鍵？

問題七：最難的問題——排座次

新的問題

“做中學”

需求階段

設計階段

實現階段

測試階段

發布階段

維護階段

理解、心得

最後想說的

1. 貝恭弘=叶恭弘斯公式

2. 最小錯誤率貝恭弘=叶恭弘斯決策

3. 最小風險貝恭弘=叶恭弘斯決策