開発効率の高さとメンテナンス性の高さはほぼイコールですよ
今（コーディング工程）が辛くても、2年後3年後のメンテナンス性のことを考えて頑張ってくださいって話がたまにあります。つまり、このコーディング工程がなかなか消化できないようなこの仕組みは、後々のメンテナンス性を高めるためだというのです。
たとえば、DB メンテナンスを楽にするために俗に言う「マスタメンテ系」を余計に作る等というならば話はわかりますが、そういうことじゃなかったんですね、この場合。コードメンテナンスの話だったんです。
開発効率ってなんですかね。
私が思うに開発効率が高いっていうのは。
- コーディング量が少なくて済む。
- モジュール構成の見通しが良く、再利用性が高い（結局コーディング量が少なくて済むってことだけど）
- 学習コストが低い。
- IDE 等のツールによる手厚い開発サポートがある。
- 困ったとき情報が得られやすい（メーカサポート等も含む）
ということではないでしょうか。かりそめの開発効率の高さに「コピペですむ」ってのもありますが（笑）
それで、ここからコードメンテナンスについて当てはめてみましょう。
- コード量が少ないならメンテナンス範囲が狭くて済む。
- モジュール構成の見通しが良いなら全体的な構成が掴みやすい。
- 学習コストが低いならメンテナの人選の幅が広がる（当該プロジェクトのメイキングに関わってなくても良いなど）
- ツールによるサポートがあれば、さらにコードが追いやすい。
- 困ったとき情報が得られやすいならメンテナもそれを頼れば良い
かりそめの開発効率の高さばっかりだったら確かにメンテナンス性は良くないでしょうが、逆に開発効率が低いならメンテナンス効率も低いのではないかと疑うべきです。開発効率が低いけどメンテナンス効率は高いなんてケースのほうが少ないと私は考えます。
コードメンテナンスしたことある人なら、メンテナンス性はどうやったら高くなるか自ずと分かると思うんですけどね。どういうコードに頭に来たかよぉーっく思い出してみてください。
- たいしたことしてないのにやたら冗長なコード
- コーディング技術がないから。これはフレームワークでカバーできないことも少なくない。
- 「なんだかよくわからないけど、こうしたら動いたのでこうしておきました」的な雰囲気を醸し出してる。
- 大量のコピペコード
- コメントがない
- 変数や関数の命名法が終わってる
- a とか b とか flag とか
- それらのコメントも終わってる
- 「区分を指定する」とか。区分ってなんだよ！
- コードが機能ごとにまとまっていない。
- 関数分け、クラス分けが下手。
- 明らかに間違っているのに奇跡的に動いているので、それが随所に使われている。
- C や Java で文字列の比較に == を使っていて、文字列が等価であるケースがほとんどない業務要件だったり。
たぶん、フレームワークとかじゃあどうにもならないようなことに頭に来ているはず。そして、それらのほとんどがソースコードレビューで潰せる問題のはず。というか、ソースコードレビューでしか潰せない問題が少なくないと思います。
でも、エラい人は、なんか魔法の方法があって、それを使えばソースコードレビューをしなくても何とかなると思っているんですね。まったく甘い話です。
