介紹自己

Hi 各位，這是記錄ASE課程的第一篇博客，也是我21年來的第一篇博客。

說起寫文章，從小我作文就爛得出奇，作文也寫寫的不利 利索。以前寫作文唯一出色的一點就是練過幾年書法，導致我的寫的字比一般的男生稍微好看那麽一點，不過現在基本只需要在電腦前敲鍵盤了。曾經打過好久的籃球，但因為我不想當靈活的小胖子，之後逐漸就沒打了。

至於在計算機領域，我覺得我是一個比較浪漫的人。因為我喜歡上了屬於程序員三大浪漫之一的計算機系統（另外倆是編譯原理和圖形學），希望有朝一日能為世界造個有用的大輪子。

現狀、經驗和計劃

至於我怎麽走上計算機這條路，怎麽來到msra，真的是緣分。高中的我是物競黨，一心一意想著讀物理，只可惜高考的時候崩盤了，被科大調劑到計算機系，那時心裏想著讀完這一學期就趕緊走人去物院。結果沒想到，還沒讀半個學期就發現，計算機賊帶勁了！物理什麽的，就被我休了。之後就是一個小萌新，從大一一路吭哧吭哧學到大三，越學越有味道。本來想著出國做AI的，但是在學校實驗室待了小半年後發現機器學習學的我頭大，同時又陰差陽錯被msra系統組的大牛們看上了，於是樂滋滋的來了msra，開啟我之後五年的直博之旅。

在職業技能方面，我覺得既然要成為一個合格的IT專業畢業生，首先要具備程序理解(Programming: Comprehension) 的能力。因為在這個快速發展的計算機領域，優秀的開源項目層出不窮，只有理解別人的想法、看懂別人的實現，才能對自己的編程技能有所提高。在這個基礎上，作為一個將來要前往系統領域的學生，對大項目的架構設計、接口設計（Programming: Design) 必須有非常強的實力, 在這大的架構設計之下，就是重要的實現技術（Implementation)， 好的實現可以成倍的提高代碼的運行效率。在這些硬實力的基礎上，我覺得個人軟件過程（Personal Software Process) 也很重要，善於工作記錄、代碼管理的人一定能對自己的當前工作狀況有一個清楚的認識。

以上提到的4點能力，我給我自己目前的評分是：

之後我希望每一項至少能夠達到5分以上。

這些能力的提高方式有很多，包括但不限於：

1. 閱讀他人源碼
2. 自己調試優秀開源軟件
3. 閱讀相關的書籍
4. 多動手寫代碼
5. 多於同學、大牛們交流

心得

首先是為什麽我要來上課並且認真參與：首先我認為做重要的是聽課也是一種能力，是一種接受別人思想的態度，同時能培養自己集中精神的能力。曾經我在大學剛入學的時候，不喜歡聽老師講課，一直都是以自習為主，雖然能維持住成績，但是學得很累。後來逐漸開始聽老師上課，發現長時間的自習導致我上課容易走神。我覺得這是病，得治。於是之後每節課我都盡力的去聽。在這之後，我發現我回去都不需要再重新自學就能快速的完成作業，學習一下子就變得非常輕松了。

在大學上課有一點跟中學不一樣，科大的計算機系不是小班教學，從來都是1個老師教導100多名學生。這導致老師跟學生的互動就很一般。於是課上的疑問大多數都是在和同學的交流間解決，當大家都無法確定時便會郵件詢問老師。雖然大家都有一天一本書，一周一學期的能力，但是我覺得認認真真從開學學到期末的效果更好，因為這個不容易忘。雖然這樣學習可能最後成績還沒有一周一學期的同學高，但是能從整個過程中領悟到許多超過課程考試範圍的感悟，這些對計算機能力的培養功不可沒。

另外關於工作中的引用和抄襲，個人認為，只要你使用別人的文章、別人的資料，就只能在作者同意的情況下使用並做出說明。對於沒有任何說明就拿來用的，或者一篇文章是多個文章的集合體的情況，這就必然是抄襲了。好在現在大環境也在對知識產權、版權等方面進行不斷維護，抄襲的現象也慢慢被壓制。

未來發展

