プロジェクト名やパッケージ名について

Question

何か新しくプログラムを作成するとき、最初はプロトタイプやテストのつもりで作るため、プロジェクト名やパッケージ名の一部に「test」というような単語を含めてしまうのですが、たいていの場合、そのままそのプロジェクトで本番を作りこんでしまうため、いびつになってしまいます。プログラミング自体の質問でなくて恐縮ですが、皆様は最初から本番のつもりの命名をされますか？ それとも最初はテストであることを明確にした命名にして、本番は別プロジェクトで作りこみますか？ 普通はこうだ、という当たりまえの標準があったりするでしょうか。
また、IDEにEclipseを利用していますが、もし最初にtestなどを含めた命名をした場合にRenameがスムーズにいく方法があれば、そちらもご教示頂ければと思っています（設定ファイルなどにもpackage名を書いていたりするので、手作業が手間だと思っています……。文字列によるファイルサーチのほかに何かよいやり方はあるでしょうか？）。

---

解決済みですが備忘録的に自分のケースを残します。
前提：テスト用のつもりでプロジェクトやパッケージ名にそれらしき文言を含めたが、そのまま作りこんでしまった（Eclipse使用）
バージョン管理していたので、まず別名でチェックアウトして完全に別プロジェクトとします。
それから、チェックアウトしてきた方について、ご回答頂いている通り、パッケージ名やプロジェクト名をRefactor -> Renameしました。設定ファイルの類推はなぜか出てくれなかったので、logbackなどの設定ファイルから前のパッケージ名を探して新しい名前に置換します。設定ファイルが少なかったのでそこだけ直せばよかったのですが、もっと複雑だったりした場合、File Searchで検索文字列とファイルネームのパターンを指定します。そのままReplaceは怖いので一応目視します。バージョン管理に「.project」ファイルをignoreせず含めていたのでそこに以前のプロジェクト名が書かれています。そこも直します。これで、いびつな手順で本格的にプログラムを組み始めてしまった場合でも、困ることはないはずです。

Answer 1

また、IDEにEclipseを利用していますが、もし最初にtestなどを含めた命名をした場合にRenameがスムーズにいく方法があれば、

「リファクタリング」 - 「名前変更」を利用すると、Javaソース内はうまく名前変更してくれますね。
設定ファイルも類推して変更できた気がします。（確認用ダイアログが出たような）

以下は一般的かは分かりませんが、経験上の参考として。
サンプルと本番用は分けて作る派（なんてあるか？）なので、サンプルはサンプル用の命名で作成します。（教育用や検証用にサンプルをそのまま残したりもします）

Comments

[poyopi]

ご回答ありがとうございます。
> 設定ファイルも類推して変更できた気がします。（確認用ダイアログが出たような）
そうだったのですね。私は今までは気にせず（オープンなものではないので）testの含まれた命名のまま本番を作って特に直さずにいたり、takyafuminさんと同様分化して作ったりしていたので、パッケージ名のrefactor -> renameの実際の動作を実は正確に把握していませんでした。確認不足にて失礼いたしました。

> サンプルと本番用は分けて作る派（なんてあるか？）なので、
私も、バージョン管理でリビジョンは残っているものの、参照も手間だったり、一般的には余計と思われるぐらい詳細のコメントを記載したりもしたいので、こういうやり方でやっていきたいなと思っています。ただ、検証用のプログラムをどこで打ち止めにするかが悩ましいのですが……。

[takyafumin]

> ただ、検証用のプログラムをどこで打ち止めにするかが悩ましいのですが……。

検証用のプログラムを本番用のリポジトリのリビジョンとして残すだけだと、そのプロジェクト以外での利用がしづらかったり、記載頂いたように参照が手間になったりするので全く別の「検証用プロジェクト」として作成してしまいます。
なるべく業務機能に依存せず、シンプルに検証できることを主眼とします。
（ServletFilterの動作だけのサンプル、Loggingのサンプル、あるライブラリ利用のサンプルなど）
そのため、打ち止めのタイミングは上記の要件が満たせる時までですね。

業務に依存する形でサンプルを作成するのであれば、確かに打ち止めタイミングが難しいですね。その検証用プログラムの位置付けを決めるのがよさそうです。

例えばですが、検証用を今後参画するメンバ向けのチュートリアル的な位置付けにするのであれば一通りのCRUD処理や認証処理を他環境にあまり依存しないで動作確認できるまでとするなどですかね。（DBサーバを外部に持たなくても動作できるようにしておくと環境構築が楽ですね。JavaDBとかH2DBとか。）

[poyopi]

追加でご回答ありがとうございます。
> なるべく業務機能に依存せず、シンプルに検証できることを主眼とします。
テンプレート、雛形のようなイメージで作るのがよいでしょうか。詳細を頂けて大変参考になりました。
今のところ他者と共有して……という感じではないのですが、過去の自分は他人ということでバージョン管理をしたりしています。
面倒くさがらず、検証用のプログラムをそのまま拡張していかないようにやり方を工夫してみたいと思います。