作業的基本資訊

課程回顧與總結

回顧自己列出的5到10個問題：嘗試解答、繼續分析、提出新問題

回顧問題，嘗試解答，繼續分析

部落格連結——寒假作業2-2

為方便老師助教查閱，下面貼上我在寒假作業2-2中提出的問題。

問題一 關於團隊成員不同投入和心態

問題重述與提問原因：鄒老師在第五章團隊中的角色與合作中的b節，依照團隊中成員的不同投入和心態，把一個團隊中的成員比喻成三種人，分別是“豬”、“雞”還有“鸚鵡”，這個比喻非常形象。然而在軟體開發過程中，我們遇到的搭檔可能是幾種型別其中的任意一種。所以我有一個疑問，我們在開發過程中要如何與不同投入和心態的搭檔相處，來確保軟體開發效率和軟體的最大化？

當時回答：我認為可以在上層結構通過獎懲機制來獎勵那些有突出貢獻的成員而督促那些參與到專案的“圍觀者”增加投入。

繼續分析：通過軟體工程實踐這門課程的學習，我認為建立合理的獎懲機制在團隊管理中是十分必要的，這樣既可以對積極者進行獎勵，也可以對那些消極懈怠者進行鞭策。尤其是在團隊程式設計的過程中，由於我所在的團隊制定了一份詳細的，並取得老師和助教一致好評的獎賞機制，所以在開發過程中每個人都幹勁十足。

問題二 關於設計與測試中投入時間

問題重述與提問原因：鄒老師在第二章個人開發技術中的a節PSP中有一份對比表格，其中例舉了大學生與工程師在PSP各個階段中花費的時間比，我發現工程師在分析和設計以及測試中投入的時間超過新人，反而在編碼環節的投入低於後者。在我的認知中生產軟體的主要過程應該是編碼，在事前和事後花費的時間總和應該少於編碼過程花費的時間。而且在我印象裡網際網路公司普遍加班問題嚴重，如果在分析和設計以及測試過程中投入的時間超過編碼過程，那麼按照網際網路公司的開發過程中嚴密的角色、任務劃分，各個環節都應該會有專人負責，不應當出現加班嚴重這種現象。

當時回答：可能是公司要開發專案太多？但是我感覺各家公司有一直在維護的產品分配給各家公司的總員工數，不應該會出現加班嚴重這種普遍現象。或者是我專案經驗還不太夠。

繼續分析：詳細的分析和設計可以規避產品與使用者需求之間存在的功能性差異，而進行詳細有效的測試可以讓產品的使用者體驗得到極大提高，通過軟體工程實踐這門課程的實踐，在早期沒有感覺，但是尤其在團隊程式設計中我發現這兩塊所花費的時間確實要大於編碼過程。

問題三 關於使用者語言行動的背後動機

問題重述與提問原因：鄒老師在第六章需求中的e節中提出“光看使用者的表面語言或行動還是不夠的。我們還要找到使用者語言行動背後的動機!”。對此我有一些疑問，我們要如何判斷我們所認為的使用者的背後動機是使用者真實的背後動機，而不僅僅是隻是我們善意的遐想？因為猜測錯使用者的背後動機不僅抓不住使用者，並且還有可能因此鬧出烏龍。

當時回答：我認為背後動機這種東西還是得從使用者入手，比如可以從使用者調研入手，如果是匿名的調研最好，這樣可以看出使用者真正的背後動機。

繼續分析：開發團隊需要與使用者代表進行積極溝通，因為一次溝通能暴露出來的問題往往非常有限，許多問題是在開發過程中不斷暴露出來的。在這門課的實踐過程中我發現往往使用者會存在潛在需求，這種需求使用者往往自己也不能發現，這就需要我們積極去和使用者進行溝通，幫助使用者發現自己的需求。

問題四 關於競爭

問題重述與提問原因：鄒老師在第九章軟體和IT業的創新的d節魔方的創新中，提到當競爭進入白熱化階段時競爭這有三個選擇，其二是“依賴自己別的優勢或壟斷, 把魔方繫結在優勢專案上銷售, 例如團支書要求團員必須去團支部購買魔方”，看到這裡我有個問題，假設此時我們的競爭對手採用了這種方法取得了壟斷，那我們是否還有意義進行軟體的維護更新？

當時回答：我認為應當斷則斷，放棄該APP後續的維護和升級，避免帶來更大損失。

繼續分析：如果我們的產品各方面體驗都優於競爭對手的產品，我認為還有必要堅持下去。如果兩個產品各方面體驗都相近的話，對方又有特殊方法可以取得壟斷，那就大可不必堅持下去。

問題五 關於結對程式設計

