修煉一名程序員的職業水準_轉

轉自：http://blog.jobbole.com/8960/

做者：林慶忠，1990年畢業於昆明工學院計算機軟件專業，後又於1999年畢業在南京大學 完成軟件工程專業碩士的學習，現供職於CNPC旗下的一個行業軟件研發中心，由於在網上看了許多有經驗的各路軟件開發人員寫的好帖，一時手癢興起，也湊一 篇壯壯聲勢。（伯樂在線注：此文寫於2005年）

假設你是一名軟件專業畢業的本科學子，如何在工做中修煉成爲一名有較高職業水準的程序員呢，本文試圖總結做者從事15年軟件開發工做的感想，但願對 有志成爲職業程序員的人有所幫助，並藉此機會感謝原昆明工學院計算機系的和智玲老師和張懷寧老師，特別感謝個人碩士導師，南京大學計算機系的博導鄭國樑教 授。

注：文章言辭尖刻，乃做者脾氣秉性使然，若是你看着有氣，就請多多見諒，放下別看了。

程序就是一系列按步驟進行的操做序列，它有好多種級別，好比最低級的微程序、次低級的彙編程序、高級 的各類編程語言程序、最高級的腳本語言程序，也許我列的不對，但不要緊，我要說的是無論是那個級別的程序，其本質都是操做的邏輯序列。大多數系統和應用程 序都是創建在高級編程語言上的，好比C、C++、C＃、FORTRAN、BISIC、JAVA等等，就讓咱們只關注這一級的編程能力吧。所以若是一個程序 員的邏輯能力不高，他永遠都不能成爲一名具備合格職業水準的程序員，咱們在下面的討論有關編程能力的方方面面，最終都是爲了最大程度地提升和實現一名程序 員的邏輯能力。

1、掌握基礎知識：十六年寒窗的持續積累

從7歲讀小學起，通過16年的學習，你從軟件專業本科畢業後，必須完成如下幾門專業課程的學習：計算 機組成、操做系統原理、彙編語言、數據結構、編譯原理、數據庫原理、軟件工程、結構性設計語言(PASCAL、C)、面向對象設計語言(C＋＋、C＃)、 計算機網絡等，你最好還懂一些算法分析、分佈式系統、計算機圖形學、形式邏輯、人工智能原理、軟件設計模式、軟件構架/框架等研究生的課程，16年來，你 積累的除了知識，更重要的是造成最適合本身的學習方法和工做方法。這些是你具有程序員職業水準的基礎能力，不要受什麼計算機軟件怪傑之類傳奇的影響，那不 過是小几率事件，並且這些怪傑們就算沒有讀過軟件本科和研究生，也每每自學了大多數專業課程，極可能比在校學習的學生對這些課程的精髓部分理解的更好，還 有他們的工做方法和思惟方式是特別而高效的，但廣泛性差，能夠借鑑，不宜模仿。好，因此如今你只須要問問本身，那些課程和知識都學會並掌握了嗎？若是是， 那就準備好進行實踐了。

2、在實踐中提升：成爲一名高水平的Coder

好了，你畢業了，在校功課都不錯，也找了一個專業對口的工做，你想大展鴻圖了，但是別急，你的翅膀還不夠硬，不信咱們說來看看。

一般，你在工做中都會用到某一種單位/公司固定的操做系統和編程語言開發環境，好比Windows、 UNIX、LINUX等操做系統，又好比用VC、VB、PB、Delph、JAVA、Motif/XWindow、QT、OpenGL、 OpenInventor等編程語言和開發環境，咱們在後面把它們合稱爲開發環境。就在校學習的有關開發環境的知識而言，大概你距工做須要的差距是不小 的，當某個操做系統和編程語言環境成爲你的飯碗時，就不該也不能用經過課程/認證考試之類的眼光和要求來評價你的能力，即便你能考100分。

