15,440
社区成员
发帖
与我相关
我的任务
分享C++程序员也是人！
前两天在坛上看到这篇文章，翻译后却找不到了！所以重新发了一贴！
Let's Reconsider That
Aren't C++ Programmers People Too?
by Michael Feathers
August 23, 2003
Summary
The industry needs refactoring tools for C++. Now.
摘要
业界现在需要一个支持C++的重构工具
--------------------------------------------------------------------------------
C++程序员也是人，难道不是吗？你当然会认为不是这样，就像业界所表现的一样！Java开始于90年代后期并快速成为国际通用的编程语言。从那时起，著作者开始在他们的书和文章中使用Java编写例子代码。当然，这是市场的需要，但也是因为Java是一种简洁的语言。如果你准备写一篇关于设计的文章，Java更适合做为页面上的代码片断。事实上，在网络上，找一些C++继续存在的理由是一件很难的事情。如果你是一个幕后的C++程序员，你知道有很多关于Java的工具，而不是C++，是的，你会很惊讶！C++是我的第一个OO（面向对象）语言，每次我再次使用它（c++）编程时，会发现C++缺少业界的支持！
C++ programmers are people too, aren't they? You wouldn't think anyone thought so, the way the industry looks today. Java started its run in the late 90s and it rapidly became the lingua franca of programming. Over night, authors started using it for all of their examples in books and articles. Certainly this was response to the market, but Java is also a much more succinct language. If you are going to write about design, Java gives you a better chance of fitting a code snippet on a page. The net effect, however, is that if you look around for evidence of C++'s continued existence, it is pretty easy to miss it. And, if you are one of these invisible C++ programmers and you are aware of that tools are available for Java but not C++, well, you should be screaming. C++ was my first OO language and every time I go back to program in it I notice the lack of support.
一些星期前，我和一个团队一起工作，准备将他们的代码分解成中等大小(模块），其中代码的一半是Java写的，而另一半是C++代码。在每次迭代开始的时候，团队成员接受任务。早上他们步入房间，你告诉他们今天他们是使用C++还是Java，他们的表情表达了一切：那些使用Java的人步履轻松，信心实足，启动了基于Java的IDE,乘着启动的时候喝一杯咖啡（诚然，Java领域也存在一些问题）。然后他们放回手中冒着蒸气的咖啡杯，看看代码，找到一些需要改变的方法（Method)，点击菜单，菜单显示了所有需要发送特定消息（因没使用过这样的IDE，这句不太理解，改为“需要修改”比较好理解）的地方。然后，他们开始在代码中修改那些被标注了的地方，他们在选出（extract)的接口和方法上点击鼠标，便自动得到了针对修改的测试代码。（我们再来看看C++程序员）C++程序员进入房间，启动了vi或者emacs（这些东西启动特快，所以C++程序员不需要喝咖啡），手工浏览代码，找出哪儿需要修改。寻找"什么使用了什么"经常是一种死胡同式的搜索。当他们准备破坏一些依赖关系时，他们坐在那儿，通过引入虚函数手工剥离接口，手工建立新的头文件和方法，所有的人都希望并祈祷他们没有破坏什么。没有自动化的工具来检查重构结果，这是一个令人精疲力竭的过程，同时也比Java的重构慢几倍。他们知道Java代码会变得更好，而C++这边的进度感觉很差。我并不认为这是由于缺少咖啡引起的。
A few weeks ago, I was working with a team whose code is split right down the middle. Half of the code is Java and the other half is C++. At the beginning of each iteration, the team members sign up for tasks. When someone walks into the room each morning you can pretty much tell whether they'll be working in C++ or Java. Their faces tell the story. The people who are going to be working in Java march in confidently and start up their Java-based IDE, then they go to get coffee while it loads (yes, there still are some issues in Java-land). When they get back with steaming cups in hand, they look around at the code, find the methods they need to change. They click a menu item and it shows them all of the places that send a particular message. Then they start going through the work of carving out a space to work with their code. They click the mouse around to extract interfaces and methods automatically so that they can get some tests in place for their changes. The C++ programmers come in and bring up vi or emacs (they load quickly so no coffee for the C++ guys) then they browse around the code manually and start to figure out where to make their changes. Figuring out what uses what is often a blind-alley search. When they are ready to break some dependencies, they sit there and try to manually peel off interfaces by introducing virtual functions. They create new header files and extract methods by hand, all the while hoping and praying that they aren't breaking anything. Without an automated tool to check their refactorings it is a nerve-wearing process and it's also several times slower. They know that the Java code is getting better, but it is hard to feel the progress on the C++ side. I don't think the lack of coffee has anything to do with it.
有一次，我拜访的一个C++团队居然不知道外面还有什么重构工具。过了一会儿，我正向一个团队展示一种测试技术。这个技术是和语言无关的，因此我使用了Java IDE。在我的编码课程上，我发现了一个我不喜欢的方法名，于是下拉菜单并点击rename（改名），当我输入新的名称后，Java IDE便替换了所有用到过的地方。不仅仅是一个文件的每一个地方，而是它被引用的每一个地方。团队的三个成员在看明白了我所做的一切后，喊道“NNNOOO WAAAAYYY!!!(没没没 门门！！）我想，如果我展示一个自动方法抽取（automated extract method 技术术语有待考证）的重构技术的话,我会彻底faint（昏倒）的。
Occasionally, some C++ teams I visit don't know what refactoring tools are out there. I was showing a team a testing technique a while back. The technique was language independent, so I pulled up a Java IDE. Over the course of my coding I found a method name that I didn't like. I pulled down a menu and hit rename. When I typed in the new name it was replaced every place it was used. Not every place in the file, every place it was used. Three of the team members recognized what they saw when I did it and they shouted "NNNOOO WAAAAAYYY!!!" I think I could have induced dead faints if I'd shown an automated extract method refactoring.
令人伤心的是，事情，本不应该这样子！
The sad thing is, it shouldn't be like this.
研究面向对象的自动重构技术是在90年代早期，Bill Opdyke和Ralph Johnson两人最先使用C++开始的。而后，John Brant和Don Roberts开发了第一个Smalltalk的重构浏览器，再后来，Martin Fowler写了一本《Refactoring》的书，正是这本书和Extreme Programming(极限编程）真正把重构技术推向实用(On the radar screen)。Java厂商匆忙在他们的IDE中建立重构工具。毕竟，Java是一种国际通用的商用语言，几乎每一个人都在用，对吧？
The first research into automated OO refactoring was done by Bill Opdyke and Ralph Johnson in the early 1990s, in C++. After that, John Brant and Don Roberts developed the first Smalltalk refactoring browser. Later, Martin Fowler wrote the book 'Refactoring.' That book and Extreme Programming really put refactoring on the radar screen. Java vendors scrambled to build refactoring tools into their IDEs. After all, it was the lingua franca, the language everyone is using, right?
几个星期后，我将访问另一个C++团队，他们是非常典型的，那儿有很多C++代码，这点任何人都可以从他们在业界的影响想象得出。但愿，我能够告诉他们，某一天将会有一个C++的重构工具可以用。对于一个有大量现有代码的团队来讲，它（重构工具）会起到立杆见影的效果！
In a few weeks, I'll be visiting another C++ team. This isn't atypical. There is a lot of C++ out there. More than anyone would imagine from looking at literature in "the industry." I wish I could tell them that someday there will be a refactoring tool for C++. For teams with large existing code bases it would be an immediate boost.
Let's Reconsider That
Aren't C++ Programmers People Too?
by Michael Feathers
August 23, 2003
Summary
The industry needs refactoring tools for C++. Now.
摘要
业界现在需要一个支持C++的重构工具
--------------------------------------------------------------------------------
C++程序员也是人，难道不是吗？你当然会认为不是这样，就像业界所表现的一样！Java开始于90年代后期并快速成为国际通用的编程语言。从那时起，著作者开始在他们的书和文章中使用Java编写例子代码。当然，这是市场的需要，但也是因为Java是一种简洁的语言。如果你准备写一篇关于设计的文章，Java更适合做为页面上的代码片断。事实上，在网络上，找一些C++继续存在的理由是一件很难的事情。如果你是一个幕后的C++程序员，你知道有很多关于Java的工具，而不是C++，是的，你会很惊讶！C++是我的第一个OO（面向对象）语言，每次我再次使用它（c++）编程时，会发现C++缺少业界的支持！
C++ programmers are people too, aren't they? You wouldn't think anyone thought so, the way the industry looks today. Java started its run in the late 90s and it rapidly became the lingua franca of programming. Over night, authors started using it for all of their examples in books and articles. Certainly this was response to the market, but Java is also a much more succinct language. If you are going to write about design, Java gives you a better chance of fitting a code snippet on a page. The net effect, however, is that if you look around for evidence of C++'s continued existence, it is pretty easy to miss it. And, if you are one of these invisible C++ programmers and you are aware of that tools are available for Java but not C++, well, you should be screaming. C++ was my first OO language and every time I go back to program in it I notice the lack of support.
一些星期前，我和一个团队一起工作，准备将他们的代码分解成中等大小(模块），其中代码的一半是Java写的，而另一半是C++代码。在每次迭代开始的时候，团队成员接受任务。早上他们步入房间，你告诉他们今天他们是使用C++还是Java，他们的表情表达了一切：那些使用Java的人步履轻松，信心实足，启动了基于Java的IDE,乘着启动的时候喝一杯咖啡（诚然，Java领域也存在一些问题）。然后他们放回手中冒着蒸气的咖啡杯，看看代码，找到一些需要改变的方法（Method)，点击菜单，菜单显示了所有需要发送特定消息（因没使用过这样的IDE，这句不太理解，改为“需要修改”比较好理解）的地方。然后，他们开始在代码中修改那些被标注了的地方，他们在选出（extract)的接口和方法上点击鼠标，便自动得到了针对修改的测试代码。（我们再来看看C++程序员）C++程序员进入房间，启动了vi或者emacs（这些东西启动特快，所以C++程序员不需要喝咖啡），手工浏览代码，找出哪儿需要修改。寻找"什么使用了什么"经常是一种死胡同式的搜索。当他们准备破坏一些依赖关系时，他们坐在那儿，通过引入虚函数手工剥离接口，手工建立新的头文件和方法，所有的人都希望并祈祷他们没有破坏什么。没有自动化的工具来检查重构结果，这是一个令人精疲力竭的过程，同时也比Java的重构慢几倍。他们知道Java代码会变得更好，而C++这边的进度感觉很差。我并不认为这是由于缺少咖啡引起的。
A few weeks ago, I was working with a team whose code is split right down the middle. Half of the code is Java and the other half is C++. At the beginning of each iteration, the team members sign up for tasks. When someone walks into the room each morning you can pretty much tell whether they'll be working in C++ or Java. Their faces tell the story. The people who are going to be working in Java march in confidently and start up their Java-based IDE, then they go to get coffee while it loads (yes, there still are some issues in Java-land). When they get back with steaming cups in hand, they look around at the code, find the methods they need to change. They click a menu item and it shows them all of the places that send a particular message. Then they start going through the work of carving out a space to work with their code. They click the mouse around to extract interfaces and methods automatically so that they can get some tests in place for their changes. The C++ programmers come in and bring up vi or emacs (they load quickly so no coffee for the C++ guys) then they browse around the code manually and start to figure out where to make their changes. Figuring out what uses what is often a blind-alley search. When they are ready to break some dependencies, they sit there and try to manually peel off interfaces by introducing virtual functions. They create new header files and extract methods by hand, all the while hoping and praying that they aren't breaking anything. Without an automated tool to check their refactorings it is a nerve-wearing process and it's also several times slower. They know that the Java code is getting better, but it is hard to feel the progress on the C++ side. I don't think the lack of coffee has anything to do with it.
有一次，我拜访的一个C++团队居然不知道外面还有什么重构工具。过了一会儿，我正向一个团队展示一种测试技术。这个技术是和语言无关的，因此我使用了Java IDE。在我的编码课程上，我发现了一个我不喜欢的方法名，于是下拉菜单并点击rename（改名），当我输入新的名称后，Java IDE便替换了所有用到过的地方。不仅仅是一个文件的每一个地方，而是它被引用的每一个地方。团队的三个成员在看明白了我所做的一切后，喊道“NNNOOO WAAAAYYY!!!(没没没 门门！！）我想，如果我展示一个自动方法抽取（automated extract method 技术术语有待考证）的重构技术的话,我会彻底faint（昏倒）的。
Occasionally, some C++ teams I visit don't know what refactoring tools are out there. I was showing a team a testing technique a while back. The technique was language independent, so I pulled up a Java IDE. Over the course of my coding I found a method name that I didn't like. I pulled down a menu and hit rename. When I typed in the new name it was replaced every place it was used. Not every place in the file, every place it was used. Three of the team members recognized what they saw when I did it and they shouted "NNNOOO WAAAAAYYY!!!" I think I could have induced dead faints if I'd shown an automated extract method refactoring.
令人伤心的是，事情，本不应该这样子！
The sad thing is, it shouldn't be like this.
研究面向对象的自动重构技术是在90年代早期，Bill Opdyke和Ralph Johnson两人最先使用C++开始的。而后，John Brant和Don Roberts开发了第一个Smalltalk的重构浏览器，再后来，Martin Fowler写了一本《Refactoring》的书，正是这本书和Extreme Programming(极限编程）真正把重构技术推向实用(On the radar screen)。Java厂商匆忙在他们的IDE中建立重构工具。毕竟，Java是一种国际通用的商用语言，几乎每一个人都在用，对吧？
The first research into automated OO refactoring was done by Bill Opdyke and Ralph Johnson in the early 1990s, in C++. After that, John Brant and Don Roberts developed the first Smalltalk refactoring browser. Later, Martin Fowler wrote the book 'Refactoring.' That book and Extreme Programming really put refactoring on the radar screen. Java vendors scrambled to build refactoring tools into their IDEs. After all, it was the lingua franca, the language everyone is using, right?
几个星期后，我将访问另一个C++团队，他们是非常典型的，那儿有很多C++代码，这点任何人都可以从他们在业界的影响想象得出。但愿，我能够告诉他们，某一天将会有一个C++的重构工具可以用。对于一个有大量现有代码的团队来讲，它（重构工具）会起到立杆见影的效果！
In a few weeks, I'll be visiting another C++ team. This isn't atypical. There is a lot of C++ out there. More than anyone would imagine from looking at literature in "the industry." I wish I could tell them that someday there will be a refactoring tool for C++. For teams with large existing code bases it would be an immediate boost.
...全文
请发表友善的回复…
发表回复
newhand2000 2003-09-15
- 打赏
- 举报
C++的确需要一个重构的工具
TinyAnt 2003-09-14
- 打赏
- 举报
悲观主义
