| @技術/プログラミング

最近、会社でリーダブルコードを輪読したり、Fukuoka.rb で Eloquent Ruby を読んだりしていて、メソッドや変数名の長さやコメントについての議論を読む機会があった。

昨日、たまたま 37signals のブログを読んでいたら、Rails の作者である David Heinemeier Hansson もこのトピックについて書いていた。

自分は WEB+DB PRESS で ukstudio さんの書いた RSpec についての記事を読んで感化されて以来、ソースコード中のコメントはすべて悪で、はっきりしたメソッド名、変数名を使えばコメントはいらないという考え方を持っている。DHH もそのような考え方のようだ。

要点をかいつまむ。

多くのプログラマーは短い変数名やメソッド名を好む。短い命名は明確性や簡潔性を犠牲にしているとみんな気づいてるんじゃないかと疑ってるんだけど、実際のところ短い命名を採用したコードが多い。特に「一行は80文字まで」教の連中に。

しかし最近のプログラミング言語は表現豊かなのだから、短い命名にこだわる必要は無い。

extension を ext と略してあるのを見かけると嫌気がさす。アプリケーション固有の略語を作るのはもっとひどい。そんなの二ヶ月後には絶対忘れてる。

過剰に明瞭な名前は一見するとバカっぽい。処理内容よりもメソッド名の方が長いとかね。でも一発でやってる内容が分かることの前ではそのバカっぽさは霧消する。

最近の Basecamp のコードにはこんなのがある。

def make_person_an_outside_subscriber_if_all_accesses_revoked
  person.update_attribute(:outside_subscriber, true) if person.reload.accesses.blank?
end

def shift_records_upward_starting_at(position)
  positioned_records.update_all "position = position - 1",
    ["position >= ?", position]
end

def someone_else_just_finished_writing?(document)
  if event = document.current_version_event
    !event.by_current_creator? and event.updated_at > 1.minute.ago
  end
end

もし十分に明確な命名をしているのであれば、コードにコメントを書く必要がない。コメントというものは往々にして不明瞭な命名をしているコードの中で必要になる。コメント付きのコードはやばい臭いを放っていると思っといた方がいい。

コメントはいらない

リーダブルコードの中にも「名前は短いコメントだと思えばいい」というくだりがあるけど、基本的にあの本には「いいコメントを書け」と書いてあるような気がする。コメントそのものを悪いとみなしていない。

先々週読んだ Eloquent Ruby の Chapter 8. Embrace Dynamic Typing の中では Ruby という言語の特性も踏まえ、コメントはいらないと書いてあった。

例えば Ruby ではメソッド名の最後にはてなをつけてあると Boolean を返すという慣習がある。だからコードの中に「○×を判定し true/false を返します」というようなコメントはいらない。

def is_longer_than?(number_of_characters)
  @content.length > number_of_characters
end

Eloquent Ruby は Chapter 1 でもコメントについて述べている。そこには「コメントを書くべき理由があるコードもある」と書いてある。そのコードの使い方を指南したコメントだ。「なぜそのようなコードを書いたのか」、「コード内で用いているアルゴリズムの説明」、「どのようにして高速化したか」というようなことは書くべきではないと言っている。この辺はリーダブルコードと正反対だ。リーダブルコードでは「なぜそのような実装にしたのか」を積極的に書くように奨励されていた。

ちょっと前にはてブでホッテントリに入ってた、ソースコード内のコメントでコードレビューをやるというやり方は最悪だと思う。売り物のコードの中でああでもないこうでもないと議論するなんて狂ってる。コードが修正されたときに議論の内容まで適切に修正されるとは思えない。下手をするとコメントとコードの内容が正反対になってしまうかも知れない。コードの背景についてはコード内に書かず、GitHub 使ってインラインコメントでやった方が良いと思う。

皆さんはどう思いますか?

| @技術/プログラミング

社畜なのでVドメインからMドメインにドメインの管理業者を変更した。そしたらDNSの設定やらなんやらを忘れていて、tech.portalshit.net が死んでた。最近は技術っぽい内容も www.portalshit.net に書いてるしここの存在意義が微妙になってきた。Jekyll、便利ではあるんだけど、rbenv で Ruby のバージョン上げるごとに gem install jekyll gsl とかやるのが若干めんどくさく感じられるようになってきてしまった。ただ記事を書くためだけにそこまでやりたくないかも。

| @技術/プログラミング

RSense という Ruby のプログラムを書いているときに、レシーバの型に応じた補完候補を表示してくれるソフトがあります。Emacs とか Vim と組み合わせて使うと便利らしいです。Java で IDE 使って開発すると補完候補がわさわさ出てきて殆ど鼻くそほじってるだけでプログラミングできるという話を聞いたので、Ruby でも鼻くそほじりながらプログラミングしたいなと思ってこいつを導入してみることにしました。春頃やったときはなかなかうまく Vim から使うことが出来なくて諦めてたんだけど 、つい最近できるようになったのでやり方をメモっておきます。

