不要急著寫**。要先把問題弄清楚。
真正的理解需求，與產品一起了解需求是什麼。
一般這些產品通常不給足夠的時間來整理需求
他們通常無法提供前後一致或完整的需求意見，文件
要弄清楚其它程式設計師或其它團隊中程式設計師需要那些互動（如介面，伺服器，不同網域名稱呼叫），如何互動
使用白板交流
畫流程圖（uml或visio）
要花大量時間調研，確保需求符合真實情況，學習了解和同事的共同語言語義。
高效的辦法是不斷檢查自己對需求的理解，確保**和需求是同步的。
高效的程式設計師是頻繁的和產品經理、業務人員溝通交流，常常用白板與同事和架構師交流討論。
思考**的時間增加，寫**時間減少。
對問題的透徹理解使除錯**的速度更快
深入思考後的**速度更快
**長度更短
如果**整體上好的，那就重構**。
如果**整體上有問題，那就重新**
ps.
有效率的會議方式
開會有效率的方式 1.漫無目的的會議是最令人討厭的。2.開會的真正意圖應該是統一認識，查漏補缺，形成結論。討論只是其中乙個不太重要的環節。不要在會議上去思考問題和發現問題，開會之前這些問題都應該提前發現，並找出解決方案。3.開會一定有乙個強有力的有控制力的主持人，這樣能保證不跑題，開會有效率。這樣開...
寫有效率的SQL查詢（I）
1.1where條件的列上都得有統計資訊。沒統計資訊sqlserver就無法估算不同查詢計畫開銷優劣，而只能採用最穩妥的scan 不管是table scan還是clustered index scan 一般情況下我們不會犯這種錯誤 where條件裡不使用非索引列是個常識。索引上的統計資訊是無法刪除的...
寫有效率的SQL查詢（I）
io 至於為什麼，回頭補一篇 我們常說，要建彪悍的索引 要寫高效的 sql 其實最終目的就是在相同結果集情況下，盡可能減少邏輯io。沒統計資訊 sqlserver 就無法估算不同查詢計畫開銷優劣，而只能採用最穩妥的 scan 不管是 table scan 還是clustered index scan...