概述
| 項目 | 內容 |
|---|---|
| 本次作業所屬課程 | 2019BUAA軟件工程 週二班 |
| 本次作業要求 | 第1次個人作業 當然，比這個更重要百倍的還是實實在在的思考，這也是標題如此命名的原因 |
| 我在本課程的目標 | 在原有實踐經驗的基礎上，系統化學習軟工領域的理論知識，總結以前以及現在的得與失，提高自身知識水平（ |
| 本次作業的幫助 | 將《構建之法》與實際經驗進行結合 |
好吧，既然是概述，那麼就先說點什麼，光一個表格個人感覺表現力太有限了。如果對筆者的自報家門沒啥興趣的話，可以直接跳到下一節。
首先，本人很早就有計算機方面的技術背景（早到什麼程度呢，我學編程那會，Google在大陸還能直接上，QQ號還都是8位的），在編程方面，私以爲還算是略知一二，或者說有那麼一點點的經驗。
其次，本人在大一開始就進行過實用系統的開發，其中包括：
- Questionor刷題網站（鏈接：https://questionor.cn，現在每屆北航學子刷航概題還都在這上面）
- 同袍APP（最懂北航學子的手機app
，不過現在出於一些複雜原因暫時無法使用） - 若干以賺錢爲目的的外包項目（大概，在大一就能綽綽有餘的cover掉包括學費在內的一切個人支出）
嘛。。。先打住，再這樣下去實在有點像是產品軟文了。[捂臉]
此外，筆者帶過不止一個技術開發團隊，作爲團隊的leader。踩過坑，也從屎山裏面爬出來過；勝利過，也失敗過；團隊裏大家一塊嗨過，也層不止一度出現嚴重分歧，甚至分崩離析過。其中，私以爲還算是有一點點略微的心得。
說這些的目的呢，其實特別簡單。筆者從沒認爲自己如何如何，只是闡述一下客觀事實，做一些微小的工作，或者說，鋪墊。以防止下面看到有些內容的時候，被認爲是在分享剛編的故事。
好了打住，先說到這。下面是正文。
個人的思考
其實說來，本人的疑惑和思考可能和大部分同學有些不一樣。所以我就儘量按照我的方式來表達，並且可以的話也說一些我對其他同學疑惑的理解吧。
思考一：PM做開發和測試之外的所有事情
PM做開發和測試之外的所有事情
這話確實很有道理，說的也沒錯。（或者倒不如說，非技術背景出身的PM也沒辦法插手這事）
然而，要是，PM也是技術背景出身，甚至還是有一定經驗的技術人員呢？
筆者自己就遇到過類似的情況。
在筆者之前早期帶的團隊裏面，就是會出現有的時候全體進展緩慢的情況。這個其實也正常，都是身邊的同學，不是誰都有寫過十幾年的代碼的。
於是，尤其是ddl迫近的時候，筆者我當時遇到這樣的情況，常常自己就看不下去了。一拍腿，老子自己上。
果不其然，自己一上陣，問題最終就很快被解決了。
如果只從結果的角度來看，這當然是皆大歡喜——這世上從來就沒有過啥好手段壞手段，能解決問題的就是最好的。
對於臨時的小隊伍來說，這還算好，最起碼結果是好的。然而之後發生的事情證明，這種做法對於長期的團隊來說，這是一件非常危險的事。
筆者帶過的一個團隊，當時就這麼幹的。期初幾次，筆者一個人單挑的成效都很不錯。越到後來，就發現大家都開始起不到作用。筆者甚至一度很生氣，去質問過他們，甚至逼過他們。可是最終，筆者得出了一個令人絕望的答案——他們真的啥也不會了。
或者換句話說，在該鍛鍊隊伍成員，該磨合團隊協作模式的時候，這些事情一樣都沒有做。最終，這個所謂被稱之爲團隊的東西，完全成了由一個強力單體，和若干起不到任何作用的人，構成的烏合之衆。對於強力單體，看似有團隊，實則孤立無援，最終遲早被硬生生累垮。對於其他人，看似有團隊，實則毫無歸屬感，自然不可能願意賣力，就算願意，也並不能真正的幫上忙。
這還不算完，如果有一天，這個團隊的強力單體出現了狀況的話，那麼，這個所謂的團隊，會立刻面臨滅頂之災，且毫無自保的能力。
這樣的故事其實歷史上已經上演過無數次：
- 諸葛亮鞠躬盡瘁，死而後已。他在的時候，把三國中最弱的蜀國治理的井井有條。然而他事必躬親，於是導致的局面就是，其他不如他的人才完全沒有成長的空間。等他一死，蜀國一下子就出現了嚴重的人才斷層。很快，蜀國就滅亡了。
- 月廚們都知道，Saber生前的經歷。甘願當聖人，想要一己之力拯救臣民。然而等有一天光輝不再的時候，就註定要面臨生命中的卡姆蘭之丘。
所以，個人認爲。就算PM，或者說領導，有着極強的個人輸出能力，也絕對不可以隨隨便便就親自上陣（當然，偶爾救急可以，但是絕不可以成爲常態）。不是因爲什麼領導的架子，而是出於整個團隊的可持續發展考慮。
不過，這裏面具體的分寸，也確實是一個值得深思的問題。從一碗雞湯爬出來，立馬跳進另一碗雞湯，也不是正確的思考問題方式。筆者也認爲，自己目前這塊實際上做得還遠遠不夠成熟。
思考二：Bug的定義
問題源自guzhanpeng同學的博客。第一個疑問，裏面說到了bug的定義問題。
首先我想說的是，Bug本身就不是一種單一的定義。
這位同學百度搜索到的結果是：
程序錯誤（英語：Bug），是程序設計中的術語，是指在軟件運行中因爲程序本身有錯誤而造成的功能不正常、死機、數據丟失、非正常中斷等現象
這個當然沒有錯，這個是程序設計意義上的bug。
然而，實際上從用戶、從需求的角度來說，不符合需求的，就是bug。這個bug是產品需求意義上的bug。這兩者並不存在矛盾抑或是衝突。
或者也可以說，bug可以一般性定義爲和期望不符的狀態及其誘因：
- 對於程序而言，結果錯誤、運行時錯誤、崩潰，這確實就是和期望的正確結果不符的狀態。
- 對於產品而言，你程序就算對了，但是人家要個蘋果你給人家運來一車梨，還美其名曰梨很好吃我們也很辛苦，這顯然就是在扯淡了。沒錯，這也是與期望狀態不符的狀態。
綜上，其實所謂bug的兩種定義（當然，也可能有更多的層面），本質還是統一的，只是站在了不同的需求立場上而已。前者是程序層面的正確，後者是產品層面的更優。根本上，BUG與否，還是取決於想要的是什麼。
思考三：領頭羊是否必要
17.1 “領導力”中，強調了團隊領導的重要性。聯想到即將開始的團隊編程，領導該如何確定？很可能出現兩種情況：一種是團隊裏有個大牛，由於他的技術最好，大家都聽他的。另一種是大家互相討論，少數服從多數，實際上沒有一個真正的領導。實際上，由於大家都是技術人員，對項目方向上的把控水平可能都差不多，所以我認爲沒有領導的小團隊，應該也是可以的吧？
這個是來自於Jason同學的問題。
先說結論，要，而且非常重要。然後，請聽我慢慢分析。
這位同學的觀點中，有這麼一句
團隊裏有個大牛，由於他的技術最好，大家都聽他的
這句話本身也是錯的。錯的原因，思考一中已經有了詳細的說明。即便在決策層面，要是決策權完全捆綁在了一個emperor的頭上，那麼這就像極了封建專制制度（沒有褒義或者貶義）——一人獨裁。
一人獨裁的好處是很明顯的，顯然這位同學也明白這個好處——只要這個leader足夠的靠譜。但是一人獨裁的壞處，其實和好處一樣的明顯——只要這個leader不夠靠譜，團隊的結局就註定只有滅亡。中國歷朝歷代無數的開國之君，和亡國之君，他們都已經用他們一生的經歷，向後人證明了這件事。
那麼既然不應該一人獨裁，那麼，就應該絕對的民主麼？答案是否定的。
反面教材，其實也很好找——現在的很多歐美國家，也就是很多人口中“皿煮”的聖地，就會存在這樣的問題。是的沒錯，他們的三權分立、議會制，確實在權利的制約平衡上做的相當不錯。
然而這樣也帶來了新的問題。俗話說得好——屁股決定腦袋。各方的立場與利益不太可能總是一致，既然不一致，那麼在這樣的體制下，不同勢力之間的通力協作將變得幾乎不可能，反而完全變成了權力的博弈戰，內耗極其嚴重。
在人的團隊中，雖然沒那麼複雜，但是大致道理也是類似的——如果一個團隊，沒有一個明確的領頭羊的話，那麼這個團隊的秩序將是很大的問題。而秩序，則對於達到團隊最優解而言，是至關重要的。簡而言之，如果一個團隊裏面，僅僅是因爲所有人水平都差不多就所有人地位絕對一致的話，那麼帶來的後果就是團隊工作的協調和調度上將會變得極爲困難，甚至出現集體負責，等於集體不負責的情況。遇了事情，意見不一，始終沒人拍個板，也是一件非常麻煩的事。
就筆者本身而言，筆者也曾在整體實力較強的團隊裏面待過（在那個團隊裏面，幾乎所有人都有和筆者差不多少的實力），然而那個團隊依然是有個leader的存在，統籌規劃着整個團隊的事務進展，一板一眼調配着資源。其他人也都參與決策，各抒己見，但是猶豫不決之時，一定是leader拍板。
綜上，我的結論是，領頭羊是必要的，但是也不可以搞成整個團隊只有唯一的領頭羊參與決策。民主是必要的，但是過度的民主還不如專制來的靠譜。
思考四：編程之法
只要有助於程序邏輯的清晰體現，什麼方法都可以使用，包括goto。
這話，在現在看起來是個政治不太正確的話，尤其是在這個已經廣泛推薦使用結構化程序設計的年代，這聽上去似乎確實像是歷史的倒退。
然而，這句話的本質確實對的。
看到有些同學認爲這話不對，其實我覺得，他們只是沒有理清楚因和果的關係。
首先，在軟件開發的蠻荒時代，先輩們之所以提出了結構化程序設計，原因就是，不結構化的話，程序質量將變得難以保證，工程項目也將難以維護。於是指定了一個標準，供後人參考。
然而，不要忘了，這個標準的意義在於，讓軟件質量變得更好。而不應該是反過來的。
早在先秦，商鞅便說過
治世不一道，便國不法古。
任何的法度，任何的規則，其根本目的都只有一個——追求最優地解決問題。
而如果死搬教條，卻反而忽視了問題的本質，走的太遠忘了爲啥而出發的話，那就是買櫝還珠的笑話了。
思考五：豬、雞和鸚鵡的故事
加入一個團隊時，要弄清楚自己在團隊中投入的級別是什麼，別人的期望值是什麼。不要拿着賣白菜的錢，操那賣白粉的心——太不值得。
這句話，其實是大實話，也是筆者認爲很多同齡人始終沒想明白的一件事。
實際上某種程度，團隊成員和團隊的關係，與軟件產品和甲方的關係，還是頗爲類似的——前者是賣家，後者是買家。前者買賣的是生產力（以及潛在的價值），後者買賣的是產品本身。本質上，都不過是供求關係而已。
正如上文中關於bug的論述
人家要一個蘋果，你給人家拉來一車梨，縱使你說這梨子如何如何好吃我們如何如何辛苦，可是你就是沒給人家需要的東西，那就是扯淡。
沒錯，如果你提供的東西，其實並不是人家所需要的，那麼你對於人家而言的價值就是零。如果你甚至還認爲自己勞苦功高，認爲人家有義務把你當大爺一樣的供着，那就不僅是沒價值，還會惹人生厭了。
這些話，看上去很政治不正確。實際上，每一個真正當過技術團隊的leader，辦過實事，招過兵買過馬的leader，都會明白這句話的含義。（筆者曾經招過一些“學霸”進自己的小團隊，然而後來發現這人考試能力是不差，可是給團隊幾乎帶不來什麼效益，甚至可以說幹啥啥不行。不僅如此，還自視甚高，認爲是我們團隊對不起他。這樣的人，用上面的話說，他們對於應試教育而言，是完美的。但是他們對於技術團隊而言，那真的就是除了BUG一無所有了。）
其實這些車軲轆話說來說去，根本矛盾還是供求關係。筆者認爲，這個問題也是軟件工程，甚至是整個產業界，的根本問題之一。
顯然，從團隊成員角度，確實是應該好好掂量對方對自己的期望的：
- 如果對方對你期望很高，你卻實際上根本不可能辦到，那麼即便人家給你開價再高，你也最好走爲上策，這是做人最基本的素質。
- 如果對方對你期望很低，而你實際上可以創造比這個高的價值的話，那麼筆者認爲：
- 你可以想辦法讓leader（或者甲方）認同你的價值，然後一起創造更大的價值
- 如果上一條行不通，那麼根據筆者的經驗，你*給他們想要的就好了（筆者之前就遇到過難以溝通的需求甲方）
- 當然，如果實在不爽的話，也可以選擇跳槽。既然沒機會兼濟天下，那麼獨善其身也可以作爲次級的選擇。
從團隊的角度，那麼該做的是這樣的：
- 盡力去觀察團隊成員，和他們多溝通，瞭解他們切實的需求，然後，儘量給他們想要的（這很重要，供求關係，實際上也應該是雙方面的，各取所需的合作關係纔有穩定的可能）
- 如果溝通了，發現這樣的人真的沒有價值的話（當然也可能只是對我們團隊沒用），那麼也沒必要強留，看着辦即可（當然，條件允許的話也可以先留着，畢竟多條人脈總有用得着的時候）
以上，就是筆者對團隊內供求關係的理解。
軟件的起源
- 化學家和統計學家約翰·圖基（John W. Tukey）在1958年撰寫一篇科學文章時，首次使用“軟件”這一術語。據報道，他早在1953年就已經提出這個詞，用來標記計算機程序（即“軟件）與使用這些程序的計算機（或“硬件”）之間的區別。軟件的概念被提出。
- 軟件工程的最初概念，是1968年Margaret Hamilton在阿波羅計劃期間提出來的。軟件，開始和工程接軌。
- 1968年NATO會議上首次提出“軟件工程”（Software Engineering）的概念，提出把軟件開發從“藝術”和“個體行爲”向“工程”和“羣體協同工作”轉化。其基本思想是應用計算機科學理論和技術以及工程管理原則和方法，按照預算和進度，實現滿用戶要求的軟件產品的定義、開發、發佈和維護的工程。從此也誕生了一門新的學科——軟件工程。軟件工程這門學科算是正式誕生了。
冷知識、趣聞
世界上第一個BUG
1945年9月，美國海軍編程員、編譯器的發明者格蕾斯·哈珀正帶着他的小組構造一個叫“馬克二型”的計算機。這個計算機使用了大量的繼電器， 一種電子機械裝置。雖然已進入9月，但天氣依然炎熱，房間裏沒有空調， 所有窗戶都敞開散熱。爲了早日將“馬克二型”構造完成，格蕾斯·哈珀帶着小組成員夜以繼日的工作。
所謂好事多磨，在9月9日下午三點，電視劇情節般的意外如期而至。突然，“馬克二型”死機了，而技術人員嘗試了許多方法，最後才定位到第70號繼電器出錯。要知道，“馬克二型”用了1萬7千多個繼電器。
既然找到是70號繼電器出錯了，那麼接下來的事情也就好辦了。格蕾斯·哈珀仔細觀察這個出錯的繼電器，然後發現一隻被繼電器打死了的飛蛾躺在中間。於是格蕾斯·哈珀小心的用鑷子將飛蛾夾出來，用透明膠布將飛蛾貼到“事件記錄本”中，並註明“第一個發現Bug的實例”。
沒錯，世界上第一個BUG，還真就是一直蟲子。
千年蟲問題與2038危機
千年蟲問題（摘自百度百科）：
計算機2000年問題，又叫做“千年蟲”、“電腦千禧年千年蟲問題”或“千年危機”。縮寫爲“Y2K”。是指在某些使用了計算機程序的智能系統（包括計算機系統、自動控制芯片等）中，由於其中的年份只使用兩位十進制數來表示，因此當系統進行（或涉及到）跨世紀的日期處理運 算時（如多個日期之間的計算或比較等），就會出現錯誤的結果，進而引發各種各樣的系統功 能紊亂甚至崩潰。因此從根本上說千年蟲是一種程序處理日期上的bug（計算機程序故障），而非病毒。
2038危機（摘自百度百科）：
也許大家都已經知道計算機的2000年問題是什麼概念，但是什麼時候又冒出來一個2038年問題的呢？
用C語言編制的程序不會碰到2000年問題，但是會有2038年問題。這是因爲，大多數C語言程序都使用到一個叫做“標準時間庫”的程序庫，這個時間庫用一個標準的4字節也就是32位的形式來儲存時間信息。
當初設計的時候，這個4字節的時間格式把1970年1月1日凌晨0時0分0秒（這個時間名叫 the Unix Epoch）作爲時間起點，這時的時間值爲0。以後所有的時間都是從這個時間開始一秒一秒累積得來的。
比方說如果時間已經累積到了919642718這個數值，就是說這時距離 the Unix Epoch已經過去了919642718秒，換算一下就應該是1999年2月21日16時18分38秒。
這樣計算時間的好處在於，把任意兩個時間值相減之後，就可以很迅速地得到這兩個時間之間相差的秒數，然後你可以利用別的程序把它換算成明白易懂的年月日時分秒的形式。
要是你曾經讀過一點兒關於計算機方面的書，你就會知道一個4字節也就是32位的存儲空間的最大值是2147483647，請注意！2038年問題的關鍵也就在這裏———當時間一秒一秒地跳完2147483647那驚心動魄的最後一秒後，你猜怎麼樣？
答案是，它就會轉爲負數也就是說時間無效。那一刻的準確的時間爲2038年1月19日星期二凌晨03:14:07，之後所有用到這種“標準時間庫”的C語言程序都會碰到時間計算上的麻煩。
這就是2038年問題。
其實，這類的問題還有很多：
- 曾經，現代計算機之父馮諾依曼，表示在計算機上編寫程序是沒有意義的事情，應當花時間在硬件上。然後，軟件時代就到來了。
- 曾經，比爾蓋茨表示，64KB內存足以應對世界上一切的程序需求。然後，2000年前後的內存都是上百MB的級別。
- 曾經，人們認爲，兩位十進制數表示年份，肯定是夠的。然後，2000年如期而至。
- 曾經，人們也以爲，timestamp弄個C語言的int32類型，就鐵定夠用了。然後，2038年也不遠了。
- 曾經，人們也認爲，MD5是永久堅不可催的。然後，現在的MD5在存儲海量數據的撞庫面前根本不堪一擊，用MD5加密的網站密碼，已經屬於可以輕鬆破解的類型了。
於是乎，在歷史的進程下，之後人們還會面對哪些曾經呢？讓我們拭目以待吧。
項目管理軟件
| 軟件 | 優點 | 缺點 |
|---|---|---|
| git | 1、功能齊全 2、支持各種複雜情況的代碼管理 3、與現代開發中的團隊協作相性優秀 4、主流版本控制，各大網站支持豐富 |
1、原生git爲純命令行，對新手不算太友好 |
| svn | 1、圖形界面 2、與windows相性良好 |
1、圖形界面（沒錯，這也是缺點） 2、功能面不如git，沒有git一樣高的可玩性 3、整體生態遠遠不如git |
| Github | 1、開源代碼多，羣衆基礎強大 2、操作簡單，即上即用 |
1、（天朝限定）速度慢 2、私有倉庫是收費的 |
| BitBucket | 1、私有倉庫無限制 2、功能豐富，專爲團隊開發設計 |
1、（天朝限定）速度慢 2、沒有太多開源代碼（至少遠遠比不上github） 3、代碼閉源 |
| Gitlab | 1、代碼開源，自行安裝，自行配置 2、完善的團隊協作支持 3、（天朝限定）速度快 4、完美的ci支持 |
1、私有的gitlab基本不存在開源代碼 2、免費版只提供部分功能 |