blocks|key|4132971|text|我常用的经验法则是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4132972|4132973|如果重复一次，请复制它。|ordered-list-item|4132974|如果重复两次，请重构它。|4132975|4132976|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|L|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|M|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|N|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|J|$]]

My common rule of thumb is:

<ol>
<li>If you repeat it once, copy it.</li>
<li>If you repeat it twice, refactor it.</li>
</ol>

blocks|key|3287874|text|如果你确定你不会再需要它，那就别费心了。即使你认为它可能会派上用场。当你真的需要它的时候重构它...|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3287875|然而，不让它可重用并不是不让它变得透明的借口。每当我尽可能透明地编写代码时，它总是证明99%25已经是可重用的……|3287876|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you're sure you're not going to need it again, don't bother. Not even if you think it might come in handy. Refactor it when you really need it again...

However, not making it reuseable is no excuse for not making it transparent. Whenever I write code as transparently as possible, it always turns out to be 99% reusable already...

blocks|key|66497|text|leppie写道：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|66498|66499|我最常用的经验法则是：|blockquote|66500|66501|66502|66503|如果重复一次，请复制它。|ordered-list-item|66504|如果重复两次，请将其重构|66505|66506|我要补充的是，确保将注释添加到代码的两个部分，以指示重复，以防出现错误。你不会想把它修复在一个部分而不是另一个部分(BTDTGTT)。|offset|length|style|BOLD|66507|抢夺|66508|entityMap^0|0|0|0|0|0|0|0|0|0|F|5|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|10|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|K|7|15|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|17|8|@$Q|18|R|19|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1A|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|X|$]]

leppie wrote:

<blockquote>
 My common rule of thumb is:
 
 <ol>
 <li>If you repeat it once, copy it.</li>
 <li>If you repeat it twice, refactor it</li>
 </ol>
</blockquote>

And I would add, make sure that a comment is added to both parts of the code to indicate the duplication in case there's a bug. You don't want to fix it in one part and not the other (BTDTGTT).

Rob

blocks|key|66553|text|我同意你的观点，因为在当前应用程序之外，以一种使类易于使用的方式编码是没有意义的。大多数情况下，如果我们不这样做，在商业环境中就没有必要这样做。如果另一个应用程序在以后需要此功能，那么提取和通用化代码可以作为第二个项目的一部分完成，管理层可能会同意这一观点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|66554|但是，使您的代码在当前应用程序的约束内可重用是一种好的实践。重构您的代码，以避免在当前工作范围内出现重复。这样，以后使用它就更容易了。与其说代码是为了重用，不如说是为了改变，改变更常见。|66555|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I agree with you insofar as there is no point in coding in a way that makes the class easy to use outside of the current application. Most if us don't do this and in business environments there is no need to. If another application needs this functionality at a later date then extracting and commonalising the code can be done as part of that second project, and management are likely to agree with this viewpoint.

However it is good practice to make your code reusable within the constraints of the current application. Refactor your code so as to avoid duplication within your current scope of work. This way you make it easier to work with at a later date. Don't so much code for reuse as for change, change is far more common.

blocks|key|4133143|text|我的2c是，代码重用的伦理需要成为公司的事情，而不仅仅是项目的事情。这意味着当你开始一个新项目时，首要的关注点是“我可以从哪些其他项目中窃取代码，以便尽可能快地完成这项工作？”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4133144|这将与“什么是最好的--或最时髦的--语言/工具？”的问题相冲突。|4133145|采用这种方法的公司最终拥有一批工程师，他们可以很容易地从一个项目切换到另一个项目，因为语言、框架和内部代码库都是一致的。|4133146|不利的一面是，切换到“新”语言或框架在政治上更加困难，即使它需要在某个时候发生。|4133147|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

My 2c is that the ethic of code-reuse needs to be a company thing, not just a project thing. This means that when you start a new project, the primary concern is "which other projects can I steal code from to get this job done as well and as quickly as possible?".

This WILL conflict with the question of "what's the best - or trendiest - language/tool for the job?"

Companies that have this approach end up with a pool of engineers that can easily switch from project to project, because language, framework and internal code base are all consistent. 

