一篇關于程序員性格的文章第1/3頁

2020-10-28 20:12:03

字體：大中小

來源：轉載

供稿：網友

    每個領域的工程人員都知道工具和他們所用材料的局限性。如果你是一位電機工程師，你就應明白各種材料的導電性和使用電壓表的各種方法。如果你是一位建筑師，你就應明白木材、混凝土、鋼材的性能。而如果你是一位軟件工程師，你的基本建筑材料是人的聰明才智，并且你的主要工具是你自己。建筑師是將建筑物結構進行詳細的設計，然后將設計藍圖交給其它人去建造，而你則是一旦當你從細節上對軟件作出設計后，軟件生成過程也就結束了。

編程的整個工作就如建造空中樓閣一樣――它并不是純粹的人工活動。于是，當軟件工程師研究工具和材料的必需性時，他們發現自己正在研究人的智力、性格，不像木材、混凝土和鋼材等可見的東西。

1  個人性格是否和本書的主題無關

編程工作極強的內部特點使得個人特點異常重要，你想想一天全神貫注地工作八小時有多么困難，你可能有過由于精力過分集中而今天無精打采的體驗?；蛴捎谏蟼€月過分投入而本月沒有一點精神，你也可能在某一天從上午8點工作到下午2點，以致于精神快要坍塌了。有時你從下午2點拼命于到5點，然后花費一周的時間修改你在其間所寫的東西。
    人們難以對編程工作進行檢查，因為沒有人知道你真正干些什么，我們經常有過這樣的體驗，我們花費8O％的時間進行我們所感興趣的20％的工作，同時花費2O％的時間生成其余80％的程序。

    你的老板并不能強迫你成為一個好的程序員，甚至過了很長一段時間你的老板也無法判斷你是否是一個稱職的程序員，如果你想成為一個高手，你得全靠你自己下功夫。它和你個人性格有關。

    一旦你自己決定成為一個高級程序員，你發展的潛力是很大的，各種研究發現，創建一個程序所需的時間比可達到10：1，同時也發現調試一個程序的時間，程序實現長度、速度、錯誤率和所發現錯誤數對不同的程序員其差別可達10：1。

你無法改變自己的聰明程度，但是你可在一定程度上改變自己的性格，已發現在程序員成為高級程序員的過程，性格是更有決定意義的因素。

2  聰明和謙虛

    聰明看起來似乎不是個人性格的一個貢獻。它也的確不是。恰巧的是，好的智力是和成為一個好的程序員有著并不嚴密關系的因素。

    為什么？難道這并不要求你有一個好的智力嗎？

    不，你不需這樣，沒有人真正同計算機一樣迅速敏捷。完全理解一個一般的程序需要你有吸收細節的很強的能力，并能同時理解所有細節，你很好地利用你的聰明要比你有多聰明更為重要。

    在 1972年，Edsger Dijkstra發表一篇論文，名字叫作“謙虛的程序員”。他在此文中主張所有的程序員都應盡力彌補他們很有限制的智力。那些最精通編程序的人往往是那些認為自己的頭腦是多么有限的人，他們是謙虛的。而那些最為糟糕的程序員往往是那些拒絕承認自己的能力不適應工作任務的程序員。他們的自我妨礙自己成為優秀程序員，你學到越多的東西來彌補你的大腦，你就越能成為一個好的程序員，你越謙虛，你取得的進步也就越快。

    許多良好的編程風格的目的是減少你大腦的負擔，以下是一些例子：

Ÿ “分解”一個系統的目的是為了使其更為簡單易懂。人們往往易于理解幾條簡單的信息而不是一條復雜的信息。所有軟件設計方法的目的是將復雜的問題分解為簡單的幾部分，不論你是否使用結構化、自頂向下或是面向對象的設計，以上目標都相同。

Ÿ 進行評審、檢查和測試是彌補人的錯誤的一種方法，評審方法部份源于“無錯編程”，如果你沒有任何錯誤，你就用不看評審你的軟件，但是當你知道自己的能力是有限時，你就應和別人討論以提高你的軟件質量。

Ÿ  將子程序編短一些有助于減少你的工作量。你根據問題而不是計算機科學術語編寫程序并使用盡可能高級的抽象思維，有助于減少你的工作量。

Ÿ 使用各種交談方式可將你從編程的死胡同中解放出來。

你也許認為靠聰明能更好地開發人的智力活動，所以你無需這些幫助。你也可能認為使用智力幫助的程序員是走彎路。實際上，研究表明，那些使用各種方式彌補其錯誤的謙虛的程序員們所編寫的程序，既易為自己也易為別人所理解，并且其程序中所含錯誤也少。實際的彎路是出現錯誤和影響進度的路。

3  好奇心

一旦你認為自己理解程序的能力是有限的，而且你意識到，進行有效的編程是補償自己能力的方法時，你就開始了你生涯中漫長的探索過程。

在變成高級程序員的過程中，對技術的好奇心是很重要的。有關的技術信息變化迅速。許多PC程序員沒有在什么機器上編過程，而許多程序員還沒有用過電腦的穿孔卡片。技術環境的特定特征每隔5到10年就發生變化。如果你跟不上這種變化，你將面臨落伍的威脅。

    程序員往往很忙碌，以致于他們沒有時間對更好地工作或對工作發生興趣。如果你真是這樣，你也不必在意大多，因為許多人都同你一樣，以下是一些培養你的好奇心的方法，你真應該好好學一學它。

    在開發過程中建立自我意識。你對開發過程越了解，不管你是通過對開發過程的閱讀或自己的觀察得來的，你就越能了解各種修改，并使你所在開發組向一個更好的方向前進。如果分配你的工作任務很少而不能提高你的技能，你也應對此滿足。如果正在開發有良好市場前景的軟件，你所學的一半知識將會在今后三年內過時，如果你不再學習新知識，你將會落伍。

