程序員中的怪象

① 為什麼都說程序員不好

因為程序員這個職業的工作狀態不利於身體健康，要長期伏案工作，而且經常處於一種忘我的狀態，自己很難控制工作時長，而且有些團隊承受任務期限的壓力，不得不經常加班。

所以大家都說程序員不好。

② 程序員的鄙視鏈是什麼

編輯器的：

Emacs → Vim → Sublime → Word → Power Point

Vim →→ Emacs + evil插件

notepad++ → notepad

all → Source Insight → notepad

編程語言的：

asm → C ↔ C++ ↔ Java ↔ C# → JavaScript → VB → VBScript

Common Lisp ↔ Scheme → Emacs Lisp →→ Python

Python ↔ Perl → shell

PHP → all

操作系統的：

Unix → Linux → Windows → DOS

Solaris →→ 其他Unix

*BSD ↔ System*

OpenBSD ↔ FreeBSD → NetBSD

Arch → Debian* → Redhat*

Debian → Ubuntu

Fedora → CentOS → RHEL

OSX → all

IDE的：

Emacs + plugins ↔ Vim + plugins → 其他加插件的編輯器

IntelliJ → Eclipse → NetBeans

Code::Blocks → CodeLite

VS → all → Turbo C 2.0

③ 我們對程序員的刻板印象就是格子襯衫加禿頂，實際上他們真的是這樣嗎

在現在的生活之中，身邊的朋友從事程序員工作的人也變得越來越多了，有很多人對於程序員這一個群體的印象相對來講也是比較客觀的覺得他們總是穿著格子襯衫，並且頭發也是比較稀少的，面對這樣的情況會讓很多人產生一種錯覺，就是在見到了程序員之後都覺得他們是這樣的形象，那麼實際生活中的他們是不是真的是這個樣子的呢？

雖然在平常工作比較繁忙的時候這些程序員的形象相對來講是比較枯燥無味，並且也不會給大家帶來特別多的驚喜，但是在放鬆的時候，這些凈程序員們也能夠散發出年輕人的活力，並且能夠和其他人很好的玩在一起，所以大家對於程序員千萬不要有這樣的固定印象。

④ 什麼是程序員編程中的老大難問題

上周，我發起了一個「程序員編程中的老大難問題」的投票，主要是基於最近Quora上的跟帖討論。根據大家的反響和投票結果，有一項投票遙遙領先，穩居第一——對於軟體開發人員來說，最大的難題是：如何命名（例如：給變數，類，函數和過程命名等等）。
對於這個結果，我多少有點意外，因為作為一個多年的開發人員，我不會投給這一項（我想我會投給「修改或維護別人的代碼」）。但是真正讓我驚訝的是，看起來好像不怎麼重要的命名居然排列第一，跟期待的結果實在差太遠了。下面是投票結果的分布圖。

該結果是來自Quora問答網站和更早的Ubuntu論壇跟帖的4500個開發者的投票。「如何命名」一項的選票幾乎是其它八項的投票結果的總和，哇！
的確，這些基於自我篩選的群體的投票結果是完全不科學的。但是我認為這個結果還是有一定意義的，換句話說，如何命名的確是個很棘手的問題，許多非編程人員可能會意識不到。
幾年前在StackExchange社區里對於這個話題剛好有個跟帖，為了強調這一點，我引用了一些內容是關於程序員在編程中對於命名的的痛苦和糾結。
「我確實在編程的時候花了很多時間在考慮如何命名。」
「我不得不同意命名是一門藝術。」
「如果你想要提高代碼的可讀性，命名的確很重要。」
我認為最後一條抓住了部分核心，解釋了命名為什麼會這么難，因為它太重要了。准確的命名可以提高代碼的可讀性，讓人容易理解，方便調試，也給以後修改和維護你的代碼的人帶來方便。一旦開始做了，很快你會發現要想出一個簡潔又准確的名字沒那麼容易。就像Jeff Atwood 所寫的：
「想出好的命名的確很難，但是有難的道理，因為好的命名需要只用一兩個單詞出表達你的根本意思。」
而且，許多人認為，正確的命名能幫你寫出好的代碼。如果不能為一個變數或者函數想出一個清晰又簡潔的名字，那可能是你的代碼有問題。那樣的話，你就得考慮重寫或者進行代碼重構了。