我覺得現在決定未來走研究路線還是工業路線對我來說還是太早。現在就選定感覺會把自己能發展的方向限制的太多。人吶就是不知道，自己不可預料。不過我是偏向工業界發展的，但也挺喜歡做科研。這個決定我覺得等我讀完博士，那時候再看看自己的興趣和狀況（比如頭發），再做決定也不遲~

在我這樣的選擇下，我覺得首先我不會把自己的視野限制的太狹隘，我可以收獲到很多工業上的知識，同時也能研究到很多前沿領域的科研課題。當然這樣肯定會導致我的精力偶爾有些分散，讓我不管在哪一方面都不會做到真正頂尖的水平，但是我覺得這也是可以接受的，因為等選定方向後就能真正紮根於某一個領域中，而在之前積累的其他方向的知識，說不定哪一天就能派上用場。

因此，我對自己本學期的規劃是：能多接觸一些知識，就盡量多接觸一些知識，多多開闊一些自己的視野。

期待

對於這門課，我希望能真正的學到企業級別的軟件開發流程，以前在大學中學到的課程雖然涉及到團隊合作，但最後仍然是各幹各的，再把東西拼湊一下，很難體現出合作的精神，因此效率也不高。目前我的代碼量大概將近10w行左右，主打C++，也寫過許多python。最大的一次獨立項目是3000+行的全棧模擬銀行管理軟件，用的是node.js 和html/css/js 來搭建的。

博客文章閱讀

我閱讀了一篇大佬的博客：熱情、能力、選擇。我很贊同這位大佬的看法，因為我自已也一直堅信著，對技術的熱情能讓自身提升到一個新高度。文中將到了一點，興趣能讓你對一件事持久，熱情才是考驗你能否一直走技術路線並有所成就的因素。我覺得說的很對。很慶幸我一直對計算機技術非常感興趣，我也很願意對計算機技術做跟深入的研究，而不是僅僅當作一種養活自己的手段。

提問環節

1. 書本P80

   對開發人員自身來說，結對工作能帶來更多的信心，高質量的產出能帶來更高的滿足感。

   我對這一點有疑惑，首先我覺得結對編程很取決於雙方的實力和雙方的性格。如果雙方實力差距懸殊，並且實力強勁的一方性格還刻薄，這樣會對編程能力較弱的一方造成編程上的心理壓力，反而拖慢整個工作的進度, 甚至影響團隊的和諧。

2. 書本P80

   在企業管理層次上，結對能更有效地交流，相互學習和傳遞經驗，分享知識，能更好地應對人員流動。

   首先我很認可傳遞經驗、應對人員流動。但是我認為，當在編程過程中，一個任務往往有不同方式的實現，如果兩個人都各執己見，往往很難協商一個共同一致的實現方案，從而導致項目停滯。同時如果有一些創新的想法也很難在交流過程中形成，因為個人感覺獨立思考往往能帶來更多的創新性。

3. 書本P109

   第二步：決定當前的沖刺需要解決的事情

   整個產品的實現被劃分為幾個互相聯系的沖刺。產品訂單上的人物被進一步細化了，被分解為以小時為單位。

   我覺得一個項目被分解到小時為單位非常困難，首先能夠做到這樣的分解，必須對架構有非常清晰的認識，並且對實現的難易程度也有充分的了解。這一部分我覺得很難在現實中把控好，因為稍有不慎，這個產品的進度被拖慢從而導致後面的產品進度都被拖慢，造成連鎖反應，這種情況要怎麽解決呢？

4. 書本P135

   軟件工程，唯一不變的是變化。所以幹脆別幻想客戶的需求會在第一時刻很明顯，然後保持不變。但要註意，我們是預期變化，不是期望變化 。

   在這個過程中，如果我們預期了變化，並對預期的變化做出了相應的調整。但隨後發現預期出現了錯誤，用戶的需求是往另一個方向走的，那麽在對於正在做調整的軟件該如何處理？

5. 書本P190

   要帶著感情去討論問題麽？有專家建議開會應該盡量不帶感情，但是別的資料又要求大家帶著感情去體會用戶的通電，還要帶著浪漫的幻想去做頭腦風暴。

   我覺得因為每個人專業的領域可能有細微的差異，很多人對一個想法褒貶不一，同時一方面認為著不可能行，另一方面又認為這是一個很好的點，如果在這樣的環境下權衡一個想法的好壞呢？

軟件工程開篇自我介紹