你須要深刻地 學習該操做系統和編程語言環境的各種開發手冊的全部內容，你會說大多數你都用不上，其實你既對又不對，對的是單從使用的角度而言，你確實用不上開發手冊的 大多數內容，好比龐大的VC開發類庫和複雜的開發環境，你在實際工做中能用到的不到總數的1/10或1/5，不對的地方在於，你用到的部分不是孤立存在 的，它們是整個體系中的一部分，只有對整個體系有了一個較完整的瞭解，才能駕輕就熟、爲所欲爲地用好你用到的部分，你纔算初步具有在這種開發環境下進行 Coding的職業水準(還遠不夠程序員的職業水準呢)，而這只是剛開始。如何才能真正掌握一種開發環境的全面的知識呢，最原始的辦法就是讀開發指南/教 程、參考手冊，通常來說，學習開發指南/教程時，你若是是一個認真的人，都會完成5/10~7/10左右內容的學習和練習，若是你想成爲職業選手，就應該 完成9/10以上內容的學習和練習。參考手冊不一樣，大多數所謂的「程序員」們只是用到了才翻翻，這差的太遠了，你應該象讀開發指南/教程同樣，每一個環節都 要讀，好比VC，參考手冊中的每一個類，類的每一個函數，都要讀上幾遍，它們每每是一小夥一小夥地糾纏在一塊兒使用的，開始時讀得你毫無頭緒、心煩意亂，不要 緊，還有一手呢，若是你開發環境安裝的全面，它們每每都有開發商作的demo例子可看，你就進入另外一個境界了，開始時你關注demo中的具體技術，後來你 發現這些demo的程序寫的都還算不錯，結構簡單但合理，若是你真的用心，就必定能發現一些個別的demo是極品，它所展示的程序邏輯結構是你設計不出來 的，你如今有點更關心它的程序設計構架，甚於對你原始目的(某種相關的技術/技巧)的關注，這時的你，開始了從一名Coder向一名Programmer 的轉變，你會忍不住要看看開發商提供的源程序，好比.h和.cpp，一般你會找到include路徑下全部的.h程序，你才知道，哇！好多好多東東在參考 手冊中都沒提到，你要學的太多了，沒時間顧及其它的業餘愛好了，如今知道爲何程序員是年輕人的職業了吧，你要有足夠多的時間才行，即便你的智商有 160。

若是你走到這一步，在你工做的團隊中，已是常常有人向你請教技術問題，常常有人請求你幫忙debug，你已經是公認的「高手」了，別得意，由於你 仍然是個Coder，爲何這麼說呢，你想一想，你已深刻了解了這個開發環境中的各類技能，知道一名Coder如何用好這些東西，但是你能設計的出提供給 Coder們用的東西嗎？唔……，你想了想，可能還不太行。對了，就是這樣，你仍是一名小我境界的程序員呢，本質是個Coder，固然已經是一名高水平的 Coder了，然而你須要進一步登堂入室才能成爲一名真正的程序員。

讓咱們繼續吧，一般你都是從精通一種編程環境開始的，假設你已經較爲精通在Windows下用VC開 發軟件了，這時在技術和技巧方面你將面臨一小一大兩個挑戰，第一個小挑戰是若是公司/單位改換了開發環境，好比用LINUX下的QT交互語言工具進行開 發，你不過是把前面掌握VC的過程再來一遍，因爲在主觀上經歷了VC工具的學習過程，在客觀上各類開發環境都有太多類似的方面，這回你掌握的應該較快。要 當心，在這時第一次誘惑之門打開了，由於你感受良好，看！這回這麼快，我就這麼好地掌握了新的開發環境，你開始關注其它暫時還用不到的同類環境，好比 VB、Delph、JAVA，如飢似渴地掌握各類開發工具，證實本身的學習能力和價值，但你忘了一點，你仍然是個Coder，只不過是一個在好多開發環境 下都能編程的Coder，就像你生活在中國，於是精通了漢語，工做須要你又掌握了英語，而後你就來了勁，把俄語、日語、阿拉伯語、拉丁語，等等等等，都學 習個遍，我只能說，有點BT。你忘了本身是個職業人，同一類的東西工做中用獲得才需學習，太多太多的Coder們喜歡在一塊兒比較和炫耀本身會掌握了幾種開 發工具，不信你看看招聘時的求職書就知道了，sigh！他們中絕大多數人永遠都只能停留在這個層次上，心浮氣躁，一輩子都再也當不成真正的程序員了。總結一 下，其實你在這時須要的是對本身掌握新開發環境的能力的自信，而不是一遍遍地重複來證實本身。