⑤ 為什麼有的程序員的代碼結構混亂

程序員都有一顆工程師的心，所以當他們到一片新的場地想做的第一件事就是，將舊的一切推倒重來。是的，他們決不會滿足於簡單的增量勞動。

或許這種微妙的心理定位可以解釋：為什麼程序員進入新項目組後寧願丟掉舊代碼重新寫，也不願意修修補補。他們認為舊代碼簡直一團糟。

但是，事實上真是這樣嗎？你之所以認為舊代碼一團糟，其實是由編程的一個基本定律決定的，那就是：寫代碼容易，讀代碼難。

為什麼你覺得舊代碼異常混亂？因為讀代碼更難。

這大概就是代碼Reuse難以實現的原因。 這就是你組里的每個人都喜歡用不同的功能將分割的字元串轉換成一個數組。比起猜測舊的功能是怎樣實現的，重新寫一個自己的功能要簡單和有趣多了。

作為這個公理的推論，你可以問問身邊的程序員他們正在奮戰的代碼怎麼樣？「簡直是一塌糊塗！」他們肯定會這樣說。「我簡直想推倒重來！」

為什麼認為代碼這么糟糕呢？「額，看看這個功能，竟然有兩頁長！完全不知道這些東西為什麼在這里！完全不知道這些API是干什麼的。」他們會這樣回答你。

漫畫：讀別人代碼是一種怎樣的體驗？

曾經，Borland的創始人 Philippe Kahn當初就是向記者們吹噓：Quattro Pro會比Microsoft Excel要好用得多，因為它是從頭開始編寫的，全部都是新的源代碼！

但是，認為新代碼比舊代碼好簡直就是荒謬。舊代碼是已經運行過的，測試過的。無數的bug在被發現前都上線運行過，發現之後程序員們可能在花了好些日子才修復了這些bug。這種修復可能是一行代碼，也可能是幾個字元，無數的時間和精力都花在了這些bug修復上。

當你決定拋棄這些舊代碼從零開始的時候，你也丟掉全部前任努力的結果。

新代碼一定比舊代買好？NO，重寫可能會帶來更大的風險。

對技術領導者來說，重寫項目的代碼也是一個異常艱難的決定。因為從公司層面說，重現代碼甚至會威脅產品的市場競爭力。一旦決定重寫代碼，那麼與競品相比，你可能落後了2~3年——在軟體行業，這時間可夠長的。

你理想中的新代碼會帶來產品功能的提升▼

但事實上，即便重寫的新代碼可以實現舊代碼的所有功能和需求，但是為產品帶來的市場競爭力只有邊際提升。因為重寫用的新技術、新語言、新框架並沒有給產品帶來質的飛躍。

更不用說在重寫的漫長過程中可能會遇到一些意外情況，比如：

1、缺錢：資金鏈的斷裂▼

2、缺人：核心程序員離職

最終導致效果不佳：達不到原產品應有的所有功能和需求，白白浪費了時間和金錢，也丟掉了市場競爭力。▼

所以重寫代碼意味著，你在把自己置身於非常危險的境地，可能幾年後你也寫不出比以前更好的代碼。你只是花了一大筆錢把已經存在的代碼又寫了一遍。

當你覺得眼前的舊代碼很爛時，該怎麼辦？

你覺得舊代碼寫的很爛，那又怎樣呢？它們已經上線，已經在實際運行中經受住了考驗。所以當你發現前任留下的代碼亂七八糟的時候，不妨冷靜下來，從以下三個方面入手理解代碼、改善代碼：

