开发人员是否应该仅限于某些软件进行开发？
开发人员是否应该仅限于某些应用程序进行开发？
对于大多数人来说，答案是只要开发团队同意这并不重要。
对于经过安全认证审核的公司，是否有一种方法可以平衡公司的风险和开发人员的灵活性、绩效？
范围
- 编码/开发软件
- 构建系统软件
- 第三方软件包含分发（库、实用程序）
- （附加） 工作站上的剩余软件
可能的解决方案
创建已批准软件的白名单，开发人员必须在使用所需软件之前请求批准该软件。批准将基于业务目的/安全风险。
创建软件黑名单。开发人员列出了所有使用的软件。审查委员会定期审查列表。
有没有人必须在一家将开发人员工具限制在团队设置之外的公司工作？他们是如何处理这种情况的？
编辑
清理问题。试图少一些争论。
Should developers be limited to certain applications for development use?
For most, the answer would be as long as the development team agrees it shouldn't matter.
For a company that is audited for security certifications, is there a method that balances the risk of the company and the flexibility, performance of the developers?
Scope
- coding/development software
- build system software
- 3rd party software included with distribution (libraries, utilities)
- (Additional) Remaining software on workstation
Possible solutions
Create white-list of approved software where developer must ask for approval for desired software before he/she can use it. Approval would be based on business purpose/security risk.
Create black-list for software. Developers list all software used. Review board periodically goes over list.
Has anyone had to work at a company that restricted developer tools beyond the team setting? How did they handle the situation?
Edit
Cleaned up question. Attempted to make less argumentative.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
限制开发人员可以在其工作机器上使用的软件是一个很棒的主意。这样，所有的开发人员都会退出，公司就不用花那么多钱在工资和设备上，从而获得更高的利润。
真实答案：不！！！
Limiting the software that developers can use on their work machines is a fantastic idea. This way, all the developers will quit, and then the company won't have to spend as much money on salaries and equipment, resulting in higher profits.
Real answer: NO!!!
不，开发人员不应该限制他们使用的软件，因为这会妨碍他们成功地完成工作。想想你付给你的开发团队多少钱——你真的希望所有的钱都因为你人为地阻止他们解决问题而白白浪费掉吗？
当开发人员需要执行具有管理权限的操作时会发生什么？ EG：注册一个 COM 对象，重新启动 IIS，或者安装他们正在构建的产品？你刚刚关闭了它们。
由于软件数量庞大，这也是不切实际的。作为一名 .NET 开发人员，我经常（至少每周一次）使用超过 50 个不同的应用程序，并且不断评估其中许多应用程序的更新升级/替代方案。如果一切都必须经过白名单，那么您的“审批”人员将完全被一两个开发人员淹没，更不用说一个团队了。
如果您采取其中任何一项操作，您将实现以下目标：
当开发人员坐在他们的大拇指上等待您的批准团队时，您将消耗大量的时间和金钱，或者以漫长而缓慢的乏味方式做事，因为他们不被允许安装有用的工具
你会让自己成为开发部门的敌人（如果你希望你的开发人员真正做你要求他们做的事情，那就不好了）
你会大大降低团队士气。没有人喜欢被锁在笼子里的感觉，每次他们想到“如果我能安装 grep 的话 5 小时前就完成了”，他们就会不高兴。
一个更可接受的答案是，如果您遇到开发人员偷懒的问题，则为“问题”软件（和网站）（例如 Pidgin、MSN Messenger 等）创建黑名单。一些开发人员也会反对这一点，但许多开发人员会对此表示同意，只要您对列入黑名单的内容保持明智并且不要太过分。
No, developers should not be limited in the software they use, because it prevents them from successfully doing their jobs. Think about how much you are paying your team of developers, - do you really want all that money to go spiraling down the drain because you've artificially prevented them from solving problems?
What happens when the developer needs to do something with administrative permissions? EG: Register a COM object, restart IIS, or install the product they're building? You've just shut them down.
This is also impractical due to the sheer amount of software. As a .NET developer I regularly (at least once per week) use upwards of 50 distinct applications, and am constantly evaluating newer upgrades/alternatives for many of these applications. If everything must go through a whitelist, your "approval" staff are going to be utterly swamped by just one or 2 developers, let alone a team of them.
If you take either of these actions, you'll achieve the following:
You'll burn giant piles of time and money as the developers sit on their thumbs waiting for your approval team, or doing things the long slow tedious way because they weren't allowed to install a helpful tool
You'll make yourself the enemy of the development department (not good if you want your devs to actually do what you ask them to do)
You'll depress team morale substantially. Nobody enjoys feeling like they're locked in a cage, and every time they think "This would be finished 5 hours ago if only I could install grep", they'll be unhappy.
A more acceptable answer is to create a blacklist for "problem" software (and websites) such as Pidgin, MSN messenger, etc if you have problems with developers slacking off. Some developers will also rail against this, but many will be OK with it, provided you are sensible in what you blacklist and don't go overboard.
我认为开发人员应该完全控制他们使用的应用程序，只要他们可以使用它们完成工作。开发人员的生产力与工作环境直接相关，没有人会喜欢受到限制，每个人都喜欢使用自己喜欢的软件。
当然，在版本控制、文档格式等方面应该有一些标准，但通常开发人员应该有权使用他们想要的任何程序。
安全性应该是开发人员关心的问题 - 公司管理员应该关心设置适当的防火墙以防止任何类型的攻击。
I think developers should have total control on applications that they use as long as they can do their job with them. Developers' productivity is directly related to working environment and no one will like being restricted and everyone likes to use software they like themselves.
Of course there should be some standards in terms of version control, document format, etc., but generally developers should have right to use any programs they want.
And security should be developer's concern - company admins should care about setting up proper firewall to protect against any kinds of attacks.
更好的解决方案是为开发人员创建一个安全的独立环境。如果环境受到损害，不会使公司的其他部门面临风险。
开发的本质是创造巧妙、巧妙、简洁的解决方案。为了实现这一目标，必须发生失败。
A better solution would to create a secure independent environment for the developers. An environment that if compromised won't put the rest of the company at risk.
The very nature of the development is to create crafty ingenuous pithy solutions. To achieve this, failures must happen.
无论他们做什么，都不会夺走整个互联网。 Google = 编码帮助 101 :)
或者也许只是允许 www.stackoverflow.com 哈哈。
Whatever they do, don't take away the Internet in general. Google = Coding Help 101 :)
Or maybe just leave www.stackoverflow.com allowed haha.
我想说这取决于很多因素。
一是团队规模。如果您有一个由六名开发人员组成的团队，那么只要出现对某些应用程序的需求，就可以进行协商。如果您有一个由 100 名开发人员组成的团队，则可能需要制定一些策略。
另一个因素是这些开发人员的行为。如果他们使用嵌入式平台的专有编译器来编译 C 代码，那么情况与在不断变化的环境中生产分布式 Web 或 PC 软件的团队有很大不同。
您生产的软件和目标客户也很重要。如果您将 Linux 内核移植到某个新平台，代码是否泄漏可能并不那么重要。 OTOH，在很多情况下，情况都非常不同。
还有更多因素，但最终都归结为两个相互冲突的目标：
您必须找到一个不会损害创造力的中间立场，同时允许足够的保证不损害公司。
I'd say this depends on quite a list of factors.
One is team size. If you have a team of half a dozen developers, this can be negotiated whenever a need for some application pops up. If you have a team of 100 developers, some policy is probably in order.
Another factor is what those developers do. If they compile C code using a proprietary compiler for an embedded platform, things are very different from a team producing distributed web or PC software in a constantly shifting environment.
The software you produce and the target customers are important, too. If you're porting the Linux kernel to some new platform, whether code leaks probably doesn't matter all that bad. OTOH, there are a lot of cases where this is very different.
There are more factors, but in the end it all boils down to two conflicting goals:
You'll have to find a middle ground that doesn't hurt creativity while allowing enough guarantees to not to hurt the company.
当然！如果您想要一个可重复的构建过程，那么您不希望它被程序员碰巧用作生成部分代码的工具的任何随机垃圾所污染。由于您正在构建的任何应用程序的持续时间都比任何人预期的要长得多，因此您还希望确保用于构建它的工具在大致相同的持续时间内可用；互联网上的随机工具不提供任何此类保证。
您的团队应该说“构建步骤允许使用以下工具，仅此而已”，并尝试使该列表简短。
显然，程序员看什么来决定做什么并不重要，所以整个互联网只要看就可以了。他是否通过魔法（或随机工具）生成代码也没关系，只要您的团队不介意只接受该工具的输出，就好像它是手工编写的一样。
Of course! If you want a repeatable build process, you don't want it contaminated by whatever random bit of junk a programmer happens to use as a tool to generate part of the code. Since whatever application you are building lasts much longer than anyone expects, you also want to ensure that the tools you use to build it are available for roughly the same duration; random tools from the internet don't provide any such gaurantee.
Your team should say "The following tools are allowed for build steps and nothing else" and attempt to make that list short.
Obviously, it shouldn't matter what a programmer looks at to decide what to do, so the entire Internet is just fine as long as its just-look. Nor does it matter if he produces code by magic (or random tool) as long as your team doesn't mind accepting just that tool's output as though it were written by hand.