/home/by-natures/dev*

ソフトウェア開発者として働く人の技術的なメモ

Heroku Junior Campに参加してきました

社会人になってから初投稿なのですが、会社の先輩に教えてもらった勉強会に参加してきたので、今日はその感想を書きたいと思います。

イベント概要

Heroku Junior Camp イベントページ)

このイベントは、自分で選択した言語を用いて、これからソフトウェア開発を生業とする人が、HerokuというPaaS上でソフトウェア開発を行ってみるというものでした。実際のテーマは言語によって異なり、JavaではリファクタリングPHPではfacebookアプリ、Rubyでは言語自体の習得という感じでした。

イベント後はビアバッシュもあります。特に「これからソフトウェア開発を生業とする人」ということで、新卒1年~3年目の方が多かったので居心地がよかったです(^_^

言語のリファクタリング

私の選択したJavaでは、Herokuが公開しているHelloWorldサンプルを、とある観点からリファクタリングしていきました。講師は有限会社システム設計の増田さんという方です。

ここで、「とある観点」というのが

ソフトウェア開発は絶対に失敗する。

というものです。この「失敗」は大きく3つに分けることができるそうです:

  • 要求:関係者間で「何のためのソフトウェアなのか」の意思疎通が出来ていない。
  • 技術:関係者の技術スキルが安定していない。枯れた技術でも、各個の技術スキルが伴わなければ意味が無い。
  • 段取り:ウォーターフローよりもアジャイル。小さな失敗を積み重ねるべき。

特に「要求」では、ソフトウェアが何のためのソフトウェアなのかを関係者へ伝えるスキルが重要であるということで、今回のリファクタリングへ話が繋がります。

リファクタリング1:余計なことを書かない

それでは実際に行ったリファクタリングについてご紹介します。まずは「余計なことを書かない」というものです。非常に当たり前のように聞こえますが、「何のためのソフトウェアなのか」をプログラムコードレベルで伝えるためには、余計なことを書いてはいけないということなんですね。

HelloWorldサンプルのレベルで、余計なことがあるのだろうか?と思うかもしれませんが、具体的にはコメント文と使用されていないimport文を削除しました。import文はIDEを利用していると自動挿入されることも多く、つい冗長になりがちです。そしてコメント文は、講師の方は「一切書くな」と強い主張をもっていました。「コメントを書かないと理解できないプログラムでは、それはただ動いているだけでソフトウェア開発者としては失格」という理由からです。

実際に現場配属し、プログラムを書く場合は上のような信念以上に「周りにスタイルを合わせる」ことも、関係者と意思疎通を行うためには重要とのことでしたが、読んで理解できないプログラムは失格だというのは、ソフトウェア開発は一人で行うものではないということから強く来ているのだろうと感じました。

リファクタリング2:変数名の変更

次に、変数名を分かりやすいものに変えます。この「分かりやすいもの」という表現も、本当は色んな解釈・命名規則があるそうなのですが、今回は変数名をフルスペリングに直す作業を行いました。

具体的には、HelloWorldを表示するHttpServletにおいて、リクエストとレスポンスを表す変数名がreq, resとなっていたのを、requestとresponseへ変更しました。これも、「何のためのソフトウェアなのか」をプログラムコードへ落とし込むことが目的です。

私は最初に学習した言語で(SchemeSICPで習いました)、変数名を変に短縮化することがなかったので、割と長い変数名を付けるのですが、講師の方によると「君たちが思っているよりも、変数名はずっと長くていい」とのことでした。特に、「コメントを書かない」というスタイルに則れば、変数名がいかに重要であるかが理解できると思います。

リファクタリング3:説明変数の導入

次に、説明変数の導入です。これも、ソフトウェアが何をするものなのかをコードで表す目的で行います。例えば

out.write("Hello world".getBytes());

というソースコードに対し、

String replyMessage = "Hello world"; write(replyMessage.getBytes());

というように、Hello worldを一度 replyMessageで受ける処理を追加します。

ある意味、コードを冗長にしていると見ることもできます。しかし、上と下を比べると「"Hello World"という文字列は、リプライに使う文字列だ」という、ソフトウェアの目的の一部がはっきりと見て取れるのではないでしょうか。このように説明的に変数を増やすことで、コメントを書かずともプログラムに意味をもたせることができます。

リファクタリング4:メソッドの抽出

共通する処理は、1つのメソッドとして抽出します。その基準としては「ひと固まりに思えたらメソッドに」「2行以上になったら、メソッドに出来ないか考える」と、少し極端にも思えるものでした。

しかし実際にソフトウェアに変更が生じる際、メソッドとして機能を分割しておけば、変更箇所・範囲が最小限で済むようになるので、非常に重要です。

リファクタリング5:オブジェクトの抽出

以上までが、言語手続きの共通のリファクタリング方法ですが、最後にオブジェクト指向リファクタリング、つまりオブジェクトの抽出を行いました。

今回はHello worldプログラムということで、MVC(Model, View, Control)を意識し、Modelに当たる「挨拶を返す」処理をオブジェクトとして抽出しました。

特にこのMVCにおいて、MVCは並びにも意味があると教えてもらいました。VとCは技術刷新が起こるため、「仕事として学び続けなければいけない」ものですが、Mは時代によって廃れない、ということのようです。何事も並びを意識せよ、とはよく言いますが、MVCという単語レベルでも並びが重要なのかと驚きました。

リファクタリングまとめ

以上がこのイベントで行ったリファクタリングとなります。どのリファクタリングも、次のような思想に基づいていることを最後にご紹介します:

  • 動くことはゴールではない
  • 何をするソフトウェアなのかをプログラムで表現する
  • 関心事を分離する(変更個所が少なくて済むようにする)

「特に、何をするソフトウェアなのかをプログラムで表現する」という哲学は、ソフトウェアだけに限ったものではないな、と感じました。仕事や学校の課題で、何らかの意見を他人へ共有する場合、その「何らかの意見」は他人からみて理解できるものなのか、理解しやすいものなのかを考えるべきだなと。

個人的な経験なのですが、例えば「このプログラムが動かないんだ」と言われてプログラムを見た場合に、相手がプログラムを「解読」することを強いていないでしょうか。相手がその場で解読できない場合、多くは伝え方が悪いだけなのに、「分からない」という畏怖・苛立ちを相手に感じさせてしまいます。相手に伝わらないというのは、同時に相手にネガティブな印象を与えていると考えるべきだと思うんです。

また少し話が変わりますが、ソフトウェア開発者として、講師の方が考える最も重要な点は、「相手の要望を理解できるかどうか」だということです。技術知識は最悪変わりがいるが、相手(顧客)の要望を理解するスキルは、変えが効かない、ということを仰っていました。

問題解決手段としてGoogleだけで済まさない、自分が知らないことはヘルプやリファレンスで調べる癖を付ける、なども何度も促して頂きました。何事も関心をもって、いろいろなところから知識を吸収していく姿勢が大切だと感じました。

イベントまとめ

今回が社会人になって初めてのイベントでしたが、入社1年~3年目向けということもあり、小手先の技術よりも、ソフトウェア開発を行うにあたって重要な「考え方」を多く教えていただき、現場配属を控えた今の時期に最適なイベントだと感じました。

社会人になって働き始めると、どうしても会社の人との交流ばかりになってしまいますが、このようなイベントに参加することで会社外の方と交流をもて、他の会社の同じようなポジションの人は今どういう状況なのかとか、自分の知らない技術を教えてもらったりできる良い機会だと感じました。様々なスキルを広め、深めるためにも今後も積極的に参加したいです。

あと最後になってしまいましたが、Heroku自体の技術も素晴らしいと感じました。Herokuが管理するAmazonEC2の領域上に、すべてのツール・環境が揃っていて、簡単にバージョン管理・デプロイ・一般公開まで出来てしまうんです。特に、簡単に一般公開できるというのは、自分の作ったソフトウェアを簡単に他人に紹介することが出来る、という点で非常に魅力的で、現場配属後もサンドボックスとしてすぐにでも利用できるだろうと感じています。