【文章內(nèi)容簡介】 的成功，也讓我意識到了自己在 Python 分析器里的一些突發(fā)奇想的設(shè)計的正確性和價值。如果我現(xiàn)在做一個新的 Python 分析器，它將比原來的精確和高效(也可以推廣到其它語言比如 JavaScript)。我也清楚的看到，Coverity 自發(fā)研制的一些不大嚴謹?shù)淖龇?，其實比程序語言領(lǐng)域里面一些看似高深的邏輯還要正確。這些微妙的提示信息，讓我把多個領(lǐng)域的知識串通了起來。所以我覺得跟這公司還有點臭味相投，加入 Coverity 也是不枉此行的?！　∪欢乙舶l(fā)現(xiàn)，Coverity 缺少我擁有的程序語言理論知識。絕大部分的 Coverity 工程師沒有系統(tǒng)的學(xué)習過 lambda calculus 和函數(shù)式編程。在我的 Python 分析器中，其實包含了 Coverity 還沒有的技術(shù)。Python 的靜態(tài)分析本來就比 C++ 和 Java 之類的難，然而我的實現(xiàn)卻異常的簡單。這些微妙的技術(shù)，貌似很多人都可以說他會做，但是他們卻很難把它做對。這就像CPS 轉(zhuǎn)換一樣，很多人都說他會做，可是真正做對的只有極少數(shù)人(我是其中之一)。這些技術(shù)源自于我對程序語言本質(zhì)的理解，源自于 Dan Friedman, Kent Dybvig 和 Amr Sabry 等老師的教誨，也源自于我自己辛勤的實驗，實驗，再實驗 在我簡短而優(yōu)雅的代碼中，包含了許多人需要花費好幾倍的代碼長度才能達到的目標。所以雖然 Coverity 的工程師們技術(shù)實力很強，但在代碼的簡單程度和對程序語言語義的理解上，真的很難達到我的程度。　　這就是為什么我經(jīng)常能夠一眼就看出 Coverity 產(chǎn)品里存在的問題，并且很快的修正錯誤。舉一個簡單的例子，有一天我修改了一行代碼，使得產(chǎn)品在某些 benchmark 上的內(nèi)存使用量減少了一半。我為什么可以做到這一點呢?因為在我的 Python 分析器里，這個問題是從一開頭就不存在的。它源自于一種幼稚的解釋器寫法，有點像 GoF 的《Design Patterns》里的那種。Coverity 的代碼里面有好些類似的問題，都是我自己根本不可能犯的錯誤，我都沒有機會給他們改進。我不是想貶低同事們的水平，他們都是 Stanford, Berkeley 等學(xué)校畢業(yè)的高手，可是我也很清楚自己的技術(shù)地位?！　∷晕揖徒?jīng)常發(fā)現(xiàn)這樣的麻煩事：我順手改掉了一個自認為很顯然的問題，或者一個我根本不會犯的錯誤，然后就發(fā)現(xiàn)有大批的測試需要被修改，我也會被要求寫出regression test，用以防止同樣的錯誤再次發(fā)生。某些同事對于測試的戰(zhàn)戰(zhàn)兢兢的態(tài)度，其實跟我當年在 Google 實習的時候沒有什么兩樣?？吹竭@里的問題了嗎?這些我根本不會犯的錯誤，幾分鐘時間順手就改掉了，但是我卻要花成天的工夫去修改和創(chuàng)建測試，防止它再次發(fā)生。我不得不說，在這些測試上所花費的工夫，占用了比我修改代碼多好幾倍，甚至幾十倍的工夫!　　想想這六個月以來我干了些什么，再比較一下在 Google 實習的那六個月獨自從頭做出來的東西，我發(fā)現(xiàn)自己簡直什么也沒有干。這就是我不喜歡測試驅(qū)動開發(fā)(TDD)的原因。在 Google 的六個月里，我無視同事對于測試的要求，從無到有的做出了如此精密的系統(tǒng)，一個測試都沒有寫照樣做得好，為什么呢?因為我的代碼非常的簡單清晰，我隨時都可以把它們完整的呈現(xiàn)在頭腦里面，從而讓心靈之眼可以看到可能出現(xiàn)的錯誤。也許這就是所謂的邏輯思維?！　y試過分依賴的人，往往不具有這樣的思維能力。他們不能夠看到代碼最簡單的本質(zhì)，所以需要做很多試探，以求達到近似解。為了不至于偏差很多，就寫很多測試，用以捕捉和防止每一次的錯誤。這就像一個初學(xué)畫畫的人，一點一點的描，用橡皮反復(fù)的擦，可總也抓不住事物的精髓。這些人對錯誤的記憶能力特別強，往往深入的追究一塊代碼是如何錯的，為什么是錯的，下次如何才能不犯同樣的錯誤?！　∪欢覅s沒法記住之前的代碼是如何錯的，我也不想知道為什么它是錯的，我只記得正確的代碼是什么樣子。錯誤的方式有千萬種，可是正確的卻往往只有一個。把腦力浪費在記憶錯誤的東西，這就是為什么很多人不能寫出真正優(yōu)美而正確的代碼。我受到的訓(xùn)練讓我可以直接得到正確的結(jié)果，所以測試對于我來說分量沒有那么重。當我的代碼需要大量的測試才能確保正確的時候，那就是它該被推翻重寫的時候。所以我的代碼往往沒有任何補丁和變通，可以說是無懈可擊。這就像是一個真正會畫畫的人，他閉目沉思，然后一氣呵成。當然，優(yōu)美的代碼并不是一蹴而就的，有的代碼被我推翻重來幾十次才最后成功，但我最后的代碼不留下絲毫錯誤的痕跡。所以我覺得，看一個程序員的水平，不要看他留下來多少行代碼，而要看他刪掉了多少行?！　∥矣X得做 Coverity 的工程師真累。這種累不止在于以上的技術(shù)層面的繁瑣，而且在于管理層對工程師的缺乏尊重以及不必要的壓力。這讓我在受到了足夠的啟發(fā)之后，開始懷疑是否還有繼續(xù)為它工作的價值。對于公司管理，以及對于 IT 行業(yè)總體的看法，我還是以后再講吧。篇二：IT工作心得感想范文　　看到了很多同學(xué)問到各銀行的待遇以及IT部門的發(fā)展之類的話題，想到了自己銀行的情況?！　〖影喾浅６?。機房是24小時開放的，每天都有人值夜班。我所在的地區(qū)我們分行只有800人不到，IT部門就只有7個人。他們每天除了正常的工作之外還要應(yīng)對各種培訓(xùn)、學(xué)習。銀行因為白天要對外營業(yè)，所以每次培訓(xùn)之類都是在晚上和周末，而且不是800人一起培訓(xùn)，而是今天這個培訓(xùn)，明天那個培訓(xùn)。這個工作量是非常大的。而且銀行加班基本是沒有加班工資的。因為國家不允許這種量的加班?！　⌒剿畣栴}。大家都說銀行薪水好。那是因為大家看到的只是薪水好的部門。我現(xiàn)在在銀行做貸款，屬于一線營銷崗位，薪水自然還不錯。但如果你不是做營銷而是后臺部門比如IT，那你只能拿到基本工資和平均獎金，這個數(shù)字看起來就沒那么有吸引力了。除非你能當老總?？蛇@個部門不像營業(yè)網(wǎng)點，一個地區(qū)可以幾十個網(wǎng)點，這個IT部門基本上一個地區(qū)就一個，也就是說一個地區(qū)就一個老總，這個老總又不像別的崗位可以橫向調(diào)動，在銀行里做IT你就只能做IT，不可能調(diào)你去做什么公司業(yè)務(wù)，所以我個人認為升遷的機會也比較小。但如果你是去總行的信息技術(shù)部搞些個產(chǎn)品研發(fā)之類也就不說了，那肯定是非常好的，但這樣的部門基本也不可能要一個剛畢業(yè)的學(xué)生?！　°y行的各項任務(wù)是很重的，而且可能看起來都非常不人性。不要以為你在IT部門就不可能有任務(wù)。我們講究的是全民皆兵。　　以上只是我個人的一