プログラマ専用SNS ミクプラ

誰かに自分が書いたコードを見せて説明しようにも
今まで作ったことのない仕様を作る時は、まず設計書通りに動く事を最優先してしまうので、どうしても分かりにくいコードになってしまいます(一応コメントは逐一残してますけど)。

そこでリファクタリングを実行しようと思ったのですが、手元の参考書はあまり参考になりませんでした…
まとめると
・条件分岐を多態勢に置き換える
・継承を委譲に置き換える
・コンストラクタではなくファクトリメソッドを使う
・処理の長い関数を複数の関数に分割する
・関数名や変数名を分かりやすいものに変更する
・マジックナンバーを殲滅する

とのことですが
具体的なことが書いてないので分かりにくいといいますか…

そんな訳で一般的なリファクタリング技法＆リファクタリングのコツ
及び一般的ではないかもしれないけど、私はこんなことをする。
というのを教えて頂ければと思います。

リファクタリングを勉強することは、分かりやすいコードを書くことにもつながるかな。　と思ってこのスレを立ててみました。
では、よろしくお願いします。

ゲームプログラムの場合だと、どんなプラットフォームでも基本構造は同じなのでフレームワーク化してます。
同じプラットフォームや同じジャンルのゲームをいくつか作ったら、共通するコードはどんどん汎用化して使い回すようにします。
いわゆる構造化とかモジュール化とかいうものです。
あと保守性を高めるために分かりやすい識別子に変えたりドキュメント(コメント)を充実させたり。
いったん完成したプログラムに対してそれをするのがリファクタリングなので、要は作りっぱなしにしないということですね。

自分の場合、10年以上メンテしているアプリがけっこうあります。
新しいプラットフォームを試すためにそれを移植してみたり、リファクタリングの実験場のような使い方をしてます。

私は組みながら一種のリファクタリングしてますね。
途中まで組んでややこしくなりそうなら、関数化やクラス構成を見直します。
便利だなという機能が思いついたら、部品としてクラスにしておくことも常々やっています。

・同じようなコードが出てきたら関数化・クラス化の機会と考える。
・今よりもメンテナンス性が上がる方法を思いついたら実行する。
・将来にわたって使うような部分が出てきたら汎用的なクラス化や関数化を考える。
・半年たって読めないコードはリファクタリング対象！

>>ISLe さん

同じプラットフォームや同じジャンルのゲームをいくつか作ったら、共通するコードはどんどん汎用化して使い回すようにします。
いわゆる構造化とかモジュール化とかいうものです。

Dixqさんがサイトで紹介していたような、必ず行う処理をテンプレートとして残しておくことと
その他のパーツの中で使い回しが出来そうなものに手入れをして残しておく、ということですね。
ソレの大切さを知ったのが割と最近だったのでこんなスレを立てたのですけど・・・ｗ

やはり具体的なやり方を聞くと参考になりますね、経験が豊かなお方のお話だとなおさら。
過去作った自分のプロジェクトに新しい仕様を移植して運用というのは、移植のテストとしてもってこいですね。
今度から僕も実践して見ますｗ


>>softyaさん

便利だなという機能が思いついたら、部品としてクラスにしておくことも常々やっています。

やはりプロやセミプロレベルのプログラマーはみんなこういうことをやっているのですね。
具体的には、使えそうな関数に使い回しが出来るように手を加えた上で
本体の定義の部分をスタティックライブラリにまとめて、宣言はヘッダーファイルで
といったところでしょうか？

それとも(僕はこちらは詳しく知らないのですが)ダイナミックリンクライブラリを使うのでしょうか？
参考までに教えて頂けると嬉しいです。

ついでに後半の４行はバッチリ記憶させてもらいましたｗ

わたしはいろんなプラットフォームやプログラム言語を使うので、いちいちバイナリを分けるのも面倒で、処理系ごとにきちんとライブラリ形式にまとめることはほとんどないです。
ネットで公開するときは特定の処理系向けのライブラリ形式を作ることもありますけど、基本ソースファイル単位ですね。

