如何使用软件产品和您自己的代码组装项目
假设您手头有一个特定的项目，它可以分为几个部分，并且您并不完全确定会出现的所有困难。 时间就是生命。
- 您如何决定某个部件应该使用软件产品还是您自己的代码？ （考虑到有些工具很棒，但需要很多时间来学习）
- 您如何选择合适的软件产品？
- 选择正确产品（如果有）的这个阶段应该花费多少时间（以百分比表示），以及评估单个产品需要多少时间？
- 有没有回头路，在产品上付出努力后发现它不适合，可以改变主意吗？
我很想听听有关这些的任何经验法则。
Let's say you have a specific project on hand, it can be divided to parts, and you are not completely sure about all the difficulties that will arise.
Time is of the essence.
- How do you decide whether a part should use software product or your own code? (considering, that some tools are awesome, but will require much time to learn)
- How do you choose the right software product?
- How much time (as a percentage) should this stage of choosing the right product, if any, take, and how much time to evaluate a single product?
- Is there a way-back, is it o.k to change your mind, after putting efforts in a product, and finding it not suitable?
I would love to hear any rules of thumb about those.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
改变你的决定就像在房子已经建成时改变你的蓝图一样。
这完全取决于您到目前为止花费的时间和金钱。
一些注意事项：
0) 在开始之前以清晰、简单的方式理解问题。了解成功的关键是什么，然后使用该列表查看是否有任何软件、语言或工具可以提供帮助，并在成本是多少，以及成本是否大于收益。
1) 使用临时抱佛脚的时间表。如果您只有 1 天或 1 周的时间，没有更多的时间来完成它，则按照您要构建的顺序构建它。 令人惊奇的是，当您必须以 100% 的质量完成 50% 的功能时，多少都不再重要了。 关注价值、价值、价值。 阅读 37 Signal 的《Getting Real》一书，了解更多相关内容。
2）不要重新发明轮子。从头开始构建一些东西似乎总是更容易。 除非您正在执行实现的一小部分并且它确实更简单，这意味着您可以避免抽象，直到您忘记您正在构建的内容，否则请考虑它。 如果你能在相同的时间内更快、更好、更便宜地构建它，那就去做吧。
3) 了解您的工具的功能，以及任何工具为您的解决方案带来的好处。您应该熟悉或至少了解您可能集成或可能不集成的许多工具。
4) 选择一种可以解决很多问题的语言。您很可能会发现许多很棒的库和工具来构建您的软件，从而节省您的时间。 如果您需要某种可以交付、可以运行并且可以借鉴他人智慧的东西，请使用现有的东西，或者在需要时可以轻松访问 .NET 或 Java 的语言。
Changing your decisions is like changing your blueprint for a house while it's already being built.
It will entirely depend on what you have spent in time and money to that point.
Some considerations:
0) Understand the problem in clear and simple terms before beginning. Know what's critical to it's success and then use that list to see if any software, language, or tool will aid it, and at what cost, and if the cost outweighs the benefit.
1) Use a crammer's schedule. Build it in the order of what you would build if you only had 1 day or 1 week and no more to work on it. It's amazing how much doesn't matter anymore when you have to do 50% of the features at 100% of the quality. Focus on value, value, value. Read something like 37 Signal's book Getting Real for more on this.
2) Do not re-invent the wheel. It's always easier it seems to build something from scratch. Unless you are doing a fraction of the implementation and it's truly simpler, meaning you can avoid abstraction until you forget what you were building, consider it. If you can build it faster, better, cheaper and in the same amount of time, do it.
3) Know the features of your tools, and the benefits any tools need to give your solution. You should be familiar with or at least aware of many of the tools out there that you may or may not integrate.
4) Pick a language that is used to solve a lot of problems. Chances are you will find many great libraries and tools to build your software that will save your time. If you need something that delivers, can run, and you can lean on the smarts of others, use something established, or a language that can access .NET or Java easily if need be.
对于您识别为软件组件/包的软件的每个部分：
您如何决定某个部分应该使用软件产品还是您自己的代码？
（考虑到有些工具很棒，但需要很多时间来学习）
问问自己，您正在考虑的组件是否是您产品主要业务核心的一部分。
如果没有，那么通常最好使用现有的解决方案，并且不要花太多时间在上面。
如果是，请确保现有产品没有比您计划的更好。 - 如果有的话，请考虑购买它的许可证，而不是开发您的产品。
在线搜索类似的组件（商业、开源甚至文章/演示源代码）。
如果组件包含用户界面，是否美观且易于使用？
如果您对上述所有问题的回答是“是”，则不要自行开发该组件。
如果没有：
该组件是开源的还是在文章/演示代码中发布的？ - 如果是这样，它很强大，您可以对代码进行改进或使用它作为示例来帮助您编写更适合您的要求的代码吗？ - 如果是这样，请编写自己的代码，并将代码用作您自己的组件的一部分，该组件不是从头开始开发的。
如果您对上述问题的回答是否定的，那么您必须开发自己的（或者您在错误的地方搜索）。
如何选择合适的软件产品？
选择正确产品（如果有）的这一阶段应花费多少时间（以百分比表示），以及评估单个产品需要多长时间？
在产品上付出努力后发现它不适合，是否有回头路，可以改变主意吗？
始终设计您的软件，以便每个组件都是可替换的。
（使用接口和适配器设计模式，划分为多个组件，尽可能松散地连接所有组件（使用事件、绑定等）——松散耦合。
即使您自己实现某些功能，也要确保有回头路 - 有时您可能会使用错误的技术/设计，并且必须用您开发/购买的新组件替换组件。
其他经验法则：
在考虑每个组件之前，请考虑使用哪些应用程序范围的技术。
用汇编语言编写需要的时间最长，用 C 语言编写需要的时间最长，用 C++ 编写的时间更短，用更现代的语言（例如 C#、Java、Delphi）编写的时间更短。
哪个有更多与您相关的自我组件？ 您的团队有哪些经验。
如果您使用 .NET (C#)，那么 WPF 可以帮助您降低 GUI 和业务逻辑之间的耦合并制作出更好看的 GUI，但是学习如何使用它需要时间（5 天）强烈推荐最低限度的课程）。
For each part of your software you recognize as a software component/package:
How do you decide whether a part should use software product or your own code?
(considering, that some tools are awesome, but will require much time to learn)
Ask yourself whether the component you are considering is a part of your product's main business core.
If not then it is usually better to use an existing solution and not send too much time on it.
If it is then make sure there is no existing product that is better than what you are planning. - It there is, consider purchasing licenses to it instead of developing your product.
Search online for similar components (commercial, open source and even articles/demo-source-code).
If component includes a user-interface, is it plesent to look at and easy to use?
If you answered yes to all the above then do not develop the component yourself.
If not:
Is the component open source or published in an article / demo-code? - If so, it robust, could you take the code an improve it or use it as an example to help you write code that is more suitable for your requirements? - If so write your own code, use code as part of your own component that is not developed from scratch.
If your answer to the above is no, then you'll have to develop your own (or you're searching in the wrong places).
How do you choose the right software product?
How much time (as a percentage) should this stage of choosing the right product, if any, take, and how much time to evaluate a single product?
Is there a way-back, is it o.k to change your mind, after putting efforts in a product, and finding it not suitable?
Always design your software so that every component is replaceable.
(Use interfaces & adapter design pattern, divide to many assemblies, connect all components as loosely as possible (using events, binding, as etc.) - loose coupling.
Even if you implement something yourself make sure there is a way back - sometime you may use the wrong technology/design and have to replace a component with a new one you develop/purchase.
Other rules of thumb:
Consider which application-wide technologies to use before considering each component.
Writing in assembly would take the longest, in C less, in C++ even less, in more modern languages such as C#, Java, Delphi even less.
Which has more of the self components that are relevant to you? What does your team have experience in.
If you are using .NET (C#), then WPF could help you lower the coupling between GUI and business logic and make a better looking GUI, however it take time to learn how to use it (a 5 day minimum course is very much recommended).
与任何技术一样，困难在于基于非常大的可能解决方案空间来构建良好的解决方案。 有多少开发者，就有多少种方法可以解决这个问题。
我通常会花一些时间来理解问题并尽可能清晰、简洁地陈述它，最好以书面形式。 问题描述应该完全从任何可能的解决方案中抽象出来。 接下来，我通常会列出需要应用于解决方案的可用约束（时间、预算、法律、政治、性能、可用性、团队内的技能可用性等）。
那么理论上来说，你需要在市场上寻找能够解决问题并同时满足限制的东西。 在实践中，这个过程并不是那么简单：你尝试识别可能有用的市场类别，然后研究它们，看看有什么可用，并不断尝试尽可能缩小约束和能力之间的差距，通常是通过返回、重新审视和重新协商限制来实现的。
一些通用提示：
在研究过程中不断回到原来的问题。
总是有不止一种解决方案，在深入研究之前尝试扩大搜索空间的广度（专注于解决问题的不同方法）。
在决定是否进一步调查之前，明确一些值得研究的选项，以及值得在每个选项上花费的时间。
很少值得寻找最佳解决方案，尤其是在技术格局不断快速变化的情况下。 寻找足够好的解决方案：“选择的悖论 - 为什么多即少”。
很少值得向用户求助帮助（除非他们是软件专家）在多个选项之间进行选择。 如果您有许多选项看起来都同样有吸引力，这意味着您需要返回并更好地理解原始问题，那么您很可能错过了一两个要求。
关于使用第三方组件的一些进一步说明（指 GUI 组件，但也很容易应用于其他软件领域）。
关于范围界定的更多说明，为一个项目进行创作和研究。
As in any art the difficulty is composing a good solution based on a very large possible solutions space. There as many ways to go about this as there are developers.
I’d normally spend some time understanding the problem and stating it clearly and succinctly as possible, preferably in a written form. The problem description should be completely abstracted away from any possible solutions. Next I’d normally list available constraints that will need to be applied to the solution (time, budget, legal, political, performance, usability, skill availability within team and so on).
Then the theory goes that you need to look on the market for something that solves the problem and meets the constraints at the same time. In practise, the process is not that straight-forward: you try to identify market categories that are likely to be useful, then research them, see what is available and continuously try to reduce the gap between the constraints and capabilities as much as possible, often by going back and revisiting and re-negotiating the constraints.
A few generic tips:
During the research keep coming back to the original problem.
There is always more than one solution, try to extend breadth (concentrating on very different ways of solving the problem) of the search space before going deeper.
Be clear on a number of options it’s worth researching, and amount of time worth spending on each of them before making a decision whether to investigate further.
It’s seldom worth finding an optimal solution, especially then technological landscape keeps changing very rapidly. Look for a solution that is good enough: “The Paradox of Choice - Why More is Less”.
It’s rarely worth turning to users for help (unless they are software experts) on choosing between several options. If you’ve got a number of options all looking equally attractive that means you need to go back and understand the original problem better, it’s likely you’ve missed a requirement or two.
Some further notes on using third-party components (refers to GUI components, but easy to apply to other software areas as well).
And even more notes on scoping, composing and researching for a project.
问自己两个问题。
1）产品是否成熟。 如果是，那么
2）您自己创建它提供的功能需要多长时间。 如果该值乘以您的小时费率大于产品的成本，则使用该产品。
请咨询您的其他开发人员网络。 他们是否使用过它，是否遇到过问题。 查阅互联网。 使用该产品创建原型。 效果好吗？ 有什么重大bug吗？
这取决于项目的规模以及产品对成功的重要性。 大多数时候，您将能够在很短的时间内获得产品的高级视图。
使用它可能只需几分钟，然后您就会说，不，还没有准备好迎接黄金时段。 如果成功了，一两天的实验可能会告诉您它通过了您的项目的要求。
如果这是一个拥有许多开发人员的大型项目，那么您可能需要花更多时间用它来制作原型应用程序，以确保它值得投入所有时间。
如果你发现效果不佳，回去也没有什么问题。 事实上你可能必须这样做。 理想情况下，您会尽早发现这一点。 不是11点的时候。 同样，这就是原型设计的目的。
Ask your self two questions.
1) Is it a mature product. If yes, then
2) How long it would take to create the functionality it provides on your own. If that value times your hourly rate is greater than the cost of the product, then use that product.
Consult your network of other developers. Have they used it, did they run into problems. Consult the interweb. Create a prototype using the product. Does it work well? Any major bugs?
It depends on the size of the project, and the criticality of the product to the success. Most of the time, you are going to be able to get a high level view of the product in a very short amount of time.
It may be just a few minutes using it before you say, nope - not ready for prime time. If it makes past that, a day or two of experimentation may tell you that it passes muster for your project.
If it's a huge project with many developers, then you probably want to spend more time doing a prototype application with it to be sure it's worth investing all that time in.
If you find it's not working out, there's nothing wrong with going back. In fact you probably have to. Ideally you will find this out early. Not at the 11th hour. Again, this is the purpose of prototyping.
这里已经有一些非常好的答案，所以我不会重复，但是有一点你绝对应该考虑，虽然我认为这是显而易见的，但我还没有看到这里提到它：
您可以用来实施解决方案的人员、他们的核心能力以及他们的一般能力水平。
你必须由谁来实施这个（假设是一个团队，而不仅仅是你自己 - 但即使只有你也是相关的......）会对结果产生巨大的影响。 如果您没有经验丰富的程序员来帮助您开发此功能，那么您最好寻找一些 OTS 产品来为您完成这项工作...或者，即使您拥有不太可能成功的程序员，您仍然可能会成功希望找到总体项目风险较低的解决方案。
There are already some really good answers here, so I won't repeat it, however there is one point you should definitely consider, and though I would have thought its obvious I havent seen it mentioned here yet:
The personnel you have available to implement the solution, their core competency, and their general level of competence.
Who you have to implement this (assuming it's a team, and not just yourself - but relevant even if its just you, too...) can have a HUGE effect on the outcome. If you don't have experienced programmers to help you develop this, you're better off looking for some OTS product to do the work for you... Or, even if you have programmers who are not likely to succeed, you still might want to find a solution with lower overall project risk.