5

我正在开发一个具有抽象 GUI API 的大型程序。它非常基于 GUI，许多对话框和一些讨厌的功能严重依赖于 GUI 的消息流（正确的焦点/鼠标/主动处理序列等） - 不容易移植

我现在想将它从当前使用的 FOX Toolkit 移植到本机 Cocoa/MFC。

我给自己定了一个到年底的时间框架，但我的主要工作是继续使用现有工具包进行开发工作，但在完成这两项任务之前，没有计划向最终客户发布。

我的问题是我应该如何度过我的时间？

  1. 停止在主程序上工作，先做一个 90% 的 GUI 移植（大约 3 个月）
  2. 将所有内容拆分为每个月的较小会话。
  3. 将星期一/星期二分配给 GUI 项目，一周的其余时间分配给应用程序。
  4. 先完成应用程序，然后移植。

我认为我需要平衡三个论点。

  1. 动机，我想看看这两个项目都发生了什么
  2. 大脑输入溢出，这两项任务都需要我大脑中的大量详细信息，有时足够了。
  3. 我猜移植是intervowen，所以移植还需要对现有代码和同时编写的新代码进行大量代码更改。
4

4 回答 4

1

我会先完成应用程序，然后再移植它。IMO，您同时处理的项目越少，您的效率就越高。

于 2010-02-03T00:23:29.583 回答
0

这真的取决于你对什么感到舒服。

就个人而言，我现在就开始移植——一次一个子系统/一块。您不必一次性完成所有内容的移植。您可能会发现必须重写应用程序的基础以支持移植。如果您等到完成应用程序进行移植，您最终可能会重写应用程序的大部分内容。所以我会从移植支持库和核心功能开始，然后慢慢地工作到边缘。

同时，每次向非端口引入新类时，请确保它从一开始就可移植。

于 2010-02-03T01:15:34.407 回答
0

我从 MFC、Cocoa 和 GTK 各一个月开始做基本工作。并且在这一周之后系统之间循环以获得GUI抽象层。我还没有触及应用程序本身。

这非常有效。即使 MFC、Cocoa 和 GTK 的复杂性使我在典型的星期一早上进行切换时变得更糟。

我现在知道很多我必须如何更改我的应用程序。在继续添加功能之前，我将移植 GUI 工具包，因为正如 Jon 提到的那样，否则我将不得不编写两次部件。

于 2010-06-17T23:18:48.460 回答
0

如果没有计划向客户发布，那么您可以完全按照您的意愿构建工作。

我的第一印象是，努力在当前平台上完成应用程序，当你要扔掉那些代码时，至少部分浪费了时间（你学到了一些东西，但最终的代码没有用）。

就我个人而言，我会保留现有版本并重新开始 Cocoa 重写。

首先，我将其划分为功能块，并将每个块视为一个敏捷风格的版本。这些应该集中在最终用户的任务和功能上，包括 GUI 和后端工作。

（我不喜欢分开处理 GUI 和应用程序逻辑的想法的原因是它们不是分开的。作为重写的一部分，可能会有改进的机会，如果你不得不保留，这会更难它们是兼​​容的。重写是一个机会，可以进行不经常发生的根本性改变——我会接受的）。

逐个处理功能块，使其达到完整、可释放的状态，然后再进行下一个。这会给你成就感和衡量进步的能力。这也意味着，如果某个实现突然出现，那么您将拥有完整的可用块。

此外，通过专注于端到端的任务，希望大脑溢出的东西被最小化，因为你总是在一个特定的区域内工作，而不是在整个应用程序中工作。

于 2010-02-04T16:35:33.113 回答