他人の作ったソースコードを引き継いで修正するというよくある業務で気をつけてほしいと思っていること

この記事は Wanoグループ Advent Calendar 2017の16日目の記事になります。

前置き

業務でプログラムを書いていると、他の人が書いたソースコードに、バグ対応やちょっとした機能追加の依頼がくることは日常茶飯事だと思います。そのような場面で、常日頃気をつけてほしいと思っていることを書きたいと思います。個人的なワガママということになりますが、きっと共感してくれる人も多いと思います。

目的はソースコードのメンテナンス性を下げないためです。

バカバカしいほど簡単なことなので、対象読者は業務でプログラムを書き始めたばかりの新人プログラマとなるのですが、想像以上にソースコードの保守性を下げる対応を目にすることが多く、もしかするとそれ以外の人にも役に立つことがあるかもしれません。

ちょっとアバウトですが前提条件として以下のようなプロジェクトを想定しています。

• 実稼働フェーズに入っている等で大胆なリファクタリングが困難

つまり、影響範囲をなるべく限定して、ちょこちょこっと修正するような場面です。

一貫性

それで、気をつけてほしいと思っていることがどんなことかというと、

「ソースコードの一貫性を保つ」

これだけです。
もちろん、他にも気をつけないといけないことはたくさんあるでしょうが、とにもかくにも、まずはこれです。

もう少し詳しく

ソースコードの一貫性を保つということがどういうことかを説明する代わりに、そのために具体的に気をつけるポイントをあげてみます。

1. 命名方法
2. モジュール粒度

1.は変数などの名前の付け方です。プロジェクトによってはクラス名や関数名の命名規則が決められていることもよくあるでしょうけど、ブロック内だけで使うような変数についても、ここでは該当します。for文で数をカウントアップするような時は、for (int i=0;のようにiを使うならそれを徹底しましょう、とかそういう話です。

2.はわかりやすい例だと、クラスや関数に分ける判断基準についてです。開発者の個性が出てしまいがちな部分ですが、周囲のソースコードをよく見て、そこにうまく馴染むようなモジュールを追加することを優先しましょう、という話になります。

これらについて、既存のソースコードと一貫性が保たれているか？というのが気をつけるポイントになります。

なぜソースコードの一貫性を保つようにしてほしいのか

あとからソースコードが読むのに、余分な労力と時間がかかるようになってしまうからです。

ある程度経験を積んだプログラマーがソースコードを読む時、よほど複雑なロジックにでもなっていない限り1行ずつあるいは1文字ずつ追っていったりしません。あたかも速読術でよく言われるようなやり方で、ソースコードの塊を見てそこで行われている処理をまとめて時には予測しながら 次々と読み進めていきます。

その状態で周りと違う雰囲気の記述がなされていると「うん？」と立ち止まって書いてあることを精査する必要が出てきてしまいます。変数の名前の付け方が違うだけで、このようなことになってしまいます。

最後に

プロジェクトの規模が大きくなればなるほど、そもそも場所によって一貫性が保たれていないということもよくあるでしょう。それでも、一貫性を保つということを心がけて欲しいのです。ソースファイル内、関数内、もっと細かく言えばそのブロック内においてだけでも、なるべく既にそこにある流儀にしたがって、あとからそのコードを読む人が苦労しないか？ということに思いを馳せながら。