Mac でのお話です

前提条件ですが、Mac で使ってます。環境は Homebrew で構築してます。また RSense を使うには Java Runtime Environment が必要です。あなたと Java

RSense のインストール

JRE のインストールは済んでいるものとします。Homebre で RSense をインストールしましょう。簡単です。

brew install rsense

インストールが済んだら以下のようなメッセージが表示されると思うので、指示に従いましょう。

If this is your first install, create default config file:
    ruby /usr/local/Cellar/rsense/0.3/libexec/etc/config.rb > ~/.rsense

すると ~/.rsense というファイルが作られ、中身は以下のようになっています。

home = /usr/local/Cellar/rsense/0.3/libexec
load-path = /Users/morygonzalez/.rbenv/versions/1.9.3-p194/lib/ruby/site_ruby/1.9.1:/Users/morygonzalez/.rbenv/versions/1.9.3-p194/lib/ruby/site_ruby/1.9.1/x86_64-darwin11.4.0:/Users/morygonzalez/.rbenv/versions/1.9.3-p194/lib/ruby/site_ruby:/Users/morygonzalez/.rbenv/versions/1.9.3-p194/lib/ruby/vendor_ruby/1.9.1:/Users/morygonzalez/.rbenv/versions/1.9.3-p194/lib/ruby/vendor_ruby/1.9.1/x86_64-darwin11.4.0:/Users/morygonzalez/.rbenv/versions/1.9.3-p194/lib/ruby/vendor_ruby:/Users/morygonzalez/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1:/Users/morygonzalez/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/x86_64-darwin11.4.0
gem-path = /Users/morygonzalez/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1:/Users/morygonzalez/.gem/ruby/1.9.1

rbenv 使ってる人は load-path にちゃんと rbenv のパスが含まれているか確認して下さい。

Vim の設定

このままではまだ RSense がインストールされただけで、Vim から利用することができません。Homebrew で入れた RSense には rsense.vim がついてくるので、こいつを Vim の plugin ディレクトリにコピーします。

cp /usr/local/Cellar/rsense/0.3/libexec/etc/rsense.vim ~/.vim/plugin/

次に .vimrc で rsenseHome を指定しなければなりません。

let g:rsenseHome = "RSense home"

と書きます。僕はこの rsenseHome が分からなくてハマりました。先ほどの config.rb を実行したときに生成された ~/.rsense に書いてある home をここに指定します。なので rsenseHome は /usr/local/Cellar/rsense/0.3/libexec です。

ここまで済んだところで Vim から RSense が認識されているか確かめます。適当に Vim を起動して :se ft=ruby とし、:RSenseVersion とコマンドを打ってみます。ここで RSense 0.3 のように成功されたら設定完了です。filetype が ruby になっているファイルで 1. と打った後、補完候補を呼び出すコマンド(^X ^U)で候補を呼び出せます。以下のような感じ。

8da56d016a74ebc9d38afcf593bfeadd.png (200×116)

“ネオコン” と連携させましょう

さらに言うと、たいていの Vim ユーザーの皆さんは neocomplcache も使ってるでしょうから、neocomplcache と RSense を連携させましょう。ネオコン作者の Shougo さんのブログ記事を参考にして下さい。

以上で完了です。これで Vim で Ruby な皆さんも鼻くそほじりながらプログラミングできますね。

| @労働

9月1日からシニアエンジニアを拝命しました。シニアエンジニアには 30days/Sqale の刺身☆ブーメランさんやインフラエンジニアの @lamanotrama さんなんかがいて、自分のような職業エンジニア歴の短い人間が同じ肩書きで仕事して良いのかと不安もあるんですけど、技術責任者の mizzy さんには業務内容の他、 Lokka のプラグイン作ったりバグを見つけて pull request 送ったりしてたことを評価して頂き、晴れてシニアエンジニアとなることができました。

ちなみに選考は刺身さんが書いてる前回の様子(シニアエンジニアになりました - 刺身☆ブーメランのブログ / @kyanny’s blog)からさらにラディカルになっていて、応募(pull request で行います)からレビュー、結果の発表まで GitHub のプライベートリポジトリで行われました。ジットハブ、本当に便利ですね。

シニアエンジニアの名前に恥じないよう、多くの人に喜んでもらえるサービスを提供するとともに、「所詮ペパボ」とか言われないよう、技術力を高めていきたいと思います。

| @技術/プログラミング

