您如何使用别人的密码？

Dealing with code created by other people is a fundamental skill for a developer. Give it a year and other people’s code could even be your own.

处理其他人创建的代码是开发人员的一项基本技能。 给它一年的时间，其他人的代码甚至可以是您自己的。

Today I’m going to look at some of the best approaches for how to deal with other people’s code, read legacy code, effectively. It’s not an easy topic to cover.

今天，我将探讨一些最佳方法，这些方法可以有效地处理其他人的代码，读取旧代码。 这不是一个容易涵盖的话题。

To make the process easier, I’m framing my approach through the following areas:

为了简化该过程，我将通过以下几个方面来制定方法：

• Interact
  相互作用
• Observe
  观察
• Run Tests
  运行测试
• Fix Bugs designed for Newcomers
  修复专为新手设计的错误
• Find Available Resources
  查找可用资源
• Use a Good IDE
  使用优质的IDE
• Read Books & Blogs
  阅读书籍和博客
• Contribute to Documentation
  贡献文件
• Be Considerate
  体贴

Let’s get started.

让我们开始吧。

相互作用 (Interact)

Who are the lead developers? Where are they? Are they available directly in your office? If so, go have a talk with them or email them. These people should be the best sources of knowledge about a project.

谁是主要开发人员？ 他们在哪？ 它们可以直接在您的办公室中使用吗？ 如果是这样，请与他们交谈或发送电子邮件。 这些人应该是有关项目的最佳知识来源。

Are you a remote worker or freelancer? What communication channels does the project or company have? Are developers on IRC, Slack, Twitter, email, Trello or something else?

您是远程工作者还是自由职业者？ 项目或公司有哪些沟通渠道？ 开发人员是使用IRC， Slack ，Twitter，电子邮件， Trello还是其他工具？

Make sure you are where they are. A criticism often leveled at Zend Framework 2 is that there’s no active community. That’s not the case, as the IRC channel is active on a daily basis. So make sure you are where the developers and other team members are.

确保您在他们那里。 对Zend Framework 2经常提出的批评是没有活跃的社区。 事实并非如此，因为IRC频道每天都处于活动状态。 因此，请确保您在开发人员和其他团队成员的位置。

观察 (Observe)

When you first start on a project, take it easy on yourself. Don’t expect to know everything right from the start. The estimates vary, but I’ve heard of three weeks to three months of daily work with codebases before a developer can truly be considered productive with that codebase.

首次开始项目时，请放轻松。 不要期望从一开始就了解所有内容。 估算值各不相同，但是我听说在使用代码库进行日常工作三到三个月之前，开发人员才可以真正被认为可以使用该代码库生产代码。

Some people have the misguided perception that you can, somehow, just jump in and instantly be productive. Perhaps they’ve watched too many Hollywood movies like Swordfish.

有些人误导了您可以以某种方式进入并立即变得富有成效。 也许他们看了太多的电影如箭鱼(Swordfish) 。

Codebases take time to learn as they’re invested with the ideas, preconceptions, beliefs and approaches of all the developers who worked on the project. Given that you’re new, you won’t have any of the background knowledge.

代码库需要花费时间来学习，因为他们投入了所有从事该项目的开发人员的想法 ， 先入之见 ， 信念和方法 。 如果您是新手，那么您将不会有任何背景知识。

Here are 5 good ways to get started:

这是5种入门的好方法：

• Take time to step through everything
  花时间逐步完成所有步骤
• Ask questions
  问问题
• Setup a test installation
  设置测试安装
• Attempt to use the test installation
  尝试使用测试安装
• Read through the code comments and related documentation
  通读代码注释和相关文档

Don’t be hard on yourself, give yourself a chance to make a good start. After a while, you’ll start to have a better understanding of how the application has been put together.

不要对自己施加压力，给自己一个良好的开端的机会。 一段时间后，您将开始对应用程序的组合方式有了更好的了解。

At this point, start to move faster by asking questions of other developers and senior developers. You would have built a list of questions as you went through the codebase.

在这一点上，通过询问其他开发人员和高级开发人员的问题开始更快地行动。 在遍历代码库时，您将建立一个问题列表。

Take time out to ask the other developers for answers to your questions and queries. Don’t be shy, jump in and get the answers and input you need.

花点时间请其他开发人员回答您的问题和疑问。 不要害羞，跳入并获得所需的答案和输入。

运行测试 (Run Tests)

Any good codebase should have tests. If it doesn’t, that’s not a good sign. It needn’t be insidious — it could just be a developer or development team who’d never implemented testing — but I’d be more than a little concerned if there were none.

任何好的代码库都应该进行测试。 如果不是，那不是一个好兆头。 不必太阴险-可以只是从未执行过测试的开发人员或开发团队-但如果没有，我会更加担心。

If there are tests, run them. Do they pass? I’ve come across more than one source codebase which has a suite of tests which no one seemed able to actually run. Have they been kept up to date?

如果有测试，请运行它们。 他们通过了吗？ 我遇到了多个源代码库，其中包含一组测试，似乎没有人可以实际运行。 他们是否保持最新状态？

