アドベントカレンダーが空いていたので、なんとなく投下してみます。
プログラマの3大美徳
Perlの作者であるラリー・ウォール氏は、こんな言葉を残しています。
プログラマの3大美徳は、怠惰・短気・傲慢である。
ただし、この3つは、どれも通常の意味ではありません。今回は、この「怠惰」を掘り下げてみます。
極論: プログラムは正しく動けばいい
実用品としてプログラムを書く場合1、そのプログラムの価値は、作るのにかかった時間やコードの分量に比例するものではありません。例えば、仮にある人が2ヶ月かけて、Windowsのメモ帳と全く同じ動作をするプログラムを書き上げたとしましょう。きちんとできあがったとしても、Windows環境下では「すでにメモ帳がある」ということになってしまって、あまり意味がありません。
プログラムは（多くの場合）実用品です。内部の処理がどうとかどんなツールを使ったかとか、そういうことは内輪受けこそするかもしれませんが、その選択で高速化した、あるいは多様な環境に対応できたなどの結果となって初めて、エンドユーザーへの価値を持ちます。
逆に同じ動作が得られるのであれば、何から何までコードを書いて作ったものも、既存のフレームワークに乗っかって手軽に作ったものも、まったく同等のものとなります。「がむしゃらに作る」ことは、むしろ報われない世界です。
巨人の肩の上に立つ
多くの分野で、既存のライブラリが多数存在しています。これらを十全に活用することで、
- 同じことを書かずに済むので、開発が速く進む
- UIまわりで既存ライブラリを使うことで、他のものとUIを統一化できる
- ライブラリ側のアップデートで、高速化や機能向上することもある
などのメリットがあります。逆に、既存のもので実現できることを自分で書いても時間の浪費になるだけで、新たな価値には繋がらない作業でしかないものです2。
コピペする、その状況に
1つのプロジェクト内で、ソースコードをコピペすることがあるかもしれません。それにはいろんな状況があるかと思います。
- 別なものを作るひな形にするために、古いところからコピペする
- 同じ処理が違うところに出てきたのでコピペ
前者の場合、そのパターンをあまりによく使うのであれば、どこかでくくりだして共通処理とすることで、いちいちコピペしなくても同じ物を作れるようになります。
後半についてですが、プログラムは作る時より、保守するときのほうが圧倒的に手数がかかるものです。コピペで作った場合、その箇所をすべて修正しなければいけないという、大きな手間を残してしまうことになります。同じ処理をまとめておけば、修正の時も1箇所で済みます。
一方で、YAGNI（You ain't gonna need it）という言葉もあります。いたずらに汎用化を志向しても、無駄な工数になってしまう可能性が大きいものです。汎用のライブラリ自体を作る状況でなければ、実際に必要になってから共通化していったほうがいいでしょう。
結論
手を抜けるようにするための手間は惜しまないほうが、いいかも。