「プログラムを書いてお金をもらう」というアルバイトを始めて早くも半年が経ったので、
そういった「職業プログラマ」の世界に触れて気づいたことを振り返りたいと思います。
僕自身はまだまだ「職業プログラマ」などとは呼べないへっぽこですが。
1) ソースコードを書くだけがプログラマではない
これは知っていたことでもあり、知らなかったことでもありました。
アルバイトを始めるまでは
「ソースコードを書く以外にすることって、せいぜい設計だとか仕様だとかを決めたり、
あとはテストケースを書くくらいなんじゃないの？」
という認識だったのですが、
実際にはこれをはるかに超える量の「ソースコードを書く以外の作業」が待ち構えていました。
それは例えば……
- Redmine でチケットを作る作業であったり、
- そのRedmine の処理済みチケットの報告を行う作業であったり、
- メールを打って開発チーム内でコンセンサスを取る作業であったり、
- バージョン管理ツールのコミットログを書く作業であったり(チームのルールとして、Git のコミットログは英語で書くことになってるので、英語のできない僕には結構キツい作業だったりします。weblio 辞書さん、いつもありがとうございます)、
- そのバージョン管理ツールでmerge 作業を行い、やたら発生するコンフリクトを潰す作業であったり
人に依るかもしれませんが、ソースコードを書く比率とそれ以外の作業をする比率は7:3くらいなんじゃないでしょうか。
でもって、上の立場になればなるほどソースコードを書く割合は減り、逆にそれ以外の作業の割合は増えているように思います。
僕のような足軽は9割方ソースコードを書いています！
2) ソフトウェア開発ツールの知識が必要である
こちらはアルバイトを始めるまでさっぱり知りませんでした。
ソフトウェアはソースコードの集合体ですので、効率のよいソフトウェア開発を行うためには
それらソースコードを上手い具合に管理してやる必要があります。
例えばそれはGit やmercurial といったバージョン管理ツールや、
Ant やMaven や Gradle といったビルド支援ツール(プロジェクト管理ツール？)や、
Jenkins 等のCI ツールなどが挙げられるでしょう。
また、ソフトウェア開発はだいたいがチームで行われるので、チーム間の連携を
うまく取るツールも必要です。
Redmine やtrac なんかがそれに当たると思います。
で、ソフトウェアをうまく開発するには、こういったツールを有効活用される事が求められるんですね。
ここでも「プログラム(ソースコード)を書くだけがプログラマじゃない」という1) に通じる話が出てくるわけです。
僕はこれらのツールの知識が一切なかった(というか、こういうツールがあることすら知らなかった)ので、
使えるようになるまで結構苦労しました。今はそれを反省して、Gradle を微妙に勉強しています。
3) ソフトは個人で作ってるんじゃない！ チームで作ってるんだ！！
ええ、ええ、承知しておりますとも。わかってはいるんです。頭では。
それなのに、どうして現場にクソコードが溢れるんだ！！！
前述のように、ソフトウェアはチームで開発しているので、所謂カウボーイ的なプログラムは原則NO です。
カウボーイ的どころか可読性が低いプログラムもNO です。
また一つのプロジェクト中で、似たような処理を行う記述を複数個記述するのもNO です。
可読性が低いプログラムを書いたり、冗長な書き方をしたり、他の人が作ってくれている処理を再発明したりすると、
コードレビューの時に吊し上げられて、リファクタリングを余儀なくされます。
コードの可読性はメンテナンスのしやすさに直結するので、大変に重要なファクタであるということは重々承知して
はいるんですが、いざ所望の機能を実装してみると難解でスマートじゃないソースが生み出されるんですよね。
「常に『他の人がどう読むか』を意識してソースコードを書いて。コメントを読まなくても理解できるレベルまで
コードをスマートにできたら最高！」
と上司によく言われますが、その域に至るにはまだまだ時間がかかりそうです。
また、
「最終的に、機能はブラックボックスとして実装するのが理想。使う人がソースを読まなくても、
『これをこう使えばこういう結果が得られる！』という風に使えるのが楽ちんで良いよね！！」
とも言われますが、こっちは更に時間がかかりそうです……
(あと、「Perl 好きの人が書くコードはだいたいおかしい！」と言われるんですが、これは偏見じゃ……)
4) ソフトウェア開発者はモジュール化に命をかける
「モジュールに落としこむ」というのはソフトウェア開発者の至上命題らしいです。
(Haskell-er の皆さんも「モジュール化」に命をかけているようです。前回のsea forum でそのような話を聞きました)
書いたソースコードはその組織にとって資産となります。
資産と言っても、そのソースコードの再利用性が極端に低く、かつ所謂「樹海」の様相を呈していたら、それは
もはや「資産」ではなく「ゴミ」でしょう。
せっかく書いたソースを、資産として有効に運用するためにはやはり可読性が高く(メンテナンスがしやすく)、
再利用性の高い、汎用的な記述によりモジュール化する必要があります。
また、色々な部分で使われているような処理をモジュール化して外部にくくり出してやると、
急遽その部分の仕様が変更になったとしても、モジュール化した部分だけを書き直すだけで変更に対応することが可能です。
ので、モジュール化しゅごい！
(と考えると、やっぱりいずれ関数型言語の時代が本当に来るんじゃ……)
5) できるだけソースは書かない
世界中のどこかの誰かが既に作ってくれている処理・機能は再発明しないで、
その作ってくれたものを持ってきて組み込んでしまおう、という合理的なプログラミングは
学校のプログラミングの授業ではあまり教ええくれないですよね。
でも実際、そうやって開発することがめちゃめちゃ多い気がします。そっちの方が、1から開発するよりも省コストですから。
でも、そういった方法で開発するにはAPI を読まなきゃならないんですよね。
でもって、そういう類のドキュメントはだいたい英語……
うわああああああああああ！！！！！！
という感じで
学校で教えてくれるプログラミングと、現場での職業プログラミングは別物である、
という事をこの半年間で痛烈に学びました。
半年でこうなら、更にあと半年働いたら更に発見がありそうです。
でも、結局社会で使うんだったら学校でこういう事を教えれば良いのに……と思わずにいられません。
と考えると、教育機関のプログラミング教育は少しおかしいんじゃないんでしょうか。
大学の講義よりも、会社でのアルバイトの方が数十倍勉強になるとかどういうことなの……
