在很多人的潛意識裡，程式設計師就是一群口頭表達能力欠缺的技術人。作為程式設計師，我們必須用實際行動去反駁。
首先我們得學會展示自己的工作，自己開發出乙個軟體，要怎樣想其他人進行講解，偶然看到這麼一篇文章，覺得非常不錯，**之，順便附上自己的一些閱讀筆記。
採用ppt展示自己的軟體
採用以下思路做ppt分享：
1、首先預估好分享用的時間，一開始就要告訴自己時間有限，要講重點，不要事無鉅細。人的平均連續專注時間據說只有40多分鐘，大約是一節課時間。在我們平常緊張的開發節奏之下，大家可能會更容易疲倦，因此時間應該更短點。最好控制在20分鐘以內，再不夠就半小時，別超了。
只要一開始定好量定好時間，整個ppt分享的調調就基本定下來了，後面做ppt就容易把握重點，講ppt時也不會一開始就很悠閒，後來就越來越悠閒（讓聽眾想睡），或者反過來發現時間不夠用。如果覺得系統太大內容太多，那就將內容再壓縮，講的粒度再粗點。任何系統任何內容都可以有針對性地以任何粒度表述給別人聽，這是我讀研究生那幾年做學術報告的乙個重要體會。
2、ppt開頭，先告訴大家我做的這塊東西是為了解決什麼問題，實現什麼功能。比如我最近做的隨機名字搬到服務端的工作，是為了保證玩家申請到乙個隨機名字後，一定可以用這個名字建立新角色，而不會出現「名字被占用」的情況。另外，乙個新的遊戲系統的目的可能最好還從策劃的角度做一點闡述（順便幫助拉近程式與策劃之間的距離）。
3、如果系統涉及伺服器間、程序間的互動與架構，接下來就給出涉及的伺服器架構圖，這樣就讓大家知道我負責的系統在架構中處於哪個位置。比如我做登入的ppt分享，會通過架構圖告訴大家，玩家看到的每個遊戲服在技術上包含了哪些程序哪些資料庫，遊戲服和遊戲服之間怎麼劃分，大區和大區之間又如何劃分，遊戲服和遊戲服之間的互動是通過哪個程序。之所以會有這一步是因為我負責的工作經常會涉及框架搭建和程序間互動的事情，比如在老東家負責的集群後台管理與監控、補丁機制；還有現在負責的登入、跨服和gm工具的搭建。大部分系統應該不涉及這一步。
4、接著闡述主要業務流程。這時可以用流程圖，也可以用時序圖。我傾向用時序圖，因為這更便於展現程序與程序之間、類與類之間、模組與模組之間的互動。注意只要闡述主要流程、關鍵步驟就可以了，不要每個細節每個點都講出來。流程中的異常處理和保護邏輯統統忽略。如果有比較了解的同事問到異常處理的問題，可以一兩句簡單介紹一下處理方案，並告訴他ppt最後會專門講。如果流程時序比較複雜，可以先出乙個簡化的時序圖，然後再出乙個更詳細的版本。詳細版本的時序圖不一定要當場講（視乎同事的掌握程度和興趣），留在ppt中可供以後查閱。另外，在闡述流程的過程中，順帶介紹每個相關類、模組的職責。重要的協議、介面也在這一步給出。
5、介紹主要資料結構。我現在越來越有一種感覺，就是實際產品開發中，甚少有精妙複雜的演算法需要我們操心，但相對而言資料結構卻重要得多關鍵得多。採用什麼樣的資料結構在很大程度上可以決定你的**長什麼樣子、效能如何。對其他同事而言，他們知道了我的系統的資料結構，心裡對這個系統也會更有底。尤其我們做遊戲的，基本上都是在操縱玩家身上的資料，了解清楚玩家身上帶了什麼樣的資料非常重要。資料結構的描述，能畫圖就盡量畫圖；然後用開發語言寫出資料結構的示例，比如我們用lua，我可能會這樣描述玩家已經學會的職業技能：
job_skills_ =一目了然。
6、如果系統涉及資料庫儲存，則闡述資料庫表結構，並從資料庫中查詢幾條實際記錄，貼在ppt中，如果記錄太長就現場演示。不要將建錶用的sql語句直接貼在ppt裡。我嘗試過，即便表裡只有乙個字段，當我看見ppt上密密麻麻的一連串字母時，心裡都會有點抗拒厭煩。用**來描述資料庫表結構會清晰得多，大學裡的資料庫課程應該都這麼幹。
7、ppt最後，闡述開發過程中遇到的一些容易出bug的點，以及異常處理與保護邏輯。這時可以適當貼一些**。但也不要全貼上來。每頁ppt講乙個點，把相關函式貼上來；函式名和檔名保留，方便日後查詢；函式中和這一頁要講的異常點無關的**都刪掉，用省略號代替；關鍵的那一兩句用高亮顏色標出。大家在前面對流程和資料結構都有了解了，對這裡的細節問題就更容易理解，更能聽進去。到這一步，了解比較多的同事會問些更深的問題，這時就可以開啟原始**給大家看。
於是ppt到這裡就講完了。整個過程中，除非同事要求，否則只有到最後一步才展示原始**。記得有一次主程用ppt講單機版戰鬥的做法，整個過程中也是沒展示什麼**，但後來當我的工作涉及到這部分時，我能回想起他講的內容，並通過他的ppt快速理解相關**，應該說那次分享的目的是完美達到了。
給qc(quality controller(品質控制員),),一對一講**的思路也大致如此。不同的地方在於：給qc講**不會事先準備ppt，所以涉及架構、流程的東西最好在紙上畫。不要一開始就直接對著**講流程，從這個函式跳到另乙個函式，跳來跳去，那樣雖然自己講得很投入，但qc看著螢幕上翻來翻去的**也會暈——這是我親身體會，我就這樣聽過別人講**。雖然這時qc可以充當一部分小黃鴨的作用，但畢竟人家的時間也寶貴，所以還是讓人家聽懂掌握為好。另外，因為這時是一對一講，而且qc對我做的東西一般也比較了解，所以有的地方可以講得比較細。但最好也是放到最後講，先在口頭上或紙上把大致流程過一遍，然後再對著**把流程更具體地過一遍。
參考如何更好地給同事講**？ by zz翔
程式如何刪除自己
2005.2.27 private sub button1 click byval sender as system.object,byval e as system.eventargs handles button1.click dim delstring as string 要寫入批處理檔案的字...
程式設計師如何持續提公升自己的開發技能
這個世界唯一不變的就是變化，it圈子不外如是。計算機領域一直在改變，從基礎框架到計算裝置，還有幾乎每天都湧現出的新技術。因此，作為一名程式開發人員，我們更要通過不斷的學習來提高自己的技能。如何選擇讀物 利用好關注該類技術的那些 比如，在我學習ios的過程中，我一直關注 raywenderlish.c...
程式設計師如何持續提公升自己的開發技能
這個世界唯一不變的就是變化，it圈子不外如是。計算機領域一直在改變，從基礎框架到計算裝置，還有幾乎每天都湧現出的新技術。因此，作為一名程式開發人員，我們更要通過不斷的學習來提高自己的技能。如何選擇讀物 程式設計師需要的技能改變是如此之快，尤其是那些熱點的 快速演變的領域，找到這些領域合適的閱讀材料有...