我很好奇其他软件开发人员重新评估其开发环境和工具的频率。我曾经在一家大公司工作，每个人都讨厌那些僵硬的工具，但却无能为力。所以没人真的更新过他们的开发环境，因为我们不能在那个环境中。您多久评估一次并升级您的开发环境和开发？工具？
既然我在我自己的初创阶段，我发现我可以花费无穷无尽的时间来评估新的工具和开发环境，但我真的不应该，也不能承受。我已经承诺每个月花1天的时间看新的开发工具，并试着看看它是否值得转换。
你多久尝试一下新的IDE，编辑器，错误修复工具，调试器？或更新到自己的更新版本？
我只会更新，除非我真的错过了某些功能，或者意识到不使用一种工具而不使用另一种工具会导致更多任务花费更长时间/效率更低。
我想说这是齐尔布和杰克的方法的混合。我关注新版本，但正如我所说的，只有当我真正需要新的东西时才升级（或者在实验后发现新功能令人惊叹，升级不会损害我对产品的其他期望）。 – 2009-02-26 20:17:07
这是一个持续的过程，但我不会每两年左右更多地进行重大更改。一项重大改变涉及太多时间，并且权衡通常不值得。重大更改可能定义为更改现有项目的整个目标或编译器体系结构和工具链。
请注意，项目之间可能会发生重大变化 - 一个新项目可以解决完全不同的体系结构和工具链，而且不会产生重大成本。但应注意不要在这里过分流血。需要评估过程来防止随着项目复杂度的增加而选择不再支持项目的设置。
但是对于细微的变化，我只需升级工具和环境，因为我找到了机会和理由。
-Adam
对我来说，升级是事件驱动的，而不是定时器驱动的。我一直在为新工具（库，IDE，CASE工具等）着想，并对它们进行评估，因为它们出现在我的雷达上。
使用微软技术，如果没有令人信服的理由阻止我，我会转向最新版本。通过OSS，我可以使用我所知道的，除非有什么令人信服的推动我前进的东西。
在工作中，我们在版本达到支持生命周期结束时升级工具。我们升级到更老的版本。
在家里，只要我能免费找到新东西的副本，即可升级（即参加3个网络广播的一些交易会向您发送vs2008标准版，用户组等等的副本）。
IDE's。我倾向于坚持一个我知道会增长，并支持我的语言。在我的开发环境中，它是vim。它是积极开发的，并有许多脚本（有点像插件）以及DIY文档。同样靠着IDE需要时间，并且善于使用它，有效地使用它需要更多的时间。
修订控制。我尽量保持在流血的边缘之下。新功能的好处很重要。例如Subversion 1.4，只支持基本的合并。 Subversion 1.5彻底改变了他们的合并系统，并加入了new features。
任务和项目管理。我倾向于每隔几年就这样做，并且只有在获得良好的受益时才这样做。否则，我会每隔几个月继续将当前的系统升级到当前的稳定版本。
库。他们是一个折腾。由于我所做的大多数事情都不会在运出的产品中结束。经常升级我感觉更自由，但是当向后可比性被打破时，我们倾向于避免升级。
希望我的$ 0.02是有用的。
IDEs - 这可能会很棘手，但多年来我经历了一些不同的进展。有时在项目或特定功能上可能会触发升级。例如，某人使用LINQ实现了一项功能，因此一个ASP.Net 2.0项目在一夜之间成为了一个3.5项目。其他时候，这正是目前正在使用的内容。这里的一点是，一个变化会影响整个团队，所以这不是一个轻松的变化。
错误跟踪工具 - 这也是在那个集中的东西，必须小心管理的土地。由于这是一个质量保证工具，我希望他们有自己的策略来决定多久查看一次更新以及何时安装它们，因为有时候新功能可能很酷。开发团队相当于何时更新wiki。
版本控制 - 这些都是单独管理的，因为我们大多数人都使用Tortoise SVN，所以我们每个人都有一个本地客户端副本。所以，更新是在有人想要做的时候完成的。我个人喜欢尽可能保持最新状态。
操作系统 - 虽然其中的一部分可以在部门的基础上进行控制，但有足够的不同部分进行更新，有时我会自行运行更新。我不知道我们什么时候会迁移到Windows 7，因为我知道我们不会去Vista，而且我认为在某些时候我们会得到XP，因为我已经在XP上工作了大约5年在此之前，我曾经在Windows 2000 Professional上工作过几年，之前还在NT 4.0上工作过。
电脑 - 有一个政策，每3年我们就可以得到我认为的新机器。当我开始我现在的位置时，我在一个P4盒子里，所以升级到双核盒子非常好，以及从2GB到4GB的RAM提升。
heck是一个关于IDE的非编程相关的话题？ – 2009-02-26 20:10:24