Now you’ve tried running them, have a good read through them. If they’re well written, they should describe how the application works, what it’s expected to do, and how different components hang together. Make sure you take the time to do this, as it can be quite insightful.

现在，您已经尝试运行它们，请仔细阅读它们。 如果编写得当，则应描述应用程序的工作方式，预期的工作方式以及不同的组件如何挂在一起。 确保您花时间进行此操作，因为它可能很有见地。

修复专为新手设计的错误 (Fix Bugs Designed for Newcomers)

Another easy way to start out is fixing the bugs targeted at newcomers, or more junior developers, on the project. Two good examples are Joind.In and ownCloud, the bug tracker for the latter you can see in the screenshot below.

另一种简单的入门方法是修复针对该项目的新手或更多初级开发人员的错误。 两个很好的例子是Joind.In和ownCloud ，后者的错误跟踪器可以在下面的屏幕截图中看到。

You can see these tickets have been clearly marked. Have a read-through and get involved. These bugs won’t be highly technical, but you’ll be able to ease in to the project, building your confidence and knowledge.

您可以看到这些票已被清楚标记。 通读并参与。 这些错误不是技术性很高的，但是您可以轻松进行该项目，建立信心和知识。

While glory and technical complexity can be great for the ego, when things don’t work or take too long, they don’t do any favors for your pride and enthusiasm. Start small and ease your way in.

尽管荣耀和技术复杂性对于自我很重要，但是当事情行不通或花费太长时间时，它们不会为您的骄傲和热情带来任何好处。 从小处着手，轻松自如。

查找可用资源 (Find Available Resources)

One of the best things you can do when taking over a codebase, or when coming into an existing team, is to gather as many resources together as you can. Not sure of what to look for? Here’s some ideas to get you started:

接管代码库或加入现有团队时，您可以做的最好的事情之一就是尽可能多地收集资源。 不确定要寻找什么？ 这里有一些想法可以帮助您入门：

• Do you have access to the mailing list archives?
  您可以访问邮件列表档案吗？
• Is there a project or company wiki?
  是否有项目或公司Wiki？
• What project documentation has been compiled?
  编译了哪些项目文档？

• Have you read through the version control history?

  您是否阅读过版本控制历史记录 ？

• Have the contributors written meaningful commit messages, consistently?

  贡献者是否始终如一地编写了有意义的提交消息 ？

使用优质的IDE (Use a Good IDE)

Good IDEs are worth their proverbial weight in gold. Whether you’re a Ruby, Python, Go, Java, PHP or other language developer, find a good IDE either specifically dedicated to or suitably customizable for your language of choice.

优秀的IDE值得称赞。 无论您是Ruby ， Python ， Go ， Java ， PHP还是其他语言开发人员，都可以找到专门针对所选语言或可以对其进行适当自定义的优秀IDE。

I appreciate some people are purists, preferring VIM or Emacs, and that’s OK. But I’m an IDE lover and my IDE of choice is PhpStorm. There are plenty of others, such as Eclipse, TextMate, SublimeText, and VisualStudio.

我很欣赏有些人是纯粹主义者，更喜欢VIM或Emacs，这没关系。 但是我是IDE爱好者，我选择的IDE是PhpStorm 。 还有很多其他东西，例如Eclipse ， TextMate ， SublimeText和VisualStudio 。

Once you’ve found the IDE for you, start making use of the features it offers. I’ll make reference to PhpStorm specifically here, but apply these principles to your IDE of choice.

找到适合您的IDE后，就开始使用其提供的功能。 我将在这里专门参考PhpStorm，但是将这些原理应用于您选择的IDE。

Start stepping through the code and see if it complies with a standard. This needn’t be a formal standard, such as the PHP PSRs. But have the developers followed a consistent style, or is it all over the place. Use tools such as a mess detector and cyclomatic complexity tester to start to gauge the quality of the code.

开始逐步检查代码，看看它是否符合标准。 这不必是正式的标准，例如PHP PSRs 。 但是，是否让开发人员遵循一致的风格，还是到处都是。 使用混乱检测器和循环复杂度测试仪等工具来开始评估代码的质量。

Is there any code documentation? If so, your IDE should be able to make use of it as you inspect the code. Next, use a step-through debugger, such as xhprof, Xdebug or Zend Debugger, and run the application, seeing how it works.

有任何代码文档吗？ 如果是这样，您的IDE在检查代码时应该可以使用它。 接下来，使用逐步调试器(例如xhprof ， Xdebug或Zend Debugger) ，然后运行应用程序，了解其工作方式。

What does it do? What data structures does it create and make use of? Does it repeat code blocks unnecessarily? There’s far more than I can cover here, but use the features your IDE provides as you go through the code to make your life easier.

它有什么作用？ 它创建和使用什么数据结构？ 是否会不必要地重复代码块？ 在这里，我不仅可以介绍更多内容，还可以使用IDE提供的功能来简化代码编写过程。

阅读和学习 (Read and Learn)

This one’s a stand-out for me personally. The more we learn, the more we can grow and — as a result — do. We’re not the first to have tread the path we’re on. Many, many, others have come before us and made plenty of the same mistakes we’re likely to make.