今年の3月くらいから、寿限無の和田さんが発起人になって Fukuoka.rb という勉強会をやってる。毎週木曜の 19:30 からで、ペ社は会場を提供している。勉強会と言ってもやってることは技術書の輪読で、最初は『メタプログラミング Ruby』を読んだ。メタプログラミング Ruby は中級者以上向けの本でなかなかレベルが高く、当初は 30人ちかくいた参加者が回を重ねるごとに減っていき、最後は5, 6人くらいしか参加者がいなかったけれども、歯を食いしばって出席し続けた。簡潔に書ける、美しいコードが書ける、という以上のことができる Ruby の側面を学んだと思う。いまは二冊目の課題図書として洋書の『Eloquent Ruby』を読んでいる。

福岡でやってる Ruby の勉強会、何回か出たことあるけど、Rails ハンズオンみたいな初心者向けの内容だったり技術より精神面を重視した内容だったりで個人的には消化不良な感じがあった。また開催が不定期で、プログラマ同士の情報交換がしにくいと感じていた。

Fukuoka.rb は原則的に毎週開催で、扱う内容も初心者よりというよりは中上級者向けで、本を読みながら喧々諤々とした議論も繰り広げられるし、自分はあまり参加しないのだけど勉強会の後はみんなで飲みに行ったりもする。業務で感じていた疑問を詳しい人に尋ねたり情報交換しやすい。

個人的には、中学生の頃に通っていた隣町の塾を思い出す。自分は田舎に住んでいたので、都会の塾に行くだけでレベルの高さに驚くとともに刺激を受けて、都会っ子に追いつこうと勉強を頑張った。Fukuoka.rb は参加者のレベルが高く、なかなかついて行くのが大変なのだけど、確実に Ruby 力が高まっていると思うし、出てて良かったと感じる。

Asakusa.rb や Yokohama.rb のような Ruby コミュニティをずっとうらやましく思っていたけど、これらに近い Ruby コミュニティが福岡にできつつあると思う。時々は Ruby コミッターの @nagachika さんも参加している。福岡在住の Ruby プログラマで腕に覚えがある人は、是非毎週木曜日に天神プライムビル8階で開催されている Fukuoka.rb にお越しください。面白くしていきましょう。

| @労働

福岡配属になった新卒氏が自分のチームに配属されたのでペアプログラミングをやってた。一応 OJT なんだけど、東京で @hsbt さんと @antipop さんによるブートキャンプを経験してきた新卒氏に「request spec を書く前に view を書くな、ハゲ」と自分の方が叱咤されたりしてこちらも良い勉強になった。

新卒氏に便利な UNIX コマンドを教えたり、rbenv の利用方法を教えたりしながら、自分で言うのもなんだけど、俺やシニアエンジニアの @linyows 氏が独学で覚えたことを口頭で教えてもらえてすごくラッキーだよなー、と思ってしまった。TDD とペアプログラミングで OJT なんてすごいと思う。特に福岡では。

訳の分からない SI 会社に入ってしまった若者は、コードを書きたいのに詳細設計書(実はなにも詳細に設計されてない、どうせコードを書く段になって仕様は変わるし設計通りに作るなんて無理だから)を方眼の Excel ドキュメントに延々書いたりとか、訳の分からないミーティングに出席させられて延々議事録を取ったりとかしてる。SI 会社の連中は FizzBuzz 問題も本当にこんな感じに「解く」。もしSIerのマネージャがFizzBuzz問題を解いたら - GeekFactory

仕事のことをブログに書くと毎回同じ結びになってしまってる気がするけど、クソみたいな SI 会社でつまんない仕事してる人は思い切って会社変えれば良いと思う。

| @労働

hsbt さんが会社に入ってから大きく雰囲気変わった。hsbt さんは並の寿司を上にぎりとかにランクアップするパワーがあると思う。IRC とか Ustream ごしにその存在感を感じる。こういう人がメンターだなんて今年ペ社に入った新卒エンジニアはとてつもなくラッキーだったと思う。世の中には訳のわからない Java の研修を延々受けさせられてる新卒 SE さんもいるのに、ペ社の新卒エンジニアは WEB+DB PRESS に寄稿するような人から最新シャレオツ Rails 開発事情をたたき込まれたのだ。下手をすると中途で入って実サービスに投入されてる経歴不詳の怪しい30過ぎのおっさんよりも良いコーディングマナーを身につけているかもしれない。新卒エンジニア氏一名が自分の部署に配属されることになったので、来月自分は戦力外通告を受けて気がついたらハローワークに日参しているかもしれない。

なんか hsbt さんばかり持ち上げてしまったけど antipop さんも Webistrano をさくっと Rails 3.2.5 で動くようにしたりとかすごい。技術力ある人は技術力に比例して行動力が高い気がする。やらなきゃと思ったこと、読まなきゃと思った技術書を一晩とかでさくっと実装・読破してしまう。そういうところが並のエンジニアと大きく異なる点だと思う。