軟件工程第一次做業：寫一篇本身的博客

這個做業屬於哪一個課程	18級軟件工程基礎
這個做業要求在哪裏	第一次我的做業：閱讀與準備
我在這個課程的目標是	學會建立本身的博客以及Markdown的語法
其餘參考文獻	git優勢缺點
其餘參考文獻	Github的利弊分析
其餘參考文獻	GitHub、Bitbucket、Google Code 各有哪些優缺點？

我的介紹

「衣帶漸寬終不悔，爲伊消得人憔悴」

我是來自計科一班的陳攀文，我是一個開朗熱情，大膽敢於嘗試的人。熱愛編程，喜歡敲代碼的感受。加入了嵌入式團隊，目前正在進行後端方面的學習，主要學習的是Java後端。我以爲學習後端能讓我真正體會到一名程序員是什麼樣的，讓我可以有更多的機會去編寫代碼。能用代碼實現本身想作的東西能讓我得到成就感。但是拘於學習的東西還不夠，對於不少原理方面，底層方面的東西還不夠了解，但願在之後的學習中可以學到更多這方面的知識。有本身的域名，雖然東西還沒怎麼作，如今只有前端界面（前端仍是我女友給寫的，我就只買了個服務器配了個環境）可是歡迎你們來看看 點這裏
愛編程，可是我不太喜歡算法，雖然打心底我知道數據結構啊，算法啊是十分重要的，但是我還不太喜歡偏算法方面的東西。可是重要嘛，確定是要下功夫的，題仍是要刷的。

問題回答

（1）回想一下你初入大學時對你所在專業的暢想

當初你是如何作出選擇你所在專業的決定的？

小時候喜歡玩兒遊戲，對電腦接觸的比較多，因此對電腦有比較強烈的好奇心，想去更多的瞭解它的原理。計算機科學與技術這個專業也更可能是偏向計算機原理方面的，算是計科院裏面教授計算機原理比較多的一門專業，因此便選擇了這門專業。

你認爲過去一（兩）年中接觸到的課程是否符合你對你本身所在專業的期待，爲何？

比較知足本身的期待。在專業課中學習了C語言和數據結構。先學習一門語言能有助於後面其餘語言的學習；數據結構也是基礎中的基礎。代表學校對計科專業學生的基礎是十分重視的。包括從此將會學到的彙編語言，操做系統原理等等也證實了這一點。

你以爲你所在的專業是你喜歡的領域嗎，它是你擅長的領域嗎？

專業領域的話，我以爲計科專業更偏向硬件方面，由於後面會學嵌入式開發，其實我並非很喜歡偏硬件的東西，就像介紹中說到的，我更喜歡後端。由於還沒學嵌入式開發等等的東西，因此如今也還談不上擅長與否，可是我相信如今積累一些敲代碼的經驗，之後確定仍是會學的比較順利吧。

未來你會選擇從事和你專業相關的工做嗎？是的話給出你想去的城市、公司和崗位，否的話給出緣由

會從事，畢竟如今學計算機仍是比較好找工做吧，並且本身這些年又在這方面花了這麼多時間。我仍是想留在成都，公司的話還沒想好，崗位就後端工程師。

（2）對照前人們走過的路和描述將來發展，如今的你

自我感受你已經具有的專業知識、技能、能力有哪些？已經寫過的代碼量是多少？描述你作的最複雜的項目/做業。

能力的話確實太少了，除了所開的專業課，學了些Java，Java Web方面正在學，
目前可以用SSM框架作些簡單的後臺，但裏面的原理這些還不太清楚，打算去學習一下。 代碼量，若是寫的全部代碼都算的話，5000行應該是有，可是真正算是作東西的話，應該2000行左右吧。 最複雜的項目：C語言鏈表寫學生管理系統，寫的比較複雜（如今看來有的能夠簡化），並且由於當時初學鏈表，鏈表的各個操做也分開進行了不少測試和改進，最後寫了接近700行。 而後的話就是用JAVA Web的一些基礎操做去給一個前端界面接了後端，這個代碼量不是不少，主要涉及各個層，例如表現層業務層數據層之間數據的傳輸，因此對於初學者的我來講，仍是比較複雜。

離成爲一個合格的本科畢業生，在專業知識、技能、能力上還差距哪些？

那差的可就多了，彙編、數字邏輯、操做系統等等重要的課還沒開，本身也還沒開始學。Web方面像併發啊，各個框架的原理啊這些東西都還沒學，任重而道遠啊。

