一体何回作り直したら気が済むのか・・・(;^ω^)
前のはメインフォームのソースファイルが1000行超えてやる気なくした(笑)

サイズ変更とか、タイルの呼び出しとか追加したら、
アンドゥリドゥがまともに機能しなくてかなり悩む。
描画できても、もどした後やりなおして再現されなかったり。
サイズ変更後の古いビットマップにアクセスしたままで描画されなくなったりというのが原因。

ある程度進むと設計の慎重さが欠けてコードが散らかってくるのが悩ましい。

>メインフォームのソースファイルが1000行超え

ちょっとした画面でも
・GUI操作を内部ロジックに伝達するための記述
・GUI更新用の処理
とか書いてるだけで1000行くらいにはすぐになっちゃうんじゃないでしょうか．

単純なメソッド１個書くだけでも とかで行数は簡単に膨れますし．

500行ですら把握できなくなってくるレベルなので辛いです(;^ω^)
大きなプログラムを作ったことがないので1万行とか聞くとクラクラします。

今，処理アルゴリズムの動作確認用の取って付けたような小さいダイアログを（C++でMFCですが）作ってますが，
・必要な設定値をコントロールから取得してアルゴリズムに流し込む
・アルゴリズムの結果値をコントロールに表示する
だけでもう500行は越えてます．GUIが絡む部分だとそんなもんだと思いますよ．

未来（３日後とか）の自分自身の記憶力と理解力に期待できなそうな処理を書いた場合には
迷子にならないためのコメントを盛大に残しましょう（そうすることで，もっともっと行数を膨らまそう！）

フォームの行数…に微妙に関係あるかもしれない話．

ユーザコントロールの立ち位置(?)というか，そこらへんの考え方が，物によって（あるいは人によって？）違ってて，
説明しにくいけど

(A)ユーザコントロールは１つの独立したUI部品（TextBoxとかと同じような汎用部品的な）
(B)そもそもある特定のフォームを作るために，その一部分を切り出しただけのもの（そのAPPの特定のGUI専用）

みたいな？

(A)側の考えだと，ユーザコントロールは「どのフォームに使用される」とかそういう外側の都合と無関係な存在なので，
ものすごーくざっくり書くと
【データ】ー【フォーム】ー【ユーザコントロール】
みたいな関係．
ユーザコントロールに入力された値をデータに反映する作業とかはフォームが橋渡し(?)するような感じなので，フォームのコードはその分(B)よりも多くなるかも．

他方，(B)側の立場(?)の場合には
【フォーム】---【ユーザコントロール】
　　｜　　　　　／
　【　データ　】
みたいな関係．
ユーザコントロールとフォームを「合わせて１個の画面」みたく考えるので，ユーザコントロールはフォームを介さずにデータとやりとりする
（ユーザコントロール上にあるコントロール群を，（ユーザコントロールを作らずに）フォームにダイレクトに全て並べた場合にフォームに書かれただろう処理がたまたまユーザコントロール側のファイルに書かれているだけ，っていうか，そんな形）．
なので，(A)と比べるとフォーム側のファイルの行数は少なくなるのかな．

まぁなんやかんやで，
ちょっとデカめのAPPを複数人で作る際に，ガチの初心者が議論（と言う名の戦争）を重ねた結果として

【フォーム】　【ユーザコントロール】
　｜　　　　　　／
【　　　Ｘ　　　】―【↑の段のためだけに必要なデータ】
　　　　｜
【APP機能用データ（というかAPPの機能）】

って感じにするとなんとなくいいんじゃねーの！？　という感じになったりして，
日夜【Ｘ】の行数が膨れ上がるのだった．

パネル使ってユーザーコントロールとしてそれぞれ分けてメインフォームに張り付けたり、
処理系クラスを作って行数節約するのが精一杯ですねぇ・・・。
（整理整頓が得意になりたい）

そういや，各種操作をUndo/Redoできるソフト，って作ったことないですね．
（仕事の分野がそういう方向じゃないので…　とか言い訳しておこう！）

「とりあえずUndo/Redo無しの状態を作って，あとから機能追加しよう…」
とかいうのが不可能ぎみに思えるので，最初からそれありきで設計しないとまずそうですね．
（全ての操作をコマンドパターン(とか言うの?)で書く的な…？？？）

私の場合は、アクションごとに基底クラスを持たせて派生させて命令を作ってから、
基底型のリストに詰め込んで一気に再現するようにしました。