开发人员是否应限于某些开发软件?

时间:2009-09-28 03:55:28

标签: ide libraries build-system

开发人员是否应限于某些应用程序以供开发使用?

对于大多数人来说,只要开发团队同意它并不重要,答案就是答案。

对于经过安全认证审核的公司,是否有一种方法可以平衡公司的风险以及开发人员的灵活性和绩效?

范围

  1. 编码/开发软件
  2. 构建系统软件
  3. 分发包含的第三方软件(图书馆,公用事业)
  4. (附加)工作站上的剩余软件
  5. 可能的解决方案

    1. 创建已批准软件的白名单,开发人员必须先获得所需软件的批准才能使用该软件。批准将基于业务目的/安全风险。

    2. 为软件创建黑名单。开发人员列出所有使用的软件。审核委员会定期查看清单。

    3. 是否有人必须在限制开发人员工具超出团队设置的公司工作?他们是如何处理这种情况的?

      修改

      清理问题。试图减少争论。

7 个答案:

答案 0 :(得分:17)

限制开发人员可以在其工作机器上使用的软件是个绝妙的主意。通过这种方式,所有开发商都将退出,然后公司将不必在工资和设备上花费那么多钱,从而获得更高的利润。

真实回答:不是!!!

答案 1 :(得分:7)

不,开发人员不应该限制他们使用的软件,因为它阻止他们成功地完成工作。想想你为你的开发团队支付了多少钱 - 你是否真的希望所有这些资金都流失,因为你人为地阻止他们解决问题?

  

1)公司锁定电脑并将开发人员视为秘书的主管

当开发人员需要使用管理权限执行某些操作时会发生什么? EG:注册COM对象,重新启动IIS,或安装他们正在构建的产品?你刚关闭它们。

  

2)创建已批准软件的白名单......

由于软件数量庞大,这也是不切实际的。作为.NET开发人员,我经常(至少每周一次)使用超过50个不同的应用程序,并且不断评估许多这些应用程序的更新升级/替代方案。如果一切都必须通过白名单,那么你的“批准”工作人员将被一两个开发人员完全淹没,更不用说他们的团队。

如果您采取其中任何一项行动,您将获得以下结果:

  1. 当开发人员坐在他们的拇指上等待你的审批团队,或者做长期缓慢乏味的工作时,你会烧掉大量的时间和金钱,因为他们不允许安装有用的工具

  2. 你会让自己成为开发部门的敌人(如果你希望你的开发人员真正做你要求他们做的事情,那就不好了)

  3. 你会大大压抑团队士气。没有人喜欢他们被关在笼子里的感觉,每当他们想到“这将在5小时前完成,如果我只能安装grep”,他们就会不高兴。

  4. 更可接受的答案是为“问题”软件(和网站)创建黑名单,例如Pidgin,MSN messenger等,如果您遇到开发人员懈怠的问题。一些开发人员也会反对这一点,但是如果你对你的黑名单很明智并且不会过分关注,很多人都会对它有所了解。

答案 2 :(得分:3)

我认为开发人员应该完全控制他们使用的应用程序,只要他们可以使用它们。开发人员的工作效率与工作环境直接相关,没有人愿意受到限制,每个人都喜欢使用自己喜欢的软件。

当然应该在版本控制,文档格式等方面有一些标准,但一般来说开发人员应该有权使用他们想要的任何程序。

安全性应该是开发人员关注的问题 - 公司管理员应该关注如何设置适当的防火墙以防止任何类型的攻击。<​​/ p>

答案 3 :(得分:2)

更好的解决方案是为开发人员创建安全的独立环境。如果受到损害的环境不会使公司其他部门面临风险。

开发的本质是创造狡猾的巧妙精炼解决方案。要做到这一点,必须发生失败。

答案 4 :(得分:1)

无论他们做什么,都不会带走互联网。 Google =编码帮助101:)

或者只是留下www.stackoverflow.com允许哈哈。

答案 5 :(得分:1)

我会说这取决于很多因素。

一个是团队规模。如果你有一个由六个开发人员组成的团队,那么每当需要某个应用程序弹出时,就可以进行协商。如果您有一个由100名开发人员组成的团队,那么可能需要制定一些策略。

另一个因素是那些开发人员所做的事情。如果他们使用嵌入式平台的专有编译器编译C代码,那么与在不断变化的环境中生成分布式Web或PC软件的团队有很大不同。

您生产的软件和目标客户也很重要。如果您将Linux内核移植到某个新平台,那么代码泄漏是否可能并不重要。 OTOH,很多情况下非常不同。

还有更多因素,但最终归结为两个相互冲突的目标:

  • 你想给你的开发者尽可能多的自由,因为这会刺激他们的创造力。
  • 您希望尽可能地限制它们,因为这样可以降低风险。 (我说的是安全风险以及运送无法运行的软件的风险等。)

你必须找到一个不损害创造力的中间立场,同时允许足够的保证不伤害公司。

答案 6 :(得分:0)

当然!如果你想要一个可重复的构建过程,你不希望它受到程序员碰巧用作生成部分代码的工具的任何随机垃圾的污染。由于您构建的任何应用程序的持续时间比任何人预期的要长,因此您还需要确保用于构建它的工具的持续时间大致相同;来自互联网的随机工具不提供任何此类保证。

您的团队应该说“允许以下工具进行构建步骤,而不是其他任何工具”,并尝试缩短该列表。

显然,程序员决定做什么并不重要,所以整个互联网只要看起来就好了。只要你的团队不介意接受该工具的输出就好像是手工编写的那样,他是否通过魔法(或随机工具)生成代码也没关系。