（3）目前是一我的生選擇的十字路口，考研、工做、考公、出國，不一樣的選擇在大三就有不一樣的努力方向。而不管考研仍是工做的每條路徑，也有許多不一樣的分支。

對照以上你閱讀的前人們的經歷，你的選擇是什麼？

我選擇工做。大多數人考研是爲了什麼，仍是爲了以後找工做。既然如今有機會有能力去作好，爲何非要考研去作呢，在本科就努力學好技術，畢業就業，我以爲更好。並且我以爲之後在工做中學到的經驗，可能會比讀研學到的更多吧。

在這種選擇下，你認爲你相比其餘同窗來講有何優點，有何劣勢？

優點: 有比較明確的方向，而且能付出行動。行動的話，團隊給了一個很好的環境，通常沒課的時候就在團隊自習，而後一些比賽，會積極參加，並儘可能去爭取名次，好比盛特杯。
劣勢：成績上，可能仍是不是特別好吧，績點和排名就能很好的反映出來。只算得上中上水平，這方面還要加油

針對你的選擇，你給本身的大三設定的規劃安排是什麼？

繼續好好學習專業知識和後端知識，而後多看看別人的面試經驗，準備春招秋招。

你對於實現本身的夢想已經作了或者計劃作什麼樣的準備？

加入了團隊裏面有不少優秀的學長學姐和同窗，資源十分豐富，是一個很好的平臺。我以爲這算是我作的一個比較好準備和選擇吧。

提出問題

問題一

軟件工程師的思惟誤區

我看了書上P48-51的內容，對3.2軟件工程師的思惟誤區有問題。這裏主要講了三個思惟誤區：不分主次、過早優化、過早擴大化。其實我以爲雖然「軟件是‘軟’的」，但在實際的開發過程當中，適當的提早優化和擴大化仍是有必要的。主次這個暫且不談，由於項目在開發中，各類問題確定會層出不窮，解決問題確定是須要分主次的。可是優化、擴大，我以爲能夠在來發中適當的進行，由於在實際開發以前的構想階段，可能有些問題確實是想不到的，只有在開發中，代碼的編寫中，而後在編寫過程當中的測試中（此測試並不是指最終測試，指的是調試或者前期的簡單的測試）發現了問題，能夠就作出必定的優化，同時須要擴大化時也能夠經行適當的擴大，以適應需求或改進前期沒有想到的問題。因此我以爲早期的優化和擴大化仍是有必定比較的。

問題二

小強地獄

此問題出如今書本的P241-242上，主要問題是開發任務與測試需求之間存在的矛盾。我以爲過於追求開發新功能上，而不去管開發中遇到的某些bug會讓開發有一些失衡。開發和測試的關係應該是相輔相成的。去完成客戶需求須要開發人員和測試人員同時進行。由於某些bug沒有及時修改而卻是測試人員沒法進行測試，這確定會影響工期，即便提早完成了開發，可是bug沒有修復，仍是無法知足客戶的需求。因此我以爲「小強地獄」並不算一種很好的方法。更好的可讓測試與項目開發的人員多溝通，溝通出目前急需修改的一些bug（不修改就幾乎沒辦法進行更多的測試），而後讓一部分人去修改這些bug，讓測試人員和開發人員儘可能可以保持步調統一，這樣多是一種更好的方法。

問題三

招數：設計變動

此問題出自於書本的P326-328，主要問題是在項目的最後階段，經用戶的反饋以後，發現原設計有須要改進的地方，怎樣權衡利弊，作出修改，交出成品期間會出現的問題。在此討論期間，可能會出現這種狀況：有bug須要及時修復，可是須要消耗較大的精力甚至成本。此時又有某些新功能須要添加，這些功能並不在以前客戶的需求之中，可是獲得了用戶的反饋，由於在開發中，添加此功能並不須要改動太多原來已經作好的東西，可是須要更好的構建這個功能。雖然是可使用DCR來進行管理，可是在開發中真正會怎麼處理呢？

問題四

迷思之六：技術的創新是關鍵

