第一次閱讀作業
| 這個作業屬於哪個課程： | https://edu.cnblogs.com/campus/xnsy/SoftwareEngineeringClass1/homework/2713 |
| 這個作業要求在哪裡： | https://edu.cnblogs.com/campus/xnsy/SoftwareEngineeringClass1/homework/2713 |
| 我在這個課程的目標是： | 掌握軟體工程開發的具體流程和需求 |
| 這個作業在哪個具體方面幫助我實現目標： | 對本專業的深入瞭解，對未來發展方向的引導 |
一.建立部落格並介紹自己
我的名字叫孫玥祺，來自軟體三班。
世界很大，喜歡出去走走，去各地旅遊看風景，品美食，寫遊記。喜歡文學，寫文章，看書，發表自己的感慨。我的閃光點我認為是有熱情，肯上進，願意為自己的目標不懈努力。嚮往好的事物，並努力向前。比較樂觀，以積極的心態面對未來。
二.閱讀與思考
1. 回想一下你初入大學時對軟體工程專業的暢想
當初你是如何做出選擇軟體工程專業的決定的？
剛入大學，因為家人的填的志願，我讀了物聯網工程這個專業。大一上學期可以轉專業的時候，我才真真開始考慮計算機這門大的課程，我該從哪裡入手來學。是從年級大會上了解到物聯網，網路工程是硬體方面，而軟工和計科是軟體方面。所謂的硬體我的理解是偏於能看見的，視覺化的。而軟體方面則是像app一樣，是電腦上的應用，是介面，是摸不著的。後來我查閱了百度資料，明白硬體系統是看得見摸得著的物理部件或裝置，就是類似於主機板。而軟體是以程式和文件的形式存在，通過計算機執行來體現 他的作用。同時我也參觀了物聯網的嵌入式團隊，他們所展示的是將晶片放入賽車裡，用遙控器通過網路來控制。而軟體工程的團隊則是在電腦上向我們展示所做的網頁，應用等。巨大的差異，讓我認識到也許硬體方面還需要一個人具備立體思維的模式，我覺得我不合適。後來我參加了物聯網工程的團隊，其中偏於硬體方面的方向也比較單一，而我卻被團隊在做的web前端的頁面所吸引，原來自己也是可以做多彩的網頁樣式，可以設計成自己喜歡的樣子。所以我選擇去了軟體工程，因為喜歡前端的設計，也考慮的軟體市場比較成熟，有更多的路可以選擇。
你認為過去兩年中接觸到的課程是否符合你對軟體工程專業的期待，為什麼？
我覺得過去的兩年接觸的課程我自己還是比較滿意。首先我接觸的是語言方面，學習了C語言和C#，自己學習了C++。學習了這三門語言，我也是第一次感受到作為程式設計師的快樂，第一次自己可以編寫程式，可以做出很多題目，可以呼叫函式，可以用遞迴做看似不可解的漢諾塔問題，甚至可以做一些自己小時候玩的簡單遊戲，這都是學習語言課程帶給我的。其次，我接觸到了資料結構，瞭解了更多的演算法，可以寫出更有 難度的程式碼，也知道了所謂執行的效率原來可以靠時間複雜度和空間複雜度計算的，也瞭解了更多的排序方法，算是自己對C語言的瞭解更進一步。後面學習了資料庫，我也覺得自己離現在所謂的大資料時代近了一步，更加接近那個我心目酷酷的程式設計師的樣子。但到現在還有一點小小的遺憾，因為和沒有和專案組一起做過一個大的程式，想在接下來的時間中通過課程多去實踐。
你覺得軟體工程是你喜歡的領域嗎，它是你擅長的領域嗎？
我比較喜歡，但在這個領域我覺得我還不是很擅長。因為在之前的學習當中我認為我在編寫程式碼這方面還是有所欠缺，邏輯能力不夠強。就比如在學習資料結構的時候，我學的線性表，動態連結串列以及棧，佇列。理論知識和程式碼理解起來都比較輕鬆，但真正寫程式碼的時候還是很困難，不知道如何下手，這學期我報名參加了藍橋杯比賽，但在準備的時候，我才發現那些程式題是正真的講數學思維與程式設計方法結合組成一道題，在這種靈活運用上我還是欠缺的很多。
將來你會選擇從事軟體開發相關的工作嗎？是的話給出你想去的城市、公司和崗位，否的話給出原因
我將來想從事這方面工作，我想去北京，公司的話還沒有想好，想去的崗位是web前端開發，還是堅持我現在所喜愛的設計領域，希望自己設計的網路介面可以讓人們眼前一亮。
2.即將大三的你，對照前人們走過的路和描述未來發展，現在的你
自我感覺你已經具備的專業知識、技能、能力有哪些？已經寫過的程式碼量是多少？
我覺得我具備的專業知識是這兩年所學的C語言，C#，C++，通過資料結構我能寫出較複雜的C語言程式碼，在團隊，在老師的幫助下學習了PS，對畫面的排版，製作有一個基本瞭解，能力方面，我覺得我對一個專案的要求可以做到基本瞭解，可以簡單寫出一些程式。程式碼量大概有2000條。
離成為一個合格的軟體工程專業本科畢業生，在專業知識、技能、能力上還差距哪些？
離成為一個專業的軟體工程本科畢業生，我覺得在專業知識上，我還是做不到把一個語言掌握透徹和靈活應用。其次，我的專業知識面比較狹窄，除了課堂開設的課程，沒有學更多的與專業相關的課程。技能和能力上，我沒有參加過大的專案，沒有真正的和團隊合作過，沒有獨立的完成過一個工程，可能在合作和工作的複雜度剖析上我可能很欠缺。在自學能力上，不能較快的掌握一門新語言。
3.大三是一個人生選擇的十字路口，考研、工作、考公、出國，不同的選擇在大三就有不同的努力方向。而無論考研還是工作的每條路徑，也有許多不同的分支。
對照以上你閱讀的前人們的經歷，你的選擇是什麼？
我的選擇是出國，我覺得算是對自己一種昇華。讀了老師推薦的一些文章，我覺得很多人選擇讀研或出國去繼續加強自己的能力，並有充分時間去準備簡歷去自己喜歡的公司。其次，讀完文章令我最大的感慨是我從他們的文字中感受他們對於自己職業的喜愛，也有人提到，選擇職業一定要選擇一個自己足夠喜歡的領域才能有激情幹下去。我到現在學過的一些課程，僅僅是對前端一些簡單的瞭解下，比較喜歡，所以我想去更深入瞭解它，想在更深入的學習中，去尋找它的樂趣。而我認為我可以通過出國這條路，去更多的學習和接觸，去感受興趣帶給我的動力。
在這種選擇下，你認為你相比其他同學來說有何優勢，有何劣勢？
優勢我覺得是我肯學吧，我認為在年輕的時候應該去為自己的目標努力一把，我對學習可以保持熱情，願意去學好，去上進。還有家人的支援吧，沒有後顧之憂。劣勢的話，可能是英語還沒有學的足夠好，對於程式設計能力還沒有達到一個很高的水平，還有自學能力還要提高，在自學的時候不能夠把知識掌握透徹。
針對你的選擇，你給自己的大三設定的規劃安排是什麼？
我的計劃是在校期間，首先是提高績點和平均分，達到我想申請大學的要求。其次，參加數學建模比賽和一些程式設計類的課程，繼續加強自己薄弱的方面。爭取參加專案，積累經驗，多接觸一些課外知識。還有最重要的是大二暑假準備雅思的第一次考試，並在大三考出一個滿意的成績。大三進公司參加實習和一些志願者活動，增加閱歷。
三. 提有質量的問題
1.第五章：團隊與流程
5.2.2業餘劇團模式中“不同的人會挑選不同的角色。在下一個劇目中，這些人也許會換一個完全不同的角色型別。” 問題： 讀完這段話我的理解是在這種模式下是不是每個人都要掌握不同的技能，而且要足夠熟練才可以順利完成。那是不是對一個人工程師的要求過高，現在有沒有這樣的團隊在使用這樣的方式。
2.第六章：敏捷流程
“訂單上的任務是團隊成員根據自己的情況來認領。由團隊來主導任務的估計和分配。”問題： 那麼遇到困難或者大家都不感興趣的問題，沒有人願意承擔此類問題，又恰巧是很關鍵的，怎麼樣合理的分配人員，怎麼樣才能讓團隊中的願意做，任務剛好能夠分配完。
3.第十一章：軟體設計與實現
11.3 形式化的方法中提到“很多軟體需求可以抽象為對符號的運算和變換”問題： 形式化趨向於數學化，不太明白如何用數學和推理將軟體實現出來，有沒有類似的表達和案例來說明這種方法。我通過資料瞭解到如果一個方法有良好的數學基礎，那麼它就是形式化的，典型地以形式化規約語言給出。也就是說符合此類數學特徵才可以使用還是存在廣泛性
4.第十五章：穩定和釋出階段
“推遲。如果我們的軟體是真正解決使用者的問題，是有價值的，那它一定會有下一個版本。” 問題：我讀這個解決bug問題的時候，我的理解是在這種很有價值的情況下，是不處理這個問題，等到需求量大的時候，再推出下一個版本順帶解決掉這個問題。我不知道我這樣考慮這種方式對不對。
5.第七章：實戰中的軟體工程
“那些我覺得使用者會喜歡的東西要及早和使用者交流。”問題： 我想知道及早這個時間點是怎麼樣把控比較好，是每一步跟進詢問客戶的意見還是說做出一個大概的模板給客戶，讓客戶提出問題。這個交流的時間怎樣才能更有效，更好地完成客戶的要求，達到一個滿意的效果。
四.瞭解和調查源程式版本管理工具
1. GIT
Git 是用於 Linux核心 開發的版本控制 工具。與常用的版本控制工具 CVS, Subversion 等不同，它採用了分散式版本庫的方式，不必伺服器端軟體支援（wingeddevil注：這得分是用什麼樣的服務端，使用http協議或者git協議等不太一樣。並且在push和pull的時候和伺服器端還是有互動的。），使原始碼 的釋出和交流極其方便。 Git 的速度很快，這對於諸如 Linux kernel 這樣的大專案來說自然很重要。 Git 最為出色的是它的合併跟蹤（merge tracing）能力。
優點：
1.適合分散式開發 ，強調個體。
2.公共伺服器壓力和資料量都不會太大。
3.速度快、靈活。
4.任意兩個開發者之間可以很容易的解決衝突。
5.離線工作。
缺點：
1.資料少（起碼中文資料很少）。
2.學習週期相對而言比較長。
3.不符合常規思維。
4.程式碼保密性差，一旦開發者把整個庫克隆下來就可以完全公開所有程式碼和版本資訊。[1]
2. Bugzilla
Bugzilla 是一個開源的缺陷跟蹤系統（Bug-Tracking System），它可以管理軟體開發中缺陷的提交（new），修復（resolve），關閉（close）等整個生命週期。
Bugzilla是一開源Bug Tracking System，是專門為Unix 定製開發的。
優點:
⒈ 強大的檢索功能
⒉ 使用者可配置的通過Email公佈Bug變更
⒊ 歷史變更記錄
⒋ 通過跟蹤和描述處理Bug
⒌ 附件管理
⒍ 完備的產品分類方案和細緻的安全策略
⒎ 安全的稽核機制
⒏ 強大的後端資料庫支援
缺點：
1. 安裝需要Perl和配置MYSQL資料庫，過程比較繁瑣
2. 修改配置檔案比較麻煩
3. 英文版的，能漢化但是漢化後容易出現亂碼[2]
3. Trac
Trac是一個為軟體開發專案需要而集成了Wiki和問題跟蹤管理系統 的應用平臺，是一個開源軟體 應用。Trac以簡單的方式建立了一個軟體專案管理 的Web應用，以幫助開發人員更好地寫出高質量的軟體；Trac應用力求不影響現有團隊的開發過程。
優點： 1.Trac做一個SCM配置管理平臺，意味著它有良好的擴充性
2.Trac的許可權體系是比較完備的設計
3.非常靈活，可以隨心所欲的定製，可以和TortoiseSVN整合。
缺點： 1.不支援多專案，
2 .需求和缺陷沒有分離，
3.用 wiki 來替代 Word 等工具編寫文件對於產品策劃來說門檻太高了，
4.中文化不完整，美術人員接觸起來困難重重，
5.不顯示中文名，本地化做得很差，
6.核心功能很少，不安裝外掛基本上沒法用。[3]
[1] 摘自百度百科
[2] 摘自部落格園
[3] 摘自CSDN