第一週博客做業

自我介紹

我叫謝璟毅，是中國科學技術大學16級數院應用數學方向大四學生，如今MSRA VC組實習。平時喜歡唱歌（在沒有人的時候），喜歡看電影，喜歡跑步和騎行。至於編程方面，機器學習、Web 先後端開發、Android 開發、PLT 等，我的都有所接觸（算起來我已經有9年碼齡，老了老了~）。最擅長 Python，喜歡鼓搗函數式編程語言。性格喜靜，喜歡一我的獨處。我的感受這種性格既有好處也有壞處，好處是它讓我擁有了較強的自學能力（由於有時很差意思問人），壞處是讓我經常沉浸在本身的小世界裏，狹窄了視野。

p.s. 我的平時不用博客園寫東西，而是在本身的博客 https://www.hsfzxjy.site/ （雖然長草了一段時間了）。

現狀經驗和計劃

技能	當前水平	目標	實現方法
程序理解	6	8	多閱讀優秀的代碼，同時掌握正確的閱讀方式
程序設計	6	8	在實踐中養成動手前先思考的好習慣，養成良好的編碼習慣
單元測試	3	6	經過書籍或相關博客瞭解單元測試的方法論
代碼複審	3	6	多參與相似的工做，在實踐中學習
不一樣進程/線程/平臺之間的聯繫與差別	3	7	經過相關文檔學習
我的源碼管理	6	8	多實踐

心得

「你爲什麼要來上課並認真參與」

專一於課堂不只是爲了獲取知識，更是培養本身專一力的一種手段。所以即便某門課授課老師方式不對/講的很差，這也不能成爲翹課/不聽講的理由。由於這麼作實際上是讓本身缺失了另外一種訓練——即專一力的訓練。誠然不能否認專一力訓練有多種方式，也不能否認某些學生有較強的自學能力，但這對大多說（大）學生而言是不成立的，上課認真聽講仍然是一個好的選擇。

「師生關係」

贊同文中把師生關係喻爲 Coach / Trainee 的觀點。每一個學生都懷着不一樣的目的參加訓練/學習，所以老師也不能簡單地一視同仁，即一致地嚴格要求或者一致地放水。老師爲不一樣目標的學生提供不一樣程度的幫助，學生也根據本身的目標付出相應的努力。

關於參考和抄襲

我的認爲，只要作法符合相應的標準（代碼的 License，寫論文註明出處，符合相關法律）便不算抄襲。人類現在的輝煌也是後人踩在前人的肩膀上走出來的，基於他人的想法/做品創做本沒什麼，關鍵在於手段要合理。

幾年後，你能夠作學術研究、作軟件項目、作其餘專業的工做，作公務員，出國深造，回家繼承家族企業... ，不一樣的選擇有不一樣的努力方向, 你今天是怎麼爲未來準備的？

我的對 Research 有熱情，但更傾向於產品的開發。最理想的狀況是畢業後找一個高薪（最好也是壓力不大）的公司作開發，待財務自由後轉到低壓的環境，用業餘時間幹喜歡的事，陪喜歡的人。

作獨立開發者我也想過，但真的太難了。微博上的 @Easy 大佬是一個成功的例子，但我自認爲達不到他的高度，尤爲在執行力和需求分析方面。並且一我的包攬全部事其實也是很累的，在這麼多事裏我感興趣的只有開發——至少如今是如此。因此我仍是老老實實打工吧。

代碼量

（時間過久遠了，沒法精確到100行）

語言	代碼量	來源
Python	20000+	若干網站的後端，學校的數值代數、運籌學、數學建模課程，機器學習研究項目，各類小腳本
Javascript / Node.js	10000+	若干網站的前端，各類小腳本（在 Web 技術棧裏 JS 更順手），Chrome 插件等等
Pascal / Delphi	8000	NOIP，Win 32 時代各類小程序
C / C++	6000	學校 C 語言，數據結構，算法基礎課程
Win32 ASM	4000	早年因我的興趣用匯編寫過若干程序
CSS / Less / Sass	3000	若干網站前端
Rust	2500	我的興趣
Shell	1000	各類小腳本
Haskell	500	我的興趣

我的編程接觸的早，因爲很享受用代碼創造新事物的感受，一直以來都有保持編碼的習慣，也積累了不少經驗。但我的更但願能提高編碼能力以外的軟技能，好比需求分析、團隊領導能力等等。這對將來的職業也是必要的。

