這篇總結是我在實際工作中的一些心得體會。主要是我在工作中犯的錯誤然後進行總結，也是對自己的警示。我在這裡先丟擲乙個觀點：技術能力不等同於工作能力，只能說技術能力是工作能力的一部分，在公司裡會發現有些技術不錯的程式設計師並不得志，有些技術不如他的反而得到晉公升
事件的背景是我在乙個小組周會上進行了乙個專案經驗的分享，準備上也有些倉促，大概兩三個小時寫了乙個簡單的ppt。講完後就被主管批。他說：「技術性的語言
相對較大。目前在db前面用快取擋了一層，對資料庫的壓力
減少許多。"這裡注意一下我在上面一句話中標紅的那幾個詞。這種詞是嚴禁在專案總結中出現，什麼叫相對較大，什麼叫減少許多，一切都要以具體的資料說話。相對較大之前的資料效能情況是多少，資料拿出來。你做了改動之後具體的資料是多少，拿出來。這前前後做乙個對比，很容易就得出你做這件事的意義是什麼。在這個專案中你具體做了哪些改進，而不是簡簡的說加了一層快取，這樣誰也不明白，你的快取加在**了，是怎麼實現的沒有說。我剛才的問題一說出來大家都明白，具體實施的時候很多人都會犯這樣的毛病。
在周會上分享的原圖我做了一些修改，這不影響接下來的分析。可能這裡很多人不明白我的圖。這裡我先解釋一下：這其實就是乙個把快取放到服務端還是放到客戶端的問題。大家都知道遠端通訊都需要走網路，有網路io的開銷。我上面所標識的memcache可以想像成集中式快取(比如說memcached，下面我都以memcached來寫，這樣可以和本地快取區分開)，memcached通訊也需要走網路io。我們原先的設計就是把讀寫memcached放到服務a，這樣就會至少產生兩次io，如果快取失效，走db的話最多會有三次io，但是在應用端加乙個本地快取。我的觀點是把本地快取去掉，然後把讀memcached放到客戶端，這樣大部分情況下只有走快取這樣一次io，對伺服器的壓力也減少很多。當然在會上我的觀點並沒有表達的很清楚。另外我這裡有乙個錯誤的觀點就是我覺得應該去掉本地快取去掉。我認為在這裡本地快取是不需要的。這樣一種觀點首先丟擲來是毫無意義的，因為要不要本地快取到底取決於具體的應用場景，而不能簡單的下結論，這個問題我並沒有全方位的去想。（關於效能方面可以參考《
效能調優思考》）
其實在案例二中我所犯的錯誤一案例一中犯的錯誤有些類似，如果說把讀memcached移到client端去做還有些說服力，那麼去掉本地快取就毫無說服力，因為我沒有任何的資料根據，只是根據一些臆測來進行。另外在整個討論中我的思路混亂，這也是沒有想清楚導致的。所以能不能全方位的思考乙個問題也是乙個人重要的能力。
這是乙個專案中的乙個案例，在提測的過程中竟然發現主功能有嚴重的bug。這樣的bug被測試發現確實非常慚愧，我把自己罵了好幾遍。可能每個人都會為自己辯解，誰寫**沒有問題。但是我在這裡說一下我自己的體會：一般來講寫**「一遍率（ps：整個邏輯盲寫，不做測試）」比較高的同學往往自信心比較高，因為他對自己的**有信心。而經常寫出來**有問題的程式設計師可能會心虛，即使你後面不管是自測還是靠測試把問題測出來，測出的bug越多，對於自己的打擊越大。特別是一些嚴重依賴於開發質量的專案，這樣會承受比較大的心理壓力。後果是什麼？有一點小的改動就會畏首畏尾，不敢改。但是真正要做到細緻，以我個人的體會來看，確實很難。
另外乙個就是千萬在寫**之前把整個的邏輯細細的想清楚，磨刀不誤砍柴工，真理。因為前期沒做好的後果就是後面一直在改**。這樣浪費了更多的時間。其實這是一種思維的轉變，很多人也包括我也認同一種觀點：**是寫出來的，即使前期想的再清楚，也會有遺漏。但是在工作中這是一種不太好的實踐。要慢慢的學會在前期做更多的工作，後期少的改動。這是一種功力，真的很考驗人。對於已經習慣這種思維的人可能不太難。但是如果習慣了在寫**中思考的程式設計師來說一定要力求改變，在這裡也是在警告我自己。
這裡簡單的說一下為什麼？道理很簡單，如果你是在寫**的時候進行思考說明是你喜歡發現問題解決問題的方式，這是一種被動的思維方式。這種思維方式可能做乙個程式設計師不會犯太大的錯誤，至多自己多加一些班。但是如果是乙個專案的owner，這樣極有可能犯重大錯誤，整個專案到後期發現方案不可行，這是要命的。千萬不要覺得這緊緊是一種工作方式的問題，這是思維方式的問題。要慢慢的鍛鍊自己在前期思維能力，就是主動思考，主動發現問題，這樣才可能把專案風險掌握在自己的手中。專案實踐有一句話：「有可能發生但是沒有發生的問題叫風險，如果問題已經發生，那就是真的問題」。
改變思維方式真的很難，要打破重來很痛苦，絕不會在我這裡寫出來這麼簡單，所以為什麼我覺得成功學看的熱血沸騰，發現自己一去做完全是兩回事。乙個簡單的習慣都很難改變，何況是對於一種已經幾十年的思維習慣。這裡我舉一種思維實踐，僅供參考。腦子裡想乙個問題，反覆的想，把它想的非常透徹，然後把這個問題丟擲來，看看大家都對這個問題的看法，再比對自己有哪些遺漏。這一方面是思維的過程，另一方面也算是經驗積累的過程。因為很多問題想多了考慮的面自然就會豐富起來。
上面講了三個案例對於我在工作中的一些心得體會，這裡面和技術沒有太大的關係。我在前言中也說到了技術能力不等同於工作能力。這裡可能很多人不認同，沒有關係，觀點可以求同存異。很多人可以從跳槽中獲得薪資的提公升，而公司內部的晉公升確很難（這裡不討**司等客觀原因）。因為在面試的過程中大部分只會考一些技術問題。而在工作中更多的是乙個人的綜合能力，而這是簡單的一些面試得不出來的。很多人嚐到這種甜頭就會一直依賴於這種跳槽來獲得薪資的提公升，然而更重要的是工作能力的提公升，工作能力的體現就是績效kpi。公司永遠看績效，技術再好，結果不好枉然。這裡又要叨一些玄話：以結果論英雄是公司的生存法則，也是個人的生存法則，過程是你自己的事情，對於公司而言只關心結果。
半年的工作心得與總結
眨眼間已經畢業半年,在這半年裡吃了好多苦,這些苦好多人也許都無法想像,現在覺得自己成熟了不少,為了適應,試圖著改掉了不少 毛病 但難以改變的還是自己的性格,不習慣那些場合中的阿諛逢迎和爾虞我詐,現在想想,也許我真的還沒有分清什麼是尊重，而什麼又是奉承。為了適應，在我認為是奉承的時候姑且想把它想象成是...
工作心得（一）
專案大約開始於年月日，由於之前的 不能滿足目前的業務需求，存在 資料不準確的問題，因此採購表需要it協助完善相關指令碼。通過前期的需求調研，了解了需要調整的格式 公式 邏輯等，經過乙個多月的深入研究，比較細緻的討論了指令碼的關鍵技術，在弄清楚需求和修改的方法之後，就是具體的實施了。對於這個專案我的心...
工作心得（二）
對於在這次轉換的過程中技術方面的心得，主要是建儲存過程方面的。關鍵是要有規範的思想，從儲存過程名稱到儲存過程內容都要盡量保持乙個良好的程式設計習慣。一 命名規範 儲存過程以p開頭，後面加具有一些含義的單詞 p sku mara，t mara bc 二 日誌記錄 建日誌表，插入日誌的儲存過程，生成日誌...