vimdiffで単語単位の差分表示: diffchar.vimが超便利

今日もプログラミングや文書作成にvimを巧みに操り続ける全国のvimmerの皆様におかれましては、vimを利用した差分表示であるvimdiffは欠かせないツールであることと思います。

当方も今までvimdiffについては色を見やすくしたり差分計算アルゴリズムを賢くしたりと、カスタマイズによって使い勝手を向上させてきましたが、唯一実現できていなかったのが、「単語単位の差分表示」なのであります。

しかしついに、vimdiffで単語単位の差分を表示できるようにするvimプラグイン「diffchar.vim」を先日見つけました。最初の公開が今年5月という新しいプラグインです。
diffchar.vim - Highlight the exact differences, based on characters and words : vim online

ということで、早速インストール。このプラグインはGithubにもミラーされており、すでにNeoBundleをお使いであれば導入はとっても簡単で次の一行を.vimrcに追加して ":NeoBundleInstall" するだけです。それ以外の場合については省略。

NeoBundle 'vim-scripts/diffchar.vim'

実際サンプルで試してみましょう。まず、vimdiffで差分を表示させると、次のようになりますね。

一つの行に複数箇所の変更が含まれる場合も、最初の変更から最後の変更までを含むような大きな１つの変更として認識されてしまっています。

しかしここで<F7>キーを押すと！

うおおおおぉ！すばらしい。単語単位の差分を表示できました。一行に複数の変更があってもちゃんと認識して表示。しかも、追加部分と変更部分で色分けもされています。

ちなみに、再度<F7>キーを押すと元に戻ります。なお、<F7>キーは文書全体について単語単位の差分表示を切り替えますが、<F8>キーを押すと現在の行のみ単語単位の差分表示を切り替えることができます。

これだけでも便利ですが、欲を言えば、vimdiffコマンド実行時やgit diftoolにvimdiffを使っている時に、いちいち<F7>を押すのは面倒。そんな時には、

" vimdiffで起動した際自動的に単語単位の差分(diffchar.vim)を有効にする
if &diff
  augroup enable_diffchar
    autocmd!
    autocmd VimEnter * execute "%SDChar"
  augroup END
endif

と.vimrcに書いておけばOK。vimdiffコマンドで起動した時には自動的に単語単位の差分が有効になります。（この場合、単語単位の差分をOFFにしたければ<F7>キーを押す、という使い方になります。）

これでvimdiffで差分をチェックする作業が一層はかどりますね。

※補足：autocmdのイベントはFilterWritePost、BufReadPost 、BufWinEnterなども試しましたが、FilterWritePostでは効果がなく、BufReadPostやBufWinEnterだとどうやらdiff表示途中に実行されてしまうらしく余計な箇所まで単語単位で差分表示しようとしてしまい表示が崩れます。VimEnterを指定したら期待した動作になりました。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プログラミングにおける「コメント」を軽視してないか

「他人が書いたプログラムの解読」は、ソフトウェアエンジニアにとってもっとも厄介な仕事の一つでありながら、必ず求められる作業です。

他人が書いたプログラムとの格闘戦は、ソフトウェアエンジニアの方なら経験がおありだと思います。もしかしたらそれが日常かもしれません。

逆にプログラムを白紙の状態から書いていく機会というのは、新規のソフトウェア製品や新規サービスの開発に初期メンバーとして参画するといったものがあります。しかしソフトウェアエンジニアの仕事としては、それよりも既存の製品や既存のサービスに機能を追加したり不具合を修正するなど、すでに存在するプログラムに手を加える機会も多いです。むしろこちらの方が多いかもしれません。だから、すでに存在する他人が書いたプログラムを解読する必要が出てくるわけですね。

そもそも、なぜ他人が書いたプログラムの解読が難しいのかといえば、プログラムに書かれる情報はあくまでプログラム上の処理の流れを記述してあるのであって、その処理の目的や背景、その処理を行う理由といった、いわば"プログラムの文脈"に関する情報は含まないからです。

だから、プログラムの処理自体が完全に理解できたとしても、それがどういう目的で何を達成するための処理なのか、全体の中で果たす役割は何なのかさっぱり分からない、という事態もありえます。

