假设你手头有一个特定的项目，它可以分成几部分，你不能完全确定会出现的所有困难。时间就是生命。
- 您如何决定一个部件应该使用软件产品还是您自己的代码？（考虑到有些工具很棒，但需要很多时间来学习）
- 如何选择合适的软件产品？
- 选择正确产品的这个阶段（如果有的话）应该花费多少时间（以百分比计），以及评估单个产品需要多少时间？
- 有没有退路，在一个产品上下了功夫，发现它不适合之后改变主意可以吗？
我很想听听关于这些的任何经验法则。
问问题
394 次
5 回答
3
改变你的决定就像改变你正在建造的房子的蓝图。
这将完全取决于你在那一点上花费的时间和金钱。
一些考虑：
0）在开始之前，用清晰简单的术语理解问题。 知道什么对它的成功至关重要，然后使用该列表来查看是否有任何软件、语言或工具可以帮助它，以及成本是多少，以及成本是否超过收益。
1) 使用填鸭式的时间表。如果您只有 1 天或 1 周的时间并且没有更多的工作时间，请按照您将要构建的顺序构建它。令人惊讶的是，当您必须以 100% 的质量完成 50% 的功能时，多少不再重要了。专注于价值，价值，价值。阅读类似 37 Signal 的书 Getting Real 以了解更多信息。
2）不要重新发明轮子。 从头开始构建东西似乎总是更容易。除非你只做了一小部分实现并且它真的更简单，这意味着你可以避免抽象，直到你忘记你正在构建的东西，考虑一下。如果你能在相同的时间内更快、更好、更便宜地建造它，那就去做吧。
3) 了解您的工具的功能，以及任何工具为您的解决方案提供的好处。您应该熟悉或至少了解您可能集成或未集成的许多工具。
4）选择一种可以解决很多问题的语言。 您可能会发现许多出色的库和工具来构建您的软件，从而节省您的时间。如果您需要可以交付、可以运行并且可以依靠他人的聪明才智的东西，请使用已建立的东西，或者在需要时可以轻松访问 .NET 或 Java 的语言。
于 2009-06-13T20:52:18.687 回答
2
对于您识别为软件组件/包的软件的每个部分：
您如何决定一个部件应该使用软件产品还是您自己的代码？（考虑到有些工具很棒，但需要很多时间来学习）
问问自己，您正在考虑的组件是否是您产品主要业务核心的一部分。
如果没有，那么通常最好使用现有的解决方案，不要花太多时间在上面。
如果是，请确保没有比您计划的产品更好的现有产品。- 在那里，考虑购买它的许可证而不是开发你的产品。
在线搜索类似的组件（商业、开源甚至文章/演示源代码）。
- 它们中的任何一个都实现了组件的所有要求吗？
- 它们的成本是多少，开发和维护一个类似的组件会花费更多吗？
- 许可条件是什么？- 它们适合您的产品吗？
如果组件包含一个用户界面，它是否美观且易于使用？
如果您对以上所有问题的回答都是肯定的，那么不要自己开发组件。
如果不：
组件是开源的还是发布在文章/演示代码中？- 如果是这样，它很健壮，您能否对代码进行改进或以它为示例来帮助您编写更适合您要求的代码？- 如果是这样编写您自己的代码，请将代码用作您自己的组件的一部分，而不是从头开始开发。
如果您对上述问题的回答是否定的，那么您将不得不自己开发（或者您在错误的地方搜索）。
如何选择合适的软件产品？
- 参见 1 的答案。
选择正确产品的这个阶段（如果有的话）应该花费多少时间（以百分比计），以及评估单个产品需要多少时间？
- 清理一整天，搜索现有组件，阅读它们（功能、价格、评论）并下载并安装最多 5 个。
- 改天评估 2-3 个产品，比较演示/示例，查看代码，编写 2 个使用每种产品的小示例（相同示例不同产品）。
- 如果您选择超过 3 个，请改天清零并测试其他的。
有没有退路，在一个产品上下了功夫，发现它不适合之后改变主意可以吗？
始终设计您的软件，以便每个组件都是可更换的。
- 这保证了总有“退路”。（使用接口和适配器设计模式，划分为许多组件，尽可能松散地连接所有组件（使用事件、绑定等）-松散耦合。
即使您自己实现了某些东西，也要确保有回头路——有时您可能使用了错误的技术/设计，并且不得不用您开发/购买的新组件替换组件。
其他经验法则：
在考虑每个组件之前，请考虑使用哪些应用程序范围的技术。
用汇编语言编写需要的时间最长，用 C 语言更少，用 C++ 甚至更少，用 C#、Java、Delphi 等更现代的语言甚至更少。
哪个有更多与您相关的自我组件？你的团队有什么经验。
如果您使用的是 .NET (C#)，那么 WPF 可以帮助您降低 GUI 和业务逻辑之间的耦合并制作更好看的 GUI，但是学习如何使用它需要时间（非常推荐至少 5 天的课程）。
于 2009-06-20T14:44:33.370 回答
1
与任何艺术一样，困难在于基于非常大的可能解决方案空间来编写一个好的解决方案。有多少开发人员就有多少方法可以解决这个问题。
我通常会花一些时间来理解问题并尽可能清晰简洁地说明它，最好是书面形式。问题描述应该完全从任何可能的解决方案中抽象出来。接下来，我通常会列出需要应用于解决方案的可用约束（时间、预算、法律、政治、绩效、可用性、团队内的技能可用性等）。
然后理论认为，您需要在市场上寻找可以解决问题并同时满足约束条件的东西。在实践中，这个过程并不是那么简单：你尝试识别可能有用的市场类别，然后研究它们，看看有什么可用的，并不断尝试尽可能减少限制和能力之间的差距，通常是通过返回并重新审视和重新协商约束。
一些通用提示：
在研究过程中不断回到原来的问题。
总是有不止一种解决方案，在深入之前尝试扩展搜索空间的广度（专注于解决问题的非常不同的方法）。
在决定是否进一步调查之前，请明确一些值得研究的选项，以及值得花在每个选项上的时间。
很少值得找到最佳解决方案，尤其是在技术环境变化非常迅速的情况下。寻找一个足够好的解决方案：“<a href="http://video.google.com/videoplay?docid=6127548813950043200" rel="nofollow noreferrer">选择的悖论 - 为什么更多就是更少”。
在几个选项之间进行选择时，很少值得向用户寻求帮助（除非他们是软件专家）。如果您有许多看起来同样有吸引力的选项，这意味着您需要返回并更好地理解最初的问题，那么您很可能错过了一个或两个要求。
关于使用第三方组件的一些进一步说明（指的是 GUI 组件，但也易于应用于其他软件领域）。
还有更多关于项目范围界定、撰写和研究的说明。
于 2009-06-16T09:47:17.587 回答
1
- 您如何决定一个部件应该使用软件产品还是您自己的代码？（考虑到有些工具很棒，但需要很多时间来学习）
问你自己两个问题。
1）是否成熟的产品。如果是，那么
2) 自己创建它提供的功能需要多长时间。如果该值乘以您的小时费率大于产品的成本，则使用该产品。
- 如何选择合适的软件产品？
请咨询您的其他开发人员网络。他们用过吗，有没有遇到问题。咨询互联网。使用产品创建原型。它运作良好吗？有什么大bug吗？
- 选择正确产品的这个阶段（如果有的话）应该花费多少时间（以百分比计），以及评估单个产品需要多少时间？
这取决于项目的规模，以及产品对成功的重要性。大多数情况下，您将能够在很短的时间内获得产品的高级视图。
在你说，不——还没准备好迎接黄金时段之前，它可能只是用了几分钟。如果它过去了，一两天的实验可能会告诉你它通过了你的项目的集合。
如果这是一个包含许多开发人员的大型项目，那么您可能希望花更多时间用它来制作原型应用程序，以确保值得投入所有时间。
- 有没有退路，在一个产品上下了功夫，发现它不适合之后改变主意可以吗？
如果你发现它没有成功，回去也没有错。事实上，你可能不得不这样做。理想情况下，您会尽早发现这一点。不是在第 11 个小时。同样，这是原型设计的目的。
于 2009-06-16T22:26:40.923 回答
1
这里已经有一些非常好的答案，所以我不会重复它，但是有一点你一定要考虑，虽然我认为很明显我还没有看到这里提到过：
你可以实施的人员解决方案、他们的核心能力和他们的一般能力水平。
您必须由谁来执行此操作（假设它是一个团队，而不仅仅是您自己——即使只有您自己也是相关的……）会对结果产生巨大的影响。如果你没有经验丰富的程序员来帮助你开发这个，你最好寻找一些 OTS 产品来为你完成这项工作......或者，即使你有不太可能成功的程序员，你仍然可能希望找到整体项目风险较低的解决方案。
于 2009-06-22T18:55:53.620 回答