2014年9月4日木曜日

副業プログラマのための言語やフレームワーク、開発環境の選び方

プログラムの開発をする人の間では、いつでも、どのような開発環境、どのようなフレームワーク、どのような言語を選ぶのがいいか、みたいな話題が盛んです。

そういう話題を話したり、読んだりするのは、技術屋としては、大変楽しいことです。
ですので、技術関係のニュースサイトや掲示板、メーリングリストなどで、そういう話を見るのは、僕は大好きです。

ですが、最近、そういうニュースサイトなどで勧められているものは、自分に必要なものとは、ずいぶん違うことが多いな、と感じるようになりました。そういうサイトで勧められている開発環境のたぐいは、一言で言うと、専業プログラマのためのものであって、副業プログラマには不向きなことが多いのです。

ぼくは、医者をやりながら、時々、副業でプログラマをしています。
僕は、生活費の大部分は、本業の医者としての稼ぎで稼いでいて、プログラムを書いてもらっているお金は、それよりも少ない状況が続いています(ただ、そういう状況が今後も続くかどうかは、わかりません)。 

ぼくのような組み合わせの仕事のかけもち方をしている人は、それほど多くないようですが、プログラムを書く以外にも、営業とかナントカとか、やらなければならないことがある人というのは案外多くて、そういう人は、やはり、専業でプログラムだけをやっている人とは、必要な言語や環境の選び方が、少しちがうように思います。

最近、地方のお寺の住職をされながら、副業でプログラマをしてらっしゃる方とお会いする機会がありました。その方も、自分が使うべき技術について、僕と似た考え方を持っていらっしゃって、この話で、楽しく盛り上がりました。

そういうわけで、このエントリでは、僕が、自分が使う言語や環境を選ぶときに気をつけていることを書こうと思います。他の、僕達と似たような立場の人に、参考になるかもしれないと思うからです。

1,プログラムの動作環境は、できるだけ、「手離れのいいもの」を使う。
特に先方で指定した環境がない場合は、できるだけ、手離れのいい動作環境を選ぶようにしています(僕の場合、先方の指定した環境が手離れが良いと思えない場合には、仕事自体を断ることもあります)。
ここでいう、「手離れがいい」というのは、納品した後に、自分でサポートのために動かなくてもいい、という意味です。納品した時には、きちんと動いていたように見えても、その後に、何かトラブルが起こるかもしれませんし、納品先で何か変更を加えた結果動作がおかしくなるかもしれません。あるいは、納品したあとで、もっとスペックの高いマシンを用意するから、別のマシンでも動くようにセットアップしてほしいと言われることもあります。
そういう時、できるだけ、自分がいなくても先方のスタッフだけで対応できるように作っておくことは、副業プログラマにとっては、非常に重要です。というのは、副業プログラマには、副業よりも大切な本業がありますから、いつ本業が忙しくなって、過去の自分の作った製品のサポートのために客先の企業に訪問できなくなるかもしれないのです。
こちらに余裕があるときには、訪問してサポートを行ってお金をいただくけれど、余裕がない場合には、このとおりにやったらできるから、と先方のスタッフにメールで指示するだけでもどうにかなるように、あらかじめ準備しておくのが理想です。

2,最新のフレームワークやライブラリは、あまり使わないようにする。
最新のフレームワークやライブラリを避ける理由は、2つあります。
第一の理由は、新しいフレームワークを覚えることが、必ずしも労働時間の短縮につながらないからです。
新しいフレームワークの多くは、 一度操作を覚えると、短いプログラムを少し書くだけで、相当に複雑なプログラムを作れるように工夫されています。仮に、あるフレームワークを使えば、プログラムを仕上げるために必要な時間が10時間、短縮できるとしましょう。そうすれば、フレームワークの操作方法を覚えるために、30時間かかったとしても、同じようなプログラムを3つ以上作れば、時間については、元が取れることになります。多くのプログラマは、複数の顧客相手に、似たようなプログラムをたくさん作ることになりますから、こういうフレームワークは、覚えるときには少し時間がかかっても、大抵、覚えたほうが得になることになります。
でも、時々、専業プログラマであれば元が取れる場合でも、副業プログラマには、元が取れないことがあるのです。というのは、専業プログラマに比べて、副業プログラマは、そもそもプログラムを書く量が少ないことが多いからです。先の、3つ以上プログラムをかけば元が取れるフレームワークを、週5日のしごとで10個のプログラムを作っているプログラマが覚えるならば、確実に元が取れるでしょう。でも、週2日のしごとで3個のプログラムしか書かない副業プログラマはどうでしょう。フレームワークを覚えたことで大きく特をするとは、言い切れなくなりますし、場合によっては、少々の損になることもありうるのです(もっとも、新しい技術に触れること自体は良いことです。すぐにはメリットが出なくても、将来引き受けられる仕事の種類を増やすことにもつながりますから)。
2つ目の理由は、新しいフレームワークを使うことで、完成したプログラムが、手離れの悪いものになることが多いからです。複雑なフレームワークは、どうしても問題なく動くようにセットアップする手間がかかりますし、進歩の速いフレームワークの場合、バージョンアップにキャッチアップするための手間もバカになりません。
僕は、そういうわけで、Railsをやめました。Railsでコード書くのは、本当は大好きなんですけれどね。

3,でも、テストだけは、絶対やっておく。
最近のフレームワークの多くは、テスト駆動開発を前提にしています。たとえ、そういうフレームワークを採用しなくても、テスト駆動開発は、やっておくべきです。エラーが発生した時に、リカバーに時間を取られないようにすることは、サポートの手間を減らすために、絶対に重要です。

4,外部のライブラリやプログラムは、できるだけ使わない。
これも、手離れを良くするためです。特に、特定のバージョンのライブラリに依存したコードは書かないようにしましょう。
ウェブ関係だと、「とりあえず、apacheとmysqlが動いていれば、あとは、このディレクトリの中身をコピーしさえすれば、それだけで、どのマシンでも動きます」みたいな状態が理想だと思います。

5,開発環境は、枯れた軽いものを。
開発環境は、複雑な機能のついたビジュアルなツールよりも、エディタ、あるいは比較的軽量なIDEが良いです。また、GUIのツールよりもコマンドラインのツールのほうが良いことが多いです。 ちなみに、僕は、むかしは、eclipseを使っていましたが、今は、vimを使うようになりました。
そうすることで複雑なツールに起因する開発時のトラブルを防ぐ事にもなります。また、副業プログラマは、どうしても、本業の合間に、きまった仕事場以外の場所で開発をすることが多くなります。軽量なツールのほうが非力でポータブルなマシンを使うときに有利です。

6,言語は、できるだけ普及しているものを。
どの言語にも、メリットとデメリットがあります。しかし、副業プログラマにとっては、そういうことに関係なく、できるだけ、メジャーな言語で仕事をしたほうが、有利なことが多いです。そういうわけで、僕は、今は、ウェブ関係の仕事は、ほとんどPHP、ウェブ以外だと、ほとんどJavaでコードを書いています。
これは、必要なときに、他の人に仕事を引き継いでもらいやすいからです。「自分にしかできない仕事」は、抱えないことが大切だと思います。

 ほかにもあるかもしれませんが、とりあえず、思いつくのはそんなかんじです。
また、思いついたら、書き加えるかもしれません。

0 件のコメント:

コメントを投稿