你如今的道路不少前人曾經走過，他們有什麼經驗教訓？請從博客末尾的文章列表任選一些閱讀，針對其中一篇發表感想。

https://book.douban.com/subject/4006425/discussion/22803733/

我感受本身一直一來都缺少時間規劃的觀念。天天開始的時候都是不少事情並行操做，但有時到了最後每件事情都會出一些小問題。這個其實就是沒有優先級概念的體現。我很認同這篇文章中的觀點，即天天應該給要作的事情排序，而後按順序爲每件事情安排一段專屬的處理時間。在特定的時間就作特定的事情，這樣才能高效地完成任務。

關於《構建之法》的疑問

軟件團隊的人員也會流動，新的成員要儘快讀懂已有的程序、瞭解程序的設計，這叫作程序理解（Program Comprehension）。 ——P18

問題 當面對一個龐大的，設計不算良好，代碼風格不算規範的代碼庫時，應該如何快速地瞭解本身須要瞭解的部分？符合以上描述的代碼庫實際上是很常見的。不少時候咱們只須要關心代碼庫的一部分，也就是和本身工做相關的部分便可。可是不良的設計可能增長了模塊間的耦合度，從而使咱們難以界定什麼地方該閱讀什麼地方不應閱讀。同時不良的代碼風格可能會拖慢咱們閱讀的速度。這時應該怎麼辦？

PM 的能力要求和任務 —— P195

問題 我的十分贊同此處對 PM 應具備的能力的描述，但不知道應該如何培養這種能力，尤爲是預期用戶的新需求。

早年本人曾爲社團活動寫過一個實時會議系統，其需求僅有「大概一兩百個用戶，須要支持一對一聊天，須要支持羣聊」如此。我須要將此擴充成一個完整的系統。這其中其實還有諸多隱式需求是用戶須要的，可是用戶自身不知，或是表達不出來。其中令我記憶猶新的是會話列表的設計。因爲可能存在上百個會話，我須要設計一個便捷的檢索系統。當時我以本身的思惟方式採用了這樣一個的方案，即放置了一個支持拼音首字母檢索的輸入框。但網站上線後有些人反映這個功能很難用，他們更願意接受「依標籤歸類好，而後用鼠標點」的方式。這其實體現了不一樣人羣的不一樣習慣——我做爲編碼者是恨不得任何操做均可以用鍵盤解決，但對於普通人而言鼠標多是更適合的方式。這就是一個需求預測錯誤的例子。

如今開發人員手頭上有很多修改，分別屬於不一樣的具體任務，那如何將這些修改遷入源代碼控制系統中呢？——P230

問題 此處提到的僅是是添加新修改的流程，此處對應的修改應該都是比較小的修改。但若新需求與現有的架構不融洽又該怎麼應對呢？我認爲這是一個經常會遇到的問題。有時爲了快速開發，或是由於時代的限制沒有預測到新需求，咱們沒能將架構設計的便於擴展。此時若直接加入新需求，則會增長現有代碼的「壞味道」。長期以往，可能會造成所謂的「只有上帝纔看得懂」的代碼。適時重構是一種選擇。重構有着較大的時間成本，而且有不可預見的風險；但另外一方面，重構可能給後續的開發帶來便利，下降出錯的機率。遇到這種狀況，是應該重構，仍是繼續加入新代碼呢？這其中我不清楚應該如何選擇。

快速原型調研 （Quick Prototype）—— P166

問題 在項目的初期一般咱們會設計產品的原型，多是爲了以此快速徵求用戶的想法，也多是來自用戶的要求。原型一般是一個簡陋的、初步實現產品殺手級功能的一個程序。個人問題是，當產品進入正式研發階段時，咱們應該怎麼對待這個原型程序呢？咱們是應該基於原型的代碼開發產品，仍是從頭開始寫？感受若是是從頭開始寫，至關於有些浪費了寫原型的勞力。

單元測試應該由最熟悉代碼的人（程序的做者）來寫 —— P40

問題 然而最熟悉代碼的人一般對代碼會有先驗的理解，從而可能會忽略一些錯誤。就好像文章寫好後找錯別字時，本身看可能看半天也看不出來，由於本身對這篇文章太熟了；但若交給一個不那麼熟悉文章的人看，可能一下就找到錯別字了。