I rewrote 20,000 lines of Perl to use "use strict" in every file. I had to add "my" everywhere it was needed and I had to fix the bugs that were uncovered during the process.
The biggest thing I learned from doing this is, "It always takes longer than you think."
I had to get it done all at once overnight so that the other coders would not be writing new, unfixed code at the same time. I thought it would go quickly, but it didn't, and I was still hacking on it at 6 AM the next morning.
I did get it complete and checked in before everyone else started work though!
I rewrote a large java web application to an ASP.Net application for a realty company for various reasons.
The biggest thing I learned is that, no matter how trivial the feature the original system had, if it's not in the second system, the client thinks the rewrite is a failure. Expectation management is everything when writing the new system.
This is the biggest reason rewrites are so hard: it seems so easy to the client ("Just re-do what I already have and add a few things.").
The coolest one for me, I think, was the port of MAME to the iPod. It was a great learning experience with embedded hardware, and I got to work with a lot of great people. Official site.
I am doing a rewrite of an Inhouse Project managment system to a more standard MVC model. Its in the LAMP stack (PHP) and i am close to the 1st milestone.
The things i have learned from that currently is how simple the program feels at the beginning and i tried to not add complexity until i have to.
Example is that i programmed all the functionality first (like i was an admin user) and then when that is sorted out, add the complexity of having restrictions (user levels etc)
I ported a client server Powerbuilder app, a couple of hundred screens worth, into an ASP.NET app (C#).
Due to performance and maintainability issues, I had over the previous year moved a ton of embedded SQL out of Powerbuilder scripts and into stored procedures.
Although this would make a lot of you wince, having a lot of business logic in the database, it mean the Powerbuilder app was relatively "light" and when we built the .Net front end, it could take advantage of the SQL codebase and have a lot of functionality already built and tested.
Not saying I'd recommend building apps that way, but it certainly worked to our advantage in this instance.
We had a code generation tool in our application framework that was used to read in text-based data files, About 20 other applications made use of it.
We wanted to make use of XML data files instead of structured text-based files. The original code was quite outdated and difficult to maintain. We replaced this tool by a combination of XSLT scripts and a utility library. For the utility library we could make use of some code in the old tool.
The result was that all 20 applications could now make use of either the obsolete text based file format or the new XML based format. We also delivered a conversion-generation tool that converted old data files to new XML data files.
After bringing out one or two release we have now decided that we will no longer support the old text based format and everybody is able to convert their data to XML.
将主要公司应用程序从准标准 C++ 转换为标准 C++。 我们获得了数百万美元的销售条件，使其能够在 AIX 上运行，经过研究后，我们决定转换为标准 C++ 就像转换为 IBM 的传统 C++ 一样容易。
我不知道行数，但源代码有数百兆字节。
我们使用标准 Unix 工具来完成此操作，包括 vi 和各种编译器。
花了几个月的时间。 大多数修复都是简单的，由编译器捕获并且几乎是机械修复的。 其中一些要复杂得多。
我认为我的主要收获是：不要对尚未标准化的语言中的代码过于聪明，或者事情可能会以意想不到的方式发生变化。 我们必须对 C++ 流的一些巧妙的改编/滥用进行大量挖掘。
Converted the main company app from pre-standard C++ to standard C++. We had a multimillion dollar sale contingent on making it work on AIX, and after looking at it we decided that converting to standard C++ was going to be just as easy as converting to IBM's traditional C++.
I don't know the line count, but the source code ran to hundreds of megabytes.
We used standard Unix tools to do this, including vi and the assorted compilers.
It took a few months. Most of the fixes were simple ones, caught by the compiler and almost mechanically fixed. Some of them were much more complicated.
I think my main takeaway was: Don't get too awfully clever with code in a language that hasn't been standardized yet, or is likely to have things change in unexpected ways. We had to do a lot of digging in some of the ingenious adaptations/abuses of C++ streams.
十年前，我管理的团队将 CAD 系统从 DOS 转换为 Windows。 DOS 版本使用 自制库 进行图形绘制， Windows版本使用MFC。 转换时该软件约有 70,000 行 C 代码。 我们在这个过程中学到的最重要的东西就是抽象的力量。 所有特定于设备的不可移植例程都被隔离在几个文件中。 因此，相对容易地替换对基于 DOS 的库的调用，该库通过使用 Windows API 调用直接访问帧缓冲区来进行绘制。 同样，对于输入，我们只是将检查键盘和鼠标事件的事件循环替换为相应的 Windows 事件循环。 我们继续执行将不可移植（这次是 Windows）代码与系统其余部分隔离的政策，但我们尚未发现这特别有用。 也许有一天我们会将系统移植到Mac OS X并再次心存感激。
Ten years ago I managed a team that converted a CAD system from DOS into Windows. The DOS version used home-brew libraries for graphics drawing, the Windows version used MFC. The software was about 70.000 lines of C code at the time of the conversion. The most important thing we learned in the process is the power of abstraction. All device-specific non-portable routines were isolated in a few files. It was therefore relatively easy to substitute the calls to the DOS-based library that would draw by directly accessing the frame buffer with Windows API calls. Similarly, for input we just substituted the event loop that checked for keyboard and mouse events, with the corresponding Windows event loop. We continued our policy of isolating the non-portable (this time Windows) code from the rest of the system, but we have not yet found this particularly useful. Perhaps one day we will port the system to Mac OS X and be thankful again.
It was a performance modeling tool. Part delphi 1, part turbo pascal. It needed a rewrite else it was not going to survive. So we started as a team of 2, but only me survived to the end. And I was ready before the deadline ;-).
Several things we did:
Make it multimodel. The original had lots of globals. I removed them all and multi model was easy to adapt.
Extended error messages. Click on a message and get the help.
Lots of graphs and diagrams. All clickable to drill down.
Simulation. Change parameters over time and see how long the current configuration was enough.
We really made this one clean and it paid back heavily in the end. Such a big learning experience.
Re-wrote a system for a company that processes legal invoices - the original system was a VB monstrosity that had no idea of good OO principles - everything was mixed together. The HTML did SQL, and the SQL wrote HTML. A large part of it was a custom rules engine that used something like XML for the rules.
Two teams did the re-write, which took about 9 months. One team did the web front end and the backend workflow, while the other team (that I was on) re-wrote the rules engine. The new system was written in C#, and was done test-first. Adding new rules to the system when we were done was dirt simple, and it was all testable. Along the way we did things like convert the company from VSS to SVN, implement continuous integration, automate the deployment, and teach the other developers how to do TDD and other Scrum/XP practices.
Managing expectations was crucial through the project. Having a customer that was savvy about software was very helpful.
Having a mix of large scale (end-to-end) tests along with comprehensive unit and integration tests helped tons.
Converted vBulletin which is written in PHP into C#/Asp.NET. I'm pretty familiar with both languages, but PHP is the hands down the winner for building that software. The biggest pain in the rear was needing to do a C# equivalent of PHP's eval() for calling the templates.
It was my first challenge in trying to do a conversion. I learned that I need more experience with C# and that writing it from scratch is just the easier route sometimes.
I converted a dynamical build-process completely written in Perl to a C#/.Net solution using a workflow-engine a co-worker had developed (which was still in beta - so I had to do some refinements). That gave me the oppertunity to add fail-safe and fail-over functionality to the build process.
Before you ask - no - the microsoft workflow-foundation could not be used since you cannot dynamically change a process during its runtime.
What I learned:
to hate the Perl-developer
process-optimization using a wf-engine
fail-safe and fail-over strategies
some C# tweaks ;)
In the end it covered about 5k - 6k (including the wf-engine) LoC origin from 3 200 LoC Perl-files. But it was fun - and far better in the end ;)
将理论上可移植的 C 代码转换为跨架构的理论上可移植的 C 代码，以支持硬件更改，从而为公司每单位节省 X 美元。
大小各不相同——这是一种常见的需求，我做过小型和大型项目。
我学会了编写更可移植的 C 代码。 优雅固然很棒，但归根结底，编译器会考虑性能，并且代码应该尽可能简单和可移植。
Converting theoretically portable C code into theoretically portable C code across architectures to support a hardware change that saves the company X dollars per unit.
The size varies - this is a common need, and I've done small and large projects.
I learned to write more portable C code. Elegance is great, but when it comes right down to it the compiler takes care of performance, and the code should be as simple and portable as possible.
将用 Fortran 77 编写的模拟（尽管是在 90 年代编写的）移植到 C/Java，因为原始版本仅适用于小型数据集。 在多次解释为什么在程序开始时将整个数据表移至内存中无法扩展之后，我学会了喜欢大 O 表示法。
Ported a simulation written in Fortran 77 (despite being written in the 90s) to C/Java because the original only worked on small data sets. I learned to love big O notation after several times of explaining why just moving the entire data table into memory at the start of the program was not going to scale.
发布评论
评论（17）
我要在这里“最深奥”：
FORTRAN 77 从运行 TOPS-10 的 DECSystem-10 到
运行 VM/CMS 的 IBM 4381 大型机。
I'm going for "most abstruse" here:
FORTRAN 77 from a DECSystem-10 running TOPS-10 to an
IBM 4381 mainframe running VM/CMS.
我重写了 20,000 行 Perl，在每个文件中使用“use strict”。 我必须在需要的地方添加“我的”，并且必须修复在此过程中发现的错误。
我从这样做中学到的最重要的事情是，“它总是比你想象的要花更长的时间。”
我必须连夜一次性完成所有工作，这样其他程序员就不会同时编写新的、未修复的代码。 我以为会很快，但事实并非如此，第二天早上 6 点我还在继续黑客攻击。
不过，我确实在其他人开始工作之前完成了它并签入了！
I rewrote 20,000 lines of Perl to use "use strict" in every file. I had to add "my" everywhere it was needed and I had to fix the bugs that were uncovered during the process.
The biggest thing I learned from doing this is, "It always takes longer than you think."
I had to get it done all at once overnight so that the other coders would not be writing new, unfixed code at the same time. I thought it would go quickly, but it didn't, and I was still hacking on it at 6 AM the next morning.
I did get it complete and checked in before everyone else started work though!
由于各种原因，我将一个大型 Java Web 应用程序重写为一家房地产公司的 ASP.Net 应用程序。
我学到的最重要的一点是，无论原始系统有多么微不足道的功能，如果它不在第二个系统中，客户就会认为重写是失败的。 编写新系统时，期望管理就是一切。
这是重写如此困难的最大原因：对客户来说似乎很容易（“只需重新做我已经拥有的东西并添加一些东西。”）。
I rewrote a large java web application to an ASP.Net application for a realty company for various reasons.
The biggest thing I learned is that, no matter how trivial the feature the original system had, if it's not in the second system, the client thinks the rewrite is a failure. Expectation management is everything when writing the new system.
This is the biggest reason rewrites are so hard: it seems so easy to the client ("Just re-do what I already have and add a few things.").
我认为对我来说最酷的是 将 MAME 移植到 iPod。 这是一次很棒的嵌入式硬件学习经历，我与很多优秀的人一起工作。 官方网站。
The coolest one for me, I think, was the port of MAME to the iPod. It was a great learning experience with embedded hardware, and I got to work with a lot of great people. Official site.
我正在将内部项目管理系统重写为更标准的 MVC 模型。 它位于 LAMP 堆栈（PHP）中，我已经接近第一个里程碑了。
目前我从中学到的东西是程序一开始感觉是多么简单，并且我尝试在必要时不增加复杂性。
示例是，我首先对所有功能进行了编程（就像我是管理员用户一样），然后在解决该问题时，增加了限制的复杂性（用户级别等）
I am doing a rewrite of an Inhouse Project managment system to a more standard MVC model. Its in the LAMP stack (PHP) and i am close to the 1st milestone.
The things i have learned from that currently is how simple the program feels at the beginning and i tried to not add complexity until i have to.
Example is that i programmed all the functionality first (like i was an admin user) and then when that is sorted out, add the complexity of having restrictions (user levels etc)
我将一个 30,000 行的 MS-DOS C++ 程序移植/重新设计/重写为一个长度相似但功能更齐全且可用的 Java Swing 程序。
我学会了永远不要再从事涉及 C++ 或 Java 的工作。
I ported/redesigned/rewrote a 30,000-line MS-DOS C++ program into a similar-length but much more fully-featured and usable Java Swing program.
I learned never to take another job involving C++ or Java.
我将一个客户端服务器 Powerbuilder 应用程序（相当于几百个屏幕）移植到了 ASP.NET 应用程序 (C#) 中。
由于性能和可维护性问题，我在去年将大量嵌入式 SQL 从 Powerbuilder 脚本中移出了存储过程。
虽然这会让很多人畏缩，因为数据库中有很多业务逻辑，但这意味着 Powerbuilder 应用程序相对“轻”，当我们构建 .Net 前端时，它可以利用 SQL 代码库并具有许多功能已经构建和测试。
并不是说我建议以这种方式构建应用程序，但在这种情况下它确实对我们有利。
I ported a client server Powerbuilder app, a couple of hundred screens worth, into an ASP.NET app (C#).
Due to performance and maintainability issues, I had over the previous year moved a ton of embedded SQL out of Powerbuilder scripts and into stored procedures.
Although this would make a lot of you wince, having a lot of business logic in the database, it mean the Powerbuilder app was relatively "light" and when we built the .Net front end, it could take advantage of the SQL codebase and have a lot of functionality already built and tested.
Not saying I'd recommend building apps that way, but it certainly worked to our advantage in this instance.
我们的应用程序框架中有一个代码生成工具，用于读取基于文本的数据文件，大约 20 个其他应用程序使用了它。
我们希望使用 XML 数据文件而不是基于结构化文本的文件。 原始代码相当过时且难以维护。 我们用 XSLT 脚本和实用程序库的组合取代了这个工具。 对于实用程序库，我们可以使用旧工具中的一些代码。
结果是所有 20 个应用程序现在都可以使用过时的基于文本的文件格式或新的基于 XML 的格式。 我们还提供了一个转换生成工具，可将旧数据文件转换为新的 XML 数据文件。
在推出一两个版本后，我们现在决定不再支持旧的基于文本的格式，每个人都可以将他们的数据转换为 XML。
我们几乎不需要进行手动转换，
We had a code generation tool in our application framework that was used to read in text-based data files, About 20 other applications made use of it.
We wanted to make use of XML data files instead of structured text-based files. The original code was quite outdated and difficult to maintain. We replaced this tool by a combination of XSLT scripts and a utility library. For the utility library we could make use of some code in the old tool.
The result was that all 20 applications could now make use of either the obsolete text based file format or the new XML based format. We also delivered a conversion-generation tool that converted old data files to new XML data files.
After bringing out one or two release we have now decided that we will no longer support the old text based format and everybody is able to convert their data to XML.
We did hardly have to do manual conversions,
将主要公司应用程序从准标准 C++ 转换为标准 C++。 我们获得了数百万美元的销售条件，使其能够在 AIX 上运行，经过研究后，我们决定转换为标准 C++ 就像转换为 IBM 的传统 C++ 一样容易。
我不知道行数，但源代码有数百兆字节。
我们使用标准 Unix 工具来完成此操作，包括 vi 和各种编译器。
花了几个月的时间。 大多数修复都是简单的，由编译器捕获并且几乎是机械修复的。 其中一些要复杂得多。
我认为我的主要收获是：不要对尚未标准化的语言中的代码过于聪明，或者事情可能会以意想不到的方式发生变化。 我们必须对 C++ 流的一些巧妙的改编/滥用进行大量挖掘。
Converted the main company app from pre-standard C++ to standard C++. We had a multimillion dollar sale contingent on making it work on AIX, and after looking at it we decided that converting to standard C++ was going to be just as easy as converting to IBM's traditional C++.
I don't know the line count, but the source code ran to hundreds of megabytes.
We used standard Unix tools to do this, including vi and the assorted compilers.
It took a few months. Most of the fixes were simple ones, caught by the compiler and almost mechanically fixed. Some of them were much more complicated.
I think my main takeaway was: Don't get too awfully clever with code in a language that hasn't been standardized yet, or is likely to have things change in unexpected ways. We had to do a lot of digging in some of the ingenious adaptations/abuses of C++ streams.
十年前，我管理的团队将 CAD 系统从 DOS 转换为 Windows。 DOS 版本使用 自制库 进行图形绘制， Windows版本使用MFC。 转换时该软件约有 70,000 行 C 代码。 我们在这个过程中学到的最重要的东西就是抽象的力量。 所有特定于设备的不可移植例程都被隔离在几个文件中。 因此，相对容易地替换对基于 DOS 的库的调用，该库通过使用 Windows API 调用直接访问帧缓冲区来进行绘制。 同样，对于输入，我们只是将检查键盘和鼠标事件的事件循环替换为相应的 Windows 事件循环。 我们继续执行将不可移植（这次是 Windows）代码与系统其余部分隔离的政策，但我们尚未发现这特别有用。 也许有一天我们会将系统移植到Mac OS X并再次心存感激。
Ten years ago I managed a team that converted a CAD system from DOS into Windows. The DOS version used home-brew libraries for graphics drawing, the Windows version used MFC. The software was about 70.000 lines of C code at the time of the conversion. The most important thing we learned in the process is the power of abstraction. All device-specific non-portable routines were isolated in a few files. It was therefore relatively easy to substitute the calls to the DOS-based library that would draw by directly accessing the frame buffer with Windows API calls. Similarly, for input we just substituted the event loop that checked for keyboard and mouse events, with the corresponding Windows event loop. We continued our policy of isolating the non-portable (this time Windows) code from the rest of the system, but we have not yet found this particularly useful. Perhaps one day we will port the system to Mac OS X and be thankful again.
一些。 但我提到一个。
它是一个性能建模工具。 部分是delphi 1，部分是turbo pascal。 它需要重写，否则它就无法生存。 所以我们一开始是2人组，但只有我活到了最后。 我在截止日期前就准备好了;-)。
我们做了几件事：
我们确实把这个清理干净了，最终得到了丰厚的回报。 这么大的学习经历。
Several. But I mention one.
It was a performance modeling tool. Part delphi 1, part turbo pascal. It needed a rewrite else it was not going to survive. So we started as a team of 2, but only me survived to the end. And I was ready before the deadline ;-).
Several things we did:
We really made this one clean and it paid back heavily in the end. Such a big learning experience.
为一家处理合法发票的公司重新编写了一个系统 - 原始系统是一个 VB 怪物，不知道良好的 OO 原则 - 一切都混合在一起。 HTML 执行 SQL，SQL 编写 HTML。 其中很大一部分是使用 XML 等规则的自定义规则引擎。
两个团队进行了重写，花费了大约 9 个月的时间。 一个团队负责 Web 前端和后端工作流程，而另一个团队（我所在的团队）则重写了规则引擎。 新系统是用 C# 编写的，并且首先进行了测试。 完成后向系统添加新规则非常简单，而且都是可测试的。 在此过程中，我们做了一些事情，例如将公司从 VSS 转换为 SVN、实施持续集成、自动化部署以及教其他开发人员如何进行 TDD 和其他 Scrum/XP 实践。
在整个项目中，管理期望至关重要。 拥有精通软件的客户非常有帮助。
大规模（端到端）测试与综合单元和集成测试的结合有很大帮助。
Re-wrote a system for a company that processes legal invoices - the original system was a VB monstrosity that had no idea of good OO principles - everything was mixed together. The HTML did SQL, and the SQL wrote HTML. A large part of it was a custom rules engine that used something like XML for the rules.
Two teams did the re-write, which took about 9 months. One team did the web front end and the backend workflow, while the other team (that I was on) re-wrote the rules engine. The new system was written in C#, and was done test-first. Adding new rules to the system when we were done was dirt simple, and it was all testable. Along the way we did things like convert the company from VSS to SVN, implement continuous integration, automate the deployment, and teach the other developers how to do TDD and other Scrum/XP practices.
Managing expectations was crucial through the project. Having a customer that was savvy about software was very helpful.
Having a mix of large scale (end-to-end) tests along with comprehensive unit and integration tests helped tons.
将 PHP 编写的 vBulletin 转换为 C#/Asp.NET。 我对这两种语言都非常熟悉，但 PHP 无疑是构建该软件的赢家。 后面最大的痛苦是需要执行相当于 PHP 的 eval() 的 C# 操作来调用模板。
这是我尝试进行转换的第一个挑战。 我了解到我需要更多的 C# 经验，有时从头开始编写它是更简单的方法。
Converted vBulletin which is written in PHP into C#/Asp.NET. I'm pretty familiar with both languages, but PHP is the hands down the winner for building that software. The biggest pain in the rear was needing to do a C# equivalent of PHP's eval() for calling the templates.
It was my first challenge in trying to do a conversion. I learned that I need more experience with C# and that writing it from scratch is just the easier route sometimes.
我使用同事开发的工作流引擎（仍处于测试阶段 - 所以我必须做一些改进）将完全用 Perl 编写的动态构建过程转换为 C#/.Net 解决方案。 这使我有机会在构建过程中添加故障安全和故障转移功能。
在您询问之前 - 不 - 无法使用微软工作流基础，因为您无法在运行时动态更改流程。
我学到了什么：
最终它涵盖了大约 5k - 6k（包括 wf-engine）LoC 起源3 200 个 LoC Perl 文件。 但这很有趣——而且最终更好;)
I converted a dynamical build-process completely written in Perl to a C#/.Net solution using a workflow-engine a co-worker had developed (which was still in beta - so I had to do some refinements). That gave me the oppertunity to add fail-safe and fail-over functionality to the build process.
Before you ask - no - the microsoft workflow-foundation could not be used since you cannot dynamically change a process during its runtime.
What I learned:
In the end it covered about 5k - 6k (including the wf-engine) LoC origin from 3 200 LoC Perl-files. But it was fun - and far better in the end ;)
将理论上可移植的 C 代码转换为跨架构的理论上可移植的 C 代码，以支持硬件更改，从而为公司每单位节省 X 美元。
大小各不相同——这是一种常见的需求，我做过小型和大型项目。
我学会了编写更可移植的 C 代码。 优雅固然很棒，但归根结底，编译器会考虑性能，并且代码应该尽可能简单和可移植。
Converting theoretically portable C code into theoretically portable C code across architectures to support a hardware change that saves the company X dollars per unit.
The size varies - this is a common need, and I've done small and large projects.
I learned to write more portable C code. Elegance is great, but when it comes right down to it the compiler takes care of performance, and the code should be as simple and portable as possible.
将用 Fortran 77 编写的模拟（尽管是在 90 年代编写的）移植到 C/Java，因为原始版本仅适用于小型数据集。 在多次解释为什么在程序开始时将整个数据表移至内存中无法扩展之后，我学会了喜欢大 O 表示法。
Ported a simulation written in Fortran 77 (despite being written in the 90s) to C/Java because the original only worked on small data sets. I learned to love big O notation after several times of explaining why just moving the entire data table into memory at the start of the program was not going to scale.
将 B-2 隐形轰炸机任务软件从 JOVIAL 迁移到 C. 100%全自动转换。 严重地！
主要教训：使用可配置的自动转换工具是一个巨大的胜利。
请参阅 DMS 软件重新工程工具包。
Migrating the B-2 Stealth Bomber mission software from JOVIAL to C. 100% fully automated conversion. Seriously!
Main lesson: using configurable automated conversion tools is a huge win.
See DMS Software Reengineering Toolkit.