第二個大挑戰就是你明白了只掌握VC是不夠的，你發現本身有 點淺薄，有不少東東你會用但你不太懂，不少方面支持VC編程的知識你都沒掌握，好比操做系統的源碼、網絡協議知識、Windows 的註冊表、進程和線程的基礎知識、硬件驅動方面的知識、ActiveX、Windows 龐大的 API，又是一個等等等等，這些基礎知識的學習和掌握但是要花費大量時間的，你再一次深切地感到時間太不夠用了，由於這時的你大概有許多俗務纏身了，因此 有點沮喪，還不用提IT業天天不知有多少新東西在發佈，KAO，永遠都跟不上，越拉越遠了。哎！彆氣餒，振做一點，你仍是忘記了本身是個職業人，既然好多 東東在工做中你永遠都沒機會用，那麼幹嗎要學呢？用什麼才學什麼，最多預測到立刻要用什麼，先一步學什麼好了，要知道沒有人是真正的、無所不精的全科大 夫，除非你是神，但若是你還在耐着性子看這篇文章，你確定是我的嘛。

OK，通常工做後三五年，你經歷了上述過程，經受了誘惑和考驗，終於明白了一個道理：你要的是強勁的 學習知識的能力，是對某種軟件知識/技能的有深度的精通，一種摸到它的根的深度，而不是已掌握的技能的種類和數量。這時不管誰用他掌握了多少種你不會的技 能來嚇唬你都沒用，你對他的層次只有蔑視。經過幾年的學習和工做，要記住最重要的一點，永遠最重要：對本身學習IT知識能力的自信，一個程序員一輩子都要不 停地進行高強度的學習，用心問問本身，有沒有這個自信？別用虛榮心來騙本身哦，若是沒有的話，那就沒必要花費你寶貴的時間向下看了，做者在此感謝你有耐心看 到這裏，如今建議你關閉這篇文章，趁着年輕，當機立斷轉行吧！

3、注重邏輯：成爲一名職業程序員

好，再前進一點點，你就要成爲一名職業程序員了，讓咱們繼續來完成這個任務吧！咱們在前一節提到過， 「你發現一些個別的demo是極品，它所展示的程序邏輯結構是你設計不出來的，你如今有點更關心它的程序設計構架，甚於對你原始目的(某種相關的技術/技 巧)的關注」，其實你是在關注這個demo程序做者的思惟邏輯，全部程序的本質就是邏輯。技術你已經較好地掌握了，但只有完成邏輯能力的提升，你才能成爲 一名職業程序員。打一個比方吧，你會十八般武藝，刀槍棍棒都很精通，但就是力氣不夠，因此永遠都上不了戰場，這個力氣對程序員而言就是邏輯能力(其本質是 一我的的數學修養，注意，不是數學知識)。邏輯能力也是逐步提升的，開始時你必定是用直觀的邏輯能力來編程的，怎麼想就怎麼編，不對就再改，在改進中提升 本身的邏輯能力，從直觀邏輯能力提升到抽象邏輯能力，這是很正常的。提早說一句吧，到達邏輯能力的至高境界，其表現是用數學語言來描述問題和問題的解決辦 法，高度抽象！好，說回來吧，你要提升邏輯能力，最快的辦法就是讀別人寫的結構優秀的程序。優秀的代碼是百讀不厭的(這句話是我抄來的)，暫時放放對其中 某種技術和技巧的關注吧，你要推導和學習的是這些好程序的邏輯結構，它們是被精心設計出來的。

