雑記帳

ちょっとした文章とかメモ書きとか。

趣味でのソフトウェア開発をする際に気をつけていること

自分の時間を使ってソフトウェアを開発するにあたって、趣味のコードを触る時に気をつけていることでの現時点での考えを明文化しておきます。

1. 問題が起きた際にはupstreamに報告をする。可能であればpull requestやパッチを送る。そうではない場合は、再現可能な手順を添えてissueやチケットを作成する。

2. 動く状態にして公開する。その際、変更しても壊れてないかどうかを判定する仕組みを導入出来るのであれば導入しておく。

3. 2つ以上の方向から理解するように心がける。

です。

まず1.から。これはRuby-GNOME2のメンバーになった辺りから考え始めました。ククログにもある通り、

「既存のソフトウェアの開発元に問題を報告し、可能なら問題を修正するパッチを添える」です。ソフトウェアの開発元のことをupstream(アップストリーム)と呼ぶこともあるため、「upstreamで直す」と呼ぶこともあります。

これにかなり近いですね。upstreamで問題を解決できれば、手元で回避するよりも結果的に掛かるコストを削減できると思っていますし、感じているからです。フリーソフトウェアでは基本的にソースコードは公開されていますから、フリーソフトウェアにおいて「問題を手元で回避する」とは凡そ「問題を回避するパッチを作成し、手元のソースに当てておく」だと思います。しかし、一時期はそれでしのげるものの、パッチはいずれ当たらなくなります。

また、フリーソフトウェアでは英語で議論をすることが多いため、拙い英語でもいいので(本当はもっとしっかりとした英語を書くべきですが)、問題を報告します。英語で報告したものでもきちんと筋が通っていれば大抵の場合は対応してくれます。英語で対応した例として、yesod-paginatorのPull Requestyesod-binのscaffoldがビルドできなかった問題があります。

2. について。これは主にCIに関する話です。主にGithubに上げるコードでは可能な限りTravis CIに掛けてCIをするようにしています。CIをして、greenになるまでは確かに大変ですが、恩恵もあります。CIでpassしていれば大抵他のマシンで開発を継続することができます。CIをする、という事はビルド手順やテスト手順が明文化されているという事なので他の方々が修正する時の道標にもなるでしょう。

3. について。これは、普段の心がけの話と言うよりは受けてきた教育の影響によるものでしょう。詳しくは話しませんが、僕は理学系の出身でソフトウェア工学の学問をしてきたわけではありません。理学系の人々の特徴としてあるものを作って満足というのはまずありませんし、振る舞いからおそらくこうなっているだろうという妥協した推測をしません。振る舞いから可能であれば法則を導き出し、また可能であればデータを取ります。感覚的な議論ではなく、出来れば定量的に議論を進めます(定性的な議論をすることもあります)。法則に関していえば、ひとつの例だけの理解に留めることはありません。最低限2つ以上の事象で理解しようとします。2つでは少ない、5つ以上だという方も中にはいます。それくらい多角度から客観的に物事を取り扱うように習慣づけられています。

例えば、Haskellを理解するにしてもHaskellを書いてみる事だけではなく、理論的、つまり圏論の方面から考えて見るという事をしますし、出来ればコンパイラの中を覗くことをします。型理論をかじってみたこともあります。HaskellのGroongaのC APIバインディングであるHaroongaもその一環で開発中です。

これはRubyに関しても同じことが言えます。Rubyに関する本を読むだけでなく、CRubyの処理系のコードを読んでみることや、C言語拡張のコードを読んでみる、書いてみる事も当てはまります。

また、方向とは少し異なりますが、その言語でのFFIを使ってみるだけでもかなり理解が深まるではないでしょうか。またまたRubyの例で申し訳ありませんが、Rubyはとても興味深い言語です。RubyistはRubyの世界しか見ない傾向にありますが、それはなんてもったいない事をしているんだろう!と思います。
というのも、RubyはRubyと処理系の境界を曖昧にする言語だからです(*)。C言語でRubyを拡張することができますし、なにより、C言語拡張からはC言語の関数が呼べます(当たり前ですね)。これを利用すると、例えばmikutterが使っているruby-gtk2のようなバインディングが書けるのです。そうすると、Rubyの世界からは違った様相が見えてきますし、CとRubyの使い分けも出来るようになるでしょう(と言っておきながらそこまでできてないのですが…)。
RubyはRubyの世界はオブジェクトがぽんぽんできては消え、掴みどころがないのですが、C言語拡張の世界ではメソッドはVALUE staticですし、理解がむずかしいselfも明示されます!

と、ここまで書いてみました。
この心がけは万人向けではありませんし、現時点での僕の心がけです。フリーソフトウェアを使って開発する際にはそのソフトウェアのコードが手に入りますし、直そうと思えば手元でも直せてしまいます。
しかし、何のためにフリーソフトウェアを公開してくれているんでしょうか?
感謝の気持ちを込めて開発元に適切な手段で報告すればその開発者は喜んでくれるのではないでしょうか。

最後に、問題を報告する際には丁寧に状況を説明し、相手を不愉快な気持ちにさせないように心がけたいですね。問題を報告される側になった時はまず初めに感謝の意を表明することも心がけています。

(*)理解が浅いとかありましたら、コメント欄に是非。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。