そこで大きな役割を果たすのが、ソースコードに挿入するコメントであると考えます。コメントが書いてあることによって、"プログラムの文脈"に関する情報を得ることができれば、プログラムへの理解は飛躍的に速くなります。

一方、プログラミングにおいて、コメントは極力少なくすべきであるという主張もあります。「関数やメソッドを十分小さい単位に分離し、適切に名前をつければ、その関数やメソッドが果たす役割は名前によって十分表現できる。構造化を適切に行えば、コメントを書く必要はない。コメントは最後の手段だ」という考え方ですね。

しかし、それでもコメントを書かない理由にはならないと思います。構造化と命名の工夫によってプログラムが理解しやすくなるのは確かです。しかし、それはプログラムの処理自体が分かりやすくなるだけであって、その処理の目的や背景、その処理を行う理由といった"プログラムの文脈"に関する情報が含まれないことには変わりありません。

つまり、ソースコードをコメントに書いておかなければ、プログラムを理解するのに極めて困難を要する場合が多々あるのだから、ソースコードには適切にコメントを書くべきであって、コメントを極力少なくする方針には賛同できない、ということです。

そして、どこにどのようなコメントを入れるか、というところに、ソフトウェアエンジニアとしてのセンスが現れると思っています。

実際、絶妙な場所に適切なコメントが入っているソースコードは、プログラムの解読が大変行いやすく、メンテナンスも容易で、大変ありがたいプログラムです。多少プログラム自体が上手く書けていなくても、そのソースコードをもとに作業する人間としてはコメントが適切に入っている方が速く理解できたりするのです。

エンジニアの美学としては、コメントが無くて、プログラムのみのソースコードを扱うほうがカッコいいのかもしれませんが。そこは格好よりも実利を尊重すべきだと思うんですよね。

というわけで、ソースコードに適切なコメントを書くことを決して軽視してはいけないし、コメントは最後の手段なんかではない、と言いたいのです。

「なるほど」と思ったら
↓このリンクをクリックを。


※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

gitコミットとRedmineチケットは１対１にする

ソフトウェア開発のプロジェクトでgit(あるいはSubversion)を使っていない方が珍しいと思います。と同時に、極めてよく使われるツールがRedmineなどのプロジェクト管理ツールですね。

昔はバグトラッキングシステム（BTS）と呼ばれていましたが、バグの管理はもちろんのこと、プロジェクトのタスク管理につかうシステムとしても非常に優れており、広く使われるようになったことから最近では "プロジェクト管理ソフトウェア" などと呼ばれているようです。BTSに変わる決まった呼び方があるのかどうかはよく知りません。

ともあれ、git と redmine を連携させて使っているプロジェクトも多いことでしょう。Redmine 上のプロジェクトには git のリポジトリを関連付けることができ、gitのコミットメッセージにチケット番号を特定の書式で書くと、自動的にRedmine上のチケットとgitのコミットが関連付けされます。チケットの表示画面にgitコミットの概要とリンクが表示され、またコミットの表示画面ではチケットへのリンクが表示されます。これは後からソースコードの変更を確認したいときに、タスクの記録と一緒に追うことができて大変便利です。

ところで、１つのチケットに複数のコミットを関連付けることもできます。また逆に１つのコミットに複数のチケットを関連付けることもできます。ただし、僕の意見としては、極力チケットとコミットを１対１に対応させると、後から過去の変更を調べる際にすごく楽になります。（当然完全には無理でしょうから、出来る限りということです。）

例えば、１つのコミットに複数のチケットに関する変更を入れてしまうと、それらの変更がそれぞれどのチケットに関するものか判別するのは、変更した本人でない限り結構手間がかかるものです。あるいは、１つのチケットの解決に要した変更が複数のコミットにまたがっていると、これまたどんな変更がそのチケットに関連してなされたのかの結論を確認するのに骨が折れます。

だから、チケットとコミットを１対１に対応させるのがよいのです。もちろん、自分の手元でコミットを１回きりで済ませるのは大変だと思いますので、例えばローカル専用ブランチを作ってそこにコミットし、１つのチケットの分がまとまったら提出用ブランチにmerge --squash でまとめるといった方法をとればよいと思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

既存の他人のコードは書き直したくても我慢する

以前から続いているプロジェクトに自分が新しく入った時とか、オープンソースで公開されているソースコードに追加・修正を加える時か、他人の書いた既存のコードを見ていると、ついつい全て書き直したい衝動に駆られたりします。