你能夠先捂住這個demo程序，本身設計一個功能相同的程序 結構，而後比較一下demo的程序結構，若是差距較大，那你就不該簡單地改進一下，而是要把demo做者設計的過程在內心復原一遍，作到這一點也許有點困 難，但這種事乾的多了，你就會越幹越快，愈來愈駕輕就熟，你的邏輯能力飛速提高，你能看得上的邏輯結構優秀的程序開始很少了，下一步就是練習。從工做中開 始吧，若是你有空閒，你須要作至少兩類練習，一類是算法練習，全部的經典算法都是經典的邏輯，題目有的是，像個好學生同樣吧，每一年的國內國際編程競賽都有 邏輯要求很是高的題，你能夠只選一兩道難題來作作。當你能夠把複雜的單遞歸程序(只有A調A)變成非遞歸程序時，已經不錯了，若是你能看得懂雙遞歸程序 (A調A、A調B、B調A、B調B都有)，我爲你鼓掌！你沒必要往下看了，我有點很差意思啦――班門弄斧，你快滾蛋吧！另外一類是把之前和當前你工做中你不滿 意的程序推倒從新設計一遍，這很是重要，省時省力，由於你熟悉需求，技術上也沒問題，目的就是改進程序的邏輯結構，很划算哦，惟一要克服的就是：你對推翻 之前工做中那點小小成就的心理障礙，若是你真想優秀，說句粗話：這點心理障礙算個屁，一遍遍反覆地推倒已有的成果只能使本身快速進步，放手幹吧，沒什麼好 惋惜的，馬恩早就在《共.產.黨宣言》裏說過了：在這個過程當中，你失去的只有鎖鏈(禁錮你思想的鎖鏈)。

讓咱們來總結一下，通過自我否認後，再生的你儘管對過去的「業績」還有一些眷戀，但已經是一個初步具有職業水準的程序員了，掌握了相應的技術和技巧，具有了較高的抽象邏輯思惟能力，最主要的特徵是：能自覺地自我否認，不斷地追求更高水平的邏輯能力。

在這個過程當中，若是你能注意如下一些小的方面，你前進的步伐也許會快一些。

從編譯原理的角度來理解你工做中使用的高級語言，若是你作到這一點，至少有兩個好處，第一個好處是避免一大堆低水平重複出現的編譯錯誤。一名優秀的 Coder平均在一個工做日中應該完成200行以上的源碼，其編譯錯誤應該控制在5個如下，要知道這200行源碼不是一次完成的，因此大多數狀況下你都要 追求一次編譯經過，而一名職業水準的程序員，應該進一步作到即便用purify這類的工具來檢查源碼，也不會存在嚴重的內存泄露。第二個好處是能夠提升源 碼的可讀性和效率。規範地編寫你的代碼使你本身的邏輯清晰，由於你明白多加幾個括號和空行、多換行對齊、多註釋，編譯器是會自動識別的，不影響程序執行的 效率，反過來，控制好遞歸調用和循環內的if語句纔是提升程序效率的關鍵，要全力避免遞歸，但要深入理解遞歸，能經過本身創建堆棧來把遞歸程序轉換成非遞 歸程序，要求仍是較高的哦！

避免思惟陷阱，只要你是人就必定有本身的思惟慣性，這必定又會表如今你的程序邏輯中，有時你就是從這個慣性中跳不出來(誰都有這個時候)，但要內心 有數才 行，因此你須要幫助，若是你有幾個水平相若或更高的職業夥伴，太好了，當遇到花30分鐘還打不下的bug時，就別浪費時間了，找他們吧，最要緊的是能思路 清晰明確地表述你的問題，一般你本身在這個過程當中或者夥伴中就有人把問題解決了，又快又好。另外，有幾個能夠良性競爭的職業夥伴是人生的一件幸 事，1+1>2，你們各有所長，你最好作到及時公開你的成果，技不壓身嘛，IT發展的這麼快，你再優秀，那點東東也沒有什麼值得隱藏的，因此你能夠 技術或水平不夠高，但千萬不可讓真正具備職業水準的選手鄙視你的職業品質和行爲。

