【軟工做業&思考】關於軟工的一些概念性理解暨第一次閱讀做業

概述

項目	內容
本次做業所屬課程	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	一、功能齊全 二、支持各類複雜狀況的代碼管理 三、與現代開發中的團隊協做相性優秀 四、主流版本控制，各大網站支持豐富	一、原生git爲純命令行，對新手不算太友好
svn	一、圖形界面 二、與windows相性良好	一、圖形界面（沒錯，這也是缺點） 二、功能面不如git，沒有git同樣高的可玩性 三、總體生態遠遠不如git
Github	一、開源代碼多，羣衆基礎強大 二、操做簡單，即上即用	一、（天朝限定）速度慢 二、私有倉庫是收費的
BitBucket	一、私有倉庫無限制 二、功能豐富，專爲團隊開發設計	一、（天朝限定）速度慢 二、沒有太多開源代碼（至少遠遠比不上github） 三、代碼閉源
Gitlab	一、代碼開源，自行安裝，自行配置 二、完善的團隊協做支持 三、（天朝限定）速度快 四、完美的ci支持	一、私有的gitlab基本不存在開源代碼二、免費版只提供部分功能