しかし、既存のコードを書き直すのは得策ではないです。以前そのコードは製品リリースの段階でテストされており、機能が正常に動作することは確認済みだったりするからです。下手にいじることはむしろ余計なバグを産むことになりかねません。

だから可能な限りもとのコードを尊重するのです。いじらなくてすむ部分はいじらない。シンプルです。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

既存のプログラムの修正時には「郷に従え」

他人が作ったプログラムに手を加える時とか、オープンソースで公開されているプログラムを利用する際に一部改変する時とか、既存のプログラムを修正する機会はIT系エンジニアには日常的な仕事の一部であると思います。

新規でソースコードをイチから書いていける場合と違い、既存のソースコードに追加・修正を加える際に意識すべきことは、「郷に入っては郷に従え」ということです。

同じ動作をするプログラムの書き方は無数にあります。単に望み通りの動作をさせたいだけだったら、既存のソースコードをほとんど無視して書くことも出来てしまいます。

でも、それをやってはいけません。既に書かれたコードにおいては、プログラム全体への影響が考慮されているものがほとんどであり、他の部分との整合性がとれています。だから、何かの機能を追加したり修正する場合には、既存のコードを出来る限り利用すべきです。これは無駄なバグの発生を防ぐ事にもなります。

他にも、変数の命名規則やインデントの体裁なども含めて、既存のコードに沿って追加や修正を行うべきです。そうすることでコードが読みやすくなり、バグも発見しやすくなります。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

ソースコードのコメントは「省力化」のために入れる

プログラミングにおけるソースコードに書くコメントについて、他のエンジニアと話す機会が最近あって、その方は「コメントは最後の手段」と言っていました。

要するにその方によれば、例えば関数やメソッドの名前・引数の名前などでコード自体が機能を説明するようにすべきであり、コメントに説明を書くのは最後の手段であると。

確かに、コード自体が機能を説明していることは重要です。関数やメソッドの名前・引数の名前は読めば何を意図しているのか分かるようにすべきであり、そのためなら多少名前が長くなっても構わないと思います。一つの関数やメソッドが長くなり過ぎたり条件分岐や繰り返しといった制御構造のネストが深くなり過ぎないように、適切に分割していくべきです。

それは確かなのです。しかし、どうしても「ソースコード自体が機能を説明する」ことには限度があります。その目的や意図や、動作の詳細を説明しきれない場合は結構多いのです。

もう１つ、ソースコード自体を細かい関数やメソッドに分割した場合、もし意図がわからなければ、結局次々と呼び出し元の関数やメソッドを追っていかなければいけません。これも実際に結構な労力です。

本当に何をしているか理解するには、やはり最後はソースコードを追っかけるしか無くて、関数やメソッドの名前・引数の名前だけで何をしているか説明できるというのは無理があると思っています。それは自分自身が書いたソースコードならばともかく、他人の書いたソースコードになれば、もはや不可能です。

ソースコードを追っかける際に一番難しいのは、やはりどういう意図と目的を持って書かれているかということで、そこはコメントに書いてあるのとないのとでは理解のスピードに雲泥の差が生じます。

Web上にあるプログラミング言語のリファレンスマニュアルを思い出してみると、関数やメソッドの引数の想定する型や説明、及び返り値のとりうる型や説明、そして関数が行う処理の説明が意図と目的が分かるように書いてあります。だから、例えばRubyやPHPの関数やメソッドを、その元となるC言語のソースコードを全く知らなくても使えます。ちょっと強引な例ですが、十分に詳細な説明があれば、その先のソースコードは追っかけなくてもよくすることができる、ということです。

もちろん、プログラミング言語のリファレンスマニュアル並みの詳細度を全てのプログラミングのソースコードのコメントに求めていたら、ソースコードを書く側が余りにも大変になってしまいますが、コメントがきちんと書いてあることによって、ソースコードの理解は格段に速く楽になることは間違いありません。結局ソースコードを追っかけることになったにしても理解度とスピードが全然違うでしょう。