1、代碼的結構有問題

如果一段網路代碼突然彈出了自己的對話框，應該是UI代碼需要被處理。這些問題可以被解決掉，你要一次次小心地移動代碼，重構，改變介面。還需要一位細心的工程師立馬仔細地檢查這些改變是否有問題，從而不打擾到其他人。事實上，甚至比較大的結構變化也可以不扔掉代碼來完成。

大牛程序員Joel Spolsky回憶說，曾經在某個項目中，他和他的團隊花了好幾個月重新架構在一點上：把代碼動來動去、清理、創建有意義的基類，並創建了模塊之間的完美介面。但是他們始終非常小心翼翼，並沒有產生新的bug、也沒有丟掉任何舊代碼。

2、代碼的效率不高

曾經，Netscape的渲染代碼被傳非常緩慢。但事實上，這只會影響該項目的一小部分，這部分是你可以優化甚至重寫的。你完全不必重寫全部代碼。優化速度的1％工作量，會讓你獲得99％的爆炸性提高。

3、代碼寫得很醜

有些代碼真的寫的很醜，比如Joel曾參與一個項目，開始用下劃線做開始的成員變數約定，但後來改用更標準的「M_」。所以一半的功能用「_」開始，一半用「M」開始，這看起來真的很醜陋。但這個問題5分鍾就能解決，而不用從頭開始寫全部的代碼。

最後，你要記住，從頭開始再寫一遍並不意味著你會寫出比以前更好的代碼。因為你沒有參與到上一個版本的創建，所以你其實根本就不算有經驗。一旦你准備推倒重寫，你可能會再犯一遍版本一犯過的錯，甚至會產生更多的新問題。

一個總結：

面對糟糕的舊代碼，Keep Calm & Carry On !

在大型商業項目中，推倒重來是非常危險的行為。當然，如果你是在做實驗，想到新演算法可以隨時重寫。

⑥ 程序員都有怎樣的通病

中國的大部分程序員都有一個通病，眼高，手低，知識面寬，深度淺；有自己的理想和目標，但實施的決心太小，還總閑工資太少，覺得老闆太扣。於是總是「跳呀跳」。

⑦ 外界對程序員都有什麼樣的刻板印象

認為程序員非常不懂得人情世故嗯，認為他們只知道每天自己去編寫程序，他們的世界只有0和1，他們的情商很低，並且，不善於與人溝通交流，喜歡宅在家裡，朋友很少

⑧ 論：為什麼別人眼中的程序員都是傻×

｛要嫁就嫁程序員！錢多話少死得早｝這句話本身帶著玩笑又警世的意思。可以說，每一個程序員一天絕大部分的時間都貓在電腦面前，程序員作為一個高端行業的設計人員做一個程序員的前提條件是一個超級網蟲，熬夜輻射傷身傷害眼睛傷害腦細胞飲食不規律什麼的，在電腦面前總是最容易得到的毛病。一般程序員都會有，損害健康損害壽命。程序員是一個高端的職業，往往開發出一個程序就可以賺到比平常人超出幾倍十倍百倍不等的金錢價值，當然了這要看開發出來的東西有沒有經濟價值。但是往往一個值錢的程序軟體什麼往往要很多很多程序員日夜煎熬加班猜得出的成果，所以就是賺錢也可能搭上了健康，死得早。奉勸人們不要為了工作金錢搭上了健康。

⑨ 為什麼程序員的思維很難理解