The down-side is that switching to a "new" language or framework is much more politically difficult, even though it WILL need to happen at some point.

blocks|key|4133208|text|SOA失败或尚未解除的原因之一是很难重用服务:要么太具体，不能在其他地方使用，要么太通用(通常非常复杂)，不能满足不同客户的需求。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4133209|这不是“代码重用”，而是“服务重用”，但有一些共同的概念。|4133210|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

One of the reasons why SOA has been failing, or hasn't lifted of yet, is that it's difficult to reuse a service: either it's too specific and it can't be used elsewhere, or too generic (and usually very complex) and doesn't meet the needs of different clients.

This ain't "code reuse", it's "service reuse", but there are some common concepts.

blocks|key|4133292|text|我不是XP方法论(或任何方法论)方面的专家，但我认为YAGNI原则可以在这里应用。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4133293|只有在让重用代码时，才能修改代码进行重用。|style|BOLD|4133294|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/You_Ain%2527t_Gonna_Need_It^0|Q|5|0|0|3|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@$A|U|B|V|F|G]]|9|@]|C|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

I'm no expert in XP methodology (or any methodology), but I think the <a href="http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It" rel="nofollow noreferrer">YAGNI</a> principle could be applied here.

Only modify the code for reuse when you have to reuse it.

blocks|key|3288455|text|可配置性和可重用性是有区别的--前者在很多不同的情况下都非常有用，当环境发生变化或其他任何情况时--按照我的理解，让事情变得可配置主要是一种将代码和数据分离的情况--这真的是很好的实践。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3288456|只有当你正在创建一些你计划用来作为多个项目的库的东西时，设计可重用性才是真正有用的。随着时间的流逝，我越来越意识到YAGNI原则，这些天我的目标只是为手头的任务编写干净和健壮的代码。我的经验是，如果某个东西要被重用，你不太可能准确地预测它将如何被重用，所以现在只添加你需要的代码要好得多。这样，如果你将来需要重用它，你可以添加新的东西来做你需要的事情，而不必破坏你过去编写的任何现有功能，试图预测你现在可能会如何需要它。|3288457|你可能会发现，在这样做了几次之后，你有了一个稳定和健壮的库，不需要你去改变它，因为它实际上做了你需要的所有事情-对我来说，让它以一种进化的方式发生要比浪费太多的时间去猜测未来容易得多。|3288458|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

There is a difference between configurability and reusability- the former can be extremely useful in a lot of different situations, when the environment changes or whatever else- making things configurable in the way I understand it, is mostly a case of separating code and data- that's just good practice really.

Designing for reusability is only really useful if you're creating something you are planning to use as a library for multiple projects. As the years go by I have become increasingly aware of the YAGNI principle and these days I simply aim to write clean and robust code for the task at hand. My experience has been that if something is going to be reused it is very unlikely that you will predict exactly how it will need to be reused, so it's much better to only add the code that you need for now. That way if you need to reuse it in future you can add new stuff that does exactly what you need without having to break any existing functionality that you wrote in the past trying to anticipate how you might need it now.

You may find that after doing this a couple of times you have a library that is stable and robust and doesn't need you to change it because it actually does all the things you need- to me it's much easier to allow that to happen in that evolutionary way than to waste too much time guessing about the future.

blocks|key|896604|text|一旦你达到了技术实用程序的水平，我在现实世界中几乎看不到实际的重用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|896605|如果你仔细想想，原因是显而易见的。假设widget_bodger应用程序包含了所需功能的90%25，而您只需将缺少的功能添加到应用程序中即可。|896606|或者说，企业很欣赏widget_bodger中一个非常酷的“嘟嘟声”功能，并希望将其整合到gernerate_executive_expenses应用程序中。啊，重用，你可能会想，但是你深入研究代码，发现GEE应用程序是公司中最古老的应用程序之一，它是用C语言编写的，必须在高度可用的硬件上运行，唯一可重用的是基本算法。|896607|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Once you get above the level of technical utilities I have seen very little actual reuse in the real world.

If you think about it the reasons are clear. Say the widget_bodger application contained 90% of the functionality you require than you would just add the missing functionality to the application. 