書いたら捨てる使い捨てのコードならばともかく、後々のメンテナンスを自分や他人が行うことになるコードなのであれば、コメントを上手く入れることが非常に重要であり、特にライブラリ的に多数の箇所から参照される関数やメソッドの先頭には、引数の想定する型や説明、及び返り値のとりうる型や説明、そして処理の意図と目的が分かるようにコメント入れるべきである、というのが僕の意見です。それは後々の「省力化」になるのです。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プログラミングにも「作曲」と「編曲」がある

プログラミングというのは、最初にロジックを考える部分と、実際のコードにしてからより良く動作するように改善を加えるリファクタリングの部分があります。これはいわば、音楽でいうところの「作曲」と「編曲」みたいなもんじゃないかと思います。

音楽が編曲によって化けることがあるように、プログラミングもロジックがイマイチでも、よくリファクタリングされ磨き上げたコードはバグもなく十分良い動作をしたりします。

音楽の場合は作曲者と編曲者が別々であることはよくありますが、プログラミングの場合はロジックを考える人とリファクタリングを行う人が分かれておらず、ほとんどの場合で同一人物が行います。なので、うまく頭を切り替えて、両方を意識しながら作業することが大切です。

ロジックを最初に思いついた方法で実装しただけで終わりにしまう人が多いですが、そこからのアレンジも大切なんですよね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

動的型付けを「複数の型を持てる」と考える

PHPやRubyなど、動的型付けをもつ言語を僕も普段から使っています。ただ、動的型付けに対しても、僕は明確に変数の型を意識します。

そもそも、動的型付けに対して、「型を意識しなくてよくなる」と考えるのは間違っていると思っています。そうではなく、「一つの変数が複数の型を持てる」と考えるべきかと。

例えばPHPだと、ある関数の返り値は場合によって整数かもしれないし文字列かもしれません。失敗時にはfalseだったりします。その関数の返り値を変数に代入すると、この変数は整数かもしれないし文字列かもしれないし真偽値であるかもしれません。しかしこの特徴によって、ソースコード記述の柔軟性を上げることが出来るのですね。

ただ、やはり変数を取り扱う上で、変数の型を意識しないと思わぬバグを産んだりします。だから、「型を意識しなくてよくなる」のではなく、「一つの変数が複数の型を持てる」と考えるべきなのです。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

開発における "あと一歩" の追求

例えば、UIの配置やプログラミングのパターンを、あと１つだけ多く試してみるとか。手間としては、それほど多くなるわけではないでしょうが、これをやるかやらないかの違いは大きいと思います。

時間との兼ね合いもありますけれども、特にソフトウェアにおいてはちょっとした違いが積み重って全体の印象を決めています。むしろ地味な違いほど効たりします。

だから、ソフトウェア開発において、"あと一歩" の追求は時間に切羽詰まっていない限りは重視したいと思うのです。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

UI設計では素朴な感覚を大切にする

ソフトウェア開発におけるUI設計は、経験や理論も影響してくるものではありますが、それより大切だと思っていることは「素朴な感覚」です。

まっさらな気持ちで、初めてそのソフトウェアを触った人のような気持ちになって操作し、何を感じるか。そこで「使いやすい」と感じられるか。何か足りないと思うことはあるか。多すぎると思うことはあるか。変えたほうが良いと思うことがあるか。などなど・・・。そこでかすかに感じるわずかな違和感に気づくことが何よりも重要です。

確かにプログラミングには経験や理論もファクターとして大いに絡んできます。しかし、そのプログラミングを通して作り上げ、最終的にユーザとの接点になるUIにおいては、何も知らない人間の感覚になる必要があります。

こういった感覚の切り替えもソフトウェア開発の面白いところですね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

git diffって多用するよね

git diffは非常によく使うコマンドの１つで、僕の仕事のクオリティを支えてくれているツールでもあります。また、difftoolにvimdiffを用いたgit difftoolも同じくらいよく使います。

僕はかなりこまめにgit diffを使います。プログラミングをしていると、ちょっと書いたらgit diffで差分を見て、動作確認し、またちょっと書く、みたいな感じです。差分を確認せずに一気に書くことはほとんどないです。

あとコミット前にはインデックスとHEADの差分をgit diffとgit difftoolの両方で確認します。ここで原則として差分については全て余すところなく確認します。

あと、ローカルブランチのコミットをgit merge --squashでまとめて提出用ブランチにした際も、提出用ブランチの直前との差分を確認しますが、この際はざっと目を通す感じですね。

