构建代码资产库

时间:2009-12-21 00:56:37

标签: shared-libraries code-reuse

我一直在考虑为我们组织内部开发的所有软件设置某种类型的库。我想收集好SO人可能对这个主题有任何想法。

我认为,向开发人员灌输编写可重用代码的好处有什么意义,如果在下一个项目中开发人员做的第一件事就是文件 - >由于缺乏已经重用的代码的知识而导致的新功能。

作为一个额外的好处,我认为只要拥有这样的库就可以鼓励开发人员在编写代码时更多地考虑可重用性

我想让这个库尽可能简单,也许我唯一的两个要求是:

  • 搜索工具
  • 适用于多种类型的组件:组件,Web服务等

我看到每个资产/组件所需的基本信息是:

  • 姓名&版本
  • 描述/目的
  • 依赖关系

您会记录更多信息吗?

什么是最好的平台,即维基,论坛等?

什么会使像这样的软件库成功与不成功?

非常感谢所有想法。

由于

编辑:

发布后发现了类似的问题:

How do you ensure code is reused correctly?

How do you foster the use of shared components in your organization?

1 个答案:

答案 0 :(得分:5)

听起来贵组织没有可用的代码中央存储库。根据您的操作,这可能是因为安全限制导致知识的混合,外部供应商代码包含在部分/全部解决方案中,或者您的公司尚未看到让人们重复使用的好处,重构,并传播这种存储库的好处。

我在多家公司看到的解决方案的共同属性是多方面的方法

  1. 从管理层处购买某个级别。通常这是一个CTO / CIO,这个想法引起了共鸣,他们声称这是一件好事,并且不给任何资金来资助它,但是如果他们意识到有人会在之前支持这个想法,他们就不会吝啬他们开始征求代码并将其整合到某个地方。
  2. 一些项目清单和英文版的抵押品。在wiki上,在sharepoint列表中,在源存储库中的文本文件中看到这一点。所有这些都共享某种前端搜索服务器的共同属性,该服务器允许对解决方案的描述进行全文。
  3. 二进制文件和/或代码的一些常见共享或存储库。通常,大型组织对于许多不同的环境具有不同的认证/授权方法,并且共享单个存储库可能不实际(或者可能在逻辑上) - 不要挂在那个方面 - 只是试着让它达到目的有一个众所周知的共享/目录/存储库,适用于您的组织。
  4. 始终确保有人列为联系人 - 没有人接受过代码并在生产中运行代码而不必与之前的所有者交谈 - 如果您没有人,他们可以马上开始提问,然后他们就可以继续点击文件> new。

我见过的不成功的属性?

  1. 每个工程师每个时间段提交的N份数量=很多废话开始使其进入
  2. 没有评级/反馈方法。如果没有办法收藏/评价/给出一些让奶油上升到顶部的指标,你就不会经常回去搜索它,因为你无法从其他人那里获益,因为这些代码都没有真的很好。
  3. 缺少与作者联系的反馈/电子邮件链接,问题直接发送到他们的电子邮件中。
  4. 缺乏有机分类的能力。每当有一些预定的超级严格的层次结构或类别列表时,一切都以“其他”结束。如果您使用标签或类似标签,则可以避免使用它。
  5. 一些设计文档的要求伴随着严格格式的代码是不被接受的 - 没有人能够就设计文档的“集中”格式达成一致,并且没有人提交过是必须的。

只是我的想法。