見出し画像

アプリ開発のアウトプットをする上での反省点。ウェブカツ「Webサービス部」

しん@YouTube

私は、プログラミング学習サービス「ウェブカツ!!」を利用している。

この記事は、ウェブカツの学習過程を進める上で、自分が「もっとこうやっておけばよかった」と思った点について記事にしていく。

これからプログラミングの学習をする人の参考になれば幸いだ。ウェブカツを利用していない人でも通用するものがあるかと思う。

私は今回、ウェブカツのWebサービス部で学んだ内容を、レビュー投稿アプリという形でアウトプットした。今回はそのアウトプットに取り組むにあたっての反省点について書いていく。

アプリ開発のアウトプットを進める上での反省点

要点は以下だ。

・「処理フローをもとにコードを書く」ことを早く始めればよかった
・画面設計をもっと丁寧にすればよかった
・機能の実装は、当初の設計の内容を優先すればよかった

それぞれについて詳しく書いていく。

「処理フローをもとにコードを書く」ことを早く始めればよかった

開発では「処理フロー」をもとにプログラムを書いていく。処理フローとは、以下のようなものである。

ポスト送信
↓
バリデーションチェック
↓
もし、バリデーションチェックがうまくいってたらDB登録
↓
画面遷移する

処理の流れを書いて、その流れを元に実装していくというものだ。

私ははじめ、以下の方法でやっていた

■ダメなやり方
サンプルコードを見る→サンプルコードを見ながら書く→サンプルコードを見ないで、サンプルコードを思い出しながら書く

というやり方だ。結局、頭で暗記して定着させようとしていただけだった。

しばらく時間が経つと、処理の流れを忘れてしまう。結局定着しなかった。

処理フローを意識するようになったのは、Webサービス部の講義３周目を見たときだ。処理フローだけ見ながら書いてみることを実践してみた。

驚くほどに、すんなり書けた。そして何より、「自分で書いてる感」があり、しっくり来た。

普段エンジニアとして現場でやってるが、それと同じことをすればよかったのだ。（勉強だと思って畏まって取り組んだのは誤りだった）

処理フローを意識して書くことで、処理の中の重要な骨格を意識しながら実装できるから、途中で自分のコードの内容を見失うことも少ない。

そのことに気づいてから、次のやり方に改めた。

実装したい機能の内容を元に処理フローを書く
↓
処理フローを見ながらコードを書く

これにより、「自分で実装する」ということを身を以て体感できた。むしろ、このやり方に変えてから圧倒的にスピードが上がった。普段業務でやってることに近しい流れだったからだ。

お手本なんて、実際の現場には存在しない。

実現したい機能を処理フローに落とし込み、フローを元にコードを書く。エラーが出れば修正してやり直すし、分からないことがあれば調べて試してを繰り返す。

この流れを体得する狙いが、Webサービス部にあると感じた。実際、アウトプットを終えて、景色が変わったのは間違いない。

・画面設計をもっと丁寧にすればよかった

画面遷移図なるものを作成し、それを元に開発を行った。しかし、画面設計が雑すぎると、途中とても困ることになった。

私の画面設計は以下のような感じだった。


ここから初めて、とても苦労することになる。主に以下の問題が起きた。

・色をどうするか、開発途中で悩む
　ベースカラーを決めてはいたが、いざ当てはめてみると、しっくりこなかった。また、ボタンや枠などの色を何色にするか、逐一悩んだ。CSSを書き換えてみては試しの繰り返しだった。最初のデザイン案の時点でカラーコードまで検討できていれば、わざわざコードを替えてはリロードして…という操作を繰り返す必要もなかったと猛省する。

・画面レイアウトがあいまいで、都度検討する必要がある。
 最初の画面設計の段階では、このページになんのボタンを配置するか。くらいの情報しか持たない状態で開発をスタートした。ボタンを実装するのはいいが、どこにどのように並べたらいいかは、実装のたびに考えていた。結局、自分の中でしっくりくるまで、CSSを書き直してはリロードしての繰り返し。コードを書くのか、デザインをするのか、これらは分けて作業した方が、格段に捗ることを身を以て知った。

余談だが、次回以降のアウトプットでは画面レイアウトの作成をadobeXDで行っている。開発途中で、レイアウトや機能の変更はポロポロと出てはくるが、大まかの構成がブレることはなかったし、何度もデザインに立ち返って開発できた。

機能の実装は、当初の設計の内容を優先すればよかった

開発を進めていると、「もっとこうしたら面白いんじゃないか」という衝動が不意に起きる。レビュー投稿画面での、☆マークなどはその一つだ。

スクリーンショット 2021-05-14 8.47.18

レビューするにあたり、５段階で評価するのは、当初の設計では考えてなかった。（それもそれでどうかと思うが）

ただ、レビュー投稿にこの星の項目を増やしたおかげで、以下の手間が増えて、開発にさらに時間がかかった。

（評価が未入力の場合は、評価星0とするのか、それとも1以上のクリックを必須にするのかなどの悩みもいろいろと生じた）

・星をクリックしたときのアニメーションの実装
レビュー投稿画面では、星をクリックしたときのアニメーションを付与している。

また、星の色を替えてみたり、レイアウトを調整してみたりと表現に苦しんだ。５段階評価を数字で入力させて処理するのは簡単だが、今回は、クリックした星の位置を読み取り、その位置に適合した数字をデータベースに保存する。画面表示、ボタンの動作、登録処理すべて行うことになった。

・レビューの星の数での検索機能の実装

キーワードや投稿者の属性で、レビューを検索する機能の実装時に、検索項目に星の数を追加した。


・レビュー一覧・詳細画面での星の表示

星の表示が検索結果だけでない。自分の投稿を確認する画面や、別ユーザーの投稿を確認する画面でも表示が必要だ。データを取得して、データ内容に応じて、星の絵柄を変更する。星で表現する機能を追加したおかげで、あらゆる箇所での修正が必要になった。

今回は、例えばの話で星の機能を上げたが、他にも、アプリの概要を説明するページを設けたり、自分の投稿一覧をマイページから取得できるようにしたりという機能は、やりながら思いついた機能だ。

思いついたばかりに、そちらに気を取られてしまって、「まずは使える状態にする」ことが遅れてしまった。

当初開発すると決めた項目を優先して開発し、思いついたものを追加で開発するという流れにすればより良かったと思う。

反省は次に生かしてなんぼ

というわけで、これらの反省点を踏まえつつ、次回以降も取り組んでいく。

ちなみに、アプリの開発背景は以下の記事でまとめている。

機能については、以下の記事でまとめた。

よかったら読んでみてね。

それでは。

いただいたサポートは、夫婦でのクリエイター活動に利用させていただきます。