解决客户政策中的发展限制
如前所述，我从事 IT 咨询工作，并经历过各种客户环境。 遇到各种安全策略是很自然的，在大多数环境中，在授权我们的笔记本电脑（我们的移动开发工作站）连接到他们的网络（大多数时候只是开发网络）之前，我们必须先经过安全检查表。
有一位客户不允许外部计算机连接到他们的网络，因此我们的笔记本电脑是......带有移动 GSM 调制解调器的昂贵通信计算机。 我们被迫使用他们的台式电脑进行开发，而这些工作站都是非常旧的型号，内存较低，配备单核奔腾 4 CPU 和不稳定的磁盘。 不用说，开发工作并不是最理想的，尤其是在使用包含 100 - 400 个项目的 Visual Studio 解决方案时。
对于可以隔离的小案例，我们在自己的笔记本电脑上进行开发和测试。 但对于更大的情况，考虑到某些开发服务器（例如 SeeBeyond 和大型机 DB2 数据库）仅位于网络上，并且在计算机之间复制数百个项目的前景非常可怕，这在技术上似乎不是一个合理的想法。
我并不是要求违反客户政策的技巧（例如将笔记本电脑插入伪装台式机MAC地址）。 我只是想知道其他人在这种环境中工作时如何尝试使用自己的硬件来保留一些优势和效率。 只要有可能，我都会尝试在自己的笔记本电脑上使用虚拟服务器复制环境，但仅适用于 Microsoft 专用服务器解决方案。 虚拟化非 Microsoft 服务器和软件是一项挑战。
As described before, I work in IT consultancy and move through various customer environments. It is natural to encounter a variety of security policies, and in most environments we have had to go through a security checklist before authorizating our laptops - our mobile development workstations - for connection into their network (most of the time just development network).
There is this customer who does not allow external computers to connect to their network, so our laptops are.... expensive communication computers with mobile GSM modems. We are forced to use their desktop PCs for development, and those workstations are pretty old models with low RAM and single-core Pentium 4 CPUs and cranky disks. Needless to say, development work is sub-optimal, especially when working with Visual Studio solutions that can range 100 - 400 projects.
For small cases that can be isolated, we develop and test on our own laptops. But for the bigger cases, given that certain development servers like SeeBeyond and mainframe DB2 databases are only on the network, and the prospect of copying hundreds of projects to and fro machines is just ghastly, it does not seem like a technically sound idea.
I am not asking for tricks that violate the customer's policies (e.g. plug laptop in masquerading desktop MAC address). I just like to know what others have tried to retain some of their advantage and efficiency with their own hardware when working in such environments. Whenever I can I try to duplicate the environment with virtual servers on my own laptop, but it only goes so far with Microsoft-only server solutions. Virtualizing non-Microsoft server and software is a challenge.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这很难。 这里的根本原因是管理层不了解他们选择的环境会产生真正的成本影响。
您的问题是，虽然您可能按小时计费，但您可能不会以这种方式获得报酬，因此客户浪费的时间进入了老板的口袋，而不是您的口袋。 很多时候，这会带来轻微的利益冲突。 您的公司加快工作速度的动力几乎为零，而且您的客户也不想进行基础设施投资，因为他们认为这是临时性的投资。
我只能说，你必须与管理层一起将其推上旗杆。 您必须向他们表明，这会占用项目的实时时间，这可能会使您的交付日期面临风险，或更糟糕的是，这些机器的可靠性也会使最终产品的交付面临风险。 你有责任让你的管理层成为信徒。
Crucial 的一块 RAM 售价为 30 美元。 如果没有人愿意为你的机器支付 90 个大内存来购买 3GB RAM，那么你的管理层就会积极地与你作对，或者不尊重你。 如果到了这个地步，你就有了更大的问题，需要寻找下一个雇主。
That's tough. The root cause here is management that doesn't understand that there are real cost implications to their choice of environments.
Your problem is that while you may be billing by the hour, you probably aren't getting paid that way, so your customers' wasted time goes into the pockets of your boss and not to you. A lot of times, this presents a mild conflict of interest. Your company has about zero incentive to speed up your work, and your client doesn't want to make an infrastructure investment in what they see as a temporary engagement.
All I can say is that you have to run this up the flagpole with management. You have to show them that this is taking real time from the projects which could put your deliverable dates at risk, or worse, the reliability of these machines is such that it puts the delivery of the end product at risk as well. The onus is on you to make your management into a believer.
A gig of RAM at Crucial is thirty bucks. If nobody is willing to shell out 90 big ones for 3GB of RAM for your box, you have management that's actively working against you or does not respect you. If it comes to that, you've got bigger problems and need to look for your next employer.
当我升级当前的开发环境时，我做的一件事是找到生产力研究的链接，这些研究显示了开发环境增强时生产力提高了多少。 在我的特定情况下，我的桌面上有 2 到 3 个显示器。 我找到了 3-4 篇文章，描述了通过额外的显示器获得了多少收益。 对我来说，不言而喻的是，您希望为开发人员提供一个更新的、配置良好的系统，特别是因为如今硬件成本相对于人员成本来说是如此之小，但精打细算的人往往有不同的想法。 如果你能结合一些显示生产率提高的行业研究，我认为你很难将你的担忧仅仅视为对环境的抱怨。
FWIW，我很失望必须进行升级研究，其成本低于该部门一个月内在纸上花费的费用，但有时你必须做一些对你来说毫无意义的事情，因为这对其他人来说有意义。
One of the things that I did when I upgrade my current development environment was find links to productivity studies that showed how much productivity increased when the development environment was enhanced. In my particular case it was going from 2 to 3 monitors on my desktop. I was able to find 3-4 articles that described how much was gained by having the extra monitor. It seems self-evident to me that you'd want a newer, well-configured system for developers, especially since the cost of the hardware relative to the cost of the people is so small these days, but the bean counters often think differently. If you can go in armed with some industry studies that show productivity gains, I think it will be harder to dismiss your concerns as just complaints about the environment.
FWIW, I was disappointed to have to do the research for an upgrade that cost less than what the department would spend on paper in a month, but sometimes you have to do things that make no sense to you because it makes sense to someone else.
向你的经理写一份体面的建议，这就是你纠正解决方案所能做的一切。 如果他不愿意或无法解决问题，或者不愿意/无法将提案传递给可以解决的人，那么我会说目前的情况就是他们决定使用的。
在这种情况下，要么接受它，要么不接受它。 继续前行。
该提案应包含：
列出诸如更长的开发时间，或更少的测试，或更少的编写高质量代码的时间之类的事情。 基本上，一个不需要太多成本的小升级就能极大地提高产品的质量。
Write a decent proposal to your manager, that's about all you can do to rectify the solution. If he is unwilling or unable to fix the problem, or unwilling/unable to pass the proposal up to someone who can, then I'd say the current situation is what they've decided to use.
In that case, either live with it, or don't, ie. move on.
The proposal should contain:
List things like longer development time, or less testing, or less time to write quality code. Basically, a minor upgrade that doesn't cost much will improve the quality of the product tremendously.
我刚刚经历过这个并找到了一个很好的解决方案：找一份不同的工作
I just went through this and found a pretty good solution : get a different job
只需增量同步即可。 您没有每秒输入那么多代码，GSM 连接无法跟上它吗？ 确保您的项目设置为尽可能使用模拟/存根。
进行此设置可能超出了客户的系统管理员的能力。
应该减少对大数据库的依赖，因此您只需要运行日常回归测试。
Just synchronize incrementally. You're not typing that much code/second a gsm connection cannot keep up with it? Make sure your projects are setup to use mocks/stubs whereever possible.
Setting this up probably is beyond the capability of the systems administrators of your customer.
The dependency on the big databases should be reduced so you only need to run daily regression tests.