| 問題 | 內容 |
|---|---|
| 這個作業屬於哪個課程 | 2021春季計算機學院軟件工程(羅傑 任健) |
| 這個作業的要求在哪里 | 提問回顧與個人總結 |
| 我在這個課程的目標是 | 進一步提升工程化開發能力，積累團隊協作經驗，熟悉全棧開發流程 |
| 這個作業在哪個具體方面幫助我實現目標 | 回顧學期初提出的問題，總結課程收獲 |
提問回顧
其實，在提問博客里，對於絕大多數問題，筆者已經給出了自己的思考與解答。不過作為一篇總結性的博客，這里不妨更進一步，看看經歷了一個學期后，自己是否對這些問題有一個更深入的認識吧。
Q1. 什么樣的功能才有實現的必要？
正如筆者在提問博客里所寫的那樣，這個問題的本質其實是如何判斷一個功能的重要性。在提問博客中，根據《構建之法》一書中的觀點，鄒老師似乎是想強調即使一個功能用戶的使用頻率並不高，但也不妨礙它的重要性，比如說飛機的安全功能。
對此，在經歷了敏捷開發的過程后，筆者既同意，但又不完全同意。
同意的點在於，對於一個成熟的商業軟件而言，比如說windows，它的殺毒功能或許普通用戶平常很少接觸，但是如果沒有的話后果會不堪設想，因此對於這一類的基本功能，使用頻率並非是衡量其價值的關鍵。
不同意的點在於，對於一個敏捷開發的產品而言，如何在短時間內最大程度地抓住用戶的痛點才是關鍵，此時或許就更傾向於從用戶的角度出發，用戶要什么，我們就提供什么。
不過其實深挖下去，這兩種場景在深層次上並不矛盾，最終的落腳點還是如何更好地衡量用戶需求並加以實現。一個產品在其不同的成長階段，着眼點也往往是不同的。不過我們目前所接觸到的產品更多的還是在成長期，而非成熟期，自然也就更加傾向於后者了。
Q2. 單元測試應該由誰來寫？
對於這個問題，筆者的觀點沒有發生變化——最好還是應該交給專門的測試人員來完成。
不過，在敏捷開發這一場景下，在人力資源捉襟見肘的前提下，那當然還是交給代碼的作者比較好——畢竟總好過交給另一個同樣還在做其他開發任務的人。
Q3. 專和精的關系到底是什么？
對於這個問題，筆者的觀點也沒有發生變化——作者這里想討論的應該是“專”和“全”的關系，而不是“專”和“精”的關系。
而對於后者，筆者已在原博客中進行了解答，引用如下：
對於這個問題，我認為單純強調”專“更好或者”全“更好都過於片面而不夠客觀，歸根結底還是對於【軟件工程師】這一職位地定義太過模糊與寬泛。同樣都是工程師，不同人的分工也有所不同：有人專精於前端或后端相關技術棧，有人則需要統籌全局地架構和部署。此外，在一個人的職業生涯中，其承擔的職責也是在不斷流動的。也許他在入門時可能只是擅長某一特定方向的程序員，但在不斷的磨礪與成長后也完全有可能去獨自領導一個團隊；或者也許他在入門時各方面基礎都比較扎實，但在不斷的探索中他也完全有可能找到自己擅長且感興趣的方向，最終成為這個方向上的開拓者。
Q4. ”技能的反面“與提高技能的方法
對於這個問題，筆者當時也已經進行了詳細的解答，給出了個人的觀點。
在此，筆者想對“熟練”這個概念做進一步明確的定義。
真正的熟練，是超越。
具體而言，我們說熟能生巧，這不是沒有道理的。當一個人熟練於某件事的時候，他絕不是簡單地提高了自己的速度，而是他在這其中發現了某種訣竅，從而可以事半功倍地完成任務——這和機器語境下的熟練是不同的。
如此一來，技能與“技能的反面”之間的矛盾也就迎刃而解了。
Q5. goto到底該不該用？
goto當然不該用，這沒啥好說的。
Q6. 商業價值與開源精神是否矛盾？
這個問題，筆者當時也沒有給出一個明確的答案。很遺憾，現在也無法給出。
商業軟件的開源與否一直是一個很有趣的話題。Linux是開源的，但UNIX不是；Android是開源的，但GMS不是；蘋果的生態是閉源的，但不妨礙人家始終維持行業領導者的地位；某些軟件是閉源的，但可能多數人聽都沒聽過他們的存在。
所以矛盾嗎？
或許並不矛盾。閉源是為了維持自身的競爭力，開源是為了更好地開拓生態和市場，它們本質上都服務於產品背后的商業邏輯，服務於公司未來更長遠視角下的發展。
你看，現在連office不都開源了一部分了嘛，緊隨時代潮流才是關鍵呀。
Q7. “只先一步”最終一定會帶來“顛覆式”創新嗎？
只先一步必然不會帶來顛覆式創新，從個人視角來看。
只先一步必然會帶來顛覆式創新，從人類視角來看。
以上。
Q8. PM與開發測試人員的關系和分工應當是怎樣的？
對於這個問題，作者的觀點是【PM做開發和測試之外的所有事情】；對此，筆者當時給出的回應是：
因此，我認為，單純地把PM的工作定義為【開發和測試的補集】是非常不合理的。一個合格的PM他在一個團隊中所起到的作用更像是【粘合劑+方向標】，他既需要隨時把握各個開發測試崗位的當前進度（這如果沒有基本的技術功底的顯然無法做到），同時也需要及時將客戶的需求傳達給團隊的其他成員們，從而共同協商出下階段合理的任務計划與分工進度安排。
而在本次敏捷開發中，筆者所在的團隊所采用的【輪值PM模式】也在很大程度上進一步模糊了PM與開發測試人員之間的分界（當然這也是迫於人手不足的原因所致），但從結果來看，還是比較成功的。這里也不妨附上本組對於輪值PM模式的一點總結心得：
關於多PM管理模式，並不是簡單地將原單PM的工作一分為三，或者拷貝多份，而是建立在PM團隊內部的一致性前提下，結合不同PM的個人特點，所實現的多層次、多維度的權責分工模式。
這里我們借鑒了傳統管理中職能式、流程式、矩陣式等經典的管理方法，結合敏捷開發的特點，最終在不斷實踐的過程中完善了本團隊的PM機制，並取得了比較理想的成果，客觀上有助於提升團隊整體的凝聚力與工作效率。
具體而言，根據本團隊的實踐經驗，我們認為實行多PM制度需要滿足以下幾點先決條件（必要不充分）：
- 各PM均具備遠高於平均水平之上的團隊責任感，有一定的奉獻與犧牲精神，任一人均應在團隊遇到困境時有着挺身而出的覺悟；
- 各PM之間要配合默契，最好之前有過一定的合作經驗，對各自的性格特點有基本的了解；
- 各PM的性格、能力要能夠互補，即在任一特定小領域內，某一PM將有較高的權威甚至唯一決定權，其余PM將在理解的基礎上尊重並支持其決定；這些小領域彼此之間不會重合。而由於性格等差異，不同PM對於團隊發展的落腳點不同，於是在全局大方向的把控上也往往能夠相互補充，以免有失偏頗。
至於本團隊，PMz重點負責前端設計與實現，PMm重點負責后端算法及測試，PMt則負責整體的統籌協調以及后端API、環境部署等工作。
此外，在博客撰寫、對外交涉、宣發等工作上，各PM也會在充分溝通的前提下保持統一口徑，並進行合理分工，以保證團隊項目的有序推進。
所以，一個優秀的PM，必須是【粘合劑+方向標】——為整個團隊指出方向，且能在最需要的時候隨時可以頂上。
不過，一個合格的PM，只要把他該做的都做好，就能對得起他拿的那份工資了不是。
Q9. “殺手” + “輔助” = “維持”？
對於【殺手功能+輔助需求】這樣的組合，作者給出的建議是采取“維持”的辦法進行實現，而對於【殺手+必要】這樣的組合，作者則給出了“差異化”的建議。
對此，筆者的觀點未發生變化。引用如下：
在如今的互聯網時代，整體上來看，多數公司與產品所采用的商業模式已經與傳統制造業截然不同——傳統制造業銷售的是產品本身，而互聯網公司們銷售的則往往是產品周邊與服務。比如Google公司的核心是搜索引擎算法，但它所采用的盈利方式則是靠廣告投放：假如當時Google把全部重心都放在優化它的搜索引擎的性能上的話，那么缺少有效盈利手段的它有可能擁有如今的市場占有率嗎？
再比如，現在非常火熱的《王者榮耀》等一系列手游，它們的核心功能無疑是游戲的玩法本身，但很遺憾這部分功能通常是免費的，而真正收費的卻是各種【皮膚】等看起來並無任何實際用處的外圍功能：那這是否意味着游戲公司就只需要提供最基本的皮膚給玩家就夠了呢？
因此，我認為在資金有限的前提下，一些必要需求，哪怕是殺手功能，反而只需要“維持”即可；而恰恰是一些看似不那么重要也不難實現的輔助需求，才是真正需要做到“差異化”的關鍵所在。
新問題
- 敏捷開發的天花板是不是有點低？
- 與一個成熟的軟件（比如VS）相比，敏捷開發之后的路應當走向何方？
- 這樣下去，中國何時才能造出
MatLab呢？
知識點
需求
- 要提升目標人群的針對性，尤其是對於需求切口相對小的群體而言，需要想辦法盡可能與之早日接觸
- alpha 和 beta 階段的宣傳結果對比表明，針對性的宣傳明顯會產生更好的結果
設計
- 設計要保證足夠的可維護性，即向前兼容的能力
- 無論是前端UI還是后端數據模型，最開始都不可能做到絕對的盡善盡美，因此必須要留下后續繼續迭代的空間與可能
- 可以輔以健全的文檔實現
實現
- 前期要注重規范的建立，中期應保證格式內容的審查，后期要注重對前期的兼容
- 比如API的基本規范、CI\CD的實現、回歸測試等
測試
- 模擬測試往往不可能考慮到全部情況，因此要盡早部署到真實環境中進行內部測試
- 單元測試的覆蓋率不能說明一切，但如果連覆蓋率都沒有或許可以說明某些問題
發布
- 早發布早治療
用戶表示：只要你敢發，我就敢用
- 注重用戶反饋，隨時進行產品迭代更新
維護
- 建立維護日志，對於維護記錄進行管理，避免重復操作
反思
個人項目
軟工的個人項目由一篇篇博客組成。通過這一篇篇博客，以及博客背后所耗費的時間與精力，筆者對於自己、《道法之間》、CI/CD以及若干問答網站都產生了更加深入的認識。並且筆者關於問答網站的博客也十分幸運地成為了班級熱門博文的Top 1，得到了更多人的關注與認可。
必須要承認的是，這些博客的存在客觀上進一步鍛煉了我的寫作與分析能力，使得自己筆下的文字更有條理、更有邏輯，在簡潔精煉的同時依舊保留了筆者原先對美感的追求。
如果能再提升一波英文寫作能力就更好了
結對項目
結對項目中，博客只是錦上添花，重點又重新落回了編程本身，所謂“夢回OO”，正是基於這一原因。
但是正是這些錦上添花的博客，涵蓋了筆者對於結對項目本身的思考。無論是【MVP還是MBP】、【需求迭代與升級的方式】，還是那一個個 issue，都能夠證明筆者、筆者的隊友以及其他選擇這門課程的同學們，對此都是用心了的。
而至於編程本身，不得不說，能夠再度重新體驗一下 java 的感覺還是非常不錯的，特別是實現還是文件系統這樣一個很全面的產品，其中復雜的邏輯對於個人的編程水平也是一個比較大的考驗。
團隊項目
團隊項目要考察的能力就是全方位的了：文檔、編程這些都是基本功，還有在其上的設計、宣傳，以及PM所額外需要具備的把控全局的能力等等，不一而足。
至於感想，這里就直接引用 beta 階段的團隊總結里的內容了。
伴隨着烤漆的鍾聲與一門門課大作業 ddl 的結束，軟工 beta 階段的開發也就此終於落下帷幕。
如果把 alpha 階段比作是在一片白茫茫荒漠中摸索出一條大致的路來，那么 beta 階段就是要努力讓這條路變得更寬更廣，讓更多的人能夠走上這條我們開創的路，並能夠收獲更美麗的風景。
在 beta 階段的開發中，我們在 alpha 里積累的所有優良傳統（比如全線下meeting，kanban法沖刺等）都得到了很好的保留；同時，更令人欣慰的，是團隊中的每一個人都最終找到了自己合適的定位，在這樣的一個項目里做着自己感興趣的那部分工作，發揮自己的長處，幾乎是不求回報地想要把自己的那份工作做到最好，做到極致。
這一切，作為PM的我(tcy)，全程都看在了眼里。我記得，小樹不斷地將前端的 UI 界面進行反復優化與重構，只求為用戶提供最絲滑的使用體驗；我記得，Mokoghost為了實現詞圖中單詞移動的動態效果，親自手寫了最底層的動畫播放邏輯；我記得，潛行的螞蟻對於主頁、教程的反復打磨，以及在宣發時的不遺余力；我還記得，圓那超強的執行力以及不怕苦不怕累的擔當和責任感；還有Potassium對於核心算法的實現與數據的爬取做出的無可替代的貢獻……
類似的故事還有很多很多，多到足以讓我堅定不移地相信，我們團隊里的任何一個人，放到外面的任何一個地方，都能做到獨當一面，都能一人撐起一個甚至多個部門，都能成為未來IT行業的超級精英。
回到軟件本身上來，可以說，beta 版本的『近取Key』已經幾乎實現了我們在 alpha 開發伊始所能設想到的全部的功能，『記憶宮殿』、『A4紙背單詞』這些最核心的創意與邏輯均已得到了淋漓盡致地展現，此外還增加了諸如自定義加詞、智能推薦等等意料之外的功能。但是，這還不能說它已經足夠完美了，只能說這是我們6個人在短短2個月時間內，在無數烤漆裹挾下，在極有限的資源加持下，所能交出的一份最好的答卷。
但是，這絕不是這個軟件本身所能達到的最完美的形態。
無論是從軟件本身的可維護性、安全性、跨平台兼容性，還是從用戶體驗視角下使用的流暢性、健壯性、交互友好性，抑或是從商業視角下的盈利能力、宣發能力，我們和它都還有很長很長的一段路要走；甚至也許，這條由我們親自開辟的路，永遠也不會有所謂的盡頭。
畢竟，對我個人而言，團隊項目帶給我最大的收獲，就是有幸遇見了優秀的你們呀。