2

我只是在这个网站上浏览了一个相关的问题列表，这让我开始思考。我看到很多问题，例如：

  • 我应该使用我的包部署 XYZ 还是添加对其他路径的引用？
  • 如何配置 nant/cruisecontrol/etc.. 来运行我的单元测试？
  • 在 XYZ 设置中，我应该在哪里保存用于单元测试的配置文件
  • ETC...

现在，当我开发（使用 .NET 和 Visual Studio）时，我选择了一个非常具体的目录结构：

  • doc：包含所有文档
  • lib：包含已编译的依赖项
  • src：包含所有程序源和依赖源
  • etc：与项目相关的其他文件
  • bin：编译后的程序输出

一般来说，如果在那个目录结构中不能做某事，我就干脆不做。这包括单元测试、持续集成等......同样，我的整个程序将在 bin 目录之外运行，但操作系统或网络引用除外。我拒绝在不驻留在我的程序根目录中的文件系统上引入依赖项。我确信我错过了一些非常酷的开发方面，但我已经尝试过巡航控制，我已经尝试过 nant，老实说，作为一个从事许多小项目（200 多个小项目）的人一年）相对于几个（10-20）个大型项目，我可以诚实地说，简单性比使用这些工具的一些好处更可取。

我想我的问题是，我只是一个简单的人，还是看起来某些事情比它们需要的复杂得多？整个“设计适合所有人”的心态似乎确实有时会妨碍完成工作。

4

3 回答 3

4

我明白你关于人们如何过度复杂化事情的观点。但是，要考虑的一件事是，使用“附加”并不总是专门为了使编程更容易。有时，它们被用于以某种方式使其变得更好。通过使用这些附加工具，您可以用简单性换取其他东西。

例如，使用单元测试框架肯定会增加项目的复杂性。但是，您正在用简单性换取更多无错误的代码（理论上）。

它可能因开发人员而异。对于像你这样的人来说，简单似乎是最重要的。也许这可以让您更快地搜索配置问题的解决方案并减少花费的时间。但是，其他人可能愿意花一些时间来摆弄一个框架，以便更加确信他们的代码是可靠的。

于 2009-07-04T02:56:12.010 回答
1

一般来说，如果在那个目录结构中不能做某事，我就干脆不做。这包括单元测试、持续集成、

小型项目（每年 200 多个小型项目），而不是少数（10-20）个大型项目

假设您是一个人工作，那么在大多数商店中，您的大项目（< 1 人月）将被称为“小”，而您的小项目（1 天）将被称为“任务”。大型项目，例如联合打击战斗机或政府信息系统的软件是数百人年。我做过的大多数小型项目都是 2-6 人月，中型项目是 1-4 人年。

我想我的问题是，我只是一个简单的人，还是看起来某些事情比它们需要的复杂得多？

某些事情比一个程序员一个月所能创造的要复杂得多。

持续集成可能对不到一个月的项目没有用处，因为您没有时间建立一个有大量未集成工作的系统。

一旦你在某件事上工作的时间足够长以至于忘记了它的某些部分做了什么，或者与多个开发人员一起做任何事情，单元测试提供了一种很好的机制，可以以明确的方式说明系统的预期功能行为。

如果您正在为不同的部署配置一个软件，并且您已经对该软件充满信心，那么系统级测试通常就足够了。

于 2009-07-04T09:26:39.503 回答
0

一年200+小产品几乎每个工作日一个。我认为人们在大型项目中遇到的问题不会适用于你。

I'm curious. What are all those small projects you work on? It sounds fun. But if I had that many projects to do per year, I think I'd be using Python, not .NET. Unless it's IronPython you're using. :-)

于 2009-07-04T03:08:06.090 回答