生産性を向上させる方法

Java

生産性について考えてみた。

生産性とはプログラムについて考えると如何に早く目的のCPU命令セットを
準備できるかどうかによると思う。

目的のCPU命令セット自体は目的が同じであるならばCPUアーキテクチャが
異ならない限り同じ量の命令セットが必要となる。

つまり、プログラミングにおいては目的の命令セットを満足させるだけの
コードを準備する必要がある。

そこで、まず比較対象として第一に考えられるのがコンパイラである。
最近の実用的な言語はすべて高級言語であり、コンパイラが付随している。
このコンパイラが少ないコード量で多くの命令セットを生成できるのであれば、
それは言語間での生産性の優劣につながると思う。

ただし、少ないコード量で多くの命令セットを生成するということは、そのコードに
対して細かい変更やチューニングができないという反面もある、例えばファイルの入出力では
①File（パス）.openAndreadAndclose
②File（パス）.open;
File（パス）.read;
　File（パス）.close;
という二つのコードがあったとして
①はファイルのオープン・リード・クローズを1行で実現する。
②はファイルのオープン・リード・クローズを3行で実現する。
単純な読み込みのみであれば①が簡略的であるが、これに書き込みの処理が追加と
なった場合はどうだろう？
①の場合は新たに別のメソッドを使用するようにしなければならない。
②の場合は行間に目的の処理コードを挿入すればよい。

この例の場合はファイルの入出力であるため、承知の方も多いので対応策は想像が付くだろう。
しかし、これがもっと一般的でないライブラリであったならばどうだろう？
一般的でないライブラリでは情報が少ないため、目的の命令セットを満たすメソッド
を調べるのに時間がかかるだろう。
調べた結果で目的のメソッドがなかった場合は自作する必要がある。

つまり、簡略化コードはある一定の目的のためには生産性があがるがそれ以外ではチューニング・変更コストが高くなるため生産性が落ちるという２面性があるということだ。
ただ、簡略化コードを実現しつつも汎用的である言語はあると思うし、それはコンパイラがすばらしく、言語仕様がすばらしいということになります。

次にフレームワークを考えて見ます。
フレームワークの趣旨は大きく分けて２つある。
①毎回同じコードを書かない。
②目的を満たすためのコードを簡略化させるユーティリティー

で、フレームワークのアプローチというものはコードを書かないようにして生産性を向上させるということになります。

しかし、やはり上記のコンパイラのお話と同じように行き過ぎると汎用性が失われ、チューニング・変更コストが高くなってしまいます。


次にソースコードの自動生成を考えて見ます。
これはコードを人間が書いていませんが、機械が書いていますので
書くコード量はそこそこ発生しています。
この場合は先のチューニング・変更コストも低いと考えられます。
しかし、ソースコードの自動生成というのは言うなればコンパイラのコンパイラ
みたいなもので実現するにはそれなりの技術と時間が必要となってきます。

フレームワークやコードの自動生成は生産性を向上させるアプローチですが
導入するにはリスクがあるということを認識した上で使わないといけません。
また、これらの生産性は案件により変化するので必ず一定とは言えず、よい時も
あれば悪いときもある。悪いときはフレームワークの選定がまずかったと思われるが
、学習コスト、後のメンテナンスコストを考えるとフレームワークをいろいろ変えて仕事をするのもどうかと思う。
また、変更容易性を考えコードを書く部分と書かない部分のバランスを考えるのも重要であると思います。

それよりももっとリスクが低くて身になりそうなのが物理的にコードを早く書けるようにすることだと思います。これにはIDEのショートカットの活用も含まれます。
どのくらいの人がどの程度ショートカットを活用しているのでしょうか気になるところです。