有本身debug的特色，下面的說法做者不敢太確定，只是經驗之談。即便在VC這種高度完善的開放環境下，你仍然應該要求本身僅憑打印語句就能 debug。這也有兩點好處，第一個好處是，遇到bug你會認真想問題所在，而不是用debug工具一步步簡單地追蹤卡在哪兒了，你定位bug範圍的方式 是從大到小、從粗到精，這是一種自頂向下的思惟方式，而用工具追蹤，容易造成自底向上的思惟方式，這不算好，你應該先看到森林，再看到樹木。我反覆說起： 程序就是邏輯過程，大多數程序從main函數開始，是由數據結構和功能子程序組成的一個樹形結構的邏輯過程(要認清即便是面向對象的程序語言也是同樣 的)，它的執行過程是深度優先的，但你定位bug應該是廣度優先的，好好想一想這一點，嗯？第二個好處是強迫你思考並記住而不是用工具看到調用過程，你大腦 的抽象邏輯思惟能力和胳膊上肌肉的力量同樣，都是練出來的，若是你的bug是程序結構上的邏輯錯誤引發的，這一點就很是重要了，順便說一句，最難打的 bug就是程序邏輯結構錯誤致使的bug。你要是真正明明白白地認識到這兒了，那我就沒什麼東西能夠告訴你了。總之，程序員的職業水準：生產效率和程序質 量，主要是取決於源碼中bug的數量和debug的速度，而不是取決於編寫源碼的速度。給你一個我本身定義的考查一個職業程序員的指標：一個合格水準的職 業程序員，編程的時間若是算一份的話，其累計debug的時間不能超過一份，真正職業高手累計debug的時間應該控制在0.5份如下，如何？你關上門悄 悄問問本身，你花費在編程和debug上的時間比例是多少？若是你把程序員做爲本身一輩子的職業，那麼就永遠都要牢記一點：追求作一個0 bug的優秀程序員！這是任何一個想成爲職業程序員的人的理想，請相信：堅忍不拔地追求實現這個理想將讓你出類拔萃！

作好程序的單元測試，這是另外一項考查你是不是一名具備合格職業水準的程序員的一個必要指標。其實在你拿到需求的時候就要準備單元測試用例了，而且這 些用例 將直接影響你的詳細設計(有關軟件設計原本是該放在第四節講的)。咱們仍是打比方吧，當你拿到一個需求時，除了分析它靜態的功能外，還應明確它動態的操做 /執行過程，把這個動態過程明確地用流程圖畫出來，好比分爲A～Z的26步，其中A又能夠進一步分解爲A1～A5的5步，直到不能再分解爲止。又好比說 A3步不可分解了，那麼你應該把A3步的正常操做和全部五花八門的異常操做都列出來，確保正常的操做確定正確，異常的操做起碼程序不退出才行。這樣你就要 寫好多好多的測試用例，說句老實話，我也歷來不寫！但我通常會列一個提綱，好比A3步有正常的操做a、b、c、d、e共5項，異常的操做有f、g、h、 i、j、k、l、m、n共9項，你在進行單元測試時都應該跑一遍，這樣的程序都還不敢說質量如何好，但起碼能夠說較穩定吧！若是要想在進行單元測試時幹得 快、效率高，那麼在進行詳細設計時，你就應該把A3步中對全部正常操做和異常操做的判斷都設計好，在編程實現A3步時，使得程序的結構合理高效，對不對？ 因此，若是你在工做中是割裂地看待軟件工程中從需求、分析、設計、編程、測試等各個環節，恐怕水平頗有限喔！但若是你在分析需求時就能看到測試的問題，並 改進設計和實現，爲此作好相應的準備工做，嘿嘿，整個軟件開發過程你的效率會高不少，一般你在一個開發團隊中就會高度自信的，你已越過當一名偏頗、露骨的 高手的境界，成爲一個平靜的高手，這但是The best in the best！，用周星星的話說：是高手之高高手，由於別人看不出你高在哪兒，沒見你有什麼高招或特拚命幹，但反正你就是幹得又快又好、又省力。關於進行單元 測試還有不少複雜的方法，在此本文只提到了最基本的一點，目的是讓你在工做上考慮周全、安排有序，其它的本身琢磨吧，沒有人能替你吃飽飯！

