If there is no planned release to the customers then you have the luxury of being able to structure the work exactly as you wish.
My first impression is that putting effort into finishing the app on the current platform, when you're going to throw that code away, is time at least partially wasted (you get some learning but the ultimate code is of no use).
Personally I'd park the existing version and start over with the Cocoa rewrite.
First up I'd divide it into functional chunks and view each one as an agile style release. These should be focused on end user tasks and functions and including both the GUI and back end work for these.
(The reason I don't like the idea of working through the GUI and app logic separately is that they're not separate. As part of a rewrite there may be opportunities to make improvements and this is harder if you're having to keep them compatible. A rewrite is an opportunity to make fundamental changes that doesn't often come along - I'd take it).
Work through the functional chunks one by one, getting it to a complete, releasable state before you move on to the next one. This will give you both the sense of achievement and the ability to measure progress. It also means that if an implementation looms out of nowhere you have complete usable chunks.
Also, by focusing on end to end tasks, hopefully the mind overflow stuff is minimised as you're always working within a single specific area rather than across the app.
It really depends on what you are comfortable with.
Personally, I would start porting now - a subsystem/piece at a time. You don't have to get the whole thing ported in one shot. You might find that the foundations of your application have to be rewritten to support being ported. If you wait until finishing the application to do the port, you may end up rewriting large portions of the app anyway. So I'd start by porting supporting libraries and core functionality, then slowly work to the edges.
In the meantime, each time you introduce a new class to the non-port make sure it is portable from the get go.
我现在知道了很多我必须如何更改我的应用程序。 在继续添加功能之前，我将移植 GUI 工具包，因为正如 Jon 提到的，否则我将不得不编写两次部件。
I started with one month each for MFC, Cocoa and GTK to do the basic stuff. And after this one week cycles among the systems to get the GUI abstraction layer. I haven't touched the application itself yet.
This was pretty efficient. Even when the complexity of MFC, Cocoa and GTK makes the typical monday morning when i do the switching even worse.
And i now know a lot how i have to change my application. I will port the GUI toolkit before i continue adding features because as Jon mention i would otherwise have to write parts twice.
发布评论
评论（4）
我会先完成应用程序，然后再移植它。 IMO，你同时处理的项目越少，你的效率就越高。
I would finish the app first, then port it. IMO, the less projects you handle at the same time, the more effective you are.
如果没有计划向客户发布，那么您可以完全按照自己的意愿构建工作。
我的第一印象是，当你打算扔掉该代码时，花精力在当前平台上完成应用程序，至少是部分浪费时间（你得到了一些学习，但最终的代码没有用）。
就我个人而言，我会保留现有版本并重新开始 Cocoa 重写。
首先，我将其分为功能块，并将每个块视为敏捷风格的版本。这些应该集中于最终用户任务和功能，包括 GUI 和后端工作。
（我不喜欢分别处理 GUI 和应用程序逻辑的想法是因为它们不是分开的。作为重写的一部分，可能有机会进行改进，如果您必须保留它们是兼容的。重写是一个进行根本性改变的机会，这种改变并不经常出现——我会接受它）。
一个接一个地处理功能块，使其达到完整的、可发布的状态，然后再继续下一个功能块。这会给你带来成就感和衡量进展的能力。这也意味着，如果一个实现突然出现，你就拥有了完整的可用块。
此外，通过专注于端到端任务，希望可以最大程度地减少思维溢出的情况，因为您始终在单个特定区域而不是跨应用程序工作。
If there is no planned release to the customers then you have the luxury of being able to structure the work exactly as you wish.
My first impression is that putting effort into finishing the app on the current platform, when you're going to throw that code away, is time at least partially wasted (you get some learning but the ultimate code is of no use).
Personally I'd park the existing version and start over with the Cocoa rewrite.
First up I'd divide it into functional chunks and view each one as an agile style release. These should be focused on end user tasks and functions and including both the GUI and back end work for these.
(The reason I don't like the idea of working through the GUI and app logic separately is that they're not separate. As part of a rewrite there may be opportunities to make improvements and this is harder if you're having to keep them compatible. A rewrite is an opportunity to make fundamental changes that doesn't often come along - I'd take it).
Work through the functional chunks one by one, getting it to a complete, releasable state before you move on to the next one. This will give you both the sense of achievement and the ability to measure progress. It also means that if an implementation looms out of nowhere you have complete usable chunks.
Also, by focusing on end to end tasks, hopefully the mind overflow stuff is minimised as you're always working within a single specific area rather than across the app.
这实际上取决于您对什么感到满意。
就我个人而言，我现在就开始移植——一次移植一个子系统/部分。您不必一次性移植整个内容。您可能会发现必须重写应用程序的基础才能支持移植。如果您等到完成应用程序才进行移植，那么您最终可能会重写应用程序的大部分内容。因此，我会从移植支持库和核心功能开始，然后慢慢扩展到边缘。
与此同时，每次向非端口引入新类时，请确保它从一开始就是可移植的。
It really depends on what you are comfortable with.
Personally, I would start porting now - a subsystem/piece at a time. You don't have to get the whole thing ported in one shot. You might find that the foundations of your application have to be rewritten to support being ported. If you wait until finishing the application to do the port, you may end up rewriting large portions of the app anyway. So I'd start by porting supporting libraries and core functionality, then slowly work to the edges.
In the meantime, each time you introduce a new class to the non-port make sure it is portable from the get go.
我一开始用 MFC、Cocoa 和 GTK 各一个月的时间来完成基本的工作。经过一周的系统循环，得到 GUI 抽象层。我还没有接触过应用程序本身。
这非常有效。即使 MFC、Cocoa 和 GTK 的复杂性使得我在周一早上进行切换时的情况变得更加糟糕。
我现在知道了很多我必须如何更改我的应用程序。
在继续添加功能之前，我将移植 GUI 工具包，因为正如 Jon 提到的，否则我将不得不编写两次部件。
I started with one month each for MFC, Cocoa and GTK to do the basic stuff. And after this one week cycles among the systems to get the GUI abstraction layer. I haven't touched the application itself yet.
This was pretty efficient. Even when the complexity of MFC, Cocoa and GTK makes the typical monday morning when i do the switching even worse.
And i now know a lot how i have to change my application.
I will port the GUI toolkit before i continue adding features because as Jon mention i would otherwise have to write parts twice.