オモカゲ開発 20～23日目：テスト終了、紹介ページ作成
小さなお店のための顔がポイントカードになるアプリ、オモカゲを開発中のthere2です。
アプリの開発がようやく終了し、テストも大きな問題なく完了させることができました。
オモカゲ紹介用のページ作成も完了して公開する事ができました。残るはオモカゲのオンラインマニュアルを整備してリリース対応するのみとなります。
ここまでくるとアプリリリースが近付いてきていて、だんだんと緊張してきました。
テストの実施
単体レベルは画面の開発と並行して進めていましたので、画面間の連携を中心に結合テストをまとめて実施ました。
結合テストにおいては、36シナリオをあげて順に確認していきました。
やはりつなげてみると不具合は出るもので、8件の不具合が見つかりました。
特定の操作をしていないとNullになってしまう、または特定の順番で処理をするとゼロ除算が発生してエラーになってしまう、というようなエラーでした。
Flutter & Dartは比較的堅牢なプラットフォームでコンパイルで大抵の不具合は検知できるのですが、それでも注意しないとNullエラーやゼロ除算エラーが発生してしまいます。
近い将来、DartのNull安全のための機能がリリースされる予定という事で楽しみです。
不具合自体は気づけばすぐに直せるもので、修正に思ったほど時間がかからなかったのが良かったです。
複数人での開発だと結合テストで大量の不具合が見つかりがちですが、今回のような個人開発だと結合テストでも認識違いによる不具合というのはなく、非常に効率的だと感じました。
アプリ紹介ページのリリース
オモカゲアプリを紹介するページを作成して公開しました。
現在アプリの概要と紹介ページが作成済みです。
オンラインマニュアルは明日から徐々に作成していく予定です。
2日ぐらいで一通りマニュアル作成ができるのではないかと思っています。
今回、アプリの紹介ページの作成で、GoogleサイトとSTUDIO.designの二つのツールを比較検討し、最終的にGoogleサイトで作る事になりました。
それぞれ特徴、強味に違いがありますが、両方とも素晴らしいツールだと思いました。
Googleサイト
パワーポイントの資料を作成ぐらいの感覚で本当に簡単にWEBページを作って公開する事ができます。
HTMLやCSSの知識は不要です。
無料で、さらに独自ドメインを割り当てする事もできます。
いい感じのテンプレートが豊富で、簡単にテンプレートを切り替えて確認する事もできます。
こんなに優れたツールをGoogleという巨人が提供していて、Google Driveからすぐに始められるのに、それほど知名度がなく普及していなそうなのが不思議です。
一方でフォントサイズや余白、行間を指定する事ができず、凝ったレイアウトを構築する事はできません。
今回のようにアプリの紹介とオンラインマニュアルの公開といった程度であればGoogleサイトは十分すぎるぐらい目的を果たしてくれました。
STUDIO.design
最近twitterなどでよく見かけるようになったノーコードのWEBデザインツールです。
非常に美しいテンプレートと豊富な画像でプロレベルのWEBサイトが構築できると思いました。
レイアウトにおいても余白や並び順、各サイズなど非常に細かく調整する事ができます。
一方である程度cssの知識がないと何をどうすればいいのかわからない、という事になりそうで、HTML/CSSの知識はある程度必要だと思いました。
その上でツールの癖とか使い方に習熟する必要があります。
HTML/CSSの知識があってこのツールに習熟している人であれば、素敵なWEBページをかなりクイックに構築できるのではないでしょうか。
かなりのポテンシャルを秘めているツールで、将来のWEBサイト構築ではHTML/CSSを直書きする事はなくなるかもしれない、と思わせるものでした。
一方で、独自ドメインを利用する場合は月額９ドルの費用が発生する事と、定型的なオンラインマニュアルを構築するという目的に対してはtoo muchな気がしましたので、今回のオモカゲ用のWEBサイトとしては見送りました。
ただ、将来のstudio THERE2でのWEBサイト構築ではこのツールを主軸としていこうかと考えています。
オモカゲのリファクタリング
オモカゲを開発してきて、テストも一通り完了したのですが、画面間のデータの受け渡しが一部無理があるのと、UIとロジックが十分に分離しておらずメンテナンス性が悪くなっている部分があるので、まとめてリファクタリングしたくなってきました。
ただテストが一通り終わった今はタイミングが悪いので、次のメジャーバージョンアップ時に対応したいと考えています。
今考えているリファクタリングポイントは次の通りです。
・get_itとproviderが混在していて使い分けが明確になっていないので、基本providerに寄せる
・画面間の遷移がnamedとnamedでないものが混在しているので、namedに揃える。
・画面間のデータの受け渡しはパラメータではなくproviderに任せる
・できる限りUIとロジックを分離する。view/cotainer/component/basicでウィジェットを細分化して再利用できるものは再利用する。
こういったリファクタリングポイントは一度アプリを構築してから手を出すとコードが非常に綺麗に読みやすくなりそうです。
本当はアプリ構築の最初から綺麗に実装していければいいのですが、そうもいかないのが難しいところですね。
開発進捗サマリ
開発着手：2020年5月14日
作業日数：23日
作業した時間合計：148時間
ファーストリリースに向けた進捗：93%
