2018 年の振り返り

GitHub Activity

GitHub

2018 年も残り僅かとなりました。この記事では、私の 1 年間の活動を振り返ります。まず、GitHub Activity に目を向けると、2018 年は 2,321 コミット (contributions) と言う結果になりました。GitHub の Activity を意識し始め ておよそ 2 年が経過しましたが、特別な理由がない限り毎日コミットし続けると言う目標を今年も概ね達成できた事は何よりでした。

レコーディング・ダイエットのような形で自らのコミットを記録し続けて気付いた点として、平均的に見た場合、1 日 10 コミットは想像以上に大変 と言うものが挙げられます。もちろん、1 コミット当たりの修正量によって総作業量は変わってきますが、この事実は自分がそれまでに漠然と想像していた量よりも随分と少ないと言うのが率直な感想です。何らかのソフトウェアを開発する際にも、この事実を念頭に置きながら大雑把に見積もる事で、当初想定する期間と現実とのギャップが埋まってきたのは良い副産物であったように感じます。

リポジトリおよびコードの整理

2018 年は、2017 年の中頃から始まった これまで CubeSoft として公開してきたソフトウェアに対する開発サイクルの再構築 を推し進めた年となりましたが、その中の一つに、リポジトリおよびコードの整理があります。CubeSoft としては現在、下記の 8 個をアクティブな公開リポジトリとして管理しています。非公開リポジトリや fork したリポジトリを含めるともう少し存在しますが、ここ 2 年は多くの時間をこれらのリポジトリに注いでいます。

コードの整理と言う観点で見ると、2018 年は コメントの一部を英語で書くように方針転換した 事が大きな特徴の一つです。私自身は「下手な英語よりは、まともな日本語の方がマシ」と言う価値観なため、これまではコードのコメントも日本語で記述していました。しかし、Visual Studio を始めとした最近の開発環境には、Javadoc や XML Documentation などの構造化されたコメントを解析してポップアップ表示する機能が標準搭載される事も珍しくなくなってきました。

XML Documentation

このため、上記のようなコメントを日本語で記述した場合、該当コードを利用するユーザの開発環境では、そのユーザの言語設定に関わらず日本語が表示される事となります。前述したリポジトリもその多くは利用可能なライブラリとして NuGet に登録しており、その結果、少しずつですが海外のユーザにも試して頂けているようです。このような状況を鑑みると日本語のコメントが表示されてしまうのは好ましくないと思い、方針の転換を決定しました。

方針転換に際しては当初、英語と日本語、両方のコメントを管理する事も選択肢として検討しました。しかし、XML Documentation では複数言語のコメントを管理するための良い仕組みが見当たらなかった事、管理するコメント量が増えるにつれて嘘のコメントの危険性が増加する事、そして何より、私自身、まったく同じコメントが複数言語で記述されたソースコードなど見たくなかった事などの理由で、日本語のコメントを捨てる事にしました。2018 年現在、既存のコードには大量の日本語コメントが残ってはいますが、この辺りは少しずつ修正していこうと思います。

CI の徹底およびテストカバレッジの可視化

Codecov

ユニットテストで振り返るプログラマとしての自分史 でも触れましたが、開発サイクルを再構築して大きく変わった点は AppVeyor を利用した継続的インテグレーション (CI: Continuous Integration) の徹底、および Codecov によるテストカバレッジの可視化です。

テストカバレッジの可視化に関しては、長年、自分の中にも「テストカバレッジの数値を気にするようになると、数値を上げるためだけのユニットテストを記述するようになるのではないか?」という不安が常にありました。そして実際、数値を上げる以外の意義を感じられないユニットテストを数多く記述し、これに何の意味があるのか……と言う感情を抱く事も何度もありました。

しかし、面白い事に 2 年ほどリファクタリングや修正を続けていると、数値を上げる以外に意義を感じられないユニットテストに何度も救われる事となりました。例えば、View に表示するメニューやメッセージの文字列 などは、記述時は「定義ファイルに決め打ちで記述するのだし、テストするまでもなく明白」のような気がしていました。しかし、ある時、何らかの修正時にうっかり定義ファイルの記述位置がずれてしまい、さらに不幸な事に、ビルド時にも実行時にもエラーが発生しなかった事がありました。このケースに関しては、ユニットテストがなければ表示内容が異なっている事に、しばらく気付く事ができなかったのではないかと言う気がします。

テストカバレッジの数値を上げるためだけの近視眼的なテストコードを記述する事によって、それよりも重要なテストコードを見逃すのではないかと言う不安は依然としてあります。ただ最近は、ある程度は仕方がないと割り切り、以下のような指針で実装およびテストコードの記述を行っています。

  1. 初期リリースまでは、取り合えずテストカバレッジの数値(80%~95% 程度)を指標としてテストコードを記述する。この結果、初期リリース時点では、正常ケースおよび容易に予想可能な異常ケースのテストに留まる事が多い。
  2. リリース後に何らかの不都合が発覚した場合、必ず最初に該当の不都合が再現するテストコードを記述する。そして、テストを実行してレッド・シグナルを確認する。
  3. 該当部分の実装コードを修正し、テストを実行してグリーン・シグナルを確認する。

このサイクルによって、完全ではないにしても「少しずつだが、良くなってはいる」事を実感できるのは、テストコードを含めた保守を続けていく、あるいは習慣化する上でプラスに働いていると思います。

CubePDF シリーズの大改修

ソフトウェア別で見ると、2018 年は CubeSoft において最も多くの人達に利用されている CubePDF を始め、CubePDF シリーズの開発を継続的に続けていけるよう、様々な面において保留となっていた事柄に取り組めた 1 年であり、その意味でも充実度は高かったように思います。

具体的に挙げるとすると、GUI の英語化は大きな特徴の一つでしょうか。特に CubePDF に関しては、全て日本語表示であった頃から海外ユーザが存在していたようで、そう言った事も含めて複数言語の View を開発するためのパターンが自分の中で確立できたのは良かったと思います。

また、CubePDF には ユーザーズマニュアル と言う PDF を同梱していますが、この基となるドキュメントを markdown 形式で書き直す事でバージョン管理に含められるようになったのも、個人的には満足した出来事です。