こんな感じです。実に利用シーンは多いです。ちなみに差分アルゴリズムはhistogramがおすすめです。difftoolにvimdiffを用いる場合に、差分作成アルゴリズムを変更する方法については過去の記事を参照。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プログラミングは "新規" と "追加・修正" で全く異なる

最近思うんですが、プログラミングっていうのは、それが「新規」つまり「そのプロジェクトに関しての過去のコードが全く存在しない状態からコーディングする」のと、「追加・修正」つまり「そのプロジェクトに関して既にコードが存在し、それに対して追加あるいは修正を加える」のとでは、全く異なったものになりますね。もう少し詳細に言うならば、「追加・修正」の中でも、たとえプロジェクトに関しての過去のコードがあったとしても、実装しようとしている機能が他の機能から比較的独立しており、かつ、そこに関する部分のコードがまだ存在しない場合、「新規」に近いとみなすことができます。

さて、「新規」の場合、ソースコードの配置（どのファイルにどういった内容をコーディングするのか）、論理構成（どんなクラス・メソッドを作成してどのような役割を分担させるか、あるいはクラス・メソッドが既に用意されているフレームワークの選定）など、自分で骨組みを考えていきます。また、細かい話で言えば、クラス・メソッド・変数などの命名規則、空白や括弧のコーディングスタイルなども自分で決めていくわけです。

一方、「追加・修正」の場合は、上記で書いたようなことは（中途半端な状態で引き継いだのでない限り）元から全て存在しています。ですから、ソースコードの配置を勝手にできません。例えば画面描画のためのソースコードを集めて置いてあるフォルダに、いきなりDB接続用のソースコードを置くなんて暴挙は言語道断です。あるいは、すでにあるクラスと同じ役割のクラスを勝手に作ったら自分でさえ混乱しかねません。変数の命名規則を無視すると他のコードとの連携でミスを誘発し、バグの温床になります。要するに、既に存在するコードの規則に従うことが原則です。

従って、同じプログラミングとはいえ、「新規」と「追加・修正」では頭を切り替えなければいけません。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

書籍「パーフェクトRuby」読了

書籍「パーフェクトRuby」（Rubyサポーターズ著、技術評論社）を読み終わりました。技術書として読み応えのある一冊であったと思います。

Rubyは基本的な文法をマスターすることはもちろんですが、次に組み込みクラスとモジュールの理解が重要です。組み込みクラスとモジュールをしっかり理解しているかどうかは、Rubyを使いこなす分かれ目にもなります。ここが網羅的に分かりやすく書いてあったのは大変勉強になりました。

加えて「パーフェクトRuby」を読むまではあまり知らなかったメタプログラミング系の知識が得られたのも大きかったと思います。Rubyにおけるクラスやオブジェクトの成り立ちや、動的なオブジェクトの操作についての理解は、現場でのOJT的な勉強だけだとなかなか身に付けづらいものがあり、こういった書籍での体系化された知識に触れることが理解に大いに役立ちます。

さらに、BundlerやYARDなどのよく使われる標準外のツールの説明や、実際のアプリケーション開発をコマンドラインアプリケーションとWebアプリケーションを具体例として解説してあるのもいいポイントでしたね。Webアプリケーションの方は、RackやSinatraといった業界標準のツールにも触れていて、僕も実際仕事で使っているものですが、知識を補完することが出来ました。

それにしても技術評論社のパーフェクトシリーズは良書が多いと思います。「パーフェクトPHP」「パーフェクトJavascript」に続き「パーフェクトRuby」もリファレンス本として手元においておく一冊にしようと思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

SQLを久々に直接書いてWeb開発者として思ったこと

久々にSQLを直接書きました。とうのは、最近はORマッパーを使うことが多くて、直接SQLを書くことがめっきりなくなっていたからです。しかし今回は既存のコードに手を加える作業をするという状況で、既存のコードがORマッパーなど使用していないコードだったものですから、SQLを直接書くことになりました。

別にDBの専門家ではないので、パフォーマンスのチューニング方法などはあまり詳しくありません。もちろん速度は考慮して書きますが、それは基本的な部分であって、高度なチューニング（例えばDBMSの種類ごとの最適化やストレージエンジンごとの違いの考慮など）はできません。

