軟體開發的流程：需求調研，架構設計，開發實現，測試以及後期的維護工作。
任何乙個做過專案的人，無論專業或非專業程式猿都會接觸以及熟知的流程。
在此宣告，非專業程式猿，代指軟體開發流程完全都是自己操作，自己設計，自己開發。
專業的程式猿，代指軟體開發流程不是完全參與，而是參與其中乙個環節。畢竟是程式猿嘛，開發實現肯定避免不了。別人設計，自己開發實現。
專業或非專業最主要差別是：乙個是別人設計，自己開發實現；另乙個是自己設計，自己開發實現。
說實話，需求設計與開發實現，絕大部分不是同一人。在公司，都有相應的人員來負責軟體開發流程中一部分。公司中有牛x的架構設計師，苦x的程式猿。程式猿首先理解架構設計師的意圖，然後才能進行開發實現。
理解架構師的設計，也是一件不容易的事情。那如何更好地理解架構師的設計呢？
首先，設計人員，設計乙個東西，當然經過深思熟慮的，如此這般設計，肯定有他的理由。乙個好的架構師在整體就會決定乙個專案質量的好壞。好的架構師，不僅體現他的設計上，同時也體現他的交流上。即使設計的再好，開發人員理解不好，那專案可想而知。設計完畢，下一步就是他與開發人員的交流上了或者說他開會演講他的設計了。
架構師設計師開會講述他的設計時，我們應該注意以下幾點，目的是為了促進程式猿很好理解設計，便於開發實現。
第一：做好及時記錄。
這點不可或缺。因為程式猿不是自己親手調研需求，更不是自己親手設計的東東。所以初步理解別人的設計，必須做好記錄。第一次開會聽不懂，不可怕。可怕的是聽不懂而不去記錄。即使聽的懂，當時理解其設計，也許做好筆錄，這次聽懂，不代表會後理解。
其實，設計師講述，不能說完全正確，但是一般情況是百分之九十五以上正確。他的講述，也許會幫助你少走很多彎路。此時，設計師，就是乙個巨人。站在巨人的肩膀上，既然有免費的巨人，為何不搶占呢？
ps：此時，小弟正在做乙個專案，我們在已有的設計上，編碼實現。編碼之前肯定理解其需求設計，第一次當專業的程式猿，所以這次有點吃力，不像原來自己設計自己開發。其中吃力的原因之一，是沒有做好及時記錄。
比如，在編碼實現，突然對乙個問題疑慮，腦子用曾有過對這個問題的討論，但是對其當時的結論想不起來了。然後回頭找記錄，卻沒有找到相應的記錄。所以必須不得不重新交流，重新花費時間與合作者交流，與架構師交流。
第二：積極思考，及時消化理解。
架構師開會後，積極思考其設計的原因，並且及時消化理解架構師的講述。趁熱打鐵，會後，順著架構師的講解，自己理順思路，分析場景。因為時間一長，雖說有第一步的記錄，但是回憶，重新拾起思路，還是需要大量的時間。
ps：接著說自己接手的專案。設計師講述完後，由於各種原因，一直沒有進入狀態。所以後期理解消化時間長。
第三：記錄實現思路。
思考後，應該把實現的思路記錄下來。隨著思考的深入，對乙個功能的實現思路有所變化。不僅可以對比思考深入後的區別，同時也可以為編碼實現做基礎。設計與編碼實現，若是間隔時間長，沒有相應的思路記錄，是不是感覺很費力。若是原本你負責的卻有事離去，那若沒有相應的思路記錄，是不是你有點不負責呢？
第四：不斷溝通交流。
溝通交流，無論何處何地處於何種職位，都是不可缺少。更何況對於程式猿來說，因為公司企業全部是團隊開發，不可能一人獨戰。所以合作能力之一溝通尤其重要。憋了好幾天的問題，也許隊友的一句話會啟發你。所以不可閉門造車，正所謂三人行必有我師。
以上幾點都是本次實踐中的點點覺悟以及理解。只有更好的理解設計師的設計，才不會一遍遍推到重來。對了，程式猿不要急著開發實現，只有把思路理通理順，對於模稜兩可的問題，要及時溝通討論，否則會面臨重新開發的風險。
程式設計師快速技術提公升之道
不以賺錢為目的的技術學習提公升都是以失敗 沒提公升,沒效果,技術沒漲價 告終.今天看看這個技術點,明天看看那個技術點,都是零散的,沒有結構化,最重要的是沒有實踐,沒有和工作關聯,使用不到,可能過一段時間忘乾淨了 一定要想著自己學的這個技術點能快速提公升自己的工資水平,推薦過一段時間去市場上面試一下,...
程式設計師修煉之道
在所有的弱點中，最大的弱點就是害怕自己暴露弱點。j.b bossuet,politics from holy writ,1709 provide options,don t make lame excuses 提供各種選擇，不要找蹩腳的藉口 don t live with broken window...
程式設計師修煉之道
身為一名程式設計師，當一本叫做 程式設計師修煉之道 的書出現在面前，又怎能忍住不去看呢？於是，出現了下邊的讀書筆記。該書確實博大精深，包含了很多內容，但很多都是點到為止。那種心中有劍的感覺，躍然紙上，或許高手都是如此吧。根據多年武俠觀摩經驗，一定要把不懂的記下來，以後肯定大有用處。那就記。第一章 注...