You can spend a long time trying to make something reusable, without anyone reusing it. So I usually follow the maxim that I only make something reusable when it's going to be reused (there are a few exceptions that will stand out).
Often it's only when you come to reuse something that your client says "I want it to do the same, except..." or similar. It's only at that point that you understand which part of your reusable code is reusable, and what needs to be parameterised (e.g. via strategy patterns or similar)
Consequently I don't tend to regard code as reusable unless it's really been reused :-)
I think the better idea is to never make code reusable.
Instead, when you find two pieces of code that are very similar, refactor them - pull the common code out and leave the differences in. Rerun your unit tests, and when they succeed, you're done.
You marked two extremes here, but they are a good start. When you are to low-level, you will win nothing. Your reusable code should be worth the effort. When it does something, a mid-class programmer can implement in 3-7 lines or in 1-3 minutes, it might not be worth it, unless it is really, really needed often!
The other extreme is the generic SQL client. Of course, the reuse should not lay any burden on the user. That is a definitive no-no!
In my opinion, you should think about your project and then have a careful watch, what parts could be needed in multiple situations. These are candidates for reuse. But there are also other factors, you should check the candidates against, before you make the code reusable:
Will the extra effort (see below) be worth it? (3-7 liners!)
Does it lay extra burden on reusers and/or users?
How often will it be reused (estimated)
Can I decide now? (You might not have enough experience right now -- then better delay it and implement some use-cases as standalone, before making it reusable)
Can I really generalize all the details that much, that I can have one single code-line? Special cases can be the death of reuse ...
You might find further factors. I wanted to give some adhoc examples.
I think, "Think first" is the best rule of thumb for reuse ... and of course reuse needs much experience.
Also it needs extra effort:
That is a really main point, many people forget. Reuse does not come free! You have to pay for it.
You have extra costs for:
Extra guessing, how to make it really universal
Extra-Asking all the potential consumers
Extra-Documenting, since the consumers will only use it, when it really is simple to use
Extra-Advertising, since potential consumers must know, that there exists something reusable and that is worthwhile to reuse.
Also you have to establish a reuse-culture, what is not easy, since it goes against the fealings of plenty developers. All developers think that only them have found the holy-grail and only their code is good at all. So many people will be offended and resist reusing code. The resistence can be either open but also hidden to the bosses (which might be the worst). Also the management must be aware of reuse. Without management backup, you will not have a substantial reuse-culture in your company.
So, there is a price-tag attached to it. But it is worthwile, when you manage to really pay the price!
此外，您还可以对所有函数和类型进行评论，并使用 Doxygen（或 Javadoc）等系统，然后自动生成文档，这使得它甚至可以在 IDE 之外进行搜索，并以某种不错的方式呈现。
Only make general code reusable. A function that only appends an s last in a string will not be of value except where it is already used, but a function that can add any one or more characters to the end of a string would be useful for other uses too.
Basic functionality; if you have your own functions and types for lists, trees, sockets and/or file handling, all these can be useful in the shared libraries.
Also, you can comment on all functions and types and use a system like Doxygen (or Javadoc) and then automatically generate the documentation, which would make it searchable even outside an IDE and presented in a somewhat nice way.
If you take the time to make code generic and documented, not only can you re-use the code in another project, others will actually look at your code. This will greatly improve the probability of anyone finding bugs/quirks before your users do.
The main thing is to make a good distinction where code should be. To take the 'add an "s" to a string' example - this could be code that is put somewhere in a strings-util library along with the 'add an "h" to a string' and 'add a "b" to a string' functions. When you see those three functions together, you'll probably get the idea of making a more generic 'add any character to a string' function, thus making the code even more reusable - you can also add the letter 'r' to a string now!
The only way that you are going to spot the fact that you are appending characters to a string all the time is to make sure these functions live next to each other - otherwise everyone will have the same functions hidden somewhere in the code.
These kinds of util collections/classes/whatever contain the low-level pieces of code - they are generic, and don't seem to hold any relevance to a specific project.
The higher-end of the scale should also be treated as reusable code. Say for instance you have a customer with a great new idea, like adding images on a website. Nobody else needs this, so you go ahead and add the tag specifically for this client. Two weeks later, you have another client who asks you for the exact same thing.
What usually happens in a situation like this is that the extra code for your first client gets copied into the project of the second client - just because it looks like it is the fastest way to get things working. What is actually happening, is that the maintanability of the code is degraded. You now have the same piece of code in two places, with the same bugs. I think we all know this leads to problems in the future.
If the example was written for reusability, you can use it again in the second project, saving time and effort. Also, the added features that your next client asks are probably something you can offer the first client as an upgrade - (see, you can set the height and width now, woohoo!)
As for knowing that code exists, that is a problem that will always remain there. I think the fastest way to spread this knowledge is to make sure developers don't develop on their own - pair programming is a good example of this. This way, whenever something is written, at least two people will know about it. If you regularly mix up the pairs, the knowledge will spread through the company without any extra effort.
最近的一个例子是一个插件，旨在提供应用程序和 Protx 支付系统之间的接口。 I 是解决一个问题的东西，到目前为止已经在几个不同的项目中使用过。
I tend to build reusable libraries only when I'm sure that I'll need the functionality at least one other time, and that the time taken to make the code into a stand-alone library is less than the time taken to rebuild or copy code in. Furthermore, the library being created must solve exactly one problem, which prevents me from building giant balls of code that are too wide in their scope to be of use.
A recent example of this was a plugin designed to provide an interface between an app and the Protx payment system. I's something that solves one problem, and has been used in several different projects so far.
发布评论
评论（7）
您可以花费很长时间尝试使某些东西可重用，而没有人重用它。 因此，我通常遵循这样的格言：只有在需要重用时才使其可重用（有一些例外）。
通常，只有当您要重复使用某些东西时，您的客户才会说“我希望它做同样的事情，除了......”或类似的话。 只有到那时，您才了解可重用代码的哪一部分是可重用的，以及需要参数化的部分（例如通过 策略模式或类似的）
因此，我不倾向于认为代码是可重用的，除非它真的被重用了:-)
You can spend a long time trying to make something reusable, without anyone reusing it. So I usually follow the maxim that I only make something reusable when it's going to be reused (there are a few exceptions that will stand out).
Often it's only when you come to reuse something that your client says "I want it to do the same, except..." or similar. It's only at that point that you understand which part of your reusable code is reusable, and what needs to be parameterised (e.g. via strategy patterns or similar)
Consequently I don't tend to regard code as reusable unless it's really been reused :-)
我认为更好的想法是永远不要让代码可重用。
相反，当您发现两段非常相似的代码时，请重构它们 - 取出通用代码并保留差异。重新运行单元测试，当它们成功时，您就完成了。
您确实进行了单元测试，对吧？
I think the better idea is to never make code reusable.
Instead, when you find two pieces of code that are very similar, refactor them - pull the common code out and leave the differences in. Rerun your unit tests, and when they succeed, you're done.
You did have unit tests, right?
在德国，我们说：真理位于中间
你在这里标记了两个极端，但它们是一个好的开始。 当你处于低水平时，你将一无所获。 您的可重用代码应该值得付出努力。 当它做某事时，一个中级程序员可以在 3-7 行或 1-3 分钟内实现，这可能不值得，除非它真的非常经常需要！
另一个极端是通用 SQL 客户端。 当然，重用不应该给用户带来任何负担。 这是绝对的禁忌！
在我看来，你应该考虑你的项目，然后仔细观察，在多种情况下可能需要哪些部分。 这些是重用的候选者。 但在使代码可重用之前，还应该检查候选因素：
您可能会发现更多因素。 我想举一些特别的例子。
我认为，“先思考”是重用的最佳经验法则……当然重用需要很多经验。
还需要额外的努力：
这是一个非常重要的点，很多人都忘记了。 重复使用不是免费的！您必须为此付费。
您需要额外的成本：
此外，您还必须建立一种重用文化，这并不容易，因为它违背了许多开发人员的感受。 所有开发人员都认为只有他们找到了圣杯，只有他们的代码才是好的。 很多人会被冒犯并抵制重用代码。 抵抗可以是公开的，也可以是对老板隐藏的（这可能是最糟糕的）。 管理层还必须意识到重用。 如果没有管理支持，您的公司将不会有实质性的重用文化。
因此，它附有一个价格标签。 但当你真正付出代价时，这是值得的！
In Germany, we say: The truth lies in the middle
You marked two extremes here, but they are a good start. When you are to low-level, you will win nothing. Your reusable code should be worth the effort. When it does something, a mid-class programmer can implement in 3-7 lines or in 1-3 minutes, it might not be worth it, unless it is really, really needed often!
The other extreme is the generic SQL client. Of course, the reuse should not lay any burden on the user. That is a definitive no-no!
In my opinion, you should think about your project and then have a careful watch, what parts could be needed in multiple situations. These are candidates for reuse. But there are also other factors, you should check the candidates against, before you make the code reusable:
You might find further factors. I wanted to give some adhoc examples.
I think, "Think first" is the best rule of thumb for reuse ... and of course reuse needs much experience.
Also it needs extra effort:
That is a really main point, many people forget. Reuse does not come free! You have to pay for it.
You have extra costs for:
Also you have to establish a reuse-culture, what is not easy, since it goes against the fealings of plenty developers. All developers think that only them have found the holy-grail and only their code is good at all. So many people will be offended and resist reusing code. The resistence can be either open but also hidden to the bosses (which might be the worst). Also the management must be aware of reuse. Without management backup, you will not have a substantial reuse-culture in your company.
So, there is a price-tag attached to it. But it is worthwile, when you manage to really pay the price!
只使通用代码可重用。 仅在字符串最后附加 s 的函数除非已使用，否则没有任何价值，但可以在字符串末尾添加任何一个或多个字符的函数对于其他用途也很有用。
基本功能； 如果您有自己的列表、树、套接字和/或文件处理的函数和类型，所有这些都可以在共享库中有用。
此外，您还可以对所有函数和类型进行评论，并使用 Doxygen（或 Javadoc）等系统，然后自动生成文档，这使得它甚至可以在 IDE 之外进行搜索，并以某种不错的方式呈现。
Only make general code reusable. A function that only appends an s last in a string will not be of value except where it is already used, but a function that can add any one or more characters to the end of a string would be useful for other uses too.
Basic functionality; if you have your own functions and types for lists, trees, sockets and/or file handling, all these can be useful in the shared libraries.
Also, you can comment on all functions and types and use a system like Doxygen (or Javadoc) and then automatically generate the documentation, which would make it searchable even outside an IDE and presented in a somewhat nice way.
所有编写良好的代码都可以重用。
如果您花时间使代码通用并记录下来，您不仅可以在另一个项目中重复使用该代码，其他人也会真正查看您的代码。 这将大大提高任何人在用户之前发现错误/怪癖的可能性。
最主要的是要很好地区分代码应该放在哪里。 以“向字符串添加“s””为例 - 这可能是与“向字符串添加“h””和“向字符串添加“b”一起放在 strings-util 库中某处的代码字符串的函数。 当您同时看到这三个函数时，您可能会想到制作一个更通用的“向字符串添加任何字符”函数，从而使代码更加可重用 - 您还可以将字母“r”添加到字符串中现在！
您要发现始终将字符附加到字符串这一事实的唯一方法是确保这些函数彼此相邻 - 否则每个人都会将相同的函数隐藏在代码中的某个位置。
这些类型的 util 集合/类/任何内容都包含低级代码片段 - 它们是通用的，并且似乎与特定项目没有任何相关性。
规模的高端也应该被视为可重用代码。 举例来说，您的客户有一个很棒的新想法，例如在网站上添加图像。 其他人都不需要这个，所以您可以继续专门为此客户添加标签。 两周后，另一位客户向您提出完全相同的要求。
在这种情况下通常会发生的情况是，第一个客户端的额外代码被复制到第二个客户端的项目中 - 只是因为它看起来是让事情正常运行的最快方法。 实际发生的情况是代码的可维护性降低了。 现在，您在两个地方拥有相同的代码，并且存在相同的错误。 我想我们都知道这会导致未来出现问题。
如果该示例是为了可重用性而编写的，您可以在第二个项目中再次使用它，从而节省时间和精力。 另外，您的下一个客户要求的附加功能可能是您可以作为升级提供给第一个客户的东西 - （看，您现在可以设置高度和宽度，哇！）
至于知道代码存在，这是一个问题将永远留在那里。 我认为传播这些知识的最快方法是确保开发人员不会自行开发 - 结对编程就是一个很好的例子。 这样，每当写出一些东西时，至少有两个人会知道它。 如果你经常混合配对，知识就会在整个公司传播，而不需要任何额外的努力。
All well-written code is a candidate for re-use.
If you take the time to make code generic and documented, not only can you re-use the code in another project, others will actually look at your code. This will greatly improve the probability of anyone finding bugs/quirks before your users do.
The main thing is to make a good distinction where code should be. To take the 'add an "s" to a string' example - this could be code that is put somewhere in a strings-util library along with the 'add an "h" to a string' and 'add a "b" to a string' functions. When you see those three functions together, you'll probably get the idea of making a more generic 'add any character to a string' function, thus making the code even more reusable - you can also add the letter 'r' to a string now!
The only way that you are going to spot the fact that you are appending characters to a string all the time is to make sure these functions live next to each other - otherwise everyone will have the same functions hidden somewhere in the code.
These kinds of util collections/classes/whatever contain the low-level pieces of code - they are generic, and don't seem to hold any relevance to a specific project.
The higher-end of the scale should also be treated as reusable code. Say for instance you have a customer with a great new idea, like adding images on a website. Nobody else needs this, so you go ahead and add the tag specifically for this client. Two weeks later, you have another client who asks you for the exact same thing.
What usually happens in a situation like this is that the extra code for your first client gets copied into the project of the second client - just because it looks like it is the fastest way to get things working. What is actually happening, is that the maintanability of the code is degraded. You now have the same piece of code in two places, with the same bugs. I think we all know this leads to problems in the future.
If the example was written for reusability, you can use it again in the second project, saving time and effort. Also, the added features that your next client asks are probably something you can offer the first client as an upgrade - (see, you can set the height and width now, woohoo!)
As for knowing that code exists, that is a problem that will always remain there. I think the fastest way to spread this knowledge is to make sure developers don't develop on their own - pair programming is a good example of this. This way, whenever something is written, at least two people will know about it. If you regularly mix up the pairs, the knowledge will spread through the company without any extra effort.
我会重用并持续支持/重构：
我会扔掉（从scm中删除）并从头开始重写：
I would reuse and continually support/refactor:
I would throw away (delete from scm) and rewrite from scratch:
仅当我确定至少一次需要该功能，并且将代码制作成独立库所需的时间少于重建或复制所需的时间时，我才倾向于构建可重用库此外，正在创建的库必须解决一个问题，这使我无法构建范围太广而无法使用的巨大代码球。
最近的一个例子是一个插件，旨在提供应用程序和 Protx 支付系统之间的接口。 I 是解决一个问题的东西，到目前为止已经在几个不同的项目中使用过。
I tend to build reusable libraries only when I'm sure that I'll need the functionality at least one other time, and that the time taken to make the code into a stand-alone library is less than the time taken to rebuild or copy code in. Furthermore, the library being created must solve exactly one problem, which prevents me from building giant balls of code that are too wide in their scope to be of use.
A recent example of this was a plugin designed to provide an interface between an app and the Protx payment system. I's something that solves one problem, and has been used in several different projects so far.