此問題出自於書本的P348-349，主要是想告訴讀者不要拘泥於「技術創新是‘關鍵’」的觀念中，而且舉出了「銥星計劃」來佐證觀點。我以爲做者所舉得例子不能很好的做證觀點。由於做者舉出了一個「技術的創新」的實例，可這個創新在最後卻沒有收穫到用戶的承認和成功。我以爲這個例子做證的觀點是「並非全部創新都是能被大衆所承認的」或者「創新以前要充分分析市場需求」。由於這個手機的出現，確實是技術的創新，但是最終卻失敗了，緣由是由於它的想法有許多不靠譜的地方，或者說過度注重技術方面的實現卻丟掉了商業模式等各個方面的分析，但這並不能和「關鍵」畫上等號。這和「技術的創新是關鍵」的觀念貌似沒有太大的關係。我認爲技術創新是關鍵，但同時也須要其餘方面創新的支持。

問題五

迷思之八：創新者就是冒險家

此問題出自於書本的P354-355,主要是爲了否認一些人認爲創新者就是冒險家的觀點。其實我以爲「創新者就是冒險家」這個觀點的提出就不是頗有必要，「就是」二字過於確定。我以爲通常人而言，對創新的理解，能夠是創業，去開闢事業，這確實須要承擔風險。但創新也能夠是更新，對現有的東西進行改進，進而獲得新的東西。對於一些創新來講，根本就配不上冒險二字，好比去改進板凳所存在的不方便的地方，這種改變算是創新，可是並不須要承擔風險。固然還有更多其餘的例子。因此我以爲這個論點的提出其實不是頗有必要。

源程序版本管理工具

Git

優勢

適合分佈式開發，強調個體。

公共服務器壓力和數據量都不會太大。

速度快、靈活。

任意兩個開發者之間能夠很容易的解決衝突。

離線工做。

缺點

模式上比SVN更加複雜。

不符合常規思惟。

代碼保密性差，一旦開發者把整個庫克隆下來就能夠徹底公開全部代碼和版本信息。

GitHub

優勢：

GitHub是一個很是萬能的工具。對於任何大小的項目，他都是理想的工具；他也是偉大的web工做流工具。首先，他能夠做爲一個版本控制系統和協做工具，用它來發布工做。

利用GitHub，你能夠將項目存檔，與其餘人分享交流，並讓其餘開發者幫助你一塊兒完成這個項目。優勢在於，他支持多人共同完成一個項目，所以大家能夠在同一頁面對話交流。

建立本身的項目，並備份，代碼不須要保存在本地或者服務器，GitHub作得很是理想。

學習Git也有不少好處。他被視爲一個預先維護過程，你能夠按本身的須要恢復、提交出現問題,或者您須要恢復任何形式的代碼，能夠避免不少麻煩。Git最好的特性之一是可以跟蹤錯誤，這讓使用Github變得更加簡單。Bugs能夠公開，你能夠經過Github評論，提交錯誤。

在GitHub頁面，你能夠直接開始，而不須要設置主機或者DNS。

缺點：

若是，你是Github使用新手，首先的挑戰就是擺正心態——須要不斷實踐和時間。

他可能不是捕捉創意過程和記錄創意點子的最佳工具。對於這種特殊功能模擬能夠選擇LayerVault 或其餘類似工具。以前，咱們已經強調過Github很是適用代碼跟蹤，可是卻不是最好的設計跟蹤工具。將圖片內容轉化爲代碼，或者將設計用於產品設置，看起來依舊不是那樣順利。

這是由設計者決定的，然而，一些人發現 GUI 有點混亂，選擇CLI代替。一些開發人員學習主要使用Git命令，這樣能夠解釋爲何他們不太喜歡GUI的緣由了。稍加練習,命令的學習是不太困難的。然而，你喜歡每天寫命令嗎？特別是跟蹤項目歷史或解決衝突的時候。因此就有了另一羣喜歡GUI的人們。將提交、修改、移動文件等操做可視化，會有一個更好的體驗。而這些，就如以前提到的，須要時間來適應。

若是，你專門在GIthub上工做，版本控制存儲庫就值得你擁有，也須要你長期付出。

Bitbucket

優勢

支持Hg，最易學易用（但不是最強大的）的分佈式版本管理工具。同時也支持Git。他的網頁端的git倉庫不如github好用，可是做爲遠端倉庫足夠了。

徹底免費的閉源項目，還支持5人之內的合做開發。

提交大文件速度很快且不限容量

缺點

和GitHub相比，開源項目只有較少部分在Bitbucket中（大部分在Github裏，是由於Bitbucket用戶沒有GitHub多？）