第一次做業—初始博客

時間 2020-05-09

標籤第一次初始博客简体版

原文原文鏈接

第一次做業—初始博客

格式描述：html

問題	連接
這個做業屬於哪一個課程	課程連接
這個做業要求在哪裏	做業要求
我在這個課程的目標是	課程目標
這個做業在哪一個具體方面幫助我實現目標	具體實現
做業正文	做業正文
參考文獻	參考文獻

課程目標：前端

我在這門課裏的目標以下:git

瞭解並體驗軟件開發流程，體驗在軟件開發的各個階段的內容程序員

決定本身之後的方向github

磨練技術，準備實習web

具體實現：算法

此次做業可以幫助我實現的目標是：數據庫

決定本身的方向小程序

瞭解各類源代碼託管軟件windows

借鑑他人經驗，少走彎路

學會如何書寫文檔

做業正文

1. 關於我和個人博客

個人博客

關於我:

我是一名技術菜的出奇的程序員，喜歡閱讀和美食。本身懷着積極的態度，可是卻每每堅持不下去。間斷式的努力讓我時常亢奮，亢奮期一過就會陷入低谷。在困難面前徘徊，在徘徊中失去方向。不過本身卻很樂觀，畢竟沒到最後發生的全部事都是好事。本身還特別喜歡看書，薄弱的記憶力讓我很快的忘掉本身讀過的書，有些時候還會所以陷入迴環，讀了又忘，忘了又讀，直至放棄。

2. 閱讀與思考

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

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

提及這個，那但是說不盡的辛酸啊！當時選軟件工程方向是由於在高中的時候和信息老師的兒子的關係比較好，常常和他聊天，每天聽見他說一些關於計算機方面的知識，當時我說這個頗有趣的時候，他告訴我他爸是軟件工程的，你之後大學能夠選擇這個專業，專門研究這些，你應該很是感興趣。因而乎，我就填了這個，真的坑啊，我忘了他爸的光頭啊！！！
你認爲過去一（兩）年中接觸到的課程是否符合你對你本身所在專業的期待，爲何？

說實話，我仍是有點小失望的，大一來了每天在吐槽之中，什麼鬼啊？爲何還要學物理啊？咱們不是學計算機的麼？怎麼再學這些啊，看着少得可憐的專業課，我陷入了沉思，後面也可能就麻木了嘛，畢竟學着快過期的技術，瞭解着計算機的歷史變遷，仍是挺有趣的。
你以爲你所在的專業是你喜歡的領域嗎，它是你擅長的領域嗎？

不是，也不是擅長的領域。雖然說和當初的期待有所差距，但總的來講能夠接受，生活不就是這樣的麼，咱們老是得不到本身喜歡的東西。做爲一名碼農，就準備好好學習，我也不知道將來會怎樣，可是奮鬥老是沒錯的。
未來你會選擇從事和你專業相關的工做嗎？是的話給出你想去的城市、公司和崗位，否的話給出緣由

會呀，畢竟本身只有計算機這一技之長。若是能夠的話，我想呆在成都成爲一名獨立開發者，比起金錢，我更崇尚自由。

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

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

emmmm，這個我也不太肯定有哪些吧，有着前端開發，也會web後端開發，會寫微信小程序，也會開發C++,作過機器學習，也玩過圖形學。但這些依舊不是我所熱愛的，我還在尋找着本身的方向。代碼量我也不知道有多少，反正應該很多了吧！最複雜的話應該是最近的主動學習算法了吧，大量的數學知識和全英語的論文與文檔耗費了我大量精力。奇異值和SVN,PCA，TSNE的概念使人眼花繚亂。
離成爲一個合格的本科畢業生，在專業知識、技能、能力上還差距哪些？

差的有點多，操做系統，編譯原理,數據結構，數據庫等這些都至關晦澀難懂。答辯能力也差得不少。

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

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

我呀，應該是考研加工做吧，46分，很正常，我更傾向於工做的。
在這種選擇下，你認爲你相比其餘同窗來講有何優點，有何劣勢？

感受沒有優點，每一個同窗都很努力，我只有和他們同樣學習才能勉強跟上他們，劣勢就稍微有點多了，個人知識儲備和他們根本不在同一個量級上了，畢竟個人記憶力那麼差。
針對你的選擇，你給本身的大三設定的規劃安排是什麼？

努力啃書，努力補充數學知識，多看看英語文檔，多學學之後就業能用的前沿技術。
你對於實現本身的夢想已經作了或者計劃作什麼樣的準備？

差太多了，若是將本身的夢想比做高樓的話，我如今應該還在運建築材料，作的準備應該是地基打了幾根柱子吧，讓本身可以看得更遠。

