あなたがプロジェクトで一人で作業している開発者である場合のUMLの有用性[非公開]

プロジェクトで一人で作業する開発者の場合、UMLはどの程度役立ちますか？

プロジェクトが十分に大きく、すべてをまっすぐに保つのに苦労している場合、非常に便利です。紙/図に何かを出すことは、少なくとも私にとっては、設計と問題解決のプロセスに役立ちます。

...また、個人的なプロジェクトの場合、私の図は作業中のプロジェクトのように形式的ではなく、私と一緒に作業するのにちょうど良いことを認めています...

とても便利で貴重です。

他の人が言ったように、それはコミュニケーションに最適であり、一見すると「開発者は1人だけなので...コミュニケーションは不要」と言うことができますが、それは真実ではないと思います。

それでは、UMLとコミュニケーションの対象は誰ですか？

1. 君は！- そう、あなた。プロジェクトからしばらく離れてから戻ってくると、プロジェクトの仕組みを思い出すのに役立ちます。
2. 新しい開発者 -現在、あなたが唯一の開発者であるかもしれませんが、将来、他の誰かがあなたのプロジェクトに参加しない、あるいは複数の開発者がいるように拡大するかもしれません。
3. ビジネスアソシエイト -プロジェクトのボス、マネージャー、または見込みのあるパートナーに何かを提示する場合、プロジェクトのUMLを使用すると、プレゼンテーションや単なるカジュアルな会話でも役立ちます。
4. ドキュメンテーション -プロジェクトのUMLを含むエンドユーザードキュメンテーションを行うのがあなたであるか他の誰かであるかは、素晴らしい起動プラットフォームになる可能性があります。あなたがそれを書いたり、他の誰かに思い出せることを口述するとき、その場ですべてを思い出そうとするよりもはるかに良い。

また、必須の状況に陥った場合の練習にも役立ちます。

要するに、おそらくそれほど多くはありません。

UMLの最大の価値はコミュニケーションにあるため、1人のチームに提供できるものはほとんどありません。ラフなデザインスケッチなどには引き続き使用しますが、視覚化は複雑な問題の把握に大いに役立ちます。

考えられる重要な用途の1つは、後継者の設計を文書化することです。そのプロジェクト（すべてのプロジェクト）で作業するのはあなただけではありません。

もちろん、答えはプロジェクトのサイズと複雑さ、モデリングをどこまで進めるか、正式な設計文書を提出する必要があるかどうかによって異なります。

私は小さな個人的なプロジェクトにそれを使用しようとしましたが、それはひどく有用ではありませんでした。奇妙なクラス図やシーケンス図はあなたの考えを整理するのに役立ちますが、しばらくすると、それは価値がある以上の作業になります。

私は単独で多くの仕事をしており（フリーランス）、UMLを使用しない傾向があります。通常、ERDと組織ツールのいくつかのメモ（私はonenoteを使用しました）。不足を感じたことはありません。しかし、同じプロジェクトに多くの人が取り組んでいる大規模な環境で、それがどのように役立つかがわかります。

UMLで設計とアーキテクチャの決定を文書化しようとすると、アプリケーションについてより深く考え、時には新しいことを発見し、より良いアイデアを作成できるため、便利です。しかし、私が他の人に同意するのは、それが小さなプロジェクトである場合、あなたが一人で作業しているとき、それから多くの利益を得ないかもしれないということです。

限界だと思います... UMLはデザインのアイデアを伝えることを目的としています。実際にUMLで考えて、その設計をマッピングする他の方法と同じくらい速く作成できる場合は、先に進んで使用してください。それ以外の場合は、大まかなスケッチのように見えるものや、プロジェクトで必要なUMLの「Lite」を少し粗くした方がよいでしょう。

特定の領域で必要と思われる場合は、いくつかのユースケースを大まかに確認してください。等

どちらにしても、v2について考えるときが来る12か月後には、何かを参照する必要があります。

私は、いくつかのプロジェクトで非常に最小限の実装（スティック図、連結ボックス、およびラベル付け）を使用しました。書面で説明するよりも、特定のプロセスを表す方が簡単だと思いました。純粋主義者の中には、実際にはUMLではないと言う人もいるかもしれませんが、クライアントは気にしないので、私も気にしません。

アーキテクチャが大きすぎて単純に覚えておくことができない場合（これは自分で決定する必要があります）、アーキテクチャのグラフィカルな表現が役立つことがあります。

自分だけのためにこれを行う場合は、UMLほど正式なものは必要ありません。
目的は、アーキテクチャを視覚化して、それを処理できるようにすることです。可能な限り邪魔にならないように、機能するものはすべて使用します。

プロジェクトの適切なドキュメントを保持するのは良い習慣ですが、一人にとってはこれは非常に簡単で時間がかかる可能性があります。コードをリリースする必要があります。プロジェクトが複雑で大規模な場合は、ドキュメントを作成するのに十分だと思うかもしれません。そのため、一定の期間を過ぎても簡単に取り戻すことができます。