IT工作看似很让人崇拜，但背后但是要付出多少呢?下面是为大家带来的IT工作心得感想范文，希望可以让大家喜欢。篇一：IT工作心得感想范文我在一家叫做Coverity的公司工作，我住在三藩市(SanFrancisco)。Coverity是一个奇怪的公司，三藩市是一个奇怪的城市。Coverity制造一种叫做“静态分析”(staticanalysis)的软件。这种软件可以在不运行程序的情况下，经过对代码的分析，自动的找到程序里面可能出现的问题。这有点像我之前给Google做的那个Python分析器，只不过针对另外的语言(C，C++和Java等)，分析的侧重点不同，能处理代码的规模也貌似大一些。还有就是这么多年了，久经沙场考验了。Coverity具有世界上最先进的一些技术，所以麻雀虽小，却让很多人离不开它。恐怕很少有人知道，这小小的公司的忠实客户，包括了一系列的大拿：美国宇航局，波音，洛克希德马丁，雷神(Raytheon)，BAESystems，丰田，欧洲原子能中心(CERN)……貌似几乎所有对代码质量不敢有丝毫差错，又不得不用像C++这样毛病众多的语言的公司，都购买了Coverity的产品。比如最近的火星好奇者号上的所有200多万行代码，都经过了Coverity的静态分析。当然，如此精密的设备不可能光靠Coverity查一下错就能确保万无一失，它必须依靠很多其它的技术，但Coverity确实是这些东西的开发过程里面比较重要的部分。我必须承认，Coverity给了我足够的启发，甚至间接的让我发现了自己之前做的Python静态分析里面存在的一些问题。Coverity的产品在大规模的代码上面的成功，也让我意识到了自己在Python分析器里的一些突发奇想的设计的正确性和价值。如果我现在做一个新的Python分析器，它将比原来的精确和高效(也可以推广到其它语言比如JavaScript)。我也清楚的看到，Coverity自发研制的一些“不大严谨”的做法，其实比程序语言领域里面一些看似高深的“逻辑”还要“正确”。这些微妙的“提示信息”，让我把多个领域的知识串通了起来。所以我觉得跟这公司还有点臭味相投，加入Coverity也是不枉此行的。然而我也发现，Coverity缺少我拥有的程序语言理论知识。绝大部分的Coverity工程师没有系统的学习过lambdacalculus和函数式编程。在我的Python分析器中，其实包含了Coverity还没有的技术。Python的静态分析本来就比C++和Java之类的难，然而我的实现却异常的简单。这些微妙的技术，貌似很多人都可以说他“会做”，但是他们却很难把它做对。这就像“CPS转换”一样，很多人都说他会做，可是真正做对的只有极少数人(我是其中之一)。这些技术源自于我对程序语言本质的理解，源自于DanFriedman,KentDybvig和AmrSabry等老师的教诲，也源自于我自己辛勤的实验，实验，再实验……在我简短而优雅的代码中，包含了许多人需要花费好几倍的代码长度才能达到的目标。所以虽然Coverity的工程师们技术实力很强，但在代码的简单程度和对程序语言语义的理解上，真的很难达到我的程度。这就是为什么我经常能够一眼就看出Coverity产品里存在的问题，并且很快的修正错误。举一个简单的例子，有一天我修改了一行代码，使得产品在某些benchmark上的内存使用量减少了一半。我为什么可以做到这一点呢?因为在我的Python分析器里，这个问题是从一开头就不存在的。它源自于一种幼稚的解释器写法，有点像GoF的《DesignPatterns》里的那种。Coverity的代码里面有好些类似的问题，都是我自己根本不可能犯的错误，我都没有机会给他们改进。我不是想贬低同事们的水平，他们都是Stanford,Berkeley等学校毕业的高手，可是我也很清楚自己的技术地位。所以我就经常发现这样的麻烦事：我顺手改掉了一个自认为很显然的问题，或者一个我根本不会犯的错误，然后就发现有大批的测试需要被修改，我也会被要求写出“regressiontest”，用以防止同样的错误再次发生。某些同事对于测试的战战兢兢的态度，其实跟我当年在Google实习的时候没有什么两样。看到这里的问题了吗?这些我“根本”不会犯的错误，几分钟时间顺手就改掉了，但是我却要花成天的工夫去修改和创建测试，防止它“再次”发生。我不得不说，在这些测试上所花费的工夫，占用了比我修改代码多好几倍，甚至几十倍的工夫...