在1988到200O年中，美國平均工作人數可增加11％到 19％，計算機系統分析員可增長53％。程序員可增長48％，計算機操作員可增長29％――在現有的1，237，000份工作的基礎上再增加 556，000份新工作。如果你在工作中學不到什么，你可試著找一份新工作。

    實驗。了解編程的一個有效途徑是對編程和開發過程進行實驗，如果你對所用語言的工作過程不甚了解，你可編寫一個短程序以檢查此特征并看其是如何工作的，你可在調試器中觀看程序的執行。用一個短程序而不是一個不甚了解的大程序來測試一個概念是很好的。

    如果短程序的運算表明程序運行結果并不是你所期望的，這時你應怎么辦？這正是你所需要的，最好用一個短程序在有效編程的一個關鍵方法上迅速制造錯誤，每次你可從中有所收益，制造錯誤并不是罪過，沒有從中學到什么才是罪過。

    閱讀解決問題的有關方法。解決問題是軟件開發中的一個重要活動，Herbert Simon曾報道過人工解決問題的一系列例子。他們發現人們自己通常不能發現解決問題的方法，即使這種方法很容易學到。這意味著即使你想自己創造車輪，你也不能指望成功，你可能設計出方車輪。

    在你行動之前進行分析和計劃。你將會發現在分析和行動之前存在著矛盾，有時你不得不放棄的數據和行動，對大多數程序員來說，問題并不在于過分分析和過分使用。

    學習成功項目的開發經驗。學習編程的一種非常好的方法是向一些優秀程序員學習。Jon Bentley認為你應靜心坐下來，準備一杯白蘭地，一枝好雪茄煙，然后如同讀小說一樣閱讀程序。實際上可能并不是這樣，許多人往往不愿犧牲其休息時間來閱讀――500頁的源程序，但是許多人往往樂意研究一個高級程序的設計，并有選擇地研究一些具體細節。

    軟件工程領域很少利用過去成功或失敗的例子。如果你對建筑學有所興趣，你可能會研究Louis Sullivan，Frank Lloyd Wright和 I.M.Pei的設計圖，你也可能會參觀他們的建筑物，如果你對結構工程有興趣，你可以研究 Broolyn大橋，Tacoma Narrows大橋以及其它混凝土、鋼鐵和木材建筑，你應研究你所在領域中成功或失敗的例子。

    Thomas Kuhn指出，任何成熟的科學，實際上是通過解決問題而發展起來的，而這些問題通常被看作本領域良好工作的例子，并且可用作將來進行工作的例子。軟件工程是剛入成熟階

段的一門科學，在1990年，計算機科學和技術委員會曾指出，在軟件工程領域很少有對成功和失敗的例子進行研究的文件，在1992年3月的“ACM通信”中有一篇文章主張對別人編程中出現的問題進行研究，總之，學習別人的編程是有重要意義的。

    其中一個最受歡迎的欄目是“編程拾萃”，它專門研究編程過程中出現的問題，這對于我們是有啟發的。

    你可能有或沒有一本研究編程的書，但是你可閱讀高級程序員所編寫的代碼，閱讀你所尊敬的程序員的代碼，或閱讀你并不喜歡的程序員的代碼，再將他們的代碼和你自己的代碼比較。它們之間有何異同？為什么會有差異？哪一個更好？為什么？

    除了閱讀他人的代碼之外，你也應讓其它高水平程序員評價你的代碼質量，找一些較高水平的程序員評論你的代碼，從他們評論中，你可剔除那些帶個人色彩的東西而著重于那些重要的東西。這樣可提高你的編程質量。

    閱讀手冊。手冊恐懼癥在程序員中很流行。一般來說，手冊的編寫和組織都不好，但是程序員對手冊的恐懼也和他們對書本的過分恐懼有很大關系。手冊含有一些重要的東西。所以花費時間閱讀手冊是值得的，忽視手冊中的信息正如忽視一些常見的首字母簡略詞。

    現代語言產品一般都帶有大量程序庫，這時，你花費時間查閱參考手冊是值得的，通常提供語言產品的公司，已經編寫了許多你可以調用的子程序。如果是這樣，你應弄懂有關手冊，每隔一段時間閱讀一下手冊。

    閱讀有關書籍和期刊。你應為自己閱讀本書感到幸運。你已經學到了軟件工程的許多知識，因為一本書每年都要被許多程序員所閱讀，讀一些東西可能使你的專業知識向前邁進一步，如果你每二個月閱讀一本好的計算機書籍，你的知識將會大大提高并能在同行中脫穎而出。

4  誠實

    編程生涯成熟的部分標志是不折不撓地堅持誠實，誠實通常表現在以下幾個方面：

Ÿ 不假裝你是一個編程能手

Ÿ 樂于承認自己的錯誤

Ÿ 力圖理解編譯器警告信息而不是對其置之不理

Ÿ 對你的程序有一個清晰的了解，而不是進行編譯看其是否有錯

Ÿ  提供實際狀態報告

Ÿ  提供實際方案評估，在你的上司面前堅持自己的意見

123下一頁閱讀全文

上一篇：加載flash9.ocx出現錯誤的解決方法

下一篇：關于三種主流WEB架構的思考