這篇文章最早發在我團隊的文件中。我的團隊鼓勵每個同學都在業餘時間多做演算法題，特別是新人。個人認為在程式設計能力的提公升上比做 side project 更有用，對職業發展也是如此。當然出於興趣做的 side project 另當別論。轉到這裡，希望對各位讀者有用。
持續做演算法題的目的仍然是自身能力提公升。可以繼續細化成三點:
為了更有效地實現上面的目標。推薦用下面的方式來做題:
目前 leetcode 上的題大致可分為兩種型別：
在這個分析過程中首先要大致判斷出屬於哪一類。在掌握了基本的資料結構和演算法後，應該能很好的判斷是不是屬於前兩類。如果判斷不出說明需要回頭先重新複習基本資料結構。推薦《演算法》一書。不要強行刷題。演算法書的每種資料結構及演算法的大概思路、解決的問題以及相應的時間和空間複雜度了解之後可以再回來。
例子：這個番茄時鐘內的目標是：
完成後應該有的總結是：
如果發現在要用的技術中有不熟悉的地方，應該立即中斷，開啟另乙個番茄時鐘進行學習。切忌盲目嘗試。當發現有不確定的地方時，重新開啟乙個番茄時鐘，按照當前思路把不確定地方當成乙個單獨的演算法問題進行解決。
例子:這一類題目通常採取遍歷的方法一定都能找到解法。重點是找到最優解，因此需要提前有足夠的資料結構的知識。資料結構可大致分為鏈(陣列、棧、佇列)、樹、圖。在這三類資料中要分別掌握排序和查詢演算法。特別是相應的時間複雜度。
這類題目很好判斷，通常題目中會描述了幾個資料或者狀態的關聯的關係，然後需要你找出符合條件的某些資料。那麼將題目中的關聯關係轉換成相應的資料結構，再使用對應演算法就夠了。要對資料結構的足夠熟悉，才能知道如何轉化。
這種情況下番茄時鐘的目標是：
總結是：
例子：這一類情況最好用排除法，發現不是第一種或者第二種，那麼再往這種情況下考慮。這類題的特點是通常是發散性質，剛看到題目容易有思路，但不太容易找到最優解。這種情況下，也要先判斷題目子型別。
在這種情況下，番茄時鐘的目標：
總結：當分析完之後，建議不要開始寫**，一定要休息片刻。執行階段是對我們平時寫**狀態的一種鍛鍊，應該非常珍惜。如果乙個番茄時鐘執行不完，應該拆分成多個。在這段時間中，設定的番茄時鐘目標應該是：
要實現執行高效，最重要的是養成良好的編碼習慣，不要犯小錯誤。要始終朝著只要想清楚了，一次寫好，不要除錯的狀態要求自己。這裡常見的小錯誤有：
除錯超過寫**時間 30% 時說明狀態非常有問題。在這個階段的總結是：
如果中間發現了分析階段的錯誤或者疏漏。應該立即結束編碼，休息。並且重新開啟分析階段的時鐘。切忌邊寫邊改方案。如果發現編碼過程狀態不夠好，應該加長休息時間，或者乾脆結束掉。不要給自己留下低效的映像。將任務留到第二天其實也可以檢驗自己第一天的思路是否足夠系統化，如果是，那麼第二天應該能很快的重新找回思路。
一定要做好總結，特別是當沒有解出題來，沒有思路的時候，一定要通過結束階段的總結來反思犯了什麼錯誤。解出來了也一定要總結題目的特點，題目中哪些要素是解出該題的關鍵。不做總結的話，花掉的時間所得到的收穫通常只有 50% 左右。
在題目完成後，要特別注意總結此題最後是歸納到哪種型別中，它在這種型別中的獨特之處是什麼。經過總結，這樣題目才會變成你在此問題域中的積累。
做好總結，讓每道題都有最大的收穫。乙個月之後自己的狀態應該會有很大變化。
祝各位成長快樂。
如何有效地閱讀文獻並做筆記
一 記筆記 1 中心思想 經典句子 精巧的實驗方案 中心思想。盡可能用50個字左右，歸納文章 目的 表徵手段 主要結論 在總結概括，abstract，conclusion，discuss裡面，可尋。提煉出中心思想後，文獻要記憶的東西並不多。2 discussion中好的英文句型，要記一下。尤其是英文...
如何有效地報告Bug？
simon首先列舉了一系列拙劣bug報告的例子，包括 接著，他點出了報告bug的目的 在bug報告裡，要設法搞清什麼是事實 例如 我在電腦旁 和 xx出現了 什麼是推測 例如 我想問題可能是出在 如果願意的話，您可以省去推測，但是千萬別省略事實。然後，simon針對bug報告的不同問題分別提出了自己...
如何有效地報告Bug？
作者 崔康 發布於 十月 08,2012 自由軟體開發者simon tatham針對如何有效地報告bug發表了自己的看法，他列舉了一系列拙劣bug報告的例子，並提出了改正建議。simon首先列舉了一系列拙劣bug報告的例子，包括 接著，他點出了報告bug的目的 在bug報告裡，要設法搞清什麼是事實 ...