我只是在这个网站上看了一个相关的问题清单，它让我思考。我看到很多问题，如：
现在，当我开发（使用.NET和Visual Studio）时，我选择了一个非常具体的目录结构：
一般来说，如果在该目录结构中无法完成某些操作，我根本就不这样做。这包括单元测试，持续集成等......同样，我的整个程序将用完bin目录，但OS或网络引用除外。我拒绝在不存在于程序根目录中的文件系统上引入依赖项。我确信我错过了一些非常酷的开发方面，但我已经尝试过巡航控制而且我已经尝试过并且说实话，作为一个与很多小项目合作的人（200多个小项目）与一些（10-20）大型项目相比，我可以诚实地说，简单性比使用这些工具的一些好处更令人满意。
我想我的问题是，我只是一个傻瓜，还是看起来某些事情比他们需要的要复杂得多？这整个“设计所以它适合所有”的心态似乎真的妨碍了有时完成任务。
答案 0 :(得分：4)
我看到了关于人们如何使事情过于复杂的观点。但是，需要考虑的一件事是，使用“extras”并不总是特别意味着使编程更容易。有时候，它们的使用是为了让它以某种方式变得更好。通过使用这些额外的工具，您可以简单地交换其他内容。
例如，使用单元测试框架肯定会增加项目的复杂性。但是，您可以简单地交换更简单的错误代码（理论上）。
它可能因开发人员与开发人员而异。对于像你这样的人来说，简约似乎至关重要。也许这可以让您获得更快的速度，更少的时间来寻找配置问题的解决方案。但是，其他人可能愿意花一些时间来摆弄框架，以便对自己的代码更加有信心。
答案 1 :(得分：1)
一般来说，如果在该目录结构中无法完成某些操作，我根本就不这样做。这包括单元测试，持续集成，
小型项目（每年200多个小项目），而不是少数（10-20个）大型项目
假设您自己工作，您的大型项目（<1个月）将被称为“小型”，而您的小型项目（1天）将在大多数商店中被称为“任务”。大型项目，如联合打击战斗机或政府信息系统的软件，数百人年。我参与过的大多数小项目都是2-6个月，而中等项目是1-4个人。
我想我的问题是，我只是一个傻瓜，还是看起来某些事情比他们需要的要复杂得多？
某些事情比在一个程序员月份创建的更复杂。
持续集成可能对不到一个月的项目没有用，因为你没有时间建立一个你有大量未集成工作的系统。
一旦你做了足够长的事情，它就足以忘记它的某些部分，或者在有多个开发人员的任何事情上，单元测试提供了一个很好的机制来说明系统的预期功能行为。毫不含糊的。
如果您正在为不同的部署配置一个软件，并且您已经对该软件充满信心，那么系统级测试通常就足够了。
答案 2 :(得分：0)
每年200多件小型产品几乎每个工作日一件。我不认为人们对大型项目的问题会适用于你。
我很好奇。你工作的那些小项目是什么？听起来很有趣。但如果我每年要做那么多项目，我想我会使用Python，而不是.NET。除非是你正在使用的IronPython。 ： - ）