了解其他人的代码
我偶尔会不幸地不得不对非常旧的、糟糕没有记录和糟糕没有设计的进行修改代码。
进行一个简单的更改通常需要很长时间，因为现有代码没有太多结构，而且我确实必须阅读大量代码才能了解情况。
我认为在这种情况下会有很大帮助的是一种工具，它可以让人们直观地了解代码的概述，然后甚至可以深入了解更多细节。 我怀疑这样的工具很难正确使用，因为它试图找到很少或根本没有的结构。
我想这并不是一个真正的问题，而是一个沉思。 我应该把它变成一个问题 - 其他人会做什么来帮助他们了解其他人的代码，好的和坏的？
I'm occasionally unfortunate enough to have to make alterations to very old, poorly not documented and poorly not designed code.
It often takes a long time to make a simple change because there is not much structure to the existing code and I really have to read a lot of code before I have a feel for where things would be.
What I think would help a lot in cases like this is a tool that would allow one to visualise an overview of the code, and then maybe even drill down for more detail. I suspect such a tool would be very hard to get right, given that is trying to find structure where there is little or none.
I guess this is not really a question, but rather a musing. I should make it into a question - What do others do to assist in getting their head around other peoples code, the good and the bad?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（16）
嗯，这是一个很难的问题，要说的太多了，时间太少了......
1）如果你可以运行代码，它会让生活变得更容易，断点（尤其是条件断点）是你的朋友。
2）纯粹主义者的方法是为已知功能编写一些单元测试，然后重构以改进代码和理解，然后重新测试。 如果出现问题，则创建更多单元测试 - 重复直到无聊/旧/移动到新项目
3) ReSharper 擅长显示事物的使用位置，例如调用方法的内容，它是静态的，但是一个良好的开始，并且它有帮助通过重构。
4) 许多 .net 事件被编码为公共事件，即使在最好的情况下，事件的调试也很痛苦。 将它们重新编码为私有，并使用带有添加/删除功能的属性。 然后，您可以使用断点来查看正在侦听事件的内容。
顺便说一句 - 我正在 .Net 领域玩游戏，并且希望有一个工具可以帮助完成此类工作，就像 Joel 一样，有人知道一个好的动态代码审查工具吗？
Hmm, this is a hard one, so much to say so little time ...
1) If you can run the code it makes life soooo much easier, breakpoints (especially conditional) break points are you friend.
2) A purists' approach would be to write a few unit tests, for known functionality, then refactor to improve code and understanding, then re-test. If things break, then create more unit tests - repeat until bored/old/moved to new project
3) ReSharper is good at showing where things are being used, what's calling a method for instance, it's static but a good start, and it helps with refactoring.
4) Many .net events are coded as public, and events can be a pain to debug at the best of times. Recode them to be private and use a property with add/remove. You can then use break point to see what is listening on an event.
BTW - I'm playing in the .Net space, and would love a tool to help do this kind of stuff, like Joel does anyone out there know of a good dynamic code reviewing tool?
过去我曾被要求拥有一些令人讨厌的代码——无论是工作还是“娱乐”。
我接手的大多数业余爱好者只是在几次迭代中改进了代码来完成他们需要的事情。 这总是一个巨大的混乱，库 A 调用 B，回调到 A，调用 C，调用 B 等等。很多时候他们会使用线程，而不是看到关键部分。
我发现获取代码句柄的最佳/唯一方法是从操作系统入口点 [main()] 开始，并构建我自己的显示调用树的调用堆栈图。 您实际上并不需要从一开始就构建一棵完整的树。 只需跟踪您在每个阶段正在处理的部分，您就会对事情有足够的掌握，以便能够运行它。
最重要的是，使用你能找到的最大的死树和一支笔。 将一切都摆在您面前，这样您就不必在屏幕或页面上来回跳转，让生活变得更加简单。
编辑：有很多关于编码标准的讨论......它们只会使糟糕的代码看起来与好的代码一致（并且通常更难发现）。 编码标准并不总是使维护代码变得更容易。
I have been asked to take ownership of some NASTY code in the past - both work and "play".
Most of the amateurs I took over code for had just sort of evolved the code to do what they needed over several iterations. It was always a giant incestuous mess of library A calling B, calling back into A, calling C, calling B, etc. A lot of the time they'd use threads and not a critical section was to be seen.
I found the best/only way to get a handle on the code was start at the OS entry point [main()] and build my own call stack diagram showing the call tree. You don't really need to build a full tree at the outset. Just trace through the section(s) you're working on at each stage and you'll get a good enough handle on things to be able to run with it.
To top it all off, use the biggest slice of dead tree you can find and a pen. Laying it all out in front of you so you don't have to jump back and forward on screens or pages makes life so much simpler.
EDIT: There's a lot of talk about coding standards... they will just make poor code look consistent with good code (and usually be harder to spot). Coding standards don't always make maintaining code easier.
我定期这样做。 并开发了一些工具和技巧。
这样做的问题是，在大多数公司里，你是看重结果的。 这就是为什么一些程序员快速编写出糟糕的代码并转向不同的项目的原因。 所以你只剩下垃圾，你的老板将你缓慢的进展与快速而肮脏的人进行比较。 （幸运的是我现在的雇主不同）。
I do this on a regular basis. And have developed some tools and tricks.
The problem with this is that on most companies you are appreciated by result. That's why some programmers write poor code fast and move on to a different project. So you are left with the garbage, and your boss compares your sluggish progress with the quick and dirtu guy. (Luckily my current employer is different).
我通常使用组件使用的各种关键方式的 UML 序列图。 我不知道有什么工具可以自动生成它们，但是许多 UML 工具（例如 BoUML 和 EA Sparx）可以从源代码创建类/操作，从而节省一些输入。
I generally use UML sequence diagrams of various key ways that the component is used. I don't know of any tools that can generate them automatically, but many UML tools such as BoUML and EA Sparx can create classes/operations from source code which saves some typing.
关于这种情况的权威文本是 Michael Feathers 的《有效处理遗留代码》。 作为 S. Lott 说进行一些单元测试来确定遗留代码的行为。 一旦你有了这些，你就可以开始重构了。 Object Mentor 网站上似乎有一个示例章节可用。
The definitive text on this situation is Michael Feathers' Working Effectively with Legacy Code. As S. Lott says get some unit tests in to establish behaviour of the lagacy code. Once you have those in you can begin to refactor. There seems to be a sample chapter available on the Object Mentor website.
我强烈推荐BOUML。 它是一个免费的 UML 建模工具，它：
因此：将代码导入 BOUML 并在其中查看，或导出到 SVG 并在 Firefox 中查看。
I strongly recommend BOUML. It's a free UML modelling tool, which:
So: import your code into BOUML and view it there, or export to SVG and view it in Firefox.
请参阅对旧版 ASP.NET Webform 应用程序进行单元测试，获取有关掌握旧版应用程序的建议通过单元测试。
类似的问题和答案还有很多。 这是搜索 https://stackoverflow.com/search?q=unit+test+legacy
的要点如果您正在为该遗留物编写单元测试，那么了解遗留物可能是最简单的。
See Unit Testing Legacy ASP.NET Webforms Applications for advice on getting a grip on legacy apps via unit testing.
There are many similar questions and answers. Here's the search https://stackoverflow.com/search?q=unit+test+legacy
The point is that getting your head around legacy is probably easiest if you are writing unit tests for that legacy.
我没有很幸运地使用工具来自动审查记录不完善/执行的代码，因为一个令人困惑/设计糟糕的程序通常会转化为一个不太有用的模型。 这并不令人兴奋或立即得到回报，但我通过选择一个位置并逐行跟踪程序执行、记录和添加注释以及在适用的情况下进行重构而获得了最佳结果。
I haven't had great luck with tools to automate the review of poorly documented/executed code, cause a confusing/badly designed program generally translates to a less than useful model. It's not exciting or immediately rewarding, but I've had the best results with picking a spot and following the program execution line by line, documenting and adding comments as I go, and refactoring where applicable.
一个好的 IDE（EMACS 或 Eclipse）在很多情况下都可以提供帮助。 同样在 UNIX 平台上，有一些用于交叉引用（etags、ctags）或检查（lint）或 gcc 的工具，并且打开了许多警告选项。
首先，在尝试理解函数/方法之前，我会对其进行一些重构以适应您的编码约定（空格、大括号、缩进），并删除大部分注释（如果它们看起来是错误的）。
然后我会重构并评论您理解的部分，并尝试在整个源代码树中查找/grep这些部分并在那里重构它们。
随着时间的推移，你会得到一个更好的、你喜欢使用的代码。
a good IDE (EMACS or Eclipse) could help in many cases. Also on a UNIX-platform, there are some tools for crossreferencing (etags, ctags) or checking (lint) or gcc with many many warning options turned on.
First, before trying to comprehend a function/method, i would refactor it a bit to fit your coding conventions (spaces, braces, indentation) and remove most of the comments if they seem to be wrong.
Then I would refactor and comment the parts you understood, and try to find/grep those parts over the whole source tree and refactor them there also.
Over the time, you get a nicer code, you like to work with.
我个人画了很多图表，并弄清楚了结构的骨架。
当下的时尚（可能是相当正确的）让我编写单元测试来测试我的断言，并为我对系统所做的更改建立一个安全网。
一旦我足够了解系统的功能，我就会尝试以最明智的方式修复错误，并希望我的安全网接近完成。
然而，这只是我。 ;)
I personally do a lot of drawing of diagrams, and figuring out the bones of the structure.
The fad de jour (and possibly quite rightly) has got me writing unit tests to test my assertions, and build up a safety net for changes I make to the system.
Once I get to a point where I'm comfortable enought knowing what the system does, I'll take a stab at fixing bugs in the sanest way possible, and hope my safety nets neared completion.
That's just me, however. ;)
我实际上一直在使用 ReSharper 的重构功能来帮助我处理我最近继承的一堆项目。 因此，为了找出另一个程序员结构非常糟糕、未记录的代码，我实际上是从重构它开始的。
清理代码、正确重命名方法、类和名称空间、提取方法都是结构性更改，可以阐明一段代码应该做什么。 重构您不“了解”的代码可能听起来违反直觉，但请相信我，ReSharper 确实允许您这样做。 以红鲱鱼死代码问题为例。 您会在类中看到一个方法，或者可能会看到一个命名奇怪的变量。 您可以首先尝试查找用法，或者进行文本搜索，但 ReSharper 实际上会检测死代码并将其涂成灰色。 一旦你打开一个文件，你就会看到灰色的和带有滚动条标志的东西，这在过去会是令人困惑的红鲱鱼。
还有许多其他技巧，可能还有许多其他工具可以做类似的事情，但我是 ReSharper 迷。
干杯。
i have actuaally been using the refactoring features of ReSharper to help m get a handle on a bunch of projects that i inherited recently. So, to figure out another programmer's very poorly structured, undocumented code, i actually start by refactoring it.
Cleaning up the code, renaming methods, classes and namespaces properly, extracting methods are all structural changes that can shed light on what a piece of code is supposed to do. It might sound counterintuitive to refactor code that you don't "know" but trut me, ReSharper really allows you to do this. Take for example the issue of red herring dead code. You see a method in a class or perhaps a strangely named variable. You can start by trying to lookup usages or, ungh, do a text search, but ReSharper will actually detect dead code and color it gray. As soon as you open a file you see in gray and with scroll bar flags what would have in the past been confusing red herrings.
There are dozens of other tricks and probably a number of other tools that can do similar things but i am a ReSharper junky.
Cheers.
从用户的角度深入了解软件。 通过研究用户界面并与之交互，可以了解很多有关底层结构的知识。
Get to know the software intimately from a user's point of view. A lot can be learnt about the underlying structure by studying and interacting with the user interface(s).
能够在可怜的东西上乱写乱画对我来说是最有用的方法。 通常，当我尝试制作基本的代码结构图时，我会出现很多“嗯，这很有趣......”，最终证明这些图比图本身更有用。 自动化工具可能比我想象的更有帮助，但对我来说，找到这些有趣的部分的价值超过了快速生成图表的价值。
对于图表，我主要寻找数据的去向。 它从哪里来，到哪里结束，途中经历了什么。 一般来说，数据发生的情况似乎会给整体布局留下良好的印象，并且如果我重写的话，还需要回到一些要点。
Being able to scribble all over the poor thing is the most useful method for me. Usually I turn up a lot of "huh, that's funny..." while trying to make basic code structure diagrams that turns out to be more useful than the diagrams themselves in the end. Automated tools are probably more helpful than I give them credit for, but the value of finding those funny bits exceeds the value of rapidly generated diagrams for me.
For diagrams, I look for mostly where the data is going. Where does it come in, where does it end up, and what does it go through on the way. Generally what happens to the data seems to give a good impression of the overall layout, and some bones to come back to if I'm rewriting.
当我处理遗留代码时，我不会尝试理解整个系统。 这将导致复杂性超载和随后的大脑爆炸。
相反，我采用系统的一个功能，并尝试从头到尾完全理解它是如何工作的。 我通常会从 UI 代码中可以找到特定功能的点开始调试代码（因为这通常是我首先能够找到的唯一东西）。 然后我将在 GUI 中执行一些操作，并将代码一直深入到数据库中，然后进行备份。 这通常会导致对系统的至少一项功能的完全理解，有时也会深入了解系统的其他部分。
一旦我了解了正在调用哪些函数以及涉及哪些存储过程、表和视图，我就会搜索代码以找出应用程序的哪些其他部分依赖于这些相同的函数/过程。 这就是我如何确定我要做的更改是否会破坏系统中的其他任何内容。
有时尝试制作数据库和/或代码结构的图表也很有用，但有时它太糟糕或太复杂，以至于最好忽略整个系统，只关注您需要的部分改变。
When I'm working on legacy code, I don't attempt to understand the entire system. That would result in complexity overload and subsequent brain explosion.
Rather, I take one single feature of the system and try to understand completely how it works, from end to end. I will generally debug into the code, starting from the point in the UI code where I can find the specific functionality (since this is usually the only thing I'll be able to find at first). Then I will perform some action in the GUI, and drill down in the code all the way down into the database and then back up. This usually results in a complete understanding of at least one feature of the system, and sometimes gives insight into other parts of the system as well.
Once I understand what functions are being called and what stored procedures, tables, and views are involved, I then do a search through the code to find out what other parts of the application rely on these same functions/procs. This is how I find out if a change I'm going to make will break anything else in the system.
It can also sometimes be useful to attempt to make diagrams of the database and/or code structure, but sometimes it's just so bad or so insanely complex that it's better to ignore the system as a whole and just focus on the part that you need to change.
我的大问题是，我（目前）有非常大的系统需要在相当短的时间内理解（在这一点上我可怜合约开发人员）并且没有很多这样做的经验（之前很幸运能够成为从头开始设计。）
我使用的一种方法是尝试理解变量、方法、类等命名的含义。这很有用，因为它（希望越来越多）嵌入了火车的高级视图原子层面的思想。
我这样说是因为开发人员通常会有意义地命名他们的元素（用他们认为的内容）并提供对其预期功能的深入了解。 诚然，如果开发人员对其程序、术语的理解有缺陷，或者（通常是这种情况，恕我直言）试图听起来很聪明，那么这是有缺陷的。 有多少开发人员第一次看到关键字或类名，然后才在字典中查找该术语？
My big problem is that I (currently) have very large systems to understand in a fairly short space of time (I pity contract developers on this point) and don't have a lot of experience doing this (having previously been fortunate enough to be the one designing from the ground up.)
One method I use is to try to understand the meaning of the naming of variables, methods, classes, etc. This is useful because it (hopefully increasingly) embeds a high-level view of a train of thought from an atomic level.
I say this because typically developers will name their elements (with what they believe are) meaningfully and providing insight into their intended function. This is flawed, admittedly, if the developer has a defective understanding of their program, the terminology or (often the case, imho) is trying to sound clever. How many developers have seen keywords or class names and only then looked up the term in the dictionary, for the first time?
这完全取决于您公司正在使用的标准和编码规则。
如果每个人都以不同的风格编码，那么很难维护其他程序员的代码等等，如果你决定使用什么标准有一些规则，一切都会好起来:)注意：你不必做很多规则，因为人们应该有可能以他们喜欢的风格进行编码，否则你可能会感到非常惊讶。
It's all about the standards and coding rules your company is using.
if everyone codes in different style, then it's hard to maintain other programmer code and etc, if you decide what standard you'll use have some rules, everything will be fine :) Note: that you don't have to make a lot of rules, because people should have possibility to code in style they like, otherwise you can be very surprised.