>>ISLeさん
ふむふむ、つまり自分に一番合った形を取るのが一番いいということなのですね。
これを機にスタティックライブラリについて勉強しようかとも考えたのですが、ソースファイルにまとめた方が楽チンな気もしてきました・・・ｗ
少なくともライブラリを作るためにビルドする必要はないですしねｗ
やはりプログラマーとしての大先輩のお言葉は参考になりますね。　ありがとうございます。


っと、まだまだ皆さんの答えを待っていますよ～

作ったクラスが、標準ライブラリやそれに準ずるものに適応可能ならば、そのように書き換えることがあります。
たとえば、複数のデータに一つ一つアクセスして処理する場合などは、それをラップするイテレータクラスを作ってstd::for_eachで処理したりするようにしたり、自作した乱数エンジンをboost::randomのエンジンクラスとして使えるようにインターフェイスを再設計したりとかしたことがあります。

私の場合は手を加える可能性の多いものはソースコードのままのライブラリ。
LIBにするのは変更も落ち着いて色々使えるのができた時。
DLLとなると大きさもある程度有ってライブラリとして公開するときぐらいでしょうか。

DLLのメリットって差し替えが効くことですから使い方によっては便利ですよ。
まぁ個人で非公開で使っている分にはメリットはほぼ無いですが。
フリーソフトのプラグインとか、フリーソフトの主要部分をＤＬＬにしてオンラインアップデート可能にするとか。

jay さんが書きました:これを機にスタティックライブラリについて勉強しようかとも考えたのですが、ソースファイルにまとめた方が楽チンな気もしてきました・・・ｗ
少なくともライブラリを作るためにビルドする必要はないですしねｗ

何となく勘違いされているような。
わたしが言うソースファイル単位というのは、中身には一切手を加えずにプロジェクトに追加するだけで使い回せるソースファイル、を基準にするという意味で、ライブラリ単位でひとつのソースファイルにまとめるというようなことではないですよ。
むしろ流用しやすくするために細かく機能単位にソースファイルを分けてます。

なので、スタティックライブラリを作りたくなったら、VC++の場合ならスタティックライブラリのプロジェクトを新規作成して適当にソースファイルを追加してビルドするだけですぐに作成できます。
実際にはクロス開発ばかりなのでVC++用のライブラリだけ用意しても役に立たないですし、仕事で納品するときは保守対応で面倒臭いことになるのでソースファイルで管理しているわけです。

急ぐので今回返信は短めで失礼します。

>>tkmakwins15さん

作ったクラスが、標準ライブラリやそれに準ずるものに適応可能ならば、そのように書き換えることがあります。

そうして次から使いまわせるようにすることで開発がスムーズに進む。　それがリファクタリングですね～。
標準ライブラリ対応ならば、殆どの開発環境で使えますものね。
自作ライブラリのまとめ方のお話になってて元はリファクタリングということを忘れかけていまたｗ
そしてＳＴＬライブラリは僕にはとても扱えない代物・・・ｗ

>>softyaさん

私の場合は手を加える可能性の多いものはソースコードのままのライブラリ。
LIBにするのは変更も落ち着いて色々使えるのができた時。
DLLとなると大きさもある程度有ってライブラリとして公開するときぐらいでしょうか。

ふむふむ～、なるほど～
ちょっとＤＬＬについて調べて来ます（オイ）

使いやすいように改良を加えて、形になったらLIBにまとめる。　ですか
なんだか開発が凄くはかどりそうですね、いずれ僕もそう言うことが出来るようになりたいですね。
そのためにもまずは知識と経験を深めないと、ですけどね・・・ｗ

>>ISLeさん

わたしが言うソースファイル単位というのは、中身には一切手を加えずにプロジェクトに追加するだけで使い回せるソースファイル、を基準にするという意味で、ライブラリ単位でひとつのソースファイルにまとめるというようなことではないですよ。
むしろ流用しやすくするために細かく機能単位にソースファイルを分けてます。

ふ～む、やはりみなさん自分なりのやり方で纏められているのですね。
機能の似た関数を一つのソースファイルにまとめておけば融通も利きそうですしね。
修正も楽ですし、これもいいやり方ですね。


みなさんお話ありがとうございました。
とっても参考になりました。　今後も何かありましたらよろしくお願いしますね。