构建代码资源库

发布于 2024-08-15 16:59:42 字数 1435 浏览 1 评论 0原文

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

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

发布评论

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

评论(1

别念他 2024-08-22 16:59:42

听起来您的组织没有可用的中央代码存储库。根据您所做的操作,这可能是由于安全限制导致知识的压缩、部分/全部解决方案中包含外部供应商代码这一事实,或者您的公司尚未看到让人们重用的好处,重构并宣传此类存储库的好处。

我在多家公司看到的解决方案的共同特征是多管齐下。

  1. 在某种程度上从管理层那里获得支持。通常,这个想法会引起 CTO/CIO 的共鸣,他们声称这是一件好事,并且不会提供任何资金来资助它,但如果他们知道有人会在之前支持这个想法,他们就不会阻碍你。他们开始征集代码并将其整合到某个地方。
  2. 一些项目清单和抵押品有英文版本。在 wiki、共享点列表、源存储库中的文本文件中看到了这一点。它们都具有某种前端搜索服务器的共同属性,该服务器允许在解决方案的描述上提供全文。
  3. 二进制文件和/或代码的一些常见共享或存储库。通常,大型组织针对许多不同的环境有不同的身份验证/授权方法,并且共享单个源存储库可能不切实际(或在逻辑上不可能) - 不要在这方面挂断 - 只要尝试抓住要点有一个适合您的组织的众所周知的共享/目录/存储库。
  4. 始终确保有人被列为联系人 - 没有人会在不与它的前任所有者交谈的情况下获取代码并在生产中运行它 - 如果你没有人,他们可以立即开始询问问题他们可能会直接点击文件->新建。

我见过不成功的属性?

  1. 每个工程师每个时间段提交 N 次提交 = 大量废话开始出现
  2. 没有评级/反馈的方法。如果没有办法收藏/评分/给出一些指标,让奶油上升到顶部,你就不会经常回去搜索它,因为你无法从其他人辛苦地完成代码中受益。真的非常好。
  3. 缺乏反馈/电子邮件链接,可以直接通过电子邮件联系作者并提出问题。
  4. 缺乏有机分类的能力。每当有一些预先确定的超级严格的层次结构或类别列表时,所有内容都会以“其他”结束。如果您使用标签或类似的东西,您可以避免它。
  5. 要求附带一些具有严格格式的设计文档,代码不被接受 - 没有人能够就设计文档的“集中”格式达成一致,也没有人在需要时提交。

只是我的想法。

Sounds like there is no central repository of code available at your organization. Depending on what you do this could be because of compatmentalization of the knowledge due to security restrictions, the fact that external vendor code is included in some/all of the solutions, or your company has not yet seen the benefits of getting people to reuse, refactor, and evangelize the benefits of such a repository.

The common attributes of solutions I have seen work at mutiple corporations are a multi pronged approach.

  1. Buy in at some level from the management. Usually it's a CTO/CIO that the idea resonates with and they claim it's a good thing and don't give any money to fund it but they won't sand in your way if they are aware that someone is going to champion the idea before they start soliciting code and consolidating it somewhere.
  2. Some list of projects and the collateral available in english. Seen this on wikis, on sharepoint lists, in text files within a source repository. All of them share the common attribute of some sort of front end search server that allows full text over the description of a solution.
  3. Some common share or repository for the binaries and / or code. Oftentimes a large org has different authentication/authorization methods for many different environments and it might not be practical (or possible logistically) to share a single soure repository - don't get hung up on that aspect - just try to get it to the point that there is a well known share/directory/repository that works for your org.
  4. Always make sure there is someone listed as a contact - no one ever takes code and runs it in production without at lest talking to the previous owner of it - and if you don't have a person they can start asking questions of right away then they might just go ahead and hit file->new.

Unsuccessful attributes I've seen?

  1. N submissions per engineer per time period = lots of crap starts making it's way in
  2. No method of rating / feedback. If there is no means to favorite/rate/give some indicator that allows the cream to rise to the top you don't go back to search it often because you weren't able to benefit from everyone else's slogging through the code that wasn't really very good.
  3. Lack of feedback/email link that contacts the author with questions directly into their email.
  4. lack of ability to categorize organically. Every time there is some super rigid hierarchy or category list that was predetermined everything ends up in "other". If you use tags or similar you can avoid it.
  5. Requirement of some design document to accompany it that is of a rigid format the code isn't accepted - no one can ever agree on the "centralized" format of a design doc and no one ever submits when this is required.

Just my thinking.

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