1、程序員的思維比普通人要嚴謹。
對編程有一定了解的人都能理解這一點，一是一二是二，電腦不認模稜兩可的回答，因為「模稜兩可意味著更多的可能答案」，所以你跟程序員交談的時候，如果你問他「為什麼要這樣問」或「你為什麼聽不懂」，你就會知道你自己的描述有多麼的不嚴謹了。
最簡單的例子，你媽媽讓你去市場買水果，如果看到有蘋果就買一個蘋果，看到梨就買兩個。你看到市場有蘋果和梨，你會買什麼回家？
首先給出一個大前提，在程序上不存在「潛台詞」或者「潛規則」這種東西，唯一起作用的只有「字面意思」。
一般人肯定是買一個蘋果和兩個梨。當然程序員也不是腦子有坑，以一個正常人的思維考慮也會買一個蘋果和兩個梨，但是看到這問題的第一個瞬間的直覺反應，卻是「如果看到梨就買兩個蘋果」。這個問題不存在潛台詞，所以所有人都會直接從字面理解老媽的意圖。
按照程序的邏輯分析，這句話共分為兩個部分，代表兩個程序任務。「如果看到有蘋果就買兩個蘋果」為任務一，條件是「看到有蘋果」，目標對象「買蘋果」，數量「一個」；「如果看到有梨就買兩個」為任務二，條件是「看到有梨」，數量「兩個」，沒有給出新的目標對象。
因此按照程序邏輯來講，第二句話將繼承上一個目標對象，也就是「買蘋果」，所以這句話被看起來像職業病一樣的思維直接翻譯成了「如果看到有蘋果就買一個蘋果，如果看到有梨就買兩個蘋果。」

————————————————————

2、程序員看問題比一般人透徹。
這是職業特性導致的，因為電腦編程的嚴謹性，因此程序員面對一個問題、一個需要實現的目標或者一個bug時，他會思考更底層的問題，並且會習慣性採用歸納法來盡量避免以後可能遇到同樣的問題。
比如用輸入法輸入中文的詞句，有的時候打出了一串拼音，然後按下數字2選取發現不是自己想要的詞，然後發覺數字1對應的才是自己想要的，刪掉，重新輸入拼音，這次按下數字1的瞬間卻發現兩個詞的位置調換了，於是又刪掉重新鍵入，這次認真地看了看，終於選對了想要的詞的序號。
這個時候你會說，啊，我下次應該更小心一點，不要馬虎大意想當然，看清楚了再點。
程序員不這么想，他會想，導致這個問題的看來是輸入法的「詞語順序自動調整」功能，他會自動監測使用者輸入的各種詞語的頻率，來自動調整詞語的順序，底層代碼實現的邏輯很簡單，每個不同的詞對應一個從輸入法安裝到現在的輸入次數的計數器，直接按計數器排列順序就好了；也有的輸入法會監測你輸入後是否會將其刪掉，那麼這時候會被智能識別為打錯字，計數器不會加一。
然後再一思考，這種功能一般都是可以開關的，如果我想要靠記憶記住順序使用而不用輸入法自動調整的話，比如對漢字輸入的速度有一定要求需要考記憶記住漢字序號，我只需要進入輸入法設置將其關掉即可；如果我想要它幫助我調整詞句位置，但是又不需要頻繁地調整，那麼在我有工作需要的時候我會提前關掉，平時開啟即可；而如果我想單純依賴這一功能，那就不用管它，下次看清楚再選就好了。

⑩ 為什麼都說悲劇的程序員程序員很悲劇嗎

情景一：

程序員的悲哀，不是情商問題，不是衣著問題，更不是自黑之類的，悲哀是並沒有決策權。項目做成什麼樣，你有決定權嗎？那是領導和產品經理的事。注意流程是這樣的：領導或經理決定要改需求，然後通知你，然後你等設計給你圖，然後你做好。程序員只是一個執行者，別人叫你幹啥你就只能幹啥，除非產品是傻逼到讓你實現不可能的功能。最後項目做壞了，裁員了是誰？程序員。

做程序員越久，越是感到：我們就是新時代的手工藝者。只有少數的人，從手工藝者，變成了發明手工藝製作機器的人，少部分人變成了設計手工藝品的人，少部分人變成了車間主任罷了。

「碼農」這個詞有著深深地悲哀。

歡迎大家都來吐槽！