標高+1m

Don't be rational.

燃え尽きプログラマと動的開発について

f:id:ympbyc:20150810204334p:plain

徳島の山奥でフロントエンドJSのための動的開発環境を作っている。関連して、会社の技術ブログでチラッと動的開発について触れた。こっちではもう少し突っ込んで書いてみる。

この記事の後半ではBirdについて触れるけれど、この記事の目的はBirdの宣伝ではなく問題提起と解決策の示唆です。一緒に開発環境について真剣に考えてみたい。

mechanic.pilotz.jp

高等言語の発明から60余年、数え切れないほどのプログラミング言語があって、みんなそれぞれ気に入った言語を使ってソフトウェアを記述しているけれど、一部の例外*1を除くと、どの言語を使っても本質的な開発スタイルは一緒なのが現状だろう。ドキュメントを参照しながらエディタないしIDEソースコードを記述し、実行して動作確認をする(テスト含む)。静的言語と動的言語の違いはソースコードの記述と実行の間にコンパイルが挟まるか否かだけだ。

これが悪いというわけじゃない。シンタックスが好きな言語なら、エディタで綺麗にハイライトされたソースを眺めてるだけで楽しいこともある。僕はRainbow Delimiterで虹色に輝くS式をPareditするだけで心が落ち着く。

でも時々、エディタと向かい合うのが辛い時がある。Joel on Software - 射撃しつつ前進で書かれているような現象で、このブログでも過去に触れた

プログラマの生産性の一番大きなファクターはその時の精神状態だ。もうこれは有無を言わさずそうなのだ。プログラミングスキルや知識やコミュニケーション能力や読解力なんかは差し置いて、ダントツで気分の問題が一番大きいのだ。管理職の方は是非参考にしてください。

話が脱線したように見えて、これがそうじゃない。気分が良い時は、お気に入りのエディタとお気に入りのキーボードでお気に入りの言語を書き殴るのが一番効率が良い。些細なデバッグに1時間や2時間かかろうとも砂糖とカフェインとニコチンで乗り切れるし、残業でも泊まりでも平気でできる。要するにハイだからだ。

でも気分が乗らない時はもうどうしようもない。エディタを開くのさえ苦痛で、画面いっぱいのソースコードなんて見た時には目は虚ろに、脳みそは粘土になって、手は勝手に⌘-tabを叩いて僕をブラウザに引き戻す。こんなときはGmailをポチポチいじったりSlackでbotをからかったりとか軽い作業しかできない。これは皿洗いとか洗濯とかと一緒で、要するに一度やり始めてしまえばどうってことはないはずなのだ。でもプログラミングはこの状態からやり始めるまでの障壁が極端に高い気がする。

だったらGmailやSlackを弄るくらいの感覚でプログラミングができれば良いんだ。

エディタで書いて、別途動作確認というループをUIとして捉えて、その問題点を考えよう。

まずレスポンスの問題がある。普通のUIなら、なにかアクションを起こしたときにアプリケーションを切り替えて最初から実行し直して結果を確認するなんてことはあり得ない。Slackで文章を書いてEnterを押したらすぐにチャンネルに表示されるし、Gmailでスレッドのタイトルをクリックしたらすぐに本文が表示される。ゲームと一緒なのだ。アクションに対する報酬は即座に欲しい。これを 課題1 とする。

次に、イントロスペクションの問題。これにドキュメントの問題も含める。実際にプログラムを書くときは、エディタ→動作確認→エディタ→動作確認という単純なループにはならず、デバッグのために実行時情報を覗き見たり、ドキュメントを参照したりといった脇道が発生する。理想的には全部一つの画面でやりたくないですか!? これが 課題2

最後に、エディタの精神衛生上の問題は、きっとその圧倒的な視覚的情報量だ。そして多くの場合、表示される情報が十分整頓されていないこともストレスの原因だろう。これを 課題3 としよう。

課題1課題2 の半分を解決するのが動的開発だ。ここで言う動的開発ってなんのこっちゃについては記事冒頭のリンク先を参照して頂きたい。簡単に言えばランタイムに開発する手法のことだ。開発環境自体が実行環境上のソフトウェアなのだ。書いた式はその場で評価して結果がわかるし、実行時情報についてはそもそもこれが実行時、つまりランタイムであるわけで、その場でなんでも覗き見れる。 課題2 の残り半分、つまりドキュメント問題は動的開発の定義の範疇ではないというだけで、動的開発環境にドキュメント参照機能をつけるのは簡単だ。

問題は 課題3 だ。これの解決には2つ必要なものがあると思う。コード分類の指針とGUIだ。

まず情報の整頓が十分でないとはどういうことか。

テキストファイルだとどうしても上下方向への1次元しかコードの各部分(コード片)を分けて配置する余地がないため、まったく違う役割のコード片がダラっと並んでしまいがちだ。加えて上下方向の次元は、純粋関数型言語でもない限り実行の順番というセマンティクスも持っているため、実行順に依存したコードなのかそうでないのかがはっきりしないという問題も抱えてしまう。

それぞれ疎なコード片は疎であることがはっきりするように並べたいわけで、これにはもう一つ以上の次元が必要になることを納得頂きたい。

コード片を分類する指針も必要だ 。冒頭のリンク先で紹介したSmalltalkでは、これをクラスカテゴリとクラスとメソッドカテゴリで分類していて、クラスブラウザを使ってナビゲートできるようになっている。

今回開発中のBirdでは違う方針を採った。だってオブジェクト指向じゃないから。

Birdを汎用の開発環境ではなく特定のFLUXフレームワーク専用にした意図はここにある。フレームワークを使うと、自然に各コード片は明確に分類できる。MVCでいえばモデルはモデルで纏めればいいし、ビューはビューで纏めればいいということだ。今回はFacebook流のFLUXを分解して、コンポーネントの概念をなくした簡素な(未圧縮2KB)フレームワークを使った。コンポーネントがないので、このフレームワーク用のコード片は

の4種類に分けられる。ちなみに関数型なのでストアはオブジェクトではなく、リードオンリーなオブジェクトへの参照(Clojureでいうatom)である。

この分類を使うと、こんなUIを作れる。

f:id:ympbyc:20150811194146p:plain

トランジションリスナの赤丸や、トランジションとDOMリスナのピルにホバーするとソースがプレビューできて、クリックすれば編集できる。一度に提示する情報が減り、圧迫感が軽減された。

コードの種類の次元が加わり、更にトランジションリスナは3次元になっている。エディタでの上下1次元の配置より格段に整頓されていることに同意してもらえると思う。

注意して欲しいのは、この記事ではグラフィカルプログラミングについて何も触れていないことだ。グラフィカルであることに主眼はない。インターフェースの改善を実直に行った結果こうなっただけ。

思ったより長くなってしまった。とにかくこれで課題は3つとも解決し、気分が乗らない燃え尽き状態でもGmailやSlackのようにプログラミングできそうな兆候が見えてきたのではないだろうか。

Birdを使った開発の様子をスクリーンキャストしてみた。お気楽な感じが出せただろうか。

www.youtube.com

Birdはまだ生焼けだけど、方向性は面白いんじゃないかと手前味噌ながら思っている。

面白い開発環境を作るのが流行ったら面白いなと思います。みなさんも如何でしょうか。

Birdを触ってみたい方はこちら

mechanic.pilotz.jp

*1:Smalltalk, データフロープログラミング, Scratchなどのグラフィカル言語, etc