Or say the business admired a really cool "beep" function in the widget_bodger and wanted it incorporated into the gernerate_executive_expenses application. Ah resuse you might think, but then you dig into the code and find that GEE application is one of the oldest apps in the company, is written in C, must run on highly available hardware and the only thing that is resuable is the basic algorithm.

blocks|key|901862|text|我认为最好的方法是尝试使用良好的接口和类之间的职责分离来设计代码，而不是过多地担心重用。但至少如果你以这种方式设计，你就保留了重用的可能性。一个不错的经验法则是问问自己：“如果我在3个月后回到这个代码，我能理解它吗?如果有必要的话，我能扩展它吗？”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|901863|IMO业界最糟糕的实践之一是，当一个团队被允许去编写他们自己的“可重用”框架时……|901864|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think that the best approach is to try and design code with good interfaces and separation of responsibilities between classes without worrying too much about reuse. But at least if you design this way you're leaving open the possibility of reuse. A good rule of thumb is to ask yourself "if I come back to this code after 3 months, will I understand it and could I extend it if I had to?"

IMO one of the worst practices in the industry is when a team are given the go-ahead to go off and write their own "reusable" framework....

blocks|key|3288623|text|关于是什么让代码变得可重用有非常不同的观点。我想说，你的时间花在了让代码清晰和分解良好(即职责分离)上。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3288624|这样做的一个附带好处是更好的可重用性。主要的好处是使代码更容易理解、更改和调试。|3288625|把它包起来。不要仅仅为了使其可重用而进行复杂的配置方案、扩展点和事件。尝试找到正确的移动部分，以便可以根据新的需求编写代码。|3288626|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

There are very different opinions on what makes code reusable. I'd say your time well spent making the code clear and well-factored (i.e. separation between responsibilities). 

A side benefit from this is better reusability. The main benefit is making the code easier to understand, change and debug.

To wrap it up. Don't do complex configuration schemes, extension points and events just to make it reusable. Try to find the right moving parts so that the code can be composed in response to new needs.

blocks|key|4133628|text|我喜欢LISP模型，在该模型中，您可以不断扩展语言。最终，您会得到一种针对您的问题域的特定于域的语言。我并不是真的写任何lisp，而是在我最常用的语言中-Lua和C语言-我通常将一些东西提取到模块中并重用它，而不是克隆和修改它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4133629|对于C程序员来说，这种方法的典型例子是Dave+Hanson的书C+Interfaces+and+Implementations。Dave把他在写三四个编译器时的每一个可重用的想法都放在一本书里-而且这个软件是免费的。很棒的东西。现在，如果我写了C代码，并且我想第二次使用它，我会用Hanson风格做一个接口。我在这个学期做了一些事情:2维数组，带块的2维数组，2维位图，pbmplus文件的读取器和写入器，等等。有了这个基础设施，就很容易编写一个我多年来一直想要的程序，那就是消除书页复印件扫描中的黑边。|offset|length|4133630|所以我同意任何人所说的，当你想要重用它时，把它拔出来-但不是在此之前。|4133631|entityMap|0|LINK|mutability|MUTABLE|url|http://www.cs.princeton.edu/software/cii/^0|0|W|W|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

I like the LISP model where you are continually extending the language. Eventually you wind up with a domain-specific language for your problem domain. Not that I actually write any lisp, but in the languages I use most often---Lua and C right now---I usually pull something out into a module and reuse it rather than clone and modify.

For a C programmer, the quintessential example of this approach is Dave Hanson's book<a href="http://www.cs.princeton.edu/software/cii/" rel="nofollow noreferrer">C Interfaces and Implementations</a>. Dave took every reusable idea he'd had in writing three or four compilers and put them all in a book---and the software is free. Fabulous stuff. Now if I write C code and I want to use it a second time, I make an interface in Hanson style. Some things I did this term: 2-dimensional arrays, 2-dimensional arrays with blocking, 2-dimensional bitmaps, readers and writers for pbmplus files, and so on. With this infrastructure in place it was easy to write a program I'd been wanting for years, which is to remove black edges from scans of photocopies of book pages.

So I agree with whomever said when you want to reuse it, pull it out---but not before.

