ソースコードの保守性を保つために心がけていることはなんでしょう？

Question

ソースコードを書いていて、フレームワークを使用しているのである程度保守性は担保されていると思いますが、どう考えてスパゲッティーコードになっているという実感があります。記述していくたびに、それが増大していき、後々見た時、どういう処理を行っているのか理解に苦しむ場面が多々有ります。

例えばビジネスロジックを記述する部分などの分離がきちんと統一できていないところや、条件分岐や繰り返し分のネストの深さ。クラスメソッドやインスタンスメソッドを多用し、またそれらが、他のクラスメソッドやインスタンスメソッドを利用しているなど。
ソースコードから、どういう処理を行っているのか読み取るのは至難の技です。

そこで皆さんに、日頃、新しいシステムのコーディングを一からスタートするにあたって、心がけている点や、スパゲッティーコードにならないための手法などあれば教えていただきたいです。

自分は変数や関数の命名には気をつけておりますが、どうしても命名が長くなってしまうことなどあります。

Answer 1

レイヤードアーキテクチャーなどを採用すると、関心が分離されて特定のロジックが各層に集約されるので、コードが読みやすくなります。

Answer 2

シンプルに実装すること
できる限りだれが見てもわかる実装に努める

Answer 3

極力テストコードを書くようにする。
テストコードの有無でリファクタリングの回転スピードが格段に違います。
テストコードを書くのは面倒という声をきいたりもしますが、1回テストコードを書いた開発に触れると、逆にテストコード無しで開発するのはキツいです。。

Answer 4

コードが汚いことがわかるなら下の２つを繰り返し行うといいですよ。

実装フェーズ-作りたい機能を実装する、この時はスパゲティコードになっても構わないので、時間をかけずに実装を進める。

リファクタリングフェーズ-機能ができて動くようになったら、IDEのリファクタリング機能を多用してスパゲティをほぐす。実装フェーズからなるべく時間をあけずに行うことが重要。

Answer 5

正直、新規で書く場合は、保守性はあまり考えません。

理由は２つあります。

一つは、私の場合は多くバグを作るので修正するときにバグの原因を考えると、コーディングに問題がありかなり修正を加えます。また、ユーザーに確認を取ると必ず追加の要件（要件漏れ）があるので、それを追加すると自然とリファクタリングが進みます。強いて言えば、つねにリファクタリングすることでしょうか。

もう一つは、今後の保守のことは基本的にわからないということです。保守で困ったらそのときに、修正するというくらいのつもりでいます。経験的にできるだけシンプルにしたほうが結果的にわかりやすいことが多いです。

命名に関しては、ドメインを意識すれば、ある程度は短くなります。私の場合はパッケージやクラスを考えると冗長な名前になっているか、バッケージやクラスを分割すべき場合に長い名前になっていることが多いです。

メソッドがメソッドを呼び出している点は問題ないと思います。適切に役割を分割すると、短いメソッドを大量に作るのは当然のことです。もしそれで、読みづらいと感じているのなら、保守のときに関係のない処理まで読もうとしているか、中を確認しなくては行けないほど命名がまずいかです。（処理が適切に分割されていない場合もあるかもしれません・・・）

Comments

[退会済みユーザー]

> 保守のときに関係のない処理まで読もうとしているか、中を確認しなくては行けないほど命名がまずいかです
とても参考になりました。回答ありがとうございます！