最近新玩具太多，差點讓我的blog被N82系列文章淹沒了。幸虧即時看到qing兄兩篇不錯的文章 程式設計的兩個觀點 (1/2)和程式設計的兩個觀點 (2/2)，讓我決定還是來早點把這個系列寫完，不然就快變富奸了。
qing兄的兩篇文章指出程式員的兩種型態，一是重視演算法、資料結構、執行效率的「效率魔人」，二是重視程式架構、擴充性、彈性、可理解性的「架構狂」。這兩種人其實都很好，要完成一個偉大的軟體，團隊中兩種人一定都要有。比較糟糕的是，有很多「第三型態人」，他們的信念只有一條：「程式只要會動就好」。第三型態人不在乎效率，也不管架構漂不漂亮，上面要求他做什麼，他就想辦法東湊西湊，從Google找程式剪貼，從MSDN抓範例來用，反正只要能隨便測過一個case就能交差了。
其實第三型態人也不一定是不懂演算法、不懂design patterns，他們常常只是因為火燒屁股了，就不管三七二十一先弄出可以動的程式再說，效率或架構等到下一階段再來改就好…。問題是，下一階段又有新的功能要做，這些人再度面臨抉擇時還是會決定先讓程式「會動再說」。我看過很多各式各樣的程式員，只要碰到這種人，同樣的過程是履試不爽不斷出現。
所以要成為一個優秀的程式設計師的關鍵是什麼？關鍵不在於coding速度有多快、懂多少演算法，或是背了多少patterns，最重要的是「熱情」！
偉大的程式設計師都非常喜歡寫程式，寫程式的過程是一種絕妙的享受，他們執著的地方或許不同，可能是程式的效率，也可能是開發的效率，甚至是架構的彈性或是程式碼的精簡美觀程度，但他們都非常想要並堅持自己應該寫出「好程式」。熱情能驅動他們把軟體的某一個面向雕琢到極致，這需要超乎常人的毅力和堅持，以及絕不向壓力妥協的精神。只要具備這種熱情，不管你在乎的是什麼，都可以成為一名偉大的程式設計大師。
P.S. 雖然這篇文章講的東西很八股，但我發現這真的非常重要，看一個人的熱情就能知道他做出來的成品是什麼樣子。如果是我來面試，我一定會在面試時觀察這人有沒有喜歡寫程式的熱情，沒有熱情的人容易向現實壓力低頭，也不會要有不斷精益求精的信念，在如此競爭的時代是很難生存的。
P.S.2 要追求神乎其技前，當然要先知道自己的目標是什麼樣子，所以我本來想在這篇寫一個優秀的程式設計師應該要有的特質和能力，但才寫了第一項就落落長。所以還是等待下一篇再繼續這個主題好了。（路人：「這不就是擺明要當富奸嗎！」）
請問一下能否推薦C語言的好書？
在你身上我看到無比的熱情…
難怪你都要坐在冷氣房。
真的是很enjoy在寫程式阿
能見到樣的發光體，真是三生有幸
geekzyc:
C語言的書嘛，只能推經典的The C Programming Language了！
tomAman:
照你這麼說我不待冷氣房好像自己會燒起來一樣….(這樣我就能加入驚奇四超人了?!)
Pingback: 寫程式之道 « 凍啡走甜
第三種人也是很有用的。
在大型軟件開發過程中往住需要製作大量的原型模型，模型本身不要效率不要架構，只是要成形快，能表達設計概念就好了。有這種人在，還真是省功夫。另外兩種人也不用被這類工作累倒。
到底什麼是富奸?
富奸就是漫畫獵人的作者，因為他有習慣性的拖稿，所以已經變成拖搞的代名詞XD
Pingback: 追求神乎其技的程式設計之道(五） | vgod’s blog
Pingback: 追求神乎其技的程式設計之道(八） | vgod’s blog
Pingback: 網站製作學習誌 » [Web] 連結分享
Pingback: 好文: 追求神乎其技的程式設計之道 | TechNow 當代科技 - web host by CommuniLink
Pingback: 追求神乎其技的程式設計之道（九） | vgod’s blog
Pingback: 追求神乎其技的程式設計之道（十） | vgod’s blog
Pingback: 千万莫当温水中的青蛙 « 冉翔 ~ At World's End
不好意思，其實我只是想問………PS3在哪裡~”~
熱情….等你回台灣從事資訊業codeing的工作 就會知道 老闆跟你想的不依樣囉…
每各工程師都有寫程式的原始熱情…但是公司環境 上司 專案時程 是否允許你這樣做就得看工作命運了
業界很需要 “架構狂”!
今天又回頭來看此篇文章，我心理只有百感交集。先說我的資歷好了，三年半的軟體工作經驗，有著「架構狂」的「熱情」，但經驗仍嫌不足。
出生在「台灣」這個小地方，碰過嵌入式Linux 1年資歷 ，目前這份工作是我人生主要第二份工作，同事曾問我，為什麼不往現在熱門的Linux走？
其實我不想明白說，進了那個職務，老板只會當你是現成的，根本不會考慮訓練你需要花多大代價。
所以我只選擇當個「助理工程師」，努力的對目前的專案研究「架構」到底怎樣才會好？但最近上面主管抱怨，我專案拖太久，他的要求只有到「先求有再求好」，意思是他並不是很在乎架構(即使他軟體有10年經歷)。
真正寫過Linux的都知道，你不懂「架構」，想學嵌入式linux，只有處處碰壁的份，我已經退而求其次，只想自己專研「架構」，卻發現這樣也會抱怨。
面對瞬息萬變的市場，「冰淇淋三明治」的保存期限能多久?在我的有生之年會出現「銀彈」或「速食架構狂」?
我希望有，畢竟那算「奇蹟」，有著奇蹟的世界，我或許會覺得，痛苦也值得。
hi vgod,
看了你這篇文章，非常有心得，彷彿講中了我的痛處。
我是第二型並在學習第一型的人，我覺得程式寫得不夠漂亮會對不起自已。
但相較於第三型人，開發時間確確實實會長些。
然而，現實是這樣的，那些第三型人成為主管們眼中的”效率魔人”，交待的事辦得又快又好，加薪、升等都有”他們”，是手中愛將。
而，”我們”成為效率B咖或甚至是沒掌握好就拖搞的人…
我想主管們是真的也沒時間去看架構完不完整或code有沒有寫得亂七八糟。
而會稱”我們”及”他們”，是發現這事發生得頻繁，我想，就算我找到下份工作也會有滿大機率遇到相同問題。
所以，想請你有沒有什麼比較好的解法呢？
謝謝。
這一切都是trade-off。
對你來說程式寫得漂亮很重要，但因此失去了即時完成的時間；但另一種人來說，他們可以用很醜的方法很快完成，但接下來要再繼續在這基礎上做更多修改就「應該」要花更多時間。
要注意的是，我說應該是因為事實不見得是這樣。如果你用很漂亮的程式完成了工作，但接下來後續的維護和修改沒有幫你或者整個團隊省到時間，那其實是代表你之前的時間白花了。相反的，另一種人雖然草率的寫完一開始的程式，但他可能是發現這程式也只會被用一次，用完就再也不會被維護了，這時他其實是做了對的選擇，幫團隊省下很多時間。
如果你對程式的架構和style很講究，這是好事。但同時，在有限的時間和資源下完成也是很重要的。如何拿捏其中的平衡就是個人本事了。