問題重述與提問原因：鄒老師在第三章兩人合作的b節結對程式設計中提到結對程式設計的模式，對此我不完全贊同，我認為除去鄒老師例舉的五類情況，盲目的結對程式設計會存在一些問題。因為每個人面對問題的認識不同，會導致解決問題的方法不盡相同。而結對程式設計要求“駕駛員和領航員不斷輪換角色，不宜連續工作超過一小時。”,我認為這樣會導致思路頻繁被打斷，影響效率，嚴重的還會造成思路上衝突。理論上可以通過事前約定解決，但是依鄒老師在創新一章中提到的一種現象，就是程式設計師在開發過程中時常會產生新點子，那麼新點子的產生要實現在結對程式設計中肯定需要兩個人的共同參與。問題在於，某些點對於一個人來說是新點子，在另一個人看來會不會價值沒有那麼明顯？

當時回答：要麼制定強有力，主要是得詳細的規則，這樣兩個人在開發過程中遇到問題按照既定規則即可解決；要麼結對程式設計不要頻繁更換物件；

繼續分析：兩個人的結對程式設計也需要兩個人之間加強溝通，求同存異。當出現難以協調的問題時，需要客觀獨立的第三方介入協調解決問題。

提出新問題

在團隊作業的實際開發過程中，我在搭建專案框架的時候有同學會推薦我使用一些新興的框架，例如Java許可權認證框架Sa-Token,那麼晚問題來了，是否需要採用這些新出現的框架還有技術？
我思慮再三，即使在新框架強大新特性的誘惑下，我最終還是在實際專案中使用了傳統的許可權管理框架Shiro。主要的考量因素還是因為我覺得Shiro這個框架廣宣迭代版本眾多，是一個相對於十分成熟的框架，換一種說法就是說Shiro這個框架相當健壯，在之後的版本即使出現跨越性的迭代，你在使用過程中遇到的問題也是世界上也會有許許多多的開發者會共同遇到的問題，這意味著你修復問題的時間會遠遠小於這些新興的框架。
在這裡也想請問一下瀏覽到這篇部落格的人，在遇到新興框架時，尤其是那種新特性十分誘人的框架時，是會採用傳統框架處理問題，還是會大膽使用這些新框架？

5個階段中，每個階段收穫最大的知識或能力是什麼？

需求階段

在需求階段需要與使用者代表進行積極溝通，若沒有使用者代表的話，需要及時與使用者群體進行溝通。積極挖掘出使用者的潛在需求，當然，這個階段也不必苛求能夠事無鉅細地找尋出使用者所有的需求，因為這樣幾乎不大可能。

設計階段

在收集到使用者需求之後，我們就要針對使用者需求開展資料庫設計等設計階段的工作，設計階段需要考錄到未來系統的可拓展性還有可維護性。這一點之前汪老師在軟體工程這門課上有重點提到好多次，我當時不以為然，但是在團隊作業中實際體驗告訴我設計階段必須要考慮到未來。因為好的產品也是具有生命性的，像培養植物一樣，好的產品也需要慢慢成長。 開發人員要未雨綢繆，要為程式未來拓展預留空間。

實現階段

（1）實現階段不管是在團隊內部，還是在團隊與客戶之間要積極進行溝通。
（2）其中，團隊之間的溝通可以提高開發效率，在早期通過溝通可以發現的問題及時解決，這樣規避後期滾雪球般積累的巨大風險的出現。在α階段由於我所在的團隊內部前後端之間沒有進行積極溝通，導致在前後端介面對接時出現了許許多多的問題，這在一定程度上拖累了進度。
（3）與使用者之間的溝通，可以幫助我們及時儘早發現使用者的潛在需求，這樣可以減少後期使用者臨時加需求所帶來的巨大開銷。
（4）要階段性提供產品demo給使用者試用，這是為了儘早發現產品與使用者預期存在的差異以及發現使用者未發現的潛在需求。

測試階段

測試一定要有開發人員之外的成員參與，因為開發人員對自己的程式碼進行測試時往往難以發現自己的問題。這時就需要外部人員參與進來，協助發現未發現的問題。

釋出階段

在使用者發現bug之後要及時進行反饋，修改bug可能需要一定時間，但是我們要及時告知使用者我們收到了使用者反饋的bug。因為在課程軟體評測階段，個人親身經歷感受告訴我負責任的平臺更會博得使用者的好感。

結合自己在個人專案/結對程式設計/團隊專案的經歷，談談自己的理解或心得

個人專案

最大的收穫就是學會了PSP表格的使用，我發現這個表格不僅僅可以用在軟體開發過程中，在學習中也可以用到，很贊！我還學會了凡事預則立，不預則廢，在軟體開發過程中且不侷限於軟體開發的過程要對時間安排進行規劃，並在事後進行分析，分析的目的是為了更好的成長。

結對程式設計

