今までプロジェクトであったこと
要約
- これは技術記事でない。
- 現行プロジェクトで起きたことを連ねた。
目次
始めに
今回の記事ではコード片評価サイト作成プロジェクトについて、今まであったことを書き連ねてみる。ボリュームがありすぎて責任問題に発展する可能性があるので、プロジェクトの現状についてはまた後日記事にしておこうと思う。
リポジトリについては以下になる。
https://github.com/NULL-header/fec-frontend
疑問に思った点等あれば、是非ともIssueか当ブログのコメントにて意見を伺いたい。
では以下からがこの記事の本文だ。見出し毎にそれぞれプロジェクトで起きたことについて記述していく。
Issue driven developmentの導入
Issue driven developmentとは、GithubのIssueを使ったチケット駆動開発のことを指す（要検証）。なお、ひとまずこの記事ではこの定義を文脈として利用する。
導入の経緯
事の発端はcontoributorsにもあるg00chyさんが、過去の経験にあったIssue driven developmentを掲示したところ、私とバックエンド担当のkotarouさんが賛同した形になる。それに伴って、githubの機能であるIssueとPull requestsのテンプレートを用意した。またコミットメッセージにチケットであるIssue番号を記載することで、コミットとチケットを紐づけるルールを取り決め、更にブランチ名にもIssue番号を盛り込み、それらの決まりによって開発の手順が確定した。
導入時のメリット
Issueにて仕様を事前に確定させることで、設計を実装の前に行うことが明確化された。これらによって開発手順が画一化され、そのときの開発者の状況によって作業が左右されなくなる。また一つのプルリクエストに対して一つのIssueを紐づけることによって余分な作業がプルリクエストに混じり込むことが無くなり、レビュアーの負担が軽減される。また作業ログとしてIssueがある程度機能するのもメリットだろう。
導入時のデメリット
型安全で便利なプログラミング言語におまじないがあるように、この取り決めがある影響で、軽微な変更でもIssueを書いてブランチ名を長々と切ってプルリクエストを出すという、先ほどのおまじないになぞらえて言うところの儀式が必要になる。これが非常に面倒で、Githubの芝生のカウントにIssue作成が含まれることだけがモチベーションになっている節さえある。
自動デプロイ
今回プロジェクトではCircleCIを用いたサーバへの自動デプロイが採用されている。バックエンドが動作しているサーバで同時にnginxも起動しており、それが読み取るhtmlを自動でビルドするのがフロントエンドでの自動デプロイする仕組みになる。
自動デプロイの経緯
元々の素案ないし要求に、フロントエンドがプルリクエストを出すときにサーバにデプロイされていれば動作確認が容易である、というものがあった。そこでインフラエンジニアであるg00chyさんがフロントエンド用のCircleCI用のymlファイルを書き上げ1、master、develop、featureの各ブランチ毎にルーティングする設定をnginxに沿うように用意してくれた。そのままでも非常に便利で強力なのだが、個人的にはIssueで問題となるページを掲示するときにURLを貼ることのできるのが非常によいと思っている。問題の周知が行いやすく、また文章での説明でなく直接分かりやすい形で問題個所を挙げられるのがとてもよい。
発生した問題
いくつかあったが、g00chyさんから聞いた構築時の問題としては、CircleCIのキャッシュ機能によって変更が反映されない問題が挙げられる。これのためにブランチ名をechoで出力したのをパイプでawkに繋いで、といった文字データの加工が必要になっており、厄介だったそうだ。他にも、フロントエンドのソースファイルのビルド問題もあった。というのも、productionでは当然正規のバックエンドのAPIを使うが、開発段階ではdev版のAPIが必要なのである。そこでビルドするブランチによってAPIの向き先を変える必要があり、今までのURLを纏めていた部分を環境変数から読み取るように改変するなどの処理が必要だった。
また、動作させているうちにDOMルーティングというフロントエンドのソースコードからルーティングさせる処理のためにルーティングのなされていない基本URLの取得が必要になり、それをWebpackから固めるのに手間取ったりと、それなりに問題も発生している。
そんなとき役立った筆者のスキルとして、Bashを書けるというものがあった。それと言うのも、筆者は一時期Pythonに執心していた時期があったのだが、その時テンプレートリポジトリというgithubの機能がなく2、プロジェクトを作成する毎に手でディレクトリを作るのが面倒で、さらに言うなら一々requirements.txt3からライブラリをインストールするのも面倒だった。そこでPythonのインタプリタに付属している仮想化機能を使って仮想環境を構築し、自動でrequirements.txtからライブラリをインストールし、更にrequiements.txtの変更を監視して手が加わっていたらライブラリをインストールし直す機能を持ち、またディレクトリを作業用に初期化する機能も持った、複合型パッケージマネージャラッパーとでも言うべきコマンドを書いていたことがあったのだ4。そのときの杵柄でちょいとCircleCIのymlファイルに手を加えてやることで問題を解決したのである。
相互レビュー
今回のプロジェクトではプルリクエストに対して最低一つのapproveが必要であり、それに対して手すきのメンバーがレビューをする形をとっている。
レビューのメリット
まずもって人にコードを見せるという適度な緊張感がとてもよい。見る人を意識するのは美しいコードを書く手助けにもなるし、モチベーションにも繋がる。可読性の意義が向上するというのは本当に素晴らしいことだ。また、フロントエンドではバックエンドの見解が、バックエンドではフロントエンドの見解が得られ、事前にいわゆるオレオレなプログラムを検知できる部分があるのは本当によいことだと思う。
レビューのデメリット
相互レビューが存在するせいでプルリクエストが遅々として消化されないという問題もある。今回プロジェクトメンバーは常駐が二人、臨時が一人と非常に少人数な構成であるので、誰かが体調不良や用事でプロジェクトにいないとその時点で進行が止まる。もちろんgitのrebaseを上手く使って前のプルリクエストのコミットを引き継いだ状態で別のブランチを切るという手法も取ることができるが、その場合プルリクエストがマージされた段階でマージされたブランチでrebaseし直すという手間が発生する。開発のスピード感は間違いなく落ちてしまうだろう。
実際に問題化した点
前述のスピード感が落ちるのに伴って、プルリクエストへのレビューが一部形骸化している問題もある。今回フロントエンド一人、バックエンド一人の構成であるので、どうしても相方のコードを細かくは読めない。設計思想から哲学、果てはやや特殊な文法までもが理解できないために、どうしても命名規則や関数の切り出しなどにレビューが終始してしまう。一度などは相互レビューの取りやめまで検討に入ったほどだった。それでもやって損はないのだから5、続けることに決まったが。
効率的な議論
効率よく建設的な議論をするというのは案外難しい、ということが今回のプロジェクトでの筆者の学びだ。
マナーの欠点
たとえばだが、代案も出さずに問題点を指摘することは少々マナーにもとるところがあるのは否めない。勿論お互いが完全に技術者として成熟してかつ信頼し合っているのなら話は別だろうが、それを除けば、問題点を指摘されるのは気持ちのいいものではない、というのが人情というものだ。ここで、問題点を洗い出せるのだからむしろ気持ちのいいものではないか、と考えた読者は成熟した技術者であるのだろう。だがしかし、文脈とニュアンスを気にするアカデミックからかけ離れた一般人にとって、問題点を指摘されるというのは、お前が気に食わないと言われているに同義なのだ。そういったものに気を付けつつ、相手を立てながら有効な議論をするというのはかなりの難度がある。マナーとは議論のレベルを落とすものだと解釈してもよいぐらいにだ。
論点の記述
プロジェクトのチームの談合においても、よく論点がずれる。お互い技術者であるのにも関わらずだ。その場合の大概のケースにおいては、お互いに自身の文脈に頼って会話していることによる、前提条件のずれが原因である。そういった観点から、提案や意見を述べるときには事前に論点を記述しておくのが効果的でないかと私は思う。ばかばかしいかもしれないが、そういった文脈、論点、前提条件を明確にしておくローコンテクストな会話においてこそ効率的な議論は生まれるのだ。そのために文脈になるべく頼らず、読むことさえできれば子どもにも理解できるような自明さを保つことが肝要であるように筆者は感じた。
といったところで、今回の記事は以上である。
終わりに
やはりというか、プロジェクトであったことを纏めるとそれなりのボリュームになってしまった。まあ致し方ない部分もあって、現在進捗率が一割程度であるのにプロジェクトのフロントエンドのリポジトリの全体のコード量が三千を超えている。純粋なコーディング量（gitが検知している変更量）でなく最終結果でそれなのだから、起こることも多数あってしまうのだろう。
ところで、次はそろそろ技術記事を書きたいと思う。題材としては件のIssue番号のコミットログへの自動挿入についてだ。
