| 項目 | 內容 |
|---|---|
| 這個作業屬於哪個課程 | 北航 2022 春季敏捷軟件工程 |
| 這個作業的要求在哪里 | 作業說明鏈接 |
| 我在這個課程的目標是 | 學習現代軟件工程開發的模式，鍛煉團隊協作開發的能力 |
| 這個作業在哪個具體方面幫助我實現目標 | 通過閱讀《構建之法》了解現代軟件工程概念 調研 Git 托管平台以及 CI/CD 的使用 |
《構建之法 - 現代軟件工程》讀后提問
閱讀后發現這實在是一本很有意思的書，讓我找回來以前看科普書的樂趣，同時其中實打實的內容也引發了我很多對於軟件工程開發的思考。
“技能”比“解決問題”更重要嗎？
技能的反面是 “Problem Solving”
作者在文中提出說“通過不斷的練習，把那些低層次的問題都解決了，變成不用經過大腦的自動操作，然后才有時間和腦力來解決較高層次的問題。”對於這一點我還是非常認同，但是對於作者在文中推崇先解決“低層次問題”，我仍然有一點相反的意見：在我看來，在一些情況下這種“解決低層次的問題”未必比學習“解決問題的方式”更重要，在技術發展日新月異的今天尤為如此。
舉一個簡單的例子：例如學習網頁開發，在十五年前某個人學習網頁開發時，可能會花很大精力在 Flash 上，因為 Flash 在當時能做出令人驚艷的動畫效果，並且在許多網站中都大量運用了 Flash。但是在 2022 年的今天，我們卻很難再見到 Flash 技術的應用了，因為這項技術已經被掃入歷史的垃圾堆了（當然，Flash 在當時本身是一項不錯的技術）。同理類似有微軟開發的 Fox Pro，在今天也被遺棄了。那么學習熟練解決這種“低層次的”的技能真的還要那么大的價值嗎？再如從前一個人能熟練地背誦庫中的各種 API，但是在當下這個 IDE 技術迅速發展的今天真的有用嗎？
對此，我認為在目前這個技術迭代飛速的時代，尤其是在互聯網這個領域，“技能”或許本身的重要性沒有以前來的大了，反而“解決問題”本身更能適應當前時代的發展。
對於技術而言，“精通”比“全棧”更重要嗎？
作者在文中用“單人樂隊”與“樂手”舉例，想說明我們應當精通某一樣技術，而不是做一個泛泛的“全棧工程師”。然而實際上僅僅精通某一項單獨的技能已經不足以滿足現實的需求了。盡管現代軟件工程利用“封裝”等思想大大簡化了開發的難度，但是在開發的過程中，人們仍然會不時地遇到一些只了解單個領域就無法解決的問題，此時往往需要一名了解多個領域的“全棧工程師”的幫助。
事實上，現在越來越多的領域正在成為交叉的領域，這一點在人工智能技術飛速發展的今天顯得尤為明顯。除了在研究人工智能理論的一小部分人外，大多數人聚焦在如何使用人工智能技術為現有的領域提供更好的支持，這使得人工智能成為了一個非常廣闊的一個交叉領域，許多大學中也開辦了許多面向這種交叉學科的專業，例如“智能制造”等。一名工程師往往需要將某樣技術應用到現實生活中來，這樣的技術可能是某一樣非精通的“技能”，也可能是某一樣精通的“專業”。優秀的工程師需要同時具備技術的深度與技術的廣度。
結對編程是否對結對者的水平差異提出了更高要求？
只有水平上的差距，沒有級別上的差異。盡管可能大家的級別資歷不同，但不管在分析、設計或編碼上，雙方都擁有平等的決策權利。
在書中作者介紹了許多結對編程的好處，例如減少 bug、提高工作效率、提高解決問題的能力等。同時作者推薦結對編程時不需要過於注意兩個人水平上的差距，認為雙方具有同等的決策權力。
但是在各種編程概念（例如 Go 語言中的協程、Rust 語言中的 Linear Type）和編程范式（例如函數式編程）的今天，兩個人水平上的差距是否愈發是結對編程中不可忽視的重要影響因素之一呢？尤其是在函數式編程中（例如 Haskell 或者 Scala 等語言），往往會用比較抽象的組合子對問題進行建模，而這一點是非常依賴於編程者的函數式水平的。如果兩個人水平上差距過大，很有可能會經常出現一個人不斷詢問另一個人某段代碼的含義。誠然，在某種意義上這可以幫助開發者盡早發現自己代碼中的 bug，但是我認為這對於開發進度的拖慢是不可忍受的。
軟件開發中的重大決策應該由“豬”來定奪嗎？
在遵循敏捷原則的團隊里, 成員們並不忌諱談論不同的投入和負責程度 - 因為這就是現實。 但是他們一般有一個原則:
重大決定由 “豬” 來定奪。
作者在這篇文章中將項目人員按照投入程度分為了豬、雞、鸚鵡三種，並提出“應該讓研發和市場第一線全心投入的‘豬’來定奪重大決策”。但是在實際的生產當中，豬未必適合這個位置。
例如在某個開發團隊中，“開發人員”是團隊中“豬”的角色，他們為團隊編寫關鍵代碼，並且全力投入。那么在這個團隊中應當由“豬”來引導產品發展方向嗎？實際上，在一個團隊的分工中，其他角色也占用很重要的位置，例如市場調研的人員往往可以比開發人員先一步了解市場變化的動向，因此他們也往往能夠更清楚地把握市場風向。盡管他們在投入上可能並不如開發人員，但是由他們進行決策可能更加科學。
另一方面，需求調查和團隊管理一樣都是十分專業的任務，需要交給專業的人來完成。盡管某個開發人員非常投入，但是他未必能夠勝任這樣的角色；反之，盡管某個成員在團隊中承擔着“雞”的角色，但是他做專業的事也未必不如外行的“豬”。因此我認為這里僅僅按照這個方面划分團隊人員有點粗暴了。
軟件開發時應當由 PM 負責分解需求嗎？
一個團隊項目要在一段時間內完成諸多任務，滿足用戶的需求，實現團隊的目標，同時還希望項目能維持良好的技術架構，以便持續開發，千頭萬緒，從哪里人手? 一隊人馬站在項目的“需求”前，就像愚公和家人站在王屋山前一樣，他們可能都在想：這座山到底要花多少時間才能搬走呢？這時候我們需要一個角色站出來領導大家，把看似巨大無從下手的項目逐步分解為可以操作的工作。PM 是責無旁貸的領導者。
在談到分解需求時，作者提出 PM 應當是“責無旁貸的領導者”。然而，在實際開發中，開發者可能會遇到各種技術層面上的困難，而這一點 PM 有可能是無法預料到的。因此如果簡單地讓 PM 成為項目需求的分解者，那么在項目管理和項目時間安排上極有可能出現估計錯誤的情況。
因此，我認為除非 PM 是一位有着豐富經驗的開發人員，而且對於開發的項目有着足夠的了解，那么這樣的 PM 有義務領導團隊進行任務規划。否則在分解任務時應該讓主力的開發人員與 PM 進行協商；否則，PM 的錯誤估計可能會導致項目的開發工作無法繼續進行。
設計用戶體驗時，如何把握用戶的需求而不造成體驗的割裂？
我們的PM/Dev/Test 在設計/實現/測試這個功能的時候想過目標用戶的英文水平是什么樣么? 他們需要哪個程度的英文解釋? 如果他們連 "a" 都不懂, 他們能來到你這個網頁搜索含有英文的結果么?!
作者在這里描述了必應搜索的“實時顯示英語解釋”，並指出在實際應用時，英文解釋無需顯示“a”“on”等簡單詞匯。但是應該如何掌控這個設計的尺度呢？
不同的人的英文水平可能是大不相同的，例如一個上網查找英文資料的小學生與一個托福 110 的大學生，二人對於英文單詞的學習進度也是不同的，如果軟件自作主張地取消一些詞的顯示，可能會造成體驗上的割裂感。那么在實際設計時，考慮到這一點該如何准確把握用戶的需求呢？
源代碼版本管理軟件調研
GitLab 和 GitHub 是目前世界上最流行的兩個基於 Git 的項目管理平台，因此我挑選了這兩個平台作為調研的對象。
相同點
首先，二者都基於版本控制軟件 Git，都可以托管 Git 倉庫的代碼，其代碼管理上的功能也大致相同：包括 clone，fork，pull request 等。二者都能部署 CI/CD，都有項目管理的功能，支持團隊協作開發。
除此之外，GitHub 和 GitLab 都是基於 Ruby on Rails 開發的，這一點非常有意思。這里我看了一篇 Gitlab 團隊寫的一篇博客。在這篇博客中，GitLab 團隊提到了以下幾點：
- Ruby 的生態非常豐富，可以大大減少開發的難度
- Rails 雖然速度沒有其他框架快，但是卻非常適合開發（
Ruby was optimized for the developer） - Rails 框架中的包管理得非常有條理，不會混亂（反面可能是 NPM）
不同點
首先，GitHub 是最早進行 Git 托管服務的平台之一。相比於其他代碼托管平台，GitHub 上面已經形成了一個非常龐大的社區。除了傳統的代碼托管服務外，GitHub 還提供了依賴檢測、片段分享等功能。現在的 GitHub 除了被當作代碼托管平台外，也漸漸成為了一個程序員的社交平台，發展成了類似於“Facebook”的存在。自從 2018 年微軟收購 GitHub 后，GitHub 被有些人詬病“商業化氣息過重”，但是借着微軟 GitHub 也開放了大量原先的會員功能（例如無限量的私有倉庫等）。目前的開源社區中，暫時還沒有能夠完全取代 GitHub 的托管平台和社交平台。
GitLab 是一個開源的項目管理平台，它的代碼管理功能和 GitHub 一樣，但是它允許用戶在自己的服務器上部署 GitLab 平台，這一優勢使得許多平台和企業選擇了 GitLab 作為內部托管平台。同時，GitLab 也是一個非常好用的 DevOps 平台，官方開放了大量 API 供開發者和維護人員使用，便於第三方在上面進行二次開發。（順便，北航的面向對象課程也使用了自建 GitLab 作為代碼托管平台，其中諸如“Impersonate”之類的功能真的非常好用）
持續集成/部署工具調研
GitLab CI 使用
在本節中，我嘗試使用 GitLab CI 來編譯我的編譯器。倉庫地址為 http://gitlab.oo.buaa.edu.cn/roife-personal/racoon 。
GitHub Action 使用
在本節中，我嘗試使用 GitHub Action 來編譯我的簡歷模板。倉庫地址為 https://github.com/roife/resume 。
對 CI/CD 工具的看法
我使用了 GitLab CI 和 GitHub Action 兩款 CI 工具，下面對二者進行分析：
- GitLab CI
- 特點：GitLab CI 在使用時需要指定一個用來運行的 runner，使用時需要在自己的設備上部署一個 runner 來跑相應的任務。好處是這個過程是高度可控的，使用者可以根據自己的需要來選擇 runner，而且可以自定義 runner 的配置（如使用 docker 等）。但是如果不是自己部署的 GitLab 服務器，則可能需要購買官方的 runner。
- GitHub Action
- 特點：GitHub Action 背靠 GitHub 廣大的資源社區以及微軟的資源，因此在使用體驗上要好於 GitHub Action，包括各種環境等。同時，GitHub Action 在限制內可以免費試用，因此對於學生黨或者購買有一定困難的國人來說非常方便。
| GitHub Action | GitLab CI | |
|---|---|---|
| 優勢 | 可以直接使用社區資源，方便快捷 | 自由度更高，有豐富的 API 進行控制 |
| 劣勢 | 可定制性沒有 GitLab CI 高 | 需要自己進行一定配置 |
| 適應的場合 | 社區開源項目 | 私有項目或保密項目 |