若是你是用C＋＋編程，我再簡單談談有關內層釋放的一個小技巧，就是對全部你編寫的類，在構造和析構函數中加打印語句，統計每一個類在運行程序時構造 和析構 的地方，若是是配對的，那麼起碼沒有對象類一級的內層在程序運行結束時沒有釋放，而後你就能夠把打印語句刪掉了，招數雖土，但管用！

還有其它一些好習慣，在這裏我隨筆寫一些，你要是有不一樣見解也請一笑過之吧。編程時應該對齊縮進，一個縮進用一個tab鍵，通常是4個空格，嚴格遵 守開發 團隊的編程規範也是很是重要的。一個子程序不該超過30行(不算空行)，其內多重循環不該超過3層，不然都應該分裂成兩個子程序，個別算法程序能夠長一 些，但也不宜超過200行。一般一個類的全部成員函數總和不宜超過1500行，多了就應該考慮分解成兩個類(這個工做最好在設計時就完成)。每完成一小段 程序，好比15～30行，就當即編譯運行，不要僞裝高手，先敲它一大堆程序，再編譯運行，妄想一次成功，體驗一種假爽的、虛榮的快感，或炫耀給別人看，這 麼作只能證實本身是一個徹徹底底的傻瓜，裝酷而已。由於只要有一次不成功，你就會花費大量的時間來調程序，別人的進度在這時就遠遠地超過你了，日常心是 道，仍是修煉真功夫吧！孫子兵法裏關於這一點有明確的闡述，我就不引用了，但建議你真的不要這麼幹，除非你確實就是這樣老是一次就成功的天才，那你還看這 篇文章幹什麼呢？我又不是寫給大家這些天才們看的。再就是有學會買好書、讀好書，關於計算機和軟件方面的書太多了，時間有限，好比有一個叫侯捷的傢伙，幾 乎寫的每本書都不錯，張國峯的C＋＋編程也不錯，這只是個人我的意見啊，好書多着呢，列出來比這篇文章長好多倍，我就很少說了。還有一招，要是你運氣好， 能搞到一些著名軟件系統的源碼，好好讀讀吧，在此我只能告訴你，Linux操做系統的一些源碼不錯，是開放的，你能夠合法地搞到，其它的不要說是我建議你 侵犯知識版權啊！

4、天生神力：成爲系統分析員

原本就論述如何成爲一名職業程序員而言，本文已基本完成任務了，但《菜根譚》有言：竭世機樞，似一滴投於巨壑，窮諸玄辯，若一毫置於太虛。既已乘興到此，何妨多置一毫於太虛呢，做者不才，乾脆盡興寫算了。

你要是運氣好，直接進入了一個嚴格規範生產的軟件企業就業，剛開始就應該是按別人作好的軟件設計來實 現編程，你能夠有機會直接學習軟件設計，當你積累的足夠多了，可以對其中的一些設計提出好的改進建議，並且幹得又快又好，就會漸漸地展露頭角，我相信你終 有一天成爲一名軟件設計人員(注意，不是軟件產品設計人員)，步入系統分析員的行列，但這還需其它的一些條件和自我修煉。若是你在一個不規範的軟件企業工 做，那也不錯，你極可能直接就有機會進行軟件設計，而後開發、測試，甚至還不得不本身定義需求，把軟件開發過程的各個環節走一個遍，固然這樣對你的要求更 高，並且你也不容易獲得及時有益的指點，在正態分佈的狀況下，你應該是成長的很慢。但無論就業的單位如何，若是你決心要成爲頂尖軟件職業選手，一般什麼客 觀困難都阻擋不了你，然而你我的的因素可能會阻止你的前進。下面提出的觀點純屬一己之見，傷人自尊之處做者在此提早道歉，並建議你除非對本文有強烈的興 趣，不然就請直接看第五節或放下別看了。醜話已說在前頭了，在各類軟件開發組織的發展過程當中的事實也證實，只有少數程序員能成爲系統分析員，我想這一點不 是我杜撰的吧，所以你要是在看接下來的部分時感到氣憤難當，那也實在沒着，純屬活該，由於做者只是在說明本身的觀點而已，你最多能夠呲之以鼻，表示一下你 的輕蔑好了，但沒有任何理由能夠罵人！

