……我第一份真正的工作是在一家公司，这家公司维护一个大型遗留产品，该产品使用COBOL和Java的组合进行编程。为了在产品的Java部分进行开发，你需要从源代码控制系统中检出单个文件进行工作，这会‘锁定’文件，防止其他开发人员检出相同的文件。这个功能并不是我们实际的源代码控制系统的一部分，而是通过一系列你可以运行的csh shell脚本来实现的，这些脚本是在SSH登录到我们的开发服务器后运行的。我们每个客户都有一个‘主’jar文件，该文件代表实际的最终编译产品（jar文件实际上是一个zip文件存档，它将最终的编译后的Java类文件打包在一起）。一旦你完成了代码更改，你运行另一组脚本，这些脚本会找到每个客户的主jar文件，解压它，将你本地机器上的编译文件复制进去，然后重新压缩它。最后释放源代码控制的锁定。……
源讨论“我们列不够用了”原帖 571 条评论 · 导入时统计把你的经验，加入这段讨论。
这听起来和处理MS Access数据库非常相似... 不幸的是，我目前的工作职责之一就是管理几个Access应用程序... 它们非常古老，我指的是2000年代初的。它们是我曾经处理过的最难以控制的东西，我就不详细说了，但你的故事让我想起了不得不处理这些应用程序的经历...
完整原文我记得在第一份工作中有过类似的情况，只不过共享文件锁定是Macromedia Dreamweaver的一个完整功能。 CSS刚开始被采用，我们每个项目都只有一个“global.css”文件。当别人锁定了global.css，你需要提前声明你接下来需要使用它。不可避免地，每天都会有人离开办公室却忘记解锁global.css，导致其他人无法进行任何工作。
完整原文他们遇到了一个问题，花了两年时间，由一个小团队成功地解决了这个问题，然后你辞职了？在问题解决之后？ 当然，他们一开始的情况很糟糕，但一个能认识到自身问题、承诺解决并具备实际解决问题能力的公司对我来说听起来相当不错。很多公司都卡在第一步。 我猜辞职还有其他原因，或者你只是喜欢大规模的重构项目。
完整原文我曾经处理过“检出”代码库，非常类似于这个情况。我的意思是，没有像脚本随意地往jar包里打补丁那么疯狂，但“只是检出一个文件，这样其他人就不能工作了”这种做法似乎是一种“常见”的“解决方案”。 我对你是如何处理有人需要长时间持有代码的情况很感兴趣（我见过这种情况）。基本上，我们也有一种方式可以与另一个人共享控制权，而第二个获取源代码的人负责同时手动更新两个版本（这从未发生过，因此实施一个涉及数百个源文件的大项目需要花几周时间手动比较文件、手动实施更改，然后手动重新测试）。
完整原文在一家大公司的小团队中，我有过类似的经历。我们没有任何版本控制系统，团队在共享的开发服务器上进行所有开发，我们通过SSH登录进去。我们一个一个地用vim编辑文件，并依赖vim的文件锁定功能来确保没有人同时编辑同一文件。 奇怪的是，这个项目是我曾经参与过的最好的项目之一。
完整原文我认为很多在过去10年才学习编程的人并不知道，Git，甚至Git的大规模流行其实都是比较新的。很多编程工作是在Git出现之前进行的，而且在Git变得成熟并流行到成为默认选择之前。 这些早期的系统在我们看来听起来很糟糕且很笨拙，但它们在当时是可用的最好方案。为了防止多人同时修改文件，系统通常会进行文件锁定，这很常见，因为基本上没有人能很好地处理合并。大多数系统都基于一个服务器来管理整个流程，因此它们只在公司和更大、更成熟的爱好者团队中常见——这也是在你可以用几个键和每月5美元就启动一个云服务器之前的事情。对于一个微小的个人项目来说，建立一个本地的Git仓库来跟踪你的工作是低投入的。…
完整原文> 在我第一份真正的工作中，我为一家维护大型遗留产品的公司工作，该产品使用COBOL和Java组合编程。 > 要在产品的Java部分进行开发，你需要从源代码控制中检出单个文件进行修改，这会'锁定'文件，防止其他开发人员检出同一文件。 COBOL + Java和文件锁定……我以为我们是在同一个项目上工作，这让我回想起了很多噩梦！ 但我们使用的是Subversion的锁定系统，并且有正确的CI/CD流程，使用Jenkins。 所以你赢了，你的项目更糟糕！
完整原文> 一个小团队花了两年时间才将整个代码库迁移到Git并实现正确的CI 我很惊讶他们竟然允许人们用公司的时间和金钱来做这件事。公司通常不会看到改善这种脆弱情况的价值，只要软件还能运行就行。他们只是希望员工去适应并接受混乱。人们通常通过辞职来适应这种情况。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。