片段与框架

发布于 2024-10-07 11:33:39 字数 296 浏览 4 评论 0原文

我发现很多库和框架看起来有点太笨重且难以维护。我喜欢 FlashGameDojo 通过推广使用片段来解决此问题的方式可以根据需要将其放入代码中。显然,这种方法也有缺点,比如试图跟踪不同的代码片段。

我想知道是否有某种商定的方法来管理此类代码库。您如何保持每个片段的新鲜度,找到项目所需的片段等。如果没有“最佳实践”,也许您可​​以分享一些您的经验。

谢谢!

I've been finding that a lot of libraries and frameworks can seem a bit too unwieldy and hard to maintain. I like the way that FlashGameDojo approaches this problem by promoting the use of snippets that can be dropped into code as needed. Obviously, there are drawbacks to this approach too like trying to keep track of disparate pieces of code.

I'm wondering if there is some kind of agreed upon approach to managing this type of code library. How do you keep each snippet fresh, find the ones you need for a project, etc. If there is no "best practice" for this, perhaps you can share some of your experiences.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

謸气贵蔟 2024-10-14 11:33:39

框架往往也有成本。虽然他们可以抽象出大量重复性任务,但他们有一个学习曲线。这里的好处是文档通常非常好。我将引用 CakePHP 和 Symfony 作为例子。

代码片段总是很有帮助,但迟早它会让代码库变得不完整。理解不同的代码片段也需要脑力。代码来自不同的来源,因此不会有曾经的中心信息来源。

对我来说,在框架和片段之间进行选择的最大因素是我的技能以及团队中其他人的技能。沟通是关键。

开发人员可以阅读文档的团队应该坚持使用框架。我曾加入过这样的团队,那里的开发人员往往会谨慎行事。这样的团队往往会利用框架的 API 快速完成标准化任务。然而,当需要定制时(因为客户喜欢做出改变),他们的速度往往会变慢。这种团队的优点是每个人都可以替代另一个人。但最大的缺点是缺乏专业化,导致人们对工作的依恋度降低。

开发人员可以阅读代码本身的团队应该使用代码片段。我也曾加入过这样的团队,那里的开发人员往往懂得更多一些。他们的定制速度确实很快,但在执行重复性任务时却陷入困境。每个开发人员都有一个他们倾向于关心的身份。他们很可能对自己的工作感到自豪,并会尽一切努力在同事面前“看起来很酷”。但最大的缺点是,一些开发人员可能是自大的混蛋。

Frameworks tend to have a cost too. While they can abstract away lots of repetitive tasks, they have a learning curve. The good thing here is that the documentation is usually very good. I shall cite CakePHP and Symfony as my examples.

Snippets have always been helpful, but sooner or later, it makes the codebase patchy. It takes brainpower to understand the different snippets of code too. The code came from different sources, so there won't be once central source of information.

For me, the biggest factor in picking between frameworks and snippets is my skill, and the skill of the other folks in the team. Communication is the key.

Teams where developers are okay with reading documentation should stick to frameworks. I've been in such teams, and developers there tend to play it safe. Such a team tends to breeze through standardized tasks quickly, leveraging the API of the framework. However, when customization is required (because clients like making changes) they tend to go slower. Advantages of such a team is that each person can potentially fill in for another. The biggest disadvantage though, is that the lack of specialization makes people less attached to their work.

Teams where developers are okay with reading the code itself should go with snippets. I've also been in teams like that, and developers there tend to know a little more. They are really fast in customization, but they get bogged down when doing repetitive tasks. Each developer has an identity that they tend to care about. It's highly likely that they are proud of their work, and will do everything to "look cool" in front of their peers. The biggest disadvantage though, is that some developers can be pompous jerks.

墟烟 2024-10-14 11:33:39

我的第一选择是保留一个或多个包含您想要重用的所有代码的项目。按文件夹/命名空间分解代码是有意义的。

然后您可以将此项目包含到其他项目中并直接使用代码,而无需复制/粘贴。

优点:您可以立即看到代码是否损坏(无法编译),您可以立即看到函数/方法是否不足以满足您当前的需求。然后您可以决定是否需要更新或扩展代码。

第二个选择是使用在线片段管理器(因为它可以从任何地方访问)。由于您将复制/粘贴此代码,因此您将无法仅在一个位置修复某些问题。

在线片段管理器的一个示例是 http://www.int64.io - 您可以将片段组织到“板”中“(如文件夹),您可以使用预定义标签或您自己的标签来标记它们。在不久的将来,您将能够搜索这些片段。

还有其他代码片段管理器,例如 GitHub Gist、jsfiddle、codepen 等。

免责声明:我是 http:// /www.int64.io

My first preference would be to keep a single or multiple projects that contain all of the code you want to re-use. It makes sense to break the code out by folders/namespaces.

Then you can include this project into other projects and use the code directly without having to copy/paste.

Advantages: you immediately see if code is broken (it won't compile), you immediately see if a function/method is not specific enough for your current needs. Then you can decide if you need to update or extend the code.

Preference two would be to use an online snippet manager (since it's accessible from anywhere). You will loose the ability to fix something only in one spot since you will be copying/pasting this code.

An example of an online snippet manager is http://www.int64.io - you can organize snippets into "boards" (like folders), you can tag them using pre-defined tags or your own. You will be able to search through the snippets in the near future.

There are other snippet managers as well, like GitHub Gist, jsfiddle, codepen, etc.

Disclaimer: I'm the owner of http://www.int64.io

默嘫て 2024-10-14 11:33:39

GitHubGist 您可以在其中保存和组织您的代码片段。我喜欢与它集成的 GistBoxApp ,它具有更好(更有组织)的 UI。

我也尝试过将内容保留在 Evernote 中,但因为它不能很好地保持内容的格式,所以我很快就放弃了。 (这是一件很难放弃的事情 - 我已经在 Evernote 中记录了 15K 条笔记,记录了我世界中的所有内容。)

GistBoxApp 最好的一点是,我可以保留一些片段,这些片段可以让我开始使用文件,也可以拥有我的古怪小功能我觉得与我有情感上的联系。

There is GitHubGist where you can keep and organize your snippets. I like the GistBoxApp that integrates with it and has a nicer (and more organized) UI.

I've tried to keep things in Evernote, too, but because it doesn't keep things nicely formatted, I quickly gave up on that. (And it was a hard thing to give up on - I have 15K notes in Evernote for everything in my world already.)

The best thing about GistBoxApp is that I can keep snippets that either get me started with files or have my quirky little functions that I feel emotionally connected to.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文