UML としての注釈

昨日、あるコードベースを探りながら、コードのドメインモデルの部分を見ていました。コードベースを探る時、私はメモを取って、学んだことを覚えるようにしています。特にドメインモデルのコードベースでは、UMLクラスダイアグラムを描くのが便利です。

UMLはあまり流行っていないようです。これは経済的には良くないのですが、多くのいまいちなUML主義が消えていくのを見て、不快には思いません。私は、あの日の朝と同じように、UMLを便利なツールだと感じ続けています。コードの周辺で作業をしている時は、さまざまなクラスがどのように連携しているかを確認するために、クラスと関係を書き留めました。

私はこれには「リバースエンジニアリング」ツールは使いません。そのようなツールはコードベース上で実行され、自動的にクラスダイアグラムを生成します。技術的にはそれほど難しいことではありませんが、結果はほとんど役に立ちません。優れたダイアグラムの価値は重要なものを強調し、そうでないものを無視することです。そのため、すべてのクラスやすべての関係と機能を描いているわけではありません。覚える必要があると思うものを書き留めることにしました。特に、コードを見ているだけではあまり目立たない接続に焦点を当てました。私はまた、 end lessクラスダイアグラム構文のほんの一部しか使用しませんし、構文が不正確になっても気にしません。[1]

この処理ではスピードが重要です。現在、この種のスピーディーな処理をするときに一番のお気に入りのツールはUmletです。[2]。このツールの気に入っている点は、キャプチャしたほとんどのものが、wiki風のマークアップを使用したテキストとして入力されることです。その結果、必要な時にざっとマウスで大きく移動させるだけで、すばやくメモにまとめられます。javaプログラムなので、その汎用性のために見た目はダサくなります。

これを行うとき、私は自分だけにダイアグラムを使用します。そのため、他の人が見てわかりやすいものにするために、あえて手間をかけません。他の人々にコードを説明するためにダイアグラムを作成する場合は、別の方法でアプローチします。メモでは、自分自身にリマインダーを作成しています。説明的なダイアグラムでは、別のオーディエンスにさまざまなことを伝えようとしています。[3]