您曾经做过哪些失败的软件转换/重写？
您参与过哪些失败的转换/重写？ 该过程涉及哪些语言和框架？ 相关软件有多大？ 最后，您从参与该过程中学到的最重要的一两件事是什么？
这与这个问题相关。
What conversion/rewrite have you been involved with that failed? What where the languages and framework involved in the process? How large was the software in question? Finally what is the top one or two thing you learned from being involved with the process.
This is related to this question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我最喜欢的项目之一是在 Sun OS 3 上开发服务器应用程序的固定价格项目，该项目最终需要在运行某些（当时）当前版本的 Unix 的旧 Data General 机器上运行。
现在，我们提前知道将 C 代码移植到 Data General 会很痛苦，因为它有 9 位字节/36 位字，但没有意识到如何...缺乏...Unix 实现。
距离移植任务开始大约 5 个小时后，行政人员做出了明智的决定：简单地为客户购买一个闪亮的新 Sun 盒子。
One of my favorites was a fixed price project developing a server app on Sun OS 3 that was eventually required to run on an old Data General machine running some (at the time) current version of Unix.
Now, we knew ahead of time it would be painful porting the C code to the Data General because it had 9 bit bytes / 36 bit words but didn't realize how ... lacking... the Unix implementation would be.
It was approximately 5 hours from the start of the porting task when the wise executive decision was made to simply buy the customer a shiny new Sun box.
我最近有一个很大程度上失败了，因为我无法彻底说服管理层，从长远来看，重写应用程序比保持原样维护它更便宜。 如果我早点阅读技术债务，它可能会成功。 Jeff 关于该主题的最新文章对我来说晚了大约 8 个月！
总而言之，该应用程序约有 75K 行 C# 代码，但维护起来却是一场噩梦（内部应用程序）。 少数神类和其余的就是我所说的傀儡类（仅按名称命名的类，神类为他们所做的一切“幕后操纵”）。 几乎没有什么是用户可配置的，因此开发人员要对一切负责。
事后看来，成功的最大障碍是应用程序本身。 保持它的运行对于我们三个人来说是一项全职工作。 我认为我们能做的最好的事情就是继续重构。 “版本 2”应用程序有一些真正好的概念，我们应该继续尝试将它们集成，而不是重新开始......如果我们这样做了，我们就可以在稳定原始应用程序后构建大型组件。
I had one recently that largely failed due to my inability to thoroughly convince management that rewriting the app would be cheaper in the long run than to keep maintaining it as it was. If I had only read up on technical debt sooner, it may have been a success. Jeff's latest article on the topic was about 8 months too late for me!
All told the app was about 75K lines of C# code but it was a maintenance nightmare (in-house application). A handful of god classes and the rest were what I called puppet classes (classes by name only, the god classes "pulled the strings" for everything they did). Almost nothing was user-configurable so developers were responsible for everything.
In hindsight, the biggest roadblock to success was the app itself. Keeping it running was a full-time job for 3 of us. I think the best thing we could have done was to keep on refactoring. The "version 2" app had some real good concepts and we should have kept on trying to get them integrated instead of starting over... Had we done that, we could have built the big components after stabilizing the original app.
我曾经尝试将我用 DarkBasic 编写的游戏移植到 C 语言。
我遇到的问题是，当我移植它时，DarkBasic 是一种非常有限的语言（例如，没有参数通过引用传递），我尝试直接移植。 IE，我尝试不针对我使用的语言进行适当的重构...
结果是一团糟...
我可能可以让它工作，但大约两天后我停止了，因为我意识到它需要更多只是翻译转移到C...
I once attempted to port a game I wrote in DarkBasic to C.
The problem I ran into was that DarkBasic was such a limited language (for example, no argument passing by reference) when I ported it I attempted to do a straight port... IE, I tried not to refactor it appropriately for the language I was using...
The result was a big mess...
I probably could have gotten it working, but I stopped after about 2 days because I realized it needed more than just translation to move to C...
我当时使用 C 和 Allegro 编写了一个 Pacman 克隆版本，并尝试重写它以在 Dreamcast 上运行。
那是一些可怕的代码。 我无法从代码库中真正挽救太多东西并放弃了这个想法。
我了解到，无论我当时怎么想，我当时都是一个非常糟糕的程序员，而且在过去的几年里我学到了很多东西。 这也让我意识到，几年后，我应该学到足够的东西来回顾我今天写的代码并思考同样的事情。 基本上，我应该一直努力变得更好。
I had written a Pacman clone using C and Allegro back in the day and I tried to rewrite it to run on the Dreamcast.
That was some horrible code. I couldn't really salvage much from the code base and scrapped the idea.
I learned that regardless of what I thought at the time, I was a really horrible programmer back then and I had learned a lot in the passing years. It also made me realize that in a few years time, I should learn enough to look back on the code I was writing today and think the same thing. Basically, I should always strive to become better.
我曾经被要求将一个驱动 DEC-System10 上的照片打字机的程序转换为 IBM 4381。查看代码，我发现原始开发人员无缘无故地以以下不同的方式编写了程序的各个部分：语言：
这是 DEC 对多语言编程支持的有力证明，但这是我唯一一次不得不去找用户说“不行”。
I was once asked to convert a program which drove a photo typsetter on a DEC-System10 to IBM 4381. Looking at the code, I discovered that the original developer had, for no obvious reason, written various bits of the program in the following different languages:
This was a great testimony to DEC's support for multi-language programming, but it was the only time I've had to go to a user and say "No can do".