（1）最大的收穫是增強了自己的版權意識，使用開發者不全是自己的程式碼時，要備註上所有開發者的資訊。
（2）除此之外，我還學會了如何開展結對程式設計，在結對開發過程最重要的還是兩個人進行及時溝通。由於我當時採用的是兩個人一人負責前端一人負責後端的開發模式，所以在開發過程中溝通較少。最後在我後端程式碼幾近完成時發現前端進度還落後與預期進度，如果能夠進行及時的溝通的話，這種情況本應該避免。

團隊專案

（1）首先由衷感謝汪老師還有助教以及背後付出的許多老師們。
（2）通過團隊專案這一階段的實踐，使我真正走過了軟體開發的完整階段。我個人覺得學會最有價值的內容還是領悟到了工程性的思想。我之前不理解為什麼軟體工程要名為工程，因為我之前覺得軟體開發是一項並不複雜的工作————負責人在指揮，剩下的人跟著負責人的方向前進即可。並且我之前誤認為真正意義上的工程是像土木基建那般大興人力的才應該叫做工程。
（3）但是通過這一學期的學期，我體會到了軟體工程之所以名為工程的原因。是因為軟體開發這一流程不應該僅僅只有編碼階段，還應當包括事前的各種設計階段還有事後的測試階段等等，每一階段都需要花費一定的人力來確保整個大工程的質量不出問題。

個人技術總結————關於SpringBoot定時給特定郵箱傳送郵件

技術概述

簡述

一種使用ScheduledThreadPoolExecutor來實現定時給特定郵箱傳送郵件的方案

使用場景

我們的專案有一個功能是需要在使用者註冊成功半小時之後，給使用者傳送一封使用者反饋資訊填寫的問卷。

技術難點

SpringBoot定時任務@EnableScheduling和@Scheduled對應的定時方法不能帶引數，這給對特定郵箱傳送郵件造成阻礙。

技術詳述

部分程式碼展示

    ScheduledThreadPoolExecutor scheduledThreadPoolExecutor = new ScheduledThreadPoolExecutor(1);
    scheduledThreadPoolExecutor.schedule(new Runnable() {
        @Override public void run() {
            System.out.println(email);
            feedbackEmail.send(email);
        }
    },30*60*1000, TimeUnit.MILLISECONDS);

這部分程式碼的詳細說明見下文。

ScheduledThreadPoolExecutor原理

這部分內容參考CSDN上相關文章，我連結附在下文“參考文獻、參考部落格”中

工作原理

描述及上述程式碼說明

由上圖我們可以看到ScheduledThreadPoolExecutor類具有三個重要方法，分別是:

（1）schedule(Runnable command, long delay, TimeUnit unit)方法；
（2）scheduleWithFixedDelay(Runnable command, long initialDelay, long delay, TimeUnit unit)方法；
（3）scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit)方法；

考慮到我們實際功能只是傳送一封郵件，對應著的就是提交一個延遲執行的任務，所以我們應當採用第一個方法schedule(Runnable command, long delay, TimeUnit unit)。
第一個引數我們新建了一個Runnable物件，並在這個物件裡面呼叫傳送使用者反饋問卷郵件的方法；第二個引數對於的是時間數值，而第三個引數對應的則是第二個引數對應的時間單位，可以看到，我們在這裡設定的是30分鐘後執行這個定時任務。

技術使用中遇到的問題和解決過程

（1）剛開始時，我理所當然地使用@Scheduled註釋來實現定時傳送郵件這一功能，但是在我寫好程式測試的時候發現，在啟動SpringBoot專案時，專案出現錯誤：Only no-arg methods may be annotated with @Scheduled，這個錯誤告訴我們@Scheduled方法不能帶引數。我就開始百度@Scheduled註釋對應的定時方法要怎麼帶引數，但是逛了一大圈我沒有找到滿意的解決方案。
（2）但是，我要實現的功能是給特定的郵箱傳送使用者反饋問卷郵件，也就是說，定時傳送郵件的方法必須拿到要傳送郵件的郵箱地址。所以有兩個解決方案，一是把郵箱地址存到某個地方，再在定時方法裡面取出來，二是換一種實現方式，比如再開一個執行緒等。
（3）思量再三，我選擇第二個方案，其原因是，我在專案中沒有使用快取Redis，同時這種非關係型的資料放進資料庫不太合適。所以我採用了ScheduledThreadPoolExecutor來實現定時給特定郵箱傳送郵件的方案。

參考文獻、參考部落格

1、Spring Boot系列三 Spring @EnableScheduling 定時任務用法總結
2、定時任務ScheduledThreadPoolExecutor的使用詳解
3、定時任務 & 定時執行緒池 ScheduledThreadPoolExecutor
4、多執行緒學習（2）：ScheduledThreadPoolExecutor 與 schedule 之小結
5、ScheduledThreadPoolExecutor原理詳解