不要一直低頭做事，要抬頭思考。
人不能從重複的事情中獲得成長。
做事閉環，一件事有始有終，讓正確的事情，持續發生。
所謂靠譜的人，就是做到：凡事有交代，件件有著落，事事有回應。
事事有回應：體現的是乙個人內心的責任感，是對他人起碼的理解和尊重。
件件有著落：按照既定時間或計畫，或者約定固定時間週期反饋工作進展。
當日事，當日畢。當周事，當周畢。
盡量使用有表達力的**來代替注釋，但以下型別的注釋不應該省略：
組織以及法務資訊
對意圖的注釋，既為什麼要這麼做
與常規處理不相符的地方，註明需求單號以及業務特殊處理的簡要說明。
沒有用的**，要堅決去掉，而不是通過注釋來掩蓋它。
寫對code review友好的**：
在進行需求討論時，心中要區分技術方案和業務方案，不要在需求討論階段過多涉及到具體技術細節。這裡，筆者感覺考慮技術實現的限度。作為實現方，可以簡單提下：
除開上述兩點之外，在討論時，要更多地從開發角度來簡化業務流程。主動思考達到同樣的目標，有沒有更加簡單直接的方式？
第二點是考慮業務流程中的異常處理。一般的業務流程大多描述的是正常流程，在實際開發時，會有很多異常情況，針對這些異常情況的處理流程，是需要重點討論的。產品從需求角度，很難考慮完全異常情況，開發參與需求討論需要強調這一點。
第三點，對需求中什麼是重要的功能，什麼是無關緊要的功能，達成一致意見。在開發資源有限的情況下，重點討論和完成重要功能。
第四點，在進行需求討論之前，將待討論的需求文件發出來，讓參會者有個初步的認識，這樣好在討論會上有更加深入的討論。
第五點，當需求中涉及ui、產品、開發各方面意見時，作為核心的產品，不能只當各個參與方的傳話筒，而是要根據自己對產品的理解，將別人的訴求或者說要求轉換為可供討論的事項，並推動各方達成一致認同。如果僅僅是**ui的建議，直接貼到討論群裡，其他參與者還要理解ui的建議，並據此作出各自的判斷，這種討論效率，不如產品與ui討論梳理後，直接給出結論，討論該結論是否可行來的直接、高效。
在準備使用新功能替換舊功能時，新舊功能涉及到的介面較多的情況下，強烈建議保持原有功能，新的功能採取逐個替換的策略，完成乙個介面之後，需要反覆檢視該實現，簡化相關操作，直到每一步操作都是必要的，做好乙個頁面後，其他類似頁面可參照修改。
當在基類中提供函式a，隨著不斷的使用，發現該函式需要改進，但直接修改，會影響外部眾多使用者，這時如何做呢？
可行的重構方案如下所示：
基類a：
class base
// 使用方式
base a;
a.fun();
class derive : class base
// 新的使用方式
derive a;
a.fun***();
警惕功能的可配置性，不要覺得加上可配置後，整個專案就更勝一籌。可配置性只是錦上添花，更重要的是，不是說系統支援可配置，就要在任何地方都提供可配置功能。
極端點說，如果一切都可配置，那麼一切都沒有可配置的意義。提供策略以及使用策略的機制要謹慎，不要引入那些不必要的可配置功能，使得整個系統過於複雜。
合併**的實踐經驗：
從分支合併到主線，只合併自己的提交，不要擅自合併他人提交，因為你不知道其他人提交背後的邏輯以及關聯關係。
單次合併控制在5~10次提交以內。如果單次合併太多，可能會有多個衝突要解決，這些衝突之間有可能有先後關係，增加解決衝突難度以及出錯概率。
從分支合併到主線，要包括原始檔的父目錄以及上層目錄，直達工程根目錄。這樣，可在後續的合併中，可檢視到該次提交是否已合併到主線上。
當你的修改依賴其他人的提交，而其他人尚未合併到主線上來。這個時候如何處理？
方法一：通知其他人，將你依賴的部分先合併到主線上，然後你在提交。
方法二：自己合併依賴其他人的部分，並通知相關人員。
推薦使用方法一。
在平時的工作中，從提交記錄上看，感覺有些同事的**提交很隨意。
有同乙個檔案，一會兒提交一次，一會兒又提交一次，看下改動內容，應該是在修改時漏掉了某些地方，緊接著再打乙個補丁。
在不同業務模組（例如a、b、c和d）中，同樣的功能都受影響。該a模組後提交一次，改b、c模組時再提交一次，改d業務提交一次。這種方式，感覺沒有一次把一件事做完，會不會還有其他模組也有同類問題，但是改漏了呢？
筆者的觀點：
針對問題一，能不能在提交前，仔細回顧下提交改動範圍，多考慮下發生場景，有沒有同模組下其他函式也有類似的問題，可以一併改完，自測完再提交。
針對問題二，能不能將不同業務中的同樣功能提取出乙個獨立模組，其他業務方都呼叫該模組，有問題只改這個模組。如果不方便提取的話，要求低一點，能不能同型別的修改，合併為一次來提交。這樣，既方便審核者的審查，也方便自己後續回顧。
**提交注意事項：
第三方發過來的文件、設計稿、**什麼的，千萬不要貿然修改，一旦有修改，就不好說清楚後續的維護者是誰了，會造成很多不必要的麻煩。
當涉及到跨團隊協作時，你不清楚某個問題的負責人，於是就會詢問多個同事。如果其中乙個人向你解答，那麼，除了向他表示感謝之外，還需要主動告知其他尚未回覆你的人，此問題已得到別人的解答，以防浪費他們的時間。
更近思考一步，出現上面情況的原因是，某個問題無法找到對應的對接人，因此，會去詢問多個。可以在組織層面上進行優化，這裡我有幾點想法：
部門對外提供的服務、介面文件是聚合形式，每個介面或者模組上要註明介面提供方，要具體到負責的介面實現者最好。
從內部來說，每個功能的負責人負責維護各自模組的功能說明以及注意事項，在乙個公共wiki上對外提供服務，告知使用方。
為避免不同人針對同樣問題重複諮詢第三方，需要將經常諮詢的問題做乙個qa頁面，任何人在詢問時，先自助在qa中查詢問題關鍵字，看能否解決，如果不能解決再去詢問，得到確切答覆後，記得把問題以及對應回覆整理到qa頁面。
構造函式呼叫順序：
基類成員建構函式
基類自身建構函式
派生類成員建構函式
派生類自身建構函式
析構函式與構造順序恰好相反：
派生類自身析構函式
派生類成員析構函式
基類自身析構函式
基類成員析構函式
MongoDB應用實踐思考
最近研究mongodb，利用其可以簡單快速地搭建一套靈活的no schema儲存系統。本文通過論證和分析需求，利用mongodb快速搭建了一套具有良好效能及可用性滿足上億規模的儲存系統。在關於nosql資料庫的選型上，需要結合自身資料模型 訪問方式以及成本等方面的考慮作乙個權衡 trade off ...
學習 知識 實踐 思考 心態
學如逆水行舟，不進則退，當我工作需要學習新東西，當我希望身邊同事也能夠快速提高時，我就會想我們如何才能夠快速的學習並應用新的知識？我們必須也應該一直保持積極主動 快樂學習的心態。之前寫過一篇博文 堅持是學習的最好方法 表明學習的總體方法是堅持，堅持學習 堅持實踐 堅持思考。本篇我將從更具體的一些層面...
敏捷開發思考
敏捷開發確實是乙個非常不錯的開發模式，但是它有太多難以實現的地方。首先就是對開發人員的要求太高。幾乎要求每個專案的開發人員都要了解專案架構，熟知各種設計模式原則，有豐富編碼經驗。這一點很難做到。對於我這菜鳥來說，看敏捷開發最大的收穫就是知道了軟體是怎樣腐化的，在這裡面我看到了自己前一段時間程式設計的...