做者本身沒有到微軟面試過，但身處軟件行業，關於微軟的許多東東固然仍是有耳聞的，聽說微軟招聘一名 程序員要過五個已經成爲微軟程序員的面試關，並且是一票否決制，又聽說大多數面試題並不是編程，而是一些有關邏輯和智力的題，做者私下也作過許多流傳的微軟 面試題，並對此作法深覺得然。程序的本質就是邏輯，因此幾十年前就有人提出編程是一門藝術，而藝術是要靠天份的，這一點少有人反對。一我的的邏輯能力能夠 不斷提升，但其能到達的終極邏輯能力的層次一定爲其天生智力所限制，這一點就讓人不易接受了。可笑啊！人們能夠公開認可本身沒有某種或所有的藝術天份，但 要說本身邏輯天份不夠，換句話說認可本身笨、IQ不夠高，每每是要怒髮衝冠的，其實這又有什麼區別呢？話都說到這兒了，再次建議你若是不夠自信，就跳過這 一節吧，直接看第五節，好嗎？

好了，把話題說回來，你已經成爲一門合格的職業程序員了，若是要想成爲從事軟件系統設計的職業系統分 析員，第一件事就是悄悄找一個標準智商測試的網站或其它渠道，嚴格認真的測一測本身的智商，若是IQ低於130 (正常智商是110)，就請別費勁了，打消掉成爲系統分析員的念頭吧！好！好！先請你冷靜一下，好好想一想，其實微軟面試時就是在測你的智商和邏輯數學素質 呢，這就是本節的標題爲「天生神力」的緣由，由於設計就是從無到有地進行創造，不管是軟件仍是其它行業都同樣，能夠有借鑑的，沒有現成的，設計就是創造！ 若是你IQ在130以上，又決心要當一名職業軟件系統分析員，其實你不過是要準備好吃更大的苦而已，有什麼好虛榮的呢？

修煉仍是從基本功開始的，過程和成爲一名職業程序員差很少。必須使用設計工具這一點是不用多說的。在 工做中，你基本上遇到的是兩類方式的設計，一個是結構化設計，另外一個是面向對象設計，就我的經驗而言，面向對象的設計更好。若是你工做中不得不採用結構化 的設計，你必須熟練地掌握數據流圖和控制流圖的分析和設計，通常來說，若是你把一個軟件中用到的數據模型設計好了，針對功能化的流程，不難設計出數據流 圖，但下一步設計控制流圖纔是挑戰，若是你按照需求走不通設計好的控制流圖，那麼你或別人在按照這個設計編程實現時，一定也走不通，沒有奇蹟會發生，仍是 在設計階段嚴格要求吧，又有一點須要牢記：返工是最慢的。當你在進行控制流圖的設計時，也不要妄想獲得需求人員提供給你明確的指點，一般他們要是可以把需 求的功能和操做次序寫完整的話，你應該就感恩戴德了，從需求中整理出功能、操做的拓撲次序和條件是你做爲系統分析員的職責。看看，要是沒有一點圖論的基礎 和拓撲學的入門知識，你是當很差一個職業系統分析員的，即便你天賦不錯，必要的數學和邏輯素質仍然不可或缺。也不用氣餒，永遠沒有最好的設計，只有更好的 設計，反覆地進行設計迭代，敢於推翻舊的設計，你將快速進步。

