ゼロからの技術ブログ

初学者がゼロの状態から理解するまでの軌跡を書いていくブログ

プログラミングの作法

プログラミンを始めた頃はとにかく書きまくって処理が通ればいいやという感覚で書いていた。というか仕事で使わない個人のコードとかは見栄えよりかは、書いている事自体が楽しかったので保守性とかCPUの使用率とか全く気にしていなかった。特にテストコードなんてザラで書いて実行!あー!失敗!イェイ!なんて事は日常茶飯事。




しかし仕事で使うコードは守るべき暗黙ルールがいくつかある。何故か。それは皆んなが見て、理解し、限られたリソースの中で運用しなければならないからである。保守性、可読性は勿論のこと、いかに速く少ないメモリ、CPUで動くコードを書く事も重要だ。


未経験でこのWeb業界に入りサーバエンジニアとして働いているが、プログラミングの作法自体については全く触れてこなかった。そろそろヤバいと思っていた時に、会社の先輩に下の本を紹介してもらった。少し昔の本だけどこの「Joelシリーズ」の本は多く出版されており、人気の本らしい。

技術系の本は辞書みたいなのが多く、読んでいて疲れる本が多い(という印象)。しかし上記の本は事実だけを並べる技術本とは違い、英語のジョークを交えた文体になっているので非常に読みやすく、初学者にとって易しい一冊だろう。この本は現場のプログラマーに向けた本ではなく、どちらかというとマネージャークラスに宛てた本だ。しかし、プログラマーにも参考になる事は多く、必要でなければマネージャーに向けた部分を流し読みすると早く消化できるのでオススメだ。

いいプログラマーになる為にはどうしたらいいのか

プログラミングを勉強してると、DRY(Don’t Repeat Yourself)なコードを書けとか、保守性、可読性の高いコードを意識してかけとか一番短いコードの書き方を採用しろとかそう言われる事は多い。Joelももちろんそういった事を本書では言及しているけど、この本はどちらかというと「プログラマーはどう言った心構えを持つべきなのか」という視点で語られる事が多い。

Joelはいいプログラマーになるためにはどうしてらいいか?という問いに対して下記のテストを推奨している。

ソース管理システムを使ってる?
自動でビルド出来る?
デイリービルドしてる?
バグのデータベースがある?
新しいコードを書く前にバグを修正してる?
共有してるスケジュールはある?
仕様書書いてる?
プログラマは静かな環境で仕事している?
一番いい開発ツールを使ってる?
テスト担当者はいる?
プログラマを採用するときにコードを書かせてる?
「廊下でのランダムテスト」をしてる?

多くは「いいプロジェクトチームはどういうチームか?」という視点だけどプログラマーに取ってもいいヒントがたくさんある。

新しいコードを書く前にバグを修正してる?

プログラムを書いているとバグがバグを呼びさらにまた別のバグを呼び…なんて事よくあると思う。誰だよこんな直し方したのとか思うのはいいけど、なんでこの想定が出来なかったの?というのは結構ある。既存のコードを改修する前に影響範囲を調査すると思うけど、その時に見つけたバグはまずそのバグを直してから改修しようというJoelの提案だ。
さらにJoelおじさんはそもそもバグなんて物は無くならないよ、と提言している。ぜひSI業界に伝えたい金言だ。考えてみれば当たり前なんだけど、人間の作るものに完璧な物なんてない。今世の中に溢れてるフレームワークやOSだってバグだらけなのに、その上で成り立つアプリなんて当然バグが入り込んでもおかしくない。しかしバグの入り込む余地を少なくする事は出来るよね、とJoelはいう。そういう意味で見つけたバグは即座に直しちまおうぜ、という心意気はプログラマーにとっては大切だよね!


仕様書書いてる?

プログラマーにとっては仕様書を書く事は圧倒的に退屈だし、読む人にとっても退屈だし一体誰の為なんだと思う事があるよね。だけど仕様書がないとは新規の人が理解できないし、会社としてもプログラマーの時間節約の一つとしての財産として必要だろう。
そこでJoelはどうせ書くなら「面白く書け」と本書で提案していた。
例えば下の様な文書があったとしよう。

ユーザはCtrl+Nをタイプして新しいEmployeeテーブルを作成し、従業員の名前を入力する。

ごくありふれた機能仕様書だと思うが、面白くもないし、つまらない。そこで下の様に書き直したとしよう。

ピギー嬢は、彼女のまるまるした小さな指は太すぎて個々のキーが押せなかったので、アイライナー・スティックを使ってキーボードを突っつき、
Ctrl+Nとタイプして新しいBoyfriendテーブルを作成し、レコード"Kermit"を1件だけ入力した。

さすがアメリカである。日本にはないユーモアさがある。でも日本のお役所みたいな仕事環境でそんな事通用しないよ、といったツッコミも予想してJoelは下記の様な回答をしている。

それと、もしおかしくすると専門的でなくなってしまうと思っているなら、ごめんなさい、それはあなたがユーモアのセンスを持ってないだけのことだ。 (否定しないで。ユーモアのセンスのない人たちはみんなそれを否定する。私は騙せませんよ。) そしてもしあなたが、陽気でおかしく読んでいて楽しい仕様書を書くと軽蔑されるような会社で働いているのなら、別な働き場所を探すことだ。人生はそんないかめしく惨めな場所で日中を過ごすには短かすぎる。

つまり、ユーモアも認められない会社なんてプログラマーはいるべきではないという事だ。これは至極当然な事で、プログラマーはもっとイノベーションを起こして面白い事を考え続けるべきだと私は思っている。日本的に書くと下の様な感じになるのかな。

プレミアムフライデーなんて糞食らえと思っている上司の田中はITセンスの欠けらも持ち合わせていないので、部下の小泉くんにCtrlボタンはどこかね、と尋ねた。
何回かの質問のラリーを終えたこの糞上司は軽快なタイピングでCtrlとNキーを同時に押して新しいGomi-Bukaというテーブルを作成し、レコード"Koizumi"を一件追加した。

Joelのアドバイスによると物事はより具体的にした方がよりユーモアになるという。「ユーザ」より「ピギー嬢」の方が滑稽だし、「Employee」より「Boyfriend」の方がユーモアが溢れている。確かに言われてみればそうなので、助言通りにしてみたらやたら長くなってしまった。


プログラマーがすべきでない事

プログラマーというのはどうしても「最初から書きたがる」。当然だと思うけどプログラマーは1から書く事が楽しい。バグを直す事で得られる喜びなんてちっぽけなもんだ。それなら今までのバグを想定したもっとわかりやすいコードを書けばいいじゃないかと思ってくる。
しかしJoelは、1から丁寧に作り始めたとしたらそれは一体いつになる?作り終えた時に新しい技術が出てきたらまた書き直すの?と問いただしている。
さらにプログラマーは目の前にあるコードは「バグが直されたコード」である事を忘れがちだという。バグが直されたという事は初期段階には予見されていないバグがあったって事だ。それを全部考えると時間ていくらあっても足りなくない?古いコードは「テスト」もされているし、「修正」されているし、現に「使われて」いる。これを頭に叩き込んでいかなきゃならない。




順次まとめていきます。