3. 問題
- 我在第三章55頁看了職業發展—考級之路這一段，有個問題「這些證書真的有企業承認麼？行業承認度怎麼樣？」，我查了一些招聘要求，發現行業對這些證書不太承認的樣子，個人困惑是「如今去考這些證真的有必要麼？他們的承認度不過高的樣子。」
- 我在第四章64頁看了這一段文字"代碼風格的原則是：簡明，易讀，無二義性"，有這個問題「怎樣才能算是簡明易讀？每一個人的知識面不同，對代碼認知也不同。」。我查了資料，有這些說法"咱們不必爲了別人而修改本身的代碼，本身的代碼整潔和註釋良好就能夠了。"，根據個人實踐，我獲得這些經驗「我的以爲代碼也不是寫的易懂越好。團隊開發時，由於每一個人的代碼風格都不同，因此別人的代碼寫的再易懂也只是相對他本身來講比較容易看懂。因此這時候就有一些代碼規範須要你們去遵照，可是代碼規範又不是具體到某一點的東西，只能從大致上讓代碼變得整潔。總之，寫代碼的時候，要遵照一些常規的代碼書寫規範，不要有什麼反人類的操做。最重要的是關鍵代碼加註釋！關鍵代碼加註釋！否則幾個月之後，再簡單地代碼，本身也會看不懂的，怎麼下降溝通成本呢？」。可是我仍是不太懂，個人困惑是「是否是咱們之後工做時寫代碼時只須要寫上徹底的註釋，而不用向上兼容代碼的使用者呢？」。
- 我在第六章瞭解到了敏捷開發，瞭解到他有不少優勢，在網上查詢的時候發現咱們國家絕大多數的互聯網公司都在使用着敏捷開發，可是，我發現網上的大部分的文章都對敏捷開發持有不友好的態度，甚至scrum.org的創始人Ken Schwaber，也是Scrum的創造者之一，他在他的博客上提到了在中國推行敏捷思想的文化障礙。個人困惑是「既然敏捷開發在國內受到文化差別的影響，甚至已經丟棄了敏捷開發所帶來的優勢，爲何這麼多互聯網公司仍是在樂此不疲的採用敏捷開發呢？」
- 我在第九章總體這一章發現軟件公司彷佛並無對項目經理進行強硬的技術要求，也就是說，項目經理多是一個既不懂技術，又不懂測試的人，那麼，身爲程序員如何明白的表達這個需求作不了之類的觀點？項目經理又如何讓一堆技術人員明白他的要求呢？又何以服衆呢？
- 我在第十三章這一章發現書中提供了不少有效的測試方法，在這裏我有一個問題，是測試基本都是軟件工做人員寫的，他們不可能瞭解完全部BUG，什麼樣的測試纔是有效的測試和全面的測試呢？畢竟人的考慮是有限的。我經過一篇博客瞭解到對於一個大型的，擁有足夠多用戶的軟件產品來講，這個軟件可能遇到的狀況，也是」荒誕「的。由於一個軟件開發者（團隊），永遠沒法在測試中窮盡他們設計的軟件會被怎樣的使用，和遇到什麼樣的情況。，可是，我仍是想問，是否存在一種標準去量化這些測試的有效度呢？
4. 版本控制工具

1. Git
```
優勢： 
一、適合分佈式開發，強調個體。 
二、公共服務器壓力和數據量都不會太大。 
三、速度快、靈活。 
四、任意兩個開發者之間能夠很容易的解決衝突。 
五、離線工做。 
缺點： 
一、學習週期相對而言比較長。 
二、不符合常規思惟。 
三、代碼保密性差，一旦開發者把整個庫克隆下來就能夠徹底公開全部代碼和版本信息。
```
2. SVN
```
優勢： 
一、 管理方便，邏輯明確，符合通常人思惟習慣。 
二、 易於管理，集中式服務器更能保證安全性。 
三、 代碼一致性很是高。 
四、 適合開發人數很少的項目開發。 
缺點： 
一、 服務器壓力太大，數據庫容量暴增。 
二、 若是不能鏈接到服務器上，基本上不能夠工做，看上面第二步，若是服務器不能鏈接上，就不能提交，還原，對比等等。 
三、 不適合開源開發。可是通常集中式管理的有很是明確的權限管理機制,能夠實現分層管理,從而很好的解決開發人數衆多的問題。
```
3. VSS(VisualSourceSafe)
```
優勢:
  能夠鎖定核心代碼，由於他的工做方式是一個文件只能由一個用戶修改
缺點:
  工做效率低下，只適合小團隊開發
```
4. CVS(ConcurrentVersionSystem)
```
優勢:
    可使多個用戶並行工做。這樣對於正在編寫軟件的項目團體有利。
缺點:
 版本控制某個項目下的一些核心文件比較困難，假如團隊中的每一個人都寫文件的權限。這樣每每會不當心的讓核心代碼被修改。
```
5. Microsoft TFS
```
優勢: 
    能夠在VS中的任務版上看見需求和項目進展。能夠和VS無縫對接。
缺點:
 維護和搭建比較困難。
```
6. Trac
```
優勢: 
    良好的擴展性，很是靈活的定製各類要求
缺點:
 中文化太少，核心功能太少，需求和缺陷沒有分離
```
7. Apple XCode
```
優勢：
    能夠自動建立分類圖表。自動提供撤消、重作和保存功能，無需編寫任何編碼。
缺點：
 更新版本後，某個插件可能會失效。
```
8. BitKeeper
```
優勢:
    簡單: 很是易用的命令行接口 
 可伸縮: 嵌套的源碼庫，相似子模塊 
 精確: 可跟蹤文件的各類操做 
 安全: 全部文件訪問都會通過統一校驗
 可辨識: 源碼註解即時生效
 快速: 高性能可伸縮，支持超大規模項目
 免費: 使用 Apache 許可證
缺點:
 不是很靈活
```
9. Darcs
```
優勢:
    沒有中央服務器. 任何一個本地repository均可以既是客戶端也是服務器, 節點之間能夠任意同步.
 本地epository也能夠看做是個完整的branch
缺點:
 不易管理
 windows版有不少bug
```
10. Mercurial
```
優勢:
    1. 跨平臺
 2. 封裝好
缺點:
 1. 分支管理不靈活。
 2. 支持社區略差。
```