若是你在工做中是採用面向對象進行設計的，那就更有利了，有關面向對象設計的書太多了，不用 做者在此多費口舌，建議精讀一本經典的書，好比北大邵維忠等編譯的《面向對象的分析》，有些方法和技巧可能過期，但其邏輯的基本原理是很是正確的，其本質 是，你在邏輯上是如何認識這個世界的，你就是如何設計軟件體系結構的，而後讀讀其它書，舉一反三，本身創造機會多實踐，成功天然會到來的，總之，無論是結 構化設計仍是面向對象設計，評價一下本身的軟件系統設計方案吧，有好多指標呢，好比是否均勻和平衡？局部獨立性強不強？有沒有歧異的結構？有沒有層次太多 或太少？有沒有某個層次太大、太廣？是否是邏輯結構先複雜了再化簡的？仍是隻會設計簡單的，複雜不起來(這一點是笨哦，若是出現屢次，請你不要意氣用事， 轉行吧)？最重要的一點，是否容易理解、實現和改進？你本身會得出評價的。若是有機會看到別人的設計，必定不要錯過學習的機會，本身推導一遍，認真比較比 較，獲益會較多。

走到這一步，你就應該關注設計模式了，首先仍是學習，這方面的好書有的是，但通常在工做中用到的設計 模式較爲單一，應該多嘗試一下其它的設計模式。其次必需要明白設計模式不是設計思路，也不能代替設計思路，比方你要從A到B修一條路，設計模式只是讓你選 擇，是修水泥的仍是柏油的？是高架路仍是普通的，但線路必須你本身定，而線路就是設計思路，模式對思路是有影響，但不能代替，因此若是你的智商高達 250，我相信你直接用匯編語言也能寫出面向對象的程序來。第三在此有一個陷阱，不少系統分析員生搬硬套設計模式，全然不懂如何融會貫通，在你的一項具體 工做中，每每是以一種設計模式爲主，其它模式爲輔的，思惟不拘泥於形式纔是關鍵，並且也爲你到達更高的軟件設計的境界作好準備。

唉！都不知該怎麼向下寫好了，由於已達到做者水平的極限了，我胡亂說一點，你湊合看吧。軟件設計最終 的層次是：以沒法爲有法、以無限爲有限，這句話是李小龍說的，不是我說的。再拾人牙慧一把，類比一個故事吧，金大俠在《倚天屠龍記》裏講到張無忌初學太 極，學會的標誌是把剛學的招數全忘了，記住的是太極的道理和精神，和李小龍有些類似喔，軟件設計也同樣，忘記全部的設計模式，爲所欲爲進行設計纔是至高境 界，因此你能到達多高的軟件設計的境界最終將取決於你的哲學素質，這一點實在是很差寫啊，你本身領悟吧！做者只有祝福了！

5、職業人的終極目標：全面修煉，成爲Leader

這一節更很差寫，涉及到太多其它非技術方面的因素，特別是我的人生觀和世界觀的修煉，若是本帖的點擊 率超過做者私下指望的一個數值，那我就爭取盡力厚着臉皮再補上吧。我只說一句，雖然你們都知道軟件開發是一個團隊性的工做，但追求參與一個大型軟件系統的 成功開發，是一名軟件人員的本能，就像拿破崙說的不想當元帥的士兵不是好士兵，因此不追求實現大系統的軟件人員，也不是一個好的職業軟件人員，但你只有成 爲Leader，領導一個優秀的軟件開發團隊，纔有機會實現這個終極職業目標，對不對？

好吧，無論你如今的感覺如何，我都謝謝你能讀到這裏！我不習慣假歉虛，就不說什麼做者水平有限，本文 拋磚引玉，歡迎你們批評斧正之類的客套話了，雖然做者水平確實有限。因此我認爲你儘管有權砸磚，但實在不必搞回帖、或回罵、或頂之類的玩意兒，我只是盡 興寫一點多年從事軟件開發工做的體驗，所以接下來我就高掛免戰牌，不回覆任何回帖了。再次謝謝你能有耐心讀到這裏！但願本文對你有所裨益，祝你成功！再 見！