実習日誌（二）
実習が終わりに近づき、バックエンドAPIサーバーの基本版のコーディング作業がほぼ完了しました。ここでまとめておきたいと思います。
プロジェクトチームのリーダーとして、私が持つソフトウェアプロジェクト管理に関する唯一の知識は、冬休みに一度読んだ『人月の神話』に由来します。今回の実践を通じて、自分がいかに未熟であるかを痛感しました。それでも、少しは学べたと思っています。
設計
2年前、C言語の課題を書くときに何も考えずにVSを開いて作業していた頃と比べ、今日の自分には明らかに変化がありました。
まず、VSはもう長い間開いていません。
とにかくこの2年間、私は純粋にPythonを学んでいた時期の練習、ロボットチームでロボットの上位コンピュータを書いたときの経験、教務処ウェブサイトの教員・学生向けクローラーを書いた経験、オレンジジュースプロジェクトに参加した際に書いたファイル管理ツールなど、集中的にコードを書いたいくつかの経験を経てきました。最初はもちろん勢い任せでしたが、前後矛盾する苦い経験を何度も重ねるうちに、事前設計の重要性を理解するようになりました。設計の世界に入ったら、次はその程度の問題です。したがって、今回プロジェクト全体を管理した経験は、非常に有益な練習となりました。
まず何を作るかを明確にする、この問題は、製品を作りたいと考えるチームにとって極めて重要です。自社の製品を定義することは、戦略レベルの問題です。しかし残念ながら、今回は特に面白いアイデアはなく、責任を負っている以上、信頼性が高くシンプルなプロジェクトを真剣に作り上げることが、私がこの実習に期待していたことでした。
要するに、WeChatミニプログラムを主な特徴とする従来型のWebアプリケーションです。具体的には、目標管理システムを作ることです。
これは非常に多くの人が作っているものなので、直面する事象のモデル化については、多くの成熟したソリューションを見つけることができます。例えば、プロジェクト指向のWorktile、個人の生活管理向けのWonderList、学生向けのMy Study Life、さらにはAppleのリマインダーや、聞いたことはあるが使ったことのないその他のツールなどです。これらのツールの特徴を総合し、古典的でWeChatらしい目標管理システムをまとめ上げました。これが私たちが作るSeedとなりました。
備えるべき特性
では、Seedは何ができるべきでしょうか？
- シンプルなユーザーシステムを持ち、同期を容易にし、ユーザーの定着率を高める。
- ユーザーは自由に目標を作成・管理でき、この目標はworktileの
プロジェクトに類似する。 - ユーザーは他人の目標に招待されることができる。
- 目標は、日常的なチェックイン型（繰り返し）とプロジェクト攻略型（一回限り、マイルストーンを導入可能）に分けられる。
- メインのフロントエンドはWeChatミニプログラム。
- その他の潜在的なクライアントにも対応する。
このように、Seedは小さくて洗練された実用的なサービスであるべきであり、これはWeChatミニプログラムの本来の目的とも一致しています。
ここで「小さくて洗練されている」という特徴を強調しなければなりません。なぜ小さくてシンプルであるべきなのでしょうか？一つは、人手と時間が限られているからです。二つ目は、『人月の神話』で言及されている第二システム症候群が犯しやすい過ちを避けるためです。それは、盲目的に自信過剰になり、プロジェクトに際限なく冗長な機能を追加してしまうことです。これは、特に広告収入に関わらない私たちにとっては、労多くして益の少ない愚かなことです。簡単な例を挙げると、Mac OS版のThunderとWin版のThunderでは、明らかに誰もがシンプルで使いやすいMac版を好むでしょう。
同時に、WeChatミニプログラムとの良好な互換性も持たせる必要があります。ユーザーがスムーズに使用できるようにするためには、ユーザーのログイン名としてemailをサポートすると同時に、WeChatのopenIdをログイン認証情報としてサポートすべきです。
システムの構造
前述のように、WeChatミニプログラムを主な特徴とするWebアプリケーションを作るということは、Seedが他のフロントエンドとの互換性を持つ能力と野心を持つことを意味します。したがって、RESTfulスタイルのAPIが最良の選択肢となります。フロントエンドとバックエンドが完全に分離され、構造が明確で、消費（利用）しやすいからです。
したがって、Seedは、WeChatミニプログラムやその他の潜在的な形態をフロントエンドとし、HTTPプロトコルを通じてバックエンドが提供するリソースを消費するものとなるべきです。
バックエンドは、APIを通じて安全で信頼性の高いサービスを提供します。
このためにいくつか学び、HATEOAS (Hypermedia As The Engine Of Application State) の思想にも触れました。未熟ではありますが、可能性のある未来の一つです。
実装
APIサーバーのコーディング作業にしか参加していないため、ここではバックエンドの実装についてのみ述べます。
私は設計を戦略レベル（道）に分類し、残りの作業を戦術レベル（術）に分類するのが好きです。したがって、どの技術を選ぶか、システムを具体的にどのように実装するかは、ここに含まれると考えます。
技術
実習の要求と、Java言語を適切に使用したいという願望から、バックエンドフレームワークとしてSpring Frameworkを選択し、ついでにSpringファミリーも使用しました：
- Spring Bootをアプリケーションコンテナとして
- Spring Frameworkでビジネスロジックを実装
- Spring DataをDAOとして
- Spring Sessionでセッション管理
- Spring testでテスト
さらに、Git、TravisCi、Herokuなどのツールを使用して開発体験を向上させました。
開発プロセス
前述のように、SpringのControllerの記述体験はPythonのFlask Webフレームワークの体験と非常に似ています。おそらくFlaskはSpringから何らかのインスピレーションを得たのでしょう？リソース指向のコントローラークラスは、各リソースごとにServletを書かなければならない従来のJava Webと比べて、はるかにコンパクトだと思います。
Springはテスト駆動開発を推奨していますが、実際にこれを実行するのは容易なことではありません。テストは必ずしも好まれる作業ではないからです。専任者を割り当ててテストコードを書かせるには、学習コストが非常に高く、また人間関係上の問題もあります。そこで、開発では、各自が自分で書いたコードのテストを担当するように決めました。最終的に私がコードをレビューすることにしました。
まとめ
Seed自体について語る価値のある部分は語り終えました。次に、他のことについて話したいと思います。
自分自身についてのまとめ
実習で多くのことを学びましたが、まだ問題もあります。
プロジェクトマネージャーとして、私は全くの未熟者です。進捗管理、人員配置、その他の細かい点の把握において、多くの不足がありました。
例を挙げると：
- フロントエンド技術に関する知識の不足により、今回のプロジェクトは最終的にAPIサーバーしか動作しない可能性が高い。
- プロジェクトチームの半数しか実際に参加していない。
- 参加者へのトレーニングが抽象的で、忍耐力に欠けていた。
明らかに、私はさらに鍛錬を積む必要があります。しかし同時に、プロジェクトマネージャーと開発者という二つの役割を担ったことで、別の問題について考えさせられました。
SEerの二つの能力についての考察
システム全体のアーキテクチャと管理能力と、単一機能を実現するためのアルゴリズムの選択、調整、使用能力です。
私の大学のソフトウェア学部の授業は、後者のみに焦点を当てているようです。これは不思議なことではありません。なぜなら、アルゴリズムの習得度は測定しやすく、能力の優劣が明確に現れるからです。数学の問題を解くのと同じで、厳密な前提条件と制限の下では、人々の創造性は非常に評価しやすいものです。しかし、この「厳密な前提条件と制限」を適切に設定する能力は重要ですが、測定するのは困難です。
なぜ自己矛盾と言うのか、分かりやすく、完全に適切とは言えないかもしれませんが、例を挙げます。多くの親が、勉強の妨げになることを理由に子供の早恋を厳しく禁じながら、卒業後すぐに家庭を築くことを期待する考え方は、幼稚で非現実的であると誰もが知っています。そして、単に良い学業成績だけを持っている学生が、卒業後に万能の人間になることを暗黙のうちに期待することも、やや歪んだ考え方です。この二つの状況の違いは、後者の矛盾が前者ほど鋭くないことです。
このような実習は、確かに授業教育の不足を補うために行われたものであり、教育手段としての成績と、教育目標としての能力という二つの記号が表すものの間の矛盾を回避する機会であったと思います。