[[163850]]

自己做了n年的程序員，也和各種形形色色的程序員合作了n年，回顧總結，發現不管程序員性格是外向的還是內向的，是多話的還是沉默寡言的，他們或多或少都有如下的怪癖，區別只在于怪癖的嚴重程度。

1. 別人寫的代碼總是比自己差，我情愿重寫也不要用別人

這個現象不用多闡述，如果你是程序員，應該深有感悟。如果你還覺得感悟不深刻，你就看看你公司代碼里面是不是有類似于多個版本的諸如thread pool啊，object pool啊。

【總結】：如果有現成的允許使用的經過測試的代碼或程序庫，并且有人維護或維護成本可以接受，程序員應該盡量使用現有代碼和庫來節省時間和開發測試成本。

2. 喜歡把代碼寫的越簡短越好，語法越偏僻越好，別人越難看懂越好

最高層次就是：一行代碼，n個功能，別人都不懂，只有作者他自己懂。隨后，這個便成了炫耀的資本，到處說：“來，你過來看，知道這行代碼是干什么的嗎？恩，就知道你不知道，哈哈。”我每次都是這樣詛咒這些程序員的：“下次希望你去維護別人寫的這種代碼”。

【總結】：晦澀的代碼，維護成本會非常高。有時候，我情愿犧牲一些性能，也要寫易懂的代碼。所以，好的代碼不但要實現功能，更要好維護。我對好維護的定義標準就是：A寫的代碼讓B能很輕易的理解和修改。

3. 以為越接近機器碼的語言，就是高級的有技術含量的編程語言

在他們眼里，直接寫01010110才是最高技術，實在記不住，才用匯編。匯編還記不住，那才就用c/cpp。java/C#一點技術含量也沒有。

我想說，你們這個想法讓我這個寫html+javascript的情何以堪啊，我說，你們怎么不用刀去刻硬盤啊，那個最直接啊。實在不行，你用匯編寫個網頁我瞅瞅啊，那個我才佩服你呢。

【總結】語言本身沒有好壞之分，只是工具而已。好的程序員就是需要能在各種不同的情況下選擇適合的語言。

4. 程序結構大于一切，客戶需求可以放在一邊

我碰到有些程序員，真是極其注重程序的結構設計，當然這個沒有錯，我也相當認可，但是你知道的，客戶那需求可是一直要改啊改的，而且有一些是出乎當初我們預料的改動，但客戶才不管呢，反正按時按需完成就是了。但是，碰到有些程序員，好說歹說，他死活不肯改，說改了會影響程序結構啊，設計就很難看之類的。說實話，我也很認同，確實對結構有影響，但是我們得搞清楚誰是衣食父母啊，是客戶啊，不是結構！所以，我很想對這類程序員說：有本事你看著程序結構就飽了，別吃飯啊。

【總結】：正像我上一篇blog所說的，IT只是個工具。如果你造出來一個工具，即使再好看，再完美，如果達不到使用要求，那就什么也不是。

5. 對程序性能有時候很神經質

我記得有一次，我們需要寫一個桌面應用程序，有個程序員和我討論了很長時間到底應該用系統lock還是自己寫一個基于計數器的lock（這里我不得不說，那些程序員都是很好的程序員，理論知識很豐富深刻，以上海西南某高校居多）。我承認，基于計數器的lock確實比較高效，因為不用使程序陷入內核態。但是，對于一個本身就是慢速的用戶桌面應用，有必要自己實現一個高效lock嗎？自己實現，增加了開發測試成本，而且還增加了很多bug幾率。如果把這些時間花在改進用戶UI上，那不是遠比為了快那么幾十毫秒來的更有價值嗎？

【總結】：我們的時間和精力是有限的，所以有些事情，即使是對的，但是我們也不去做。因為如果我們把有限的時間和精力放在其他方面，我們可以收獲更多。這個就是所謂的性價比吧。

程序員一直給人印象是：性格怪異，智商高，粘著椅子，敲著電腦。我要說的是，這個都是誤解。其實現實中的程序員大多數是很開朗的，和其他人沒什么兩樣。但程序員有時候工作是非常辛苦的，可以為了修一個bug而通宵達旦，對生活和健康影響都很大。所以，我祝每個程序員都幸福健康。。。

最后，還是以一副圖片結尾，我覺得這個還是很形象的從某一個方面表達了程序員的生活：

[[163851]]