項目
内容
本次作業所屬課程
2019BUAA軟體工程 周二班
本次作業要求
第1次個人作業
當然，比這個更重要百倍的還是實實在在的思考，這也是标題如此命名的原因
我在本課程的目标
在原有實踐經驗的基礎上，系統化學習軟工領域的理論知識，總結以前以及現在的得與失，提高自身知識水準（怎麼一股生命在流逝的味道）
本次作業的幫助
将《建構之法》與實際經驗進行結合
好吧，既然是概述，那麼就先說點什麼，光一個表格個人感覺表現力太有限了。如果對筆者的自報家門沒啥興趣的話，可以直接跳到下一節。
首先，本人很早就有計算機方面的技術背景（早到什麼程度呢，我學程式設計那會，Google在大陸還能直接上，QQ号還都是8位的），在程式設計方面，私以為還算是略知一二，或者說有那麼一點點的經驗。
其次，本人在大一開始就進行過實用系統的開發，其中包括：
Questionor刷題網站（連結：https://questionor.cn，現在每屆北航學子刷航概題還都在這上面）
同袍APP（最懂北航學子的手機app，不過現在出于一些複雜原因暫時無法使用）
若幹以賺錢為目的的外包項目（大概，在大一就能綽綽有餘的cover掉包括學費在内的一切個人支出）
嘛。。。先打住，再這樣下去實在有點像是産品軟文了。[捂臉]
此外，筆者帶過不止一個技術開發團隊，作為團隊的leader。踩過坑，也從屎山裡面爬出來過；勝利過，也失敗過；團隊裡大家一塊嗨過，也層不止一度出現嚴重分歧，甚至分崩離析過。其中，私以為還算是有一點點略微的心得。
說這些的目的呢，其實特别簡單。筆者從沒認為自己如何如何，隻是闡述一下客觀事實，做一些微小的工作，或者說，鋪墊。以防止下面看到有些内容的時候，被認為是在分享剛編的故事。
好了打住，先說到這。下面是正文。
其實說來，本人的疑惑和思考可能和大部分同學有些不一樣。是以我就盡量按照我的方式來表達，并且可以的話也說一些我對其他同學疑惑的了解吧。
PM做開發和測試之外的所有事情
這話确實很有道理，說的也沒錯。（或者倒不如說，非技術背景出身的PM也沒辦法插手這事）
然而，要是，PM也是技術背景出身，甚至還是有一定經驗的技術人員呢？
筆者自己就遇到過類似的情況。
在筆者之前早期帶的團隊裡面，就是會出現有的時候全體進展緩慢的情況。這個其實也正常，都是身邊的同學，不是誰都有寫過十幾年的代碼的。
于是，尤其是ddl迫近的時候，筆者我當時遇到這樣的情況，常常自己就看不下去了。一拍腿，老子自己上。
果不其然，自己一上陣，問題最終就很快被解決了。
如果隻從結果的角度來看，這當然是皆大歡喜——這世上從來就沒有過啥好手段壞手段，能解決問題的就是最好的。
對于臨時的小隊伍來說，這還算好，最起碼結果是好的。然而之後發生的事情證明，這種做法對于長期的團隊來說，是非常危險的。
筆者帶過的一個團隊，當時就這麼幹的。期初幾次，筆者一個人單挑的成效都很不錯。越到後來，就發現大家都開始起不到作用。筆者甚至一度很生氣，去質問過他們，甚至逼過他們。可是最終，筆者得出了一個令人絕望的答案——他們真的啥也不會了。
或者換句話說，在該鍛煉隊伍成員，該磨合團隊協作模式的時候，這些事情一樣都沒有做。最終，這個所謂被稱之為團隊的東西，完全成了由一個強力單體，和若幹起不到任何作用的人，構成的烏合之衆。對于強力單體，看似有團隊，實則孤立無援，最終遲早被硬生生累垮。對于其他人，看似有團隊，實則毫無歸屬感，自然不可能願意賣力，就算願意，也并不能真正的幫上忙。
這還不算完，如果有一天，這個團隊的強力單體出現了狀況的話，那麼，這個所謂的團隊，會立刻面臨滅頂之災，且毫無自保的能力。
這樣的故事其實曆史上已經上演過無數次：
諸葛亮鞠躬盡瘁，死而後已。他在的時候，把三國中最弱的蜀國治理的井井有條。然而他事必躬親，于是導緻的局面就是，其他不如他的人才完全沒有成長的空間。等他一死，蜀國一下子就出現了嚴重的人才斷層。很快，蜀國就滅亡了。
月廚們都知道，Saber生前的經曆。甘願當聖人，想要一己之力拯救臣民。然而等有一天光輝不再的時候，就注定要面臨生命中的卡姆蘭之丘，内心無比挂念的臣民也一樣得不到任何拯救。
是以，個人認為。就算PM，或者說上司，有着極強的個人輸出能力，也絕對不可以随随便便就親自上陣（當然，偶爾救急可以，但是絕不可以成為常态）。不是因為什麼上司的架子，而是出于整個團隊的可持續發展考慮。
不過，這裡面具體的分寸，也确實是一個值得深思的問題。從一碗雞湯爬出來，立馬跳進另一碗雞湯，也不是正确的思考問題方式。筆者也認為，自己目前這塊實際上做得還遠遠不夠成熟。
問題源自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）的概念，提出把軟體開發從“藝術”和“個體行為”向“工程”和“群體協同工作”轉化。其基本思想是應用計算機科學理論和技術以及工程管理原則和方法，按照預算和進度，實作滿使用者要求的軟體産品的定義、開發、釋出和維護的工程。從此也誕生了一門新的學科——軟體工程。軟體工程這門學科算是正式誕生了。
1945年9月，美國海軍程式設計員、編譯器的發明者格蕾斯·哈珀正帶着他的小組構造一個叫“馬克二型”的計算機。這個計算機使用了大量的繼電器， 一種電子機械裝置。雖然已進入9月，但天氣依然炎熱，房間裡沒有空調， 所有窗戶都敞開散熱。為了早日将“馬克二型”構造完成，格蕾斯·哈珀帶着小組成員夜以繼日的工作。
所謂好事多磨，在9月9日下午三點，電視劇情節般的意外如期而至。突然，“馬克二型”當機了，而技術人員嘗試了許多方法，最後才定位到第70号繼電器出錯。要知道，“馬克二型”用了1萬7千多個繼電器。
既然找到是70号繼電器出錯了，那麼接下來的事情也就好辦了。格蕾斯·哈珀仔細觀察這個出錯的繼電器，然後發現一隻被繼電器打死了的飛蛾躺在中間。于是格蕾斯·哈珀小心的用鑷子将飛蛾夾出來，用透明膠布将飛蛾貼到“事件記錄本”中，并注明“第一個發現Bug的執行個體”。
沒錯，世界上第一個BUG，還真就是一直蟲子。
千年蟲問題（摘自百度百科）：
計算機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、功能豐富，專為團隊開發設計
2、沒有太多開源代碼（至少遠遠比不上github）
3、代碼閉源
Gitlab
1、代碼開源，自行安裝，自行配置
2、完善的團隊協作支援
3、（天朝限定）速度快
4、完美的ci支援
1、私有的gitlab基本不存在開源代碼
2、免費版隻提供部分功能