project-management - プログラムを移植するためのプログラミングタイムスケジュール

Question

抽象化されたGUIAPIを備えた大規模なプログラムに取り組んでいます。これは非常にGUIベースであり、多くのダイアログとGUIのメッセージフローに大きく依存するいくつかの厄介な機能（フォーカス/マウス/アクティブ処理の正しいシーケンスなど）-移植が容易ではありません

現在使用しているFOXToolkitからネイティブのCocoa/MFCに移植したいと思います。

年末までの時間枠を設定しますが、主な作業は既存のツールキットを使用して開発作業を継続することですが、両方のタスクが完了する前にエンドカスタマー向けのリリースは予定されていません。

私の質問は、どのように時間を過ごすべきかということです。

1. メインプログラムでの作業を停止し、最初にGUIの90％の移植（約3か月）を行います
2. すべてを1か月ごとの小さなセッションに分割します。
3. 月曜日/火曜日をGUIプロジェクトに割り当て、残りの週をアプリに割り当てます。
4. 最初にアプリを終了し、次に移植します。

バランスを取る必要がある3つの議論があると思います。

1. モチベーション、両方のプロジェクトで何かが起こっているのを見たい
2. 脳入力オーバーフロー、両方のタスクは私の脳に多くの詳細情報を必要とし、時には十分なだけで十分です。
3. 移植は相互作用していると思いますので、移植には既存のコードとその間に書かれる新しいコードの多くのコード変更も必要になります。

Answer 1

最初にアプリを完成させてから、移植します。IMO、同時に処理するプロジェクトが少ないほど、効果的です。

Answer 2

それは本当にあなたが何に慣れているかに依存します。

個人的には、今すぐ移植を開始します-一度にサブシステム/ピース。すべてを一度に移植する必要はありません。移植をサポートするには、アプリケーションの基盤を書き直す必要がある場合があります。アプリケーションが終了するまでポートを実行するのを待つと、とにかくアプリの大部分を書き直してしまう可能性があります。そのため、サポートするライブラリとコア機能を移植することから始め、次にゆっくりと端に向かって作業します。

それまでの間、非ポートに新しいクラスを導入するたびに、最初から移植可能であることを確認してください。

Answer 3

顧客へのリリースが計画されていない場合は、希望どおりに作業を構成できるという贅沢があります。

私の第一印象は、現在のプラットフォームでアプリを完成させるために努力することは、そのコードを捨てるときに、少なくとも部分的に無駄になるということです（ある程度の学習は得られますが、最終的なコードは役に立ちません）。

個人的には、既存のバージョンをパークして、Cocoaの書き直しからやり直します。

まず、それを機能的なチャンクに分割し、それぞれをアジャイルスタイルのリリースと見なします。これらは、エンドユーザーのタスクと機能に焦点を当て、これらのGUIとバックエンド作業の両方を含める必要があります。

（GUIとアプリロジックを別々に操作するという考えが好きではない理由は、それらが別々ではないためです。書き直しの一環として、改善を行う機会があるかもしれませんが、これを維持する必要がある場合は困難です書き直しは、あまり行われない根本的な変更を加える機会です-私はそれを取ります）。

次のチャンクに進む前に、機能チャンクを1つずつ処理し、完全なリリース可能な状態にします。これにより、達成感と進歩を測定する能力の両方が得られます。また、実装がどこからともなく迫ってきた場合、完全に使用可能なチャンクがあることも意味します。

また、エンドツーエンドのタスクに焦点を当てることで、アプリ全体ではなく、常に単一の特定の領域内で作業しているため、マインドオーバーフローが最小限に抑えられることを願っています。

Answer 4

私は、MFC、Cocoa、GTKが基本的な作業を行うためにそれぞれ1か月から始めました。そして、この1週間後、システム間を循環してGUI抽象化レイヤーを取得します。アプリケーション自体にはまだ触れていません。

これはかなり効率的でした。MFC、Cocoa、GTKの複雑さでさえ、私が切り替えを行う典型的な月曜日の朝をさらに悪化させます。

そして今、私は自分のアプリケーションをどのように変更しなければならないかをたくさん知っています。Jonが述べたように、パーツを2回作成する必要があるため、機能を追加し続ける前にGUIツールキットを移植します。