| 這個作業屬於哪個課程 | 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多？）