就我个人而言，这是一个杰出的表现。 我们学到的越多，我们就可以成长得越多，因此做得越多。 我们不是第一个踏上前进道路的人。 许多很多其他人已经出现在我们面前，并且犯了很多我们很可能会犯的同样的错误。

Save yourself a bit of time and do some justice to their hard learned experiences by learning from them. So many of the better developers are also authors and bloggers.

节省一些时间，并通过向他们学习来对他们辛苦的学习经历有所公正。 因此，许多更好的开发人员也是作家和博客作者。

One of my personal favorites is Martin Fowler, who also happens to have published a great book on the topic of refactoring. There are also other excellent books, such as Design Patterns, and websites such as SourceMaking.com.

我个人的最爱之一是马丁·福勒 ( Martin Fowler) ，他也恰巧出版了一本有关重构的书 。 另外还有其他优秀的书籍，例如《 设计模式》 ，以及网站，例如SourceMaking.com 。

Do yourself a favor and continue to invest in resources such as these. It’s not always easy, but it can be tremendously rewarding.

帮自己一个忙，继续投资诸如此类的资源。 这并不总是那么容易，但是却可以带来巨大的回报。

贡献文件 (Contribute to Documentation)

This is one which I don’t do enough of. It’s easy to be an armchair critic, sitting on the sidelines and criticizing a codebase, framework or other kind of software project. Instead of doing that, get in and get involved.

这是我做不到的。 当批评家，坐在一边，批评代码库，框架或其他类型的软件项目时，很容易。 不要这样做，而要参与进来。

Documentation isn’t for failed programmers, designers or non-technical people. Some of the largest projects actively suggest that the best place to start is documentation.

文档不适合失败的程序员，设计师或非技术人员。 一些最大的项目积极地建议最好的起点是文档。

One of the most prominent projects which does this is the Linux Kernel. What better way to learn something than to document it? After all, if you truly know it, only then can you document it.

Linux Kernel是执行此操作的最杰出的项目之一。 有什么比记录更好的学习方法？ 毕竟，如果您真正了解它，那么您才能对其进行记录。

So if it’s an open source project, get in, find out about it, read through the code, make notes as you go along, then contribute to the documentation. If it’s an internal application, be the first to start documenting; even if for no one else but yourself.

因此，如果它是一个开放源代码项目，请进入并了解它，通读代码，在进行过程中做笔记，然后为文档做贡献。 如果是内部应用程序，请第一个开始记录； 即使没有人，只有你自己。

Perhaps there’s no documentation to speak of; a truly horrid place to be. But every project has to start somewhere. As you work through the source code, write down what you know.

也许没有文件可谈。 一个真正可怕的地方。 但是每个项目都必须从某个地方开始。 在处理源代码时，写下您所知道的内容。

Some of the best developers I know, for example the lovely Lorna Jane, started blogging this way. She blogged to keep a record of what she was learning, which later turned in to one of the most popular PHP blogs around.

我认识的一些最好的开发人员，例如可爱的Lorna Jane ，都开始以这种方式撰写博客。 她在博客上记录了自己所学的内容，后来变成了周围最受欢迎PHP博客之一。

体贴 (Be Considerate)

The last point: Be considerate to the developers whose work you’re reviewing and building on. You don’t know where they were in their career and education, or what restrictions they had on them, when they wrote the code you’re now coming up to speed on.

最后一点：为正在审查和建立工作的开发人员考虑。 当他们编写代码时，您不知道他们在他们的职业和学历中所处的位置，或者他们对他们有什么限制，所以现在您可以加快学习的速度。

What’s more, at what skill level are you at? It can be easy for us, when we’re younger, newer, and less experienced, to be judgmental of others.

而且，您所掌握的技能是什么？ 当我们年轻，更新，经验不足时，对他人进行判断可能很容易。

We think we know it all and that our expectations, concepts and approaches are the true and correct ways to go. But is that really the case? I like to believe that, as we mature, and grow a bit older, we also grow wiser and become more accepting of the wide array of approaches to software development which exist.

我们认为我们都知道这一切，我们的期望，概念和方法是正确的正确方法。 但是真的是这样吗？ 我喜欢相信，随着我们的成熟和成长，我们也变得更加明智，并且越来越接受现有的各种软件开发方法。

We may not need to agree with them, but they’re not necessarily wrong. They may have a lot to teach us, which can help us grow. So always try and be considerate of other people and the position they were in. Don’t be the obnoxious newcomer, pointing fingers and laying blame. After all, that helps no one, especially you.

我们可能不需要同意它们，但是它们不一定是错误的。 他们可能有很多要教我们的知识，这可以帮助我们成长。 因此，请始终尝试并考虑其他人和他们所处的位置。不要成为令人讨厌的新人，指责和责备。 毕竟，这对任何人都没有帮助，特别是您。

结语 (Wrapping Up)

There’s loads more that you can do to make working with other people’s code a more manageable process. What methods, tips, tricks and tools do you use?

您还有许多工作要做，可以使与他人代码的合作变得更易于管理。 您使用什么方法，技巧，窍门和工具？

翻译自: https://www.sitepoint.com/work-peoples-code/