とは言うものの、そこまで高度なチューニングが求められる場面は、Webアプリケーションにおいて少ないですし、今後も少なくなっていくように思います。基本的な原則（例えば、不要なレコードは取得しない＝WHERE句でなるべく絞り込む、など）に則っていればよいと思います。以前はSQLの方で最適化しなければならなかったようなパターンも、DBMS自身の進化によって高速化している例もありますし。

Web開発者としては、そもそもSQLをチューニングしなければならないようなDB構成を避けるという方向性の方がよいような気もします（既存のシステムだとそうも行きませんが、そこはDBの専門家の出番でしょう）。

ということで、Web開発者の自分としては、SQLについては今後も基本的な原則は学んでいこうと思いますが、DBMSの種類ごとの最適化やストレージエンジンごとの違いの考慮といった事項は、DBの専門家にまかせておこうと思っています。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

システム構築に必要な「統一性のセンス」

エンジニアとしてITシステムの構築を生業とするにあたっては様々な能力を必要とされますが、中でも重要な能力だと思っているのが「統一性のセンス」ですね。

これは、直接ユーザの目に触れるユーザインターフェース（UI）についても言えることですし、直接ユーザの目に触れないプログラミングやデータベース構造といったものについても当てはまることです。

例えばUIについては、ボタンの配置の方向や順番や色、アイコンの形、語彙表現など様々な要素について統一性を持たせることが、使いやすさに大きく影響します。

プログラミングについても、変数名・クラス名・メソッド名などの命名規則、論理的構造のパターンなどに統一性を持たせることで、バグの低減やメンテナンス性の向上を図ることができます。

システム構築には美的センスが求められる、と言う場合、その多くは「統一性のセンス」を意味しているのです。なぜなら、統一性のあるUIやソースコードは美しいものだからです。芸術作品では「混沌のセンス」も美的センスとしてアリなのでしょうが、システム構築にはありえないですからね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

他人のソースコードを読む際には推理能力も要る

昨日、プログラミングの際には考え方と目的も記録を残せと書いたんですが、自分はそうするよう気をつけていても、実際に仕事で扱う既存のソースコードにおいて、考え方と目的をコメントや公開サイトや付属ドキュメント等に書いていてくれているのかというと、まあ残念ながら書いてくれていない場合も多いわけですよ。

そういう時は仕方ありませんから、まるで推理小説の名探偵よろしく推理するしかありません。例えば変数やメソッドの名前も人によって微妙に用法が異なったりするので、ソースコード全体の傾向から、その名前が意味する所を推し量ったりとか。静的にソースコードを解析するだけでは分からない時は、デバッグツールを使って実際の動きを見ながら、コードの意味を分析したり、わざとエラーを起こさせてみたり。Javascirptの時なんかはよくやる手段です。

その意味では推理能力も必要ですね。つくづくプログラミングってのは思考を駆使すると思うんですよ。だから楽しいんですけどね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プログラムを書いたら考え方と目的も記録を残すこと

プログラミングをする過程で、他人の書いたソースコードを読んでいて本当に強く思うんですけど、その実装方法に至る経緯や考え方や目的が分からないと非常に解読に苦労します。

単なる処理の動きだけならソースコードを読めば分かります。でも、例えばどういう時に使うクラスやメソッドなのかとか、以前別の方法で実装したけれど何らかのトラブルがあって直したとか、そういう情報がないときちんと理解出来ないんですよね。

だからソースコードに考え方と目的を、コメントとして残しておくか、あるいはRedmineなどのタスク管理システムを使っているならチケットに書いておくとか、何らかの方法で記録しておくべきだと思います。場合により使い分けるといいと思いますね。

これは将来そのソースコードを読む他人のためでもあり、そして後から修正をすることになった時の自分のためでもあります。忘れるものですからね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

オープンソース時代こそ「コメント力」を

オープンソースとしてソースコードが公開されているソフトウェアを仕事で使ってたりするんですが、その際にソースコードを読み込んで目的に合わせてコードを追加したり改造したりするんですよね。で、何が一番大変かって言うと、そのソースコードを書いた作者の"意図を読み取ること"です。

プログラムの動作自体はソースコードそのものを読めば分かります。ただ、この変数をここで加算して、この関数に引数として渡して・・・といったプログラミング言語の処理自体は分かっても、そのソースコードが"何を目的に書かれているのか"が分からなければ意味がありません。

