I recently joined the IT department of a big insurance company. Although the department's title is "IT", a lot of code gets written here; Java, JSP, JavaScript, COBOL and even some C++ from what I've heard. All the programs that allow insurers, brokers and the rest of the tie-wearing, white-collar workers to issue new contracts and deal with clients runs on the code produced by this department. I've been told that the department is pretty good by the parent company's standards and that we've even received an internal award or two. We're 17 people in the department, split in smaller groups of 2 or 3. As you might've guessed from the COBOL part further up, the average age is over 40 years (as a point of reference I'm 29 yo).
我最近加入了一家大型保险公司的IT部门。虽然该部门的标题是“IT”,但很多代码都写在这里; Java,JSP,JavaScript,COBOL甚至是我听过的一些C ++。所有允许保险公司,经纪人和其他领带白领工人签发新合同并与客户打交道的计划都依据该部门制作的代码。我被告知,根据母公司的标准,该部门相当不错,我们甚至还获得了一两个内部奖励。我们这个部门有17个人,分成2个或3个小组。正如你可能从COBOL部分进一步猜测的那样,平均年龄超过40岁(作为参考点,我是29岁) 。
Right now, there is no version control system in place (there exists a general backup scheme though). When needed, files are passed around through shared folders. Usually there's one person in every group responsible for copying the "final" version of the files back to the production server. I find this absurd and even a bit dangerous.
目前,还没有版本控制系统(虽然存在一般的备份方案)。需要时,文件将通过共享文件夹传递。通常每个组中都有一个人负责将文件的“最终”版本复制回生产服务器。我觉得这很荒谬甚至有点危险。
How may I try to convince management that we should implement a VCS scheme in our department? I've never deployed a VCS myself but every other place I've worked at had one. I think I'll hit a "we've been OK until now, why bother" wall from the first step, coupled with the age of most of my co-workers that will feel this step is an unnecessary hurdle.
我怎样才能说服管理层我们应该在我们的部门实施VCS计划?我自己从未部署过VCS,但我工作的其他地方都有一个。我想我会打到“我们一直都很好,直到现在,为什么要打扰”第一步的墙,加上我的大多数同事的年龄,会觉得这一步是不必要的障碍。
I know the basic advantages of VCS (traceability, granular backups, accountability etc). I'm looking to back my case with realistic cases and examples of real added value over the implementation costs, not just a "but-but-but, we must have a VCS you fools!" :-)
我知道VCS的基本优势(可追溯性,粒度备份,问责制等)。我希望用实际案例和实际成本实际附加值的例子来支持我的案例,不仅仅是“但是 - 但是,我们必须有一个你傻瓜的VCS!” :-)
12 个解决方案
#1
You don't necessarily need their permission.
您不一定需要他们的许可。
Install svn on your machine, start using it, and then start convincing your fellow team members to use it too.
在您的机器上安装svn,开始使用它,然后开始说服您的团队成员也使用它。
Then watch and see what happens.
然后观察并看看会发生什么。
Edits
- The basic idea of this is that it's easier to show than to tell.
- It's a great idea to support your ideas with a working implementation/solution.
- Of course, if you succeed, and they want the system used department/company wide, you must be prepared to support the transition, know how the software is to be installed and used.
- Going ahead and using something accepted in the industry is faster than having discussions on what system should be used.
- There is a good change that this will get you noticed. You may also get your peers respect and support.
这个的基本思想是它更容易展示而不是告诉。
通过可行的实施/解决方案来支持您的想法是个好主意。
当然,如果您成功,并且他们希望系统使用部门/公司范围,您必须准备好支持转换,知道软件的安装和使用方式。
继续使用行业中接受的东西比讨论应该使用什么系统更快。
这会让你注意到一个很好的变化。您也可以得到同行的尊重和支持。
As suggested, the same approach can be made on other areas:
如建议的那样,可以在其他方面采用相同的方法:
- issue/bug tracking systems
- quality tools
- time tracking
- continuous integration
- a wiki for knowledge base, HOWTO's, guidelines, tutorials, presentations, screencasts
- different IDEs and tools
- build tools
- automated deployment
- various scripts that would save your team time
问题/错误跟踪系统
知识库,HOWTO,指南,教程,演示文稿,截屏视频的维基
不同的IDE和工具
各种脚本可以节省您的团队时间
.. any item that will visibly add quality to your work, but doesn't (yet) disrupt existing methodologies and practices.
..任何能够明显增加工作质量的项目,但不会(现在)破坏现有的方法和实践。
#2
Joel Spolsky has an excellent article: Getting Things Done When You're Only a Grunt
乔尔·斯波尔斯基(Joel Spolsky)有一篇很棒的文章:当你只是咕噜咕噜的时候做完事情
Quote
Nobody on your team wants to use source control? Create your own CVS repository, on your own hard drive if necessary. Even without cooperation, you can check your code in independently from everybody else's. Then when they have problems that source control can solve (someone accidentally types rm * ~ instead of rm *~), they'll come to you for help. Eventually, people will realize that they can have their own checkouts, too.
您团队中没有人想要使用源代码管理?如有必要,在您自己的硬盘上创建自己的CVS存储库。即使没有合作,您也可以独立于其他人检查您的代码。然后,当他们遇到源控制可以解决的问题时(有人不小心输入rm *〜而不是rm *〜),他们会来找你帮忙。最终,人们会意识到他们也可以拥有自己的结账。
#3
Management? I will put bold the expressions and words you should use:
管理?我会大胆地使用你应该使用的表达和单词:
Your should display some examples how a VCS will prevent losing money to the company if some error/bugs or disaster happens. It will be faster to solve all problems, so maintaning the systens won't be so lazy and people become more productive.
您应该显示一些示例,如果出现一些错误/错误或灾难,VCS将如何防止向公司赔钱。解决所有问题会更快,因此保持系统不会太懒,人们会变得更有效率。
You should also mention that implementing a VCS has no costs.
您还应该提到实施VCS没有任何成本。
VCS will also give advantages for backup all the existing code. So, all the code will be safe.
VCS还将为备份所有现有代码提供优势。所以,所有代码都是安全的。
#4
My opinion on how to go about doing this, is that you should try to convince your fellow developers first. The way I see it, there are two ways this might go about:
我对如何做到这一点的看法是,你应该先尝试说服你的同事。我看待它的方式,有两种方式:
-
You give the right arguments to the other developers (possibly only the head developers will suffice), they like the idea, and the suggest it to management. Management is easy to convince at that point, so everyone is happy.
你给其他开发人员提供了正确的论据(可能只有主管开发人员就足够了),他们喜欢这个想法,并建议管理层。管理很容易说服,所以每个人都很高兴。
-
You give the right arguments to management, who get all excited (great!) and mandate that version control has to be installed and used by everyone. Here's the thing: If at this point the other developers are not sold to the idea already, then (a) they might be hostile to an idea that management is forcing upon them, and (b) they might not like you for being the cause of it all.
你给管理层提供了正确的论据,他们都很兴奋(太棒了!)并且要求每个人都必须安装和使用版本控制。事情就是这样:如果此时其他开发人员已经没有出售这个想法,那么(a)他们可能对管理层强迫他们的想法持怀疑态度,并且(b)他们可能不喜欢你因为这个原因这一切。
So what are good arguments to convince fellow developers? As someone who uses subversion (which is the one I recommend in this case, by the way) even for his solo projects, here's a few advantages I can think of:
那么说服其他开发者的好理由是什么?作为一个使用颠覆的人(顺便说一句,这是我在这种情况下推荐的那个)甚至是他的个人项目,这里有一些我能想到的优点:
-
Using version control forces people to think of code modification in terms of a series of small, self-contained changes. This is an extremely beneficial way of working: where otherwise people would be inclined to make lots of changes all over the place, leaving the code in a mess, version control kinda forces them to change the code in bite-size, easy-to-swallow bits, keeping the code compiling at all times, easing the cost of integration with other modules, etc.
使用版本控制迫使人们根据一系列小的,自包含的更改来考虑代码修改。这是一种非常有益的工作方式:否则人们会倾向于在整个地方进行大量更改,使代码陷入混乱,版本控制有点迫使他们以一口大小改变代码,易于使用吞下位,始终保持代码编译,降低与其他模块集成的成本等。
-
Version control makes it very easy to see what has changed in the code each time. This might sound trivial, but when you start modifying code it's easy to lose track after a while. But with VC it's all an "svn diff" (or equivalent) away, always.
通过版本控制,可以非常轻松地查看代码中每次更改的内容。这可能听起来微不足道,但是当你开始修改代码时,很快就会失去跟踪。但是对于VC来说,它始终是一个“svn diff”(或等价物)。
-
Version control makes it very easy to see who has changed the code each time. So that, for example, when something breaks, you know who to blame. (It's not an accident that the subversion command which shows who last changed each line is called "svn blame".)
通过版本控制,可以非常轻松地查看每次更改代码的人员。因此,例如,当某些事情发生时,你就会知道应该责怪谁。 (显示谁最后改变每一行的subversion命令被称为“svn blame”并不是偶然的。)
-
Version control makes it very easy to see why a piece of code was changed. Commit messages, if used properly, essentially provide continual documentation of the ongoing development process. Documentation that otherwise wouldn't be written.
版本控制使得很容易理解为什么一段代码被更改。如果使用得当,提交消息基本上可以持续记录正在进行的开发过程。否则不会被写入的文档。
-
Version control makes it very easy to track down regressions and see where they appeared. In the easy case, you just track down commit messages and spot the culprit. In the average case, you have to consult the diffs too. In the hard case, you have to do regression testing of previous versions using what amounts to binary search, which is still better than the no-VC case, where you simply have no clue.
通过版本控制,可以非常轻松地跟踪回归并查看它们的出现位置。在简单的情况下,您只需跟踪提交消息并发现罪魁祸首。在一般情况下,你也必须参考差异。在困难的情况下,您必须使用相当于二进制搜索的内容对先前版本进行回归测试,这仍然比没有VC的情况更好,在那里您根本没有线索。
This list is not exhaustive, of course, but these are the main benefits that come to mind right now. Obviously, as others have already mentioned, it's easier to show all this to your colleagues than to describe it to them, and setting it up for yourself first (but importing everyone's code, mind) sounds like a great idea.
当然,这份清单并非详尽无遗,但这些是我们现在想到的主要好处。显然,正如其他人已经提到的那样,向同事展示这一切比向他们描述它更容易,并且首先为自己设置(但是导入每个人的代码,思想)听起来是个好主意。
#5
As Joel points out on one of his articles, start using your own one man version control system and market its benefit on every opportunity you get. Show them the benefits of traceability, granular backups etc from your single instance. People will start realizing its benefits irrespective of their age.
正如Joel在他的一篇文章中所指出的那样,开始使用你自己的单人版本控制系统,并在你获得的每一个机会上推广它的好处。向您展示单个实例的可追溯性,粒度备份等的好处。无论年龄大小,人们都会开始意识到它的好处。
#6
I agree with the answer that are referring to the Joel Guerrilla article.
我同意那些指Joel Guerrilla文章的答案。
- Install/Use some thing with a low overhead. Hg (Mercurial) is easy in a mixed eniroment and is good because you can bail out and use something else in an easy way.
- You must share your things without making a fuzz about it. When someone needs your code, export it and use the "standard" corporate method (shared folder or whatever)
- When you get code, always import it into a repos, if you think it is a new commit of a repos you already have, try to get it into that one.
- Sooner or later you will have a code for several project and hopefully some commits on some repos. Then you can expose those with the mercurials webserver interface (hg serve -p XXXX).
- When the times comes when someone don't know why something suddenly don't works as it should be and is trying to figure out why becase it was working last monday ... and you know that you have that code in a repos step up and ask if you can be of any assistance. Get the falty code, commit it into your repos and expose with hg serve. Look at it in the browser.
以低开销安装/使用某些东西。 Hg(Mercurial)在混合环境中很容易,并且很好,因为你可以轻松地拯救并使用其他东西。
你必须分享你的东西,而不是模糊它。当有人需要您的代码时,导出它并使用“标准”公司方法(共享文件夹或其他)
当你获得代码时,总是把它导入到一个repos中,如果你认为它是你已经拥有的repos的新提交,试着把它放到那个。
迟早你会有几个项目的代码,并希望有些回购。然后你可以使用mercurials webserver接口公开它们(hg serve -p XXXX)。
当时代到来的时候,有人不知道为什么突然之间的东西不能正常工作,并试图弄清楚为什么它在星期一的星期一工作...而且你知道你有一个回购步骤中的代码并询问您是否可以提供任何帮助。获取falty代码,将其提交到您的repos并使用hg serve进行公开。在浏览器中查看它。
My point is that you must prove with real cases to your colleges that this stuff has a value. If the haven't figured it out by themselves after some many years you have a mountain to climb but it can be done. You must be patience though. It could very well take a year to convert one man (old dog). If you have any younger coworkers try to do this together, the more code you can get hold on the better.
我的观点是,你必须向你的大学证明这些东西有价值。如果多年后你没有自己想出来的话,你可以爬山但是可以做到。你必须耐心等待。转换一个人(老狗)可能需要一年的时间。如果你有任何年轻的同事尝试一起做这个,你可以获得的代码越多越好。
#7
I would point out the hazards of not having one - lost code, developers over writing each other changes, ability to rollback problems, etc.
我会指出没有丢失代码的危险,开发人员互相编写更改,回滚问题的能力等等。
Also since Subversion and some others are free, point out there is no real cost to purchase, jsut the time to implement.
此外,由于Subversion和其他一些产品都是免费的,因此指出购买没有实际成本,而且需要时间来实施。
The biggest issue you will have as the new guy is that you will be seen as rockign the boat, if they had no issues to date they will be hard to convince. Perhaps start using it locally jsut for yourself and maybe they will like what they see and start to adopt it.
作为新人,你将面临的最大问题是你将被视为摇摇欲坠的船,如果他们迄今没有任何问题他们将难以说服。也许开始在本地jsut使用它,也许他们会喜欢他们看到的并开始采用它。
I would try small steps, maybe ask the others if they ever used one, point out the benefits, when an issue arises that a system would have prevented or aided in point it out delicately.
我会尝试一些小步骤,也许会问其他人是否曾经使用过一个,指出好处,当出现一个系统会阻止或帮助指出它的问题时。
#8
From a purely business perspective, and depending on the size and nature of your parent company an IT auditor may consider your lack of a VCS a finding (i.e. something that needs fixing). I believe you could improve your pitch to management by telling them that any CVS is a great way of showing that your department respects its resources and works in a structured way and efficient way, something auditors always like to see.
从纯粹的业务角度来看,根据您母公司的规模和性质,IT审计师可能会认为您缺乏VCS(即需要修复的东西)。我相信你可以通过告诉他们任何CVS是一种很好的方式来表明你的部门尊重其资源并以结构化的方式和有效的方式工作,这是审计师总是喜欢看的东西。
I don't know how your corporate culture works but I'd be careful about rolling out your own CVS since if it does see use it suddenly becomes your responsibility when things go wrong, even if you were not at fault. To cover your ass (and keep the aforementioned auditors even happier) I'd roll the system out with a full set of written procedures for its use and maintenance.
我不知道你的企业文化是如何运作的,但我会小心推出你自己的CVS,因为如果它确实看到了使用它突然成为你的责任,当出现问题时,即使你没有错。为了掩盖你的屁股(并让上述审计员更加满意),我将推出一套完整的书面程序供其使用和维护。
Finally while I myself am a big fan of initiative at any level of the enterprise don't expect people to remember to say thanks when they figure out how great it is. Some might, but for the most part you're doing this to make your own life easier and for your own karma.
最后,虽然我自己是企业任何级别的主动粉丝,但是当他们弄清楚它有多棒时,不要指望人们记得说声谢谢。有些可能,但在大多数情况下,你这样做是为了让自己的生活更轻松,也为了自己的业力。
#9
Remember, there are plenty of version control systems that are absolutely free. And the amount of time spent installing and maintaining a version control system should be somewhere near 0 (they shouldn't require any maintenance). There isn't even a space penalty for most systems, as they can compress things internally.
请记住,有很多版本控制系统是完全免费的。安装和维护版本控制系统所花费的时间应该接近0(它们不需要任何维护)。对于大多数系统来说,甚至没有空间损失,因为它们可以在内部压缩内容。
You have listed some advantages, and there are others. But more importantly, I can't think of a single disadvantage.
您列出了一些优点,还有其他优点。但更重要的是,我无法想到一个单一的劣势。
#10
I would also recommend starting with implementing VCS (Version Control System) for yourself first. I'd recommend using one of distributed VCS (Git, Mercurial, Bazaar) rather than centralized Subversion, because it would be easier to create central repository (or repositories) by cloning than moving your Subversion repository to central place. Distributed SCM can be also used in a smaller group to exchange ideas.
我还建议首先为自己实施VCS(版本控制系统)。我建议使用分布式VCS(Git,Mercurial,Bazaar)而不是集中式Subversion,因为通过克隆创建*存储库(或存储库)比将Subversion存储库移动到中心位置更容易。分布式SCM也可以在较小的组中用于交换想法。
A few advantages of (modern) version control systems:
(现代)版本控制系统的一些优点:
-
You can always revert (go back) to last working version of your code (provided that you follow some sane version control conventions, like at least tagging only tested code). With code shared via folders it might turn out that no one version works, backup copies were deleted to save space, and recovering code from backup is tedious / was never tested.
您可以随时恢复(返回)您的代码的最后一个工作版本(前提是您遵循一些理智的版本控制约定,例如至少标记仅测试的代码)。通过文件夹共享代码,可能会发现没有一个版本可以工作,删除备份副本以节省空间,从备份中恢复代码很繁琐/从未测试过。
-
You can switch between working on some new feature (some experimental work), and working on urgent fix in currently deployed version (maintenace work) thanks to branches (and stash / shelve for uncommitted work).
您可以在处理一些新功能(一些实验性工作)之间切换,并在当前部署的版本(维护工作)中进行紧急修复,这要归功于分支(以及未提交工作的存储/搁置)。
-
If you follow good practices for version control (small and often commits, changes being about one single thing, writing good commit message describing change and whys of change) you would have much, much easier finding bugs, be it by bisecting history to find which change introduced bug, or by using version control system to look up who was responsible for given area of code (annotate / blame).
如果您遵循版本控制的良好实践(小而且经常提交,更改只涉及一件事,编写描述更改的好提交消息以及更改的原因),您将有更多,更容易找到错误,无论是通过将历史记录分开来找到哪个改变引入的bug,或者使用版本控制系统来查找谁负责给定的代码区域(注释/责备)。
#11
Start talking to the other developers about problems thay have had in the past as a way to get to know the system and how it evolved (sneaky, sneaky, sneaky, but hey this information will probably come in handy at some poitn even aside from the version control issue). You are bound to sooner or later find some wonderful examples of things that have already happened which would have been far less painful if you had version control. Use these examples when you present the idea to management.
开始与其他开发人员讨论过去遇到的问题,以此来了解系统及其演变方式(偷偷摸摸,鬼鬼祟祟,偷偷摸摸,但嘿,这些信息可能会在某些问题上派上用场,甚至除了版本控制问题)。你迟早会发现一些已经发生过的事情的精彩例子,如果你有版本控制,那就不那么痛苦了。当您将想法提交给管理层时,请使用这些示例。
I agree with the idea that you can probably start using your own version control and eventually will be able to help thm out of a fix, but I'd bet money they have been in some of those fixes already and if they already remember how painful the problme was before, it will help sell the new idea.
我同意你可以开始使用你自己的版本控制并且最终能够帮助你解决问题的想法,但是我敢打赌他们已经在这些修复程序中已经有了钱,如果他们已经记得有多痛苦了问题出现之前,它将有助于推销新想法。
#12
Look for another job.
寻找另一份工作。
Seriously.
There are way better jobs out there that don't require you to teach the existing staff.
Ones where you could go into work and just, y'know, work.
有更好的工作,不需要你教现有的工作人员。在那里你可以去上班,只是,你知道,工作。
Also, keep in mind that 30 isn't far off. That's the age at which most people
stop suffering fools gladly.
另外,请记住30不远。这是大多数人高兴地停止傻瓜的年龄。
Just a heads up.
只是一个抬头。
EDIT
It's been suggested that quitting a bad job is for quitters.
有人建议退出一个糟糕的工作是戒烟者。
Maybe so, and down-vote if you like, but keep in mind that you're supposed to
put your employer to the Joel test before you accept the job, not after.
也许是这样,如果你愿意,可以投票,但请记住,在你接受工作之前,你应该让你的雇主参加乔尔测试,而不是之后。
#1
You don't necessarily need their permission.
您不一定需要他们的许可。
Install svn on your machine, start using it, and then start convincing your fellow team members to use it too.
在您的机器上安装svn,开始使用它,然后开始说服您的团队成员也使用它。
Then watch and see what happens.
然后观察并看看会发生什么。
Edits
- The basic idea of this is that it's easier to show than to tell.
- It's a great idea to support your ideas with a working implementation/solution.
- Of course, if you succeed, and they want the system used department/company wide, you must be prepared to support the transition, know how the software is to be installed and used.
- Going ahead and using something accepted in the industry is faster than having discussions on what system should be used.
- There is a good change that this will get you noticed. You may also get your peers respect and support.
这个的基本思想是它更容易展示而不是告诉。
通过可行的实施/解决方案来支持您的想法是个好主意。
当然,如果您成功,并且他们希望系统使用部门/公司范围,您必须准备好支持转换,知道软件的安装和使用方式。
继续使用行业中接受的东西比讨论应该使用什么系统更快。
这会让你注意到一个很好的变化。您也可以得到同行的尊重和支持。
As suggested, the same approach can be made on other areas:
如建议的那样,可以在其他方面采用相同的方法:
- issue/bug tracking systems
- quality tools
- time tracking
- continuous integration
- a wiki for knowledge base, HOWTO's, guidelines, tutorials, presentations, screencasts
- different IDEs and tools
- build tools
- automated deployment
- various scripts that would save your team time
问题/错误跟踪系统
知识库,HOWTO,指南,教程,演示文稿,截屏视频的维基
不同的IDE和工具
各种脚本可以节省您的团队时间
.. any item that will visibly add quality to your work, but doesn't (yet) disrupt existing methodologies and practices.
..任何能够明显增加工作质量的项目,但不会(现在)破坏现有的方法和实践。
#2
Joel Spolsky has an excellent article: Getting Things Done When You're Only a Grunt
乔尔·斯波尔斯基(Joel Spolsky)有一篇很棒的文章:当你只是咕噜咕噜的时候做完事情
Quote
Nobody on your team wants to use source control? Create your own CVS repository, on your own hard drive if necessary. Even without cooperation, you can check your code in independently from everybody else's. Then when they have problems that source control can solve (someone accidentally types rm * ~ instead of rm *~), they'll come to you for help. Eventually, people will realize that they can have their own checkouts, too.
您团队中没有人想要使用源代码管理?如有必要,在您自己的硬盘上创建自己的CVS存储库。即使没有合作,您也可以独立于其他人检查您的代码。然后,当他们遇到源控制可以解决的问题时(有人不小心输入rm *〜而不是rm *〜),他们会来找你帮忙。最终,人们会意识到他们也可以拥有自己的结账。
#3
Management? I will put bold the expressions and words you should use:
管理?我会大胆地使用你应该使用的表达和单词:
Your should display some examples how a VCS will prevent losing money to the company if some error/bugs or disaster happens. It will be faster to solve all problems, so maintaning the systens won't be so lazy and people become more productive.
您应该显示一些示例,如果出现一些错误/错误或灾难,VCS将如何防止向公司赔钱。解决所有问题会更快,因此保持系统不会太懒,人们会变得更有效率。
You should also mention that implementing a VCS has no costs.
您还应该提到实施VCS没有任何成本。
VCS will also give advantages for backup all the existing code. So, all the code will be safe.
VCS还将为备份所有现有代码提供优势。所以,所有代码都是安全的。
#4
My opinion on how to go about doing this, is that you should try to convince your fellow developers first. The way I see it, there are two ways this might go about:
我对如何做到这一点的看法是,你应该先尝试说服你的同事。我看待它的方式,有两种方式:
-
You give the right arguments to the other developers (possibly only the head developers will suffice), they like the idea, and the suggest it to management. Management is easy to convince at that point, so everyone is happy.
你给其他开发人员提供了正确的论据(可能只有主管开发人员就足够了),他们喜欢这个想法,并建议管理层。管理很容易说服,所以每个人都很高兴。
-
You give the right arguments to management, who get all excited (great!) and mandate that version control has to be installed and used by everyone. Here's the thing: If at this point the other developers are not sold to the idea already, then (a) they might be hostile to an idea that management is forcing upon them, and (b) they might not like you for being the cause of it all.
你给管理层提供了正确的论据,他们都很兴奋(太棒了!)并且要求每个人都必须安装和使用版本控制。事情就是这样:如果此时其他开发人员已经没有出售这个想法,那么(a)他们可能对管理层强迫他们的想法持怀疑态度,并且(b)他们可能不喜欢你因为这个原因这一切。
So what are good arguments to convince fellow developers? As someone who uses subversion (which is the one I recommend in this case, by the way) even for his solo projects, here's a few advantages I can think of:
那么说服其他开发者的好理由是什么?作为一个使用颠覆的人(顺便说一句,这是我在这种情况下推荐的那个)甚至是他的个人项目,这里有一些我能想到的优点:
-
Using version control forces people to think of code modification in terms of a series of small, self-contained changes. This is an extremely beneficial way of working: where otherwise people would be inclined to make lots of changes all over the place, leaving the code in a mess, version control kinda forces them to change the code in bite-size, easy-to-swallow bits, keeping the code compiling at all times, easing the cost of integration with other modules, etc.
使用版本控制迫使人们根据一系列小的,自包含的更改来考虑代码修改。这是一种非常有益的工作方式:否则人们会倾向于在整个地方进行大量更改,使代码陷入混乱,版本控制有点迫使他们以一口大小改变代码,易于使用吞下位,始终保持代码编译,降低与其他模块集成的成本等。
-
Version control makes it very easy to see what has changed in the code each time. This might sound trivial, but when you start modifying code it's easy to lose track after a while. But with VC it's all an "svn diff" (or equivalent) away, always.
通过版本控制,可以非常轻松地查看代码中每次更改的内容。这可能听起来微不足道,但是当你开始修改代码时,很快就会失去跟踪。但是对于VC来说,它始终是一个“svn diff”(或等价物)。
-
Version control makes it very easy to see who has changed the code each time. So that, for example, when something breaks, you know who to blame. (It's not an accident that the subversion command which shows who last changed each line is called "svn blame".)
通过版本控制,可以非常轻松地查看每次更改代码的人员。因此,例如,当某些事情发生时,你就会知道应该责怪谁。 (显示谁最后改变每一行的subversion命令被称为“svn blame”并不是偶然的。)
-
Version control makes it very easy to see why a piece of code was changed. Commit messages, if used properly, essentially provide continual documentation of the ongoing development process. Documentation that otherwise wouldn't be written.
版本控制使得很容易理解为什么一段代码被更改。如果使用得当,提交消息基本上可以持续记录正在进行的开发过程。否则不会被写入的文档。
-
Version control makes it very easy to track down regressions and see where they appeared. In the easy case, you just track down commit messages and spot the culprit. In the average case, you have to consult the diffs too. In the hard case, you have to do regression testing of previous versions using what amounts to binary search, which is still better than the no-VC case, where you simply have no clue.
通过版本控制,可以非常轻松地跟踪回归并查看它们的出现位置。在简单的情况下,您只需跟踪提交消息并发现罪魁祸首。在一般情况下,你也必须参考差异。在困难的情况下,您必须使用相当于二进制搜索的内容对先前版本进行回归测试,这仍然比没有VC的情况更好,在那里您根本没有线索。
This list is not exhaustive, of course, but these are the main benefits that come to mind right now. Obviously, as others have already mentioned, it's easier to show all this to your colleagues than to describe it to them, and setting it up for yourself first (but importing everyone's code, mind) sounds like a great idea.
当然,这份清单并非详尽无遗,但这些是我们现在想到的主要好处。显然,正如其他人已经提到的那样,向同事展示这一切比向他们描述它更容易,并且首先为自己设置(但是导入每个人的代码,思想)听起来是个好主意。
#5
As Joel points out on one of his articles, start using your own one man version control system and market its benefit on every opportunity you get. Show them the benefits of traceability, granular backups etc from your single instance. People will start realizing its benefits irrespective of their age.
正如Joel在他的一篇文章中所指出的那样,开始使用你自己的单人版本控制系统,并在你获得的每一个机会上推广它的好处。向您展示单个实例的可追溯性,粒度备份等的好处。无论年龄大小,人们都会开始意识到它的好处。
#6
I agree with the answer that are referring to the Joel Guerrilla article.
我同意那些指Joel Guerrilla文章的答案。
- Install/Use some thing with a low overhead. Hg (Mercurial) is easy in a mixed eniroment and is good because you can bail out and use something else in an easy way.
- You must share your things without making a fuzz about it. When someone needs your code, export it and use the "standard" corporate method (shared folder or whatever)
- When you get code, always import it into a repos, if you think it is a new commit of a repos you already have, try to get it into that one.
- Sooner or later you will have a code for several project and hopefully some commits on some repos. Then you can expose those with the mercurials webserver interface (hg serve -p XXXX).
- When the times comes when someone don't know why something suddenly don't works as it should be and is trying to figure out why becase it was working last monday ... and you know that you have that code in a repos step up and ask if you can be of any assistance. Get the falty code, commit it into your repos and expose with hg serve. Look at it in the browser.
以低开销安装/使用某些东西。 Hg(Mercurial)在混合环境中很容易,并且很好,因为你可以轻松地拯救并使用其他东西。
你必须分享你的东西,而不是模糊它。当有人需要您的代码时,导出它并使用“标准”公司方法(共享文件夹或其他)
当你获得代码时,总是把它导入到一个repos中,如果你认为它是你已经拥有的repos的新提交,试着把它放到那个。
迟早你会有几个项目的代码,并希望有些回购。然后你可以使用mercurials webserver接口公开它们(hg serve -p XXXX)。
当时代到来的时候,有人不知道为什么突然之间的东西不能正常工作,并试图弄清楚为什么它在星期一的星期一工作...而且你知道你有一个回购步骤中的代码并询问您是否可以提供任何帮助。获取falty代码,将其提交到您的repos并使用hg serve进行公开。在浏览器中查看它。
My point is that you must prove with real cases to your colleges that this stuff has a value. If the haven't figured it out by themselves after some many years you have a mountain to climb but it can be done. You must be patience though. It could very well take a year to convert one man (old dog). If you have any younger coworkers try to do this together, the more code you can get hold on the better.
我的观点是,你必须向你的大学证明这些东西有价值。如果多年后你没有自己想出来的话,你可以爬山但是可以做到。你必须耐心等待。转换一个人(老狗)可能需要一年的时间。如果你有任何年轻的同事尝试一起做这个,你可以获得的代码越多越好。
#7
I would point out the hazards of not having one - lost code, developers over writing each other changes, ability to rollback problems, etc.
我会指出没有丢失代码的危险,开发人员互相编写更改,回滚问题的能力等等。
Also since Subversion and some others are free, point out there is no real cost to purchase, jsut the time to implement.
此外,由于Subversion和其他一些产品都是免费的,因此指出购买没有实际成本,而且需要时间来实施。
The biggest issue you will have as the new guy is that you will be seen as rockign the boat, if they had no issues to date they will be hard to convince. Perhaps start using it locally jsut for yourself and maybe they will like what they see and start to adopt it.
作为新人,你将面临的最大问题是你将被视为摇摇欲坠的船,如果他们迄今没有任何问题他们将难以说服。也许开始在本地jsut使用它,也许他们会喜欢他们看到的并开始采用它。
I would try small steps, maybe ask the others if they ever used one, point out the benefits, when an issue arises that a system would have prevented or aided in point it out delicately.
我会尝试一些小步骤,也许会问其他人是否曾经使用过一个,指出好处,当出现一个系统会阻止或帮助指出它的问题时。
#8
From a purely business perspective, and depending on the size and nature of your parent company an IT auditor may consider your lack of a VCS a finding (i.e. something that needs fixing). I believe you could improve your pitch to management by telling them that any CVS is a great way of showing that your department respects its resources and works in a structured way and efficient way, something auditors always like to see.
从纯粹的业务角度来看,根据您母公司的规模和性质,IT审计师可能会认为您缺乏VCS(即需要修复的东西)。我相信你可以通过告诉他们任何CVS是一种很好的方式来表明你的部门尊重其资源并以结构化的方式和有效的方式工作,这是审计师总是喜欢看的东西。
I don't know how your corporate culture works but I'd be careful about rolling out your own CVS since if it does see use it suddenly becomes your responsibility when things go wrong, even if you were not at fault. To cover your ass (and keep the aforementioned auditors even happier) I'd roll the system out with a full set of written procedures for its use and maintenance.
我不知道你的企业文化是如何运作的,但我会小心推出你自己的CVS,因为如果它确实看到了使用它突然成为你的责任,当出现问题时,即使你没有错。为了掩盖你的屁股(并让上述审计员更加满意),我将推出一套完整的书面程序供其使用和维护。
Finally while I myself am a big fan of initiative at any level of the enterprise don't expect people to remember to say thanks when they figure out how great it is. Some might, but for the most part you're doing this to make your own life easier and for your own karma.
最后,虽然我自己是企业任何级别的主动粉丝,但是当他们弄清楚它有多棒时,不要指望人们记得说声谢谢。有些可能,但在大多数情况下,你这样做是为了让自己的生活更轻松,也为了自己的业力。
#9
Remember, there are plenty of version control systems that are absolutely free. And the amount of time spent installing and maintaining a version control system should be somewhere near 0 (they shouldn't require any maintenance). There isn't even a space penalty for most systems, as they can compress things internally.
请记住,有很多版本控制系统是完全免费的。安装和维护版本控制系统所花费的时间应该接近0(它们不需要任何维护)。对于大多数系统来说,甚至没有空间损失,因为它们可以在内部压缩内容。
You have listed some advantages, and there are others. But more importantly, I can't think of a single disadvantage.
您列出了一些优点,还有其他优点。但更重要的是,我无法想到一个单一的劣势。
#10
I would also recommend starting with implementing VCS (Version Control System) for yourself first. I'd recommend using one of distributed VCS (Git, Mercurial, Bazaar) rather than centralized Subversion, because it would be easier to create central repository (or repositories) by cloning than moving your Subversion repository to central place. Distributed SCM can be also used in a smaller group to exchange ideas.
我还建议首先为自己实施VCS(版本控制系统)。我建议使用分布式VCS(Git,Mercurial,Bazaar)而不是集中式Subversion,因为通过克隆创建*存储库(或存储库)比将Subversion存储库移动到中心位置更容易。分布式SCM也可以在较小的组中用于交换想法。
A few advantages of (modern) version control systems:
(现代)版本控制系统的一些优点:
-
You can always revert (go back) to last working version of your code (provided that you follow some sane version control conventions, like at least tagging only tested code). With code shared via folders it might turn out that no one version works, backup copies were deleted to save space, and recovering code from backup is tedious / was never tested.
您可以随时恢复(返回)您的代码的最后一个工作版本(前提是您遵循一些理智的版本控制约定,例如至少标记仅测试的代码)。通过文件夹共享代码,可能会发现没有一个版本可以工作,删除备份副本以节省空间,从备份中恢复代码很繁琐/从未测试过。
-
You can switch between working on some new feature (some experimental work), and working on urgent fix in currently deployed version (maintenace work) thanks to branches (and stash / shelve for uncommitted work).
您可以在处理一些新功能(一些实验性工作)之间切换,并在当前部署的版本(维护工作)中进行紧急修复,这要归功于分支(以及未提交工作的存储/搁置)。
-
If you follow good practices for version control (small and often commits, changes being about one single thing, writing good commit message describing change and whys of change) you would have much, much easier finding bugs, be it by bisecting history to find which change introduced bug, or by using version control system to look up who was responsible for given area of code (annotate / blame).
如果您遵循版本控制的良好实践(小而且经常提交,更改只涉及一件事,编写描述更改的好提交消息以及更改的原因),您将有更多,更容易找到错误,无论是通过将历史记录分开来找到哪个改变引入的bug,或者使用版本控制系统来查找谁负责给定的代码区域(注释/责备)。
#11
Start talking to the other developers about problems thay have had in the past as a way to get to know the system and how it evolved (sneaky, sneaky, sneaky, but hey this information will probably come in handy at some poitn even aside from the version control issue). You are bound to sooner or later find some wonderful examples of things that have already happened which would have been far less painful if you had version control. Use these examples when you present the idea to management.
开始与其他开发人员讨论过去遇到的问题,以此来了解系统及其演变方式(偷偷摸摸,鬼鬼祟祟,偷偷摸摸,但嘿,这些信息可能会在某些问题上派上用场,甚至除了版本控制问题)。你迟早会发现一些已经发生过的事情的精彩例子,如果你有版本控制,那就不那么痛苦了。当您将想法提交给管理层时,请使用这些示例。
I agree with the idea that you can probably start using your own version control and eventually will be able to help thm out of a fix, but I'd bet money they have been in some of those fixes already and if they already remember how painful the problme was before, it will help sell the new idea.
我同意你可以开始使用你自己的版本控制并且最终能够帮助你解决问题的想法,但是我敢打赌他们已经在这些修复程序中已经有了钱,如果他们已经记得有多痛苦了问题出现之前,它将有助于推销新想法。
#12
Look for another job.
寻找另一份工作。
Seriously.
There are way better jobs out there that don't require you to teach the existing staff.
Ones where you could go into work and just, y'know, work.
有更好的工作,不需要你教现有的工作人员。在那里你可以去上班,只是,你知道,工作。
Also, keep in mind that 30 isn't far off. That's the age at which most people
stop suffering fools gladly.
另外,请记住30不远。这是大多数人高兴地停止傻瓜的年龄。
Just a heads up.
只是一个抬头。
EDIT
It's been suggested that quitting a bad job is for quitters.
有人建议退出一个糟糕的工作是戒烟者。
Maybe so, and down-vote if you like, but keep in mind that you're supposed to
put your employer to the Joel test before you accept the job, not after.
也许是这样,如果你愿意,可以投票,但请记住,在你接受工作之前,你应该让你的雇主参加乔尔测试,而不是之后。