久しぶりです。最近落ち着いてきのこ本を読める時間が取れなかったので、少し間が空いてしまいました。今後もこういうことがあるとは思いますが、着実に読み進めたいと思います。
16 コメントについてのコメント (カル・エヴァンス, Cal Evans)
コメントは重要ですね。
コメントがあると、理解の助けになることもよくあります。余り多いと逆に理解の妨げになることもよくありますが、適切に挿入されたコメントは一瞬では何を意図して書かれたかわからないコードをすぐに理解できる手助けになります。
このエッセイの著者いわく、ヘッダコメントには「プログラマがコード本体を全く読まなくても利用することはできる」くらいの情報、インラインコメントには、自分の次にコードを見て修正や拡張をする人の助けとなるような情報を入れるようにと書いています。確かにこのような方向性でコメントを書くというのはいいかもしれませんね。
私も去年くらいからjavadocなどのAPIドキュメント生成ツールを使ったりするようになりましたが、その前から特に全体量の多いコードの場合やアルゴリズム的に理解しにくいコードには適宜コメントを書くようにしていました。
javadocなどを利用するときの利点は、ツールを使ってAPIドキュメントが生成できるのももちろん利点なのですが、コメントの書き方が統一出来るのも利点かと思います。
ただ、javadocなどのコメントでは動作結果のみで、実際に何をするコードなのかしっかり書かれていないコメントも多いようなので、動作をしっかり要約したコメントを書くようにするということを心がけるべきかもしれません。そういう私も気をつけなければなりませんね。
17 コードに書けないことのみをコメントにする (ケブリン・ヘニー, Kevlin Henny)
コードに書けないことのみをコメントにする、ですか。
確かにコードを読めばわかるようなことをなぞってコメントしていても無駄に行数が増えたりしてコード自体は理解しにくくなりますね。
懐かしいものとしては
// nullを返す return null;
みたいなものでしょうか。この1行くらいだと可愛いもので済みそうですが、これが至る所にあるとさすがに苦労しそうですよね。
このエッセイでは、コードでどうしても書けないようなことをコメントに書くと書いていますが、私はもう少し制限を緩めるべきかと思います。
例えば、名前や内部動作のリファクタリングがかけられてしまって、コードだけではコードの意図が理解できなくなるようなことも想定されます。そういうときにコメントを書いてないと、どういう意図のコードだったか分かりにくくなりやすいのではないかと思います。
また、確かに慣れている人にはコメントがほとんどないコードでも理解できるかもしれませんが、あまり慣れていない人に名前や単一責任が適切になされているからと言って、コメントのないコードを見せられても理解できないのではないかと思います。
方向性としては、確かにコード自体がある程度コメントなしでも読めるようになっていることは望ましいと思います。そして、ムリに簡単に読めるようになっているコードにコメントをつけることは避けるべきだと思います。
18 学び続ける姿勢 (クリント・シャンク, Clint Shank)
タイトルはプログラマだけでない様々な分野に通じそうな言葉ですが、特にプログラマの人たちに向けてどのようにするべきか書かれていますね。
私はこのエッセイに書かれていることの半分くらいはできているでしょうか。
・書籍や雑誌、ブログ等を読む。
これは色々やっています。Twitterもそうですし、本も読むようにしています。興味のある分野についてのことが書かれているブログやWebページは色々読んだりしています。
・本当に身につけたい技術は、コードを自ら書き、手を動かして学ぶ。
最近、あまり長いコードが書けるほどの時間が取れずに実践できているとはいえないかもしれませんね。ただ、少しでもコードを書けるように新しく学んだことはちょっとしたコードにしたりはしてます。このブログの記事としても載せたりしているような小さなコードですが。
・常に自分よりレベルの高い人と仕事をする。
仕事してないので何とも言えませんが、近くにいる ( 情報専攻の大学院生の ) 友人と話をしたり、ごくたまにですがペアプログラミングをやったりもします。
・自分の「良き師」になりえる人をネット上で探す。
Twitter上には多すぎて困りますね。
・自分の利用しているフレームワークやライブラリに対する知識を深める。
なかなかこの辺りを深く見たことはないですね。少しだけLinuxカーネルを見たりしたことはなくはないですが、それでも知識を深めると言うほど見たことはないので、今度そういうことにもまた挑戦してみようかなと思います。
・何かミスをした時、バグを修正したりシステムに問題を発見したときに解決するだけでなく、バグや問題について深く理解する。
「なぜ」の部分はある程度追うようにしています。物理学を勉強するものの性でしょうか。
・自分が学びたいことを人に教えたり話したりする。
ちょうどよく一昨日、勉強会を開いてそういうことをしてたり…。ブログも自分の学習記録と同時にこの教えるという部分を兼ねて書いています。
・自分が興味を持っている言語、技術、分野に関する勉強会を自ら立ち上げるか、地元のユーザグループなどがあればそれに参加する。
そろそろ勉強会を自分も開催しようと思っています。C++やRubyについては今学んでいる最中で、この辺のことについての勉強会が開催できればと思っています。またTDDについては、id:cubeonさんが開催してくださっているTDDPC佐賀に参加中ですね。
・カンファレンスに積極的に参加する。
これはできてないかも…。勉強会までは参加するのですが、カンファレンスというものには参加したことないですね。
・通勤時間が長い場合は、ポッドキャスティングを利用して学ぶ。
通勤時間が長くない、iPodなどの携帯プレーヤーを持ってない。
・自分のコードベースに対して静的分析ツールを実行する。
しているような、していないような。しっかりやれてはいないので、やらないといけない部分は多いです。
・『達人プログラマー』を読み、学んだことを実践してみる。
来ました。まさにやってません。読もうとは思っているので、今年の余裕があるとき ( 夏あたり？ ) には読みたいですね。
・新しく学ぶのは、必ずしもコンピュータ関連技術でなくてもかまわない。
ははは、専門が物理なので物理で許して。
・学校に通う。
物理専攻ですが何か。
最後に
16、17のエッセイはコメントについて、18はプログラマとしての学び続ける姿勢についてでした。
コメントはどうしてもコーディングに慣れれば慣れるほど忘れていきがちな感じがします。コメントを書くということ、人が読むということを意識しなければなりませんね。
学び続ける姿勢は意外と自分も実践できている部分がなくはないみたいで良かったです。