結局、ある一部分の動作がどういう意味を持つのかを知るために、関連するソースコードがを読み漁り、相当広い範囲を調べてようやく分かったりします。ただ、そこまで時間がかかるのには理由がありまして、ソースコードに"コードの目的・意図を記述した"コメントがほとんど無い場合にそうなるのです。

前にも書きましたが、ソースコードを読めば分かるってのは嘘ですからね。プログラムの機械的動作は確かに分かりますが、コードの目的や意図まで読み取るのは簡単ではありません。もちろんソースコードの関連する部分を含め広い範囲を読めば見えてくるのですが、しかしそれもどうなんでしょうか。

やはり、オープンソース時代であるからこそ、ソースコードを読む人に対する配慮は大切だと思うし、だからこそ、コードの目的や意図を分かりやすく記述できる「コメント力」が大切だと思うんですよね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プログラミング言語のバイリンガル以上を

現在僕が関わっているプロジェクトは1つはRuby、もう1つがPHPをメインの言語として採用しています。自分自身の経験としても、PHPとRubyは得意とする言語なので両方とも言語を使うこと自体に苦労はありません。その他にもJavascriptは両方のプロジェクトで多用していますし、補助的にPythonも少しだけ使っています。あとは汎用言語ではありませんがシェルスクリプトも駆使します。HTML・CSSの知識は言うまでもありません。

実際プロジェクトの開発を進めてて思うんですが、２つ以上の得意な汎用言語を持っておくと色々メリットが有るんですよね。別にRubyとPHPじゃなくてPythonでもC#でもJavaでもPerlでも何でもいいんですけどね。とにかく2つあれば、色々比較ができるわけで、両方の言語を実際に使って開発した体験・経験を比べることによって言語の特徴が体感覚として分かるわけですよ。

例えば片方の言語で慣れたやり方を、もう一方の言語で実装しようとした時にすんなり行かないことがあったら、そこで言語の強みと弱みが分かります。また、そこでもう一方の言語で実装するときの最適解を考えますから、これも力になります。

それに、複数の言語での実装を知っていると、より汎用的なロジックを考えられるようになります。特定の言語に依存したロジックではく、別の言語でも問題なく実装できるようなロジックを考える傾向がつきます。その方がバグも出にくく、品質の工場にも寄与すると考えられますね。

ともあれ、プログラミング言語はバイリンガルになっておくと色々得をします。もちろん2つに留まらず、3つ4つと大いに越したことはありませんが、まずは2つを目指すとよいでしょうね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

capybaraのpage.execute_scriptとjQueryの組み合わせの汎用性がすごい

Webアプリ開発のテストに便利な Capybara(+Cucumber) ですが、テストに使うdriver がJavascriptに対応していれば、テスト中にJavascriptの実行を含めてブラウザの動きをシミュレートできるという素晴らしい特長があります。Javascript対応のdriverとしては、Capybara-WebkitやPoltergeistなんかが有名です。

ボタンやリンクのクリックなどのユーザの動作で発火するイベントは、Capybaraでclickなどのメソッドで指定すれば、Javascript側のイベントの動作もそのままシミュレートしてくれるようですが、マウスオーバーなどのイベントはどうやったらテストできるのでしょうか。

実は、Capybaraには execute_script メソッドがありまして、これでJavascriptのコード片を直接記述して実行できます。この中ではページで読み込んだライブラリなどが有効です。なのでjQueryが使えます。よってjQueryを使ってイベントを発火させることにより、かなりの汎用性を持ちえます。

例えば、マウスオーバーのステップ定義はこんなふうに書けてしまいます。

もし(/^".*?\((.*?)\)" にマウスポインタを乗せる$/) do |t_css|
  page.execute_script("$('#{t_css}').trigger('mouseenter')")
end

上記ステップ定義に従い、featureファイルにはこんなふうに書けますね。

もし "メニュー１(#menu1)" にマウスポインタを乗せる

カッコ内のCSSセレクタで指定した要素にmouseenterイベントが発生し、マウスオーバーの動作テストを実行することができます。

という感じで、execute_script メソッド内でjQueryを使うと簡単な記述で様々なことが実現出来そうです。特にテスト実行上重要なイベントの発火が非常に簡潔に書けるのでいいですね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。