blocks|key|67046|text|我的意思是，某些代码可能会经常被重用，因此为频繁重用做好准备是有意义的。其他代码不是，而且可能不需要开发，除非解决了直接的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|67047|当然，一定要意识到区分不同是很难的。:)|67048|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

IMHO, certain code is likely to be reused often, and it makes sense to prepare it for frequent reuse. Other code isn't, and probably doesn't need to be developed beyond solving the immediate problem.

Of course, do be aware that telling the difference is NP-hard. :)

blocks|key|902086|text|通常，“可重用”代码是抽象和模块化的代码，对我来说，主要好处不是可重用性，而是增加了可测试性。因为当您隔离和模块化代码时，它通常会变得更容易测试。重用是一种方便但通常未使用的副作用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|902087|另外，Juval+Lowry提倡基于接口的编程，因为他坚持认为接口是可重用性的唯一组件。其他任何东西都有隐含的功能(难以重用)，而接口只定义了一个隐式可重用的契约。|902088|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Often "reusable" code is code that is abstracted and modularized, and, to me, the main benefit is not reusability but rather increased testability. Because when you isolate and modularize code it usually becomes more testable. Reuse is a convenient but often unused side effect.

And on another note, Juval Lowry advocates interface-based programming since he maintains that interfaces are the sole component of reusability. Anything else has implied functionality (hard to re-use) while interfaces define a contract only which is implicitly reusable.

blocks|key|3288753|text|重用的另一个好处是，您可以很容易地跟踪oode库中发生的事情。如果您有一百万行代码，可能需要几个小时才能找到应用程序以特定方式运行的所有位置。在现代的IDE中，您只需单击“查找引用”，就会在几秒钟内找到使用您的组件/方法的所有位置。当您想要添加新功能、修复错误或只是想了解系统如何工作时，这会很有用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3288754|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Another benefit with reuse is that you can easiliy track where things happens in the oode base. if you got a million lines of code it can take hours to find all places where the application behaves in certain way. With a modern IDE you can just click "find references" and you'll find, within a couple seconds, all places where your component/method is used. This can be useful when you want add new features, fix bugs or just want to learn how the system works.

blocks|key|67120|text|我们有几个，但我们有更多的项目具有你想要的功能，但以他们自己的方式完成，所以通常你最终会从旧项目中蚕食功能，并在你的新项目中重新实现它们。我认为这仍然很重要--你仍然可以从以前写过代码中得到好处，并且你仍然可以节省时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|67121|此外，我发现这只是你第二次尝试和使用该功能，它变得明显的可重用性，如果你尝试和推论的东西，你几乎总是错误的，下一次必须改变它。|67122|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

We have a few, but what we have many more of are projects with the functionality you want but done in their own way, so more often than not you end up cannibalising features from old projects and reimplementing them in your new one. I'd argue that this still counts - you're still getting the benefit of having written the code before, and you still save the time.

Besides, I've found that it's only the second time that you try and use the functionality that it becomes obvious where the reusability is, and if you try and generalise something speculatively you almost always get it wrong and have to change it next time.

blocks|key|4133746|text|就像其他帖子所说的那样，如果你打算复制代码然后重用，一旦你开始调试你复制的代码，你会很高兴这样做的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4133747|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Like other posters have said if you are going to copy the code then re-use, you will be glad you did this once you start debugging your copied code.

We all write reusable classes and code. 

We factor in configurability to allow us to reuse this fantastic new class again and again. 

We tell our bosses that spending this extra time now will save us time and money later. 

But in reality, for those of us who don't write third party libraries, and spend our time working on a application as a whole, how many times does that one class you spent extra time writing to be reused actually get reused in another project? 

How many bespoke classes do you have in your library which will get used in more than one project?

Code Reusability: Is it worth it?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我们都编写可重用的类和代码。我们将可配置性考虑在内，以允许我们一次又一次地重用这个神奇的新类。我们告诉老板，现在花这额外的时间可以节省我们以后的时间和金钱。但在现实中，对于我们这些没有编写第三方库的人来说，将我们的时间花在整个应用程序上，你花了额外时间编写的一个类被重用了多少次，实际上在另一个项目中得到了重用？你的库中...

问代码可重用性:值得吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问代码可重用性:值得吗？EN