駆け出しエンジニアのオリジナルアプリ開発備忘録

# はじめに
この記事は、駆け出しエンジニアがオリジナルアプリの開発を通して学んだことを備忘録としてまとめ、一応他人に向けて書いてる風な記事となっております。
ついでに開発における手順も書いておきます。

#アプリ開発を通して気づいた改善点
####まず自分が開発を通して気づいた改善点から残します。
- 開発は`設計8割`コーディング2割だと思え
- アプリ開発の`目的を明確に`しろ
- `コアな機能`を一つ決めろ
- 浮気するな、初めに決めたものをまずは作れ
- デザインとかレスポンシブは後でやれ
- Negativityから距離を置け

# 全部一人で開発をしてみて感じたこと学んだこと
思ったままに書きます。長いので、見たい方だけ見てください。
今回はPHP x Laravelという組み合わせで、初めて誰の手も借りずに（検索は別）自力で0からアプリを開発しました。
開発も含めてPHP歴は49日。開発にかけた日数は計２５日で1日の開発時間を平均すると約5時間ほどだったかと思います。

こちらが今回開発した自己管理アプリです。
http://grower4u.herokuapp.com/
目標とタスクを立てて、進捗管理ができます。


##負よりな話
全体を通しての印象は、開発にものすごく時間がかかってしまったということ。
原因は大きく分けて３つ。

- １つ目は設計が中途半端のまま開発に入ったこと。
- ２つ目は開発手順が決まっていなかったこと。
- ３つ目はモチベーション管理の部分。

### 設計が中途半端のまま開発に入ったこと
自分は設計をするのがもどかしく、早くアプリを作りたかったので、なんとなくのイメージを紙に書き出してからすぐ開発に入りました。
なので、機能実装の構想と開発を同時並行的にしていました。これの何が悪いかというと、ゴールが定まっていないので、`無駄な作業が格段に増える`ということです。
こんな機能あったらいいな、実装してみよう！とつい浮気をしたくなります。
実装してみて良し悪しがわかり、実際に学べることももちろん多いけれど、アプリ開発をする上での自分の目的がなんなのかを軸に`優先順位`を決めないといけません。

### 開発手順が決まっていなかったこと
これも設計を怠ったことによる副作用といってよいかもしれない。
気になったところから開発に着手していたので、当然効率は悪い。必要な機能はそっちのけで、気になった細かい部分の修正をしたりしていました。
全く愚かな行為と言ってよいです。完璧主義が出ちゃいました。少しはほっといて、本当に大事な部分の開発からまず着手すべきです。

### モチベーション管理の部分
1日平均約5時間と言いましたが、5時間中4時間59分をPCの前で
ぼーっとして過ごした日もあります。1分はPCの立ち上げですね。笑
スクールとか、プログラミングに触れている人と話していると、時々、「モチベーションを言い訳にしてる奴はその時点でダメ、プログラミングやめたほうがいい」という方が意外にも結構いたりします。
気持ちはわからないでもないですが、絶対そうとも言い切れません。自分たちはコンピューターではなく人間で、感情があり、`感情によるパフォーマンスへの影響力はとても強大`です。

個人差ありありですが、自分の場合は海を越えた遠距離関係にある彼女とたびたび喧嘩をし、よくメンタルやられてました。（簡単に会えないのがキツイ）
理由は人それぞれですが、モチベーションがなかなか保てない場合は、自分の開発について誰かと楽しく話してみたり、ストレス発散の時間を無駄と思わずにあえて取ったりしてみるのが良いと思います。
完成後の楽しいイメージが湧いてくると、自然とやる気になれるかもしれません。
モチベーションを上げるのも大事だけれど、下げないことも大事です。
とにかく`モチベを下げる要因`からはなるべく離れましょう。

## 正よりな話
反省点ばかり並べましたが、学びの方が多かったのは事実です。
###オリジナルアプリ開発のメリット
- 開発の楽しさを再認識
- プログラミング力がつく 
- 客観的に考える力がつく
- 検索力がつく
- 忍耐力がつく
- 計画力がつく
- 自信がつく
- 自己解決力がつく
- 行動の結果がすぐ目に見える

あげるとキリないですがこんな感じでしょうか。

まずは、`開発はやはり楽しい`なとわかります。`自由に作れる`って想像以上に面白いです。
そして当然のことながらプログラミング力がつきます。オリジナルアプリの開発は、`基本的に自分一人`で取り組みます。
想像以上に多くのエラーにぶち当たり、Qiitaやブログ、ドキュメント等を読み漁って解決策を模索することになります。
初めのうちはエラー画面を見るだけで幻滅することはいくらでもあり得るでしょう。

自分の場合、環境構築で8時間も足止め食らったり、ドキュメントにたどり着いても読み方がわからなかったり、フォーム一つの機能実装に2時間以上平気でかかったりといくらでもありました。エラー画面の出会いなんて100回は優に超えてたと思います(盛ってるかもしれないけど気分的には本当にそんな感じ)。

しかしこのエラーを乗り越えるための道中がまさに`成長の一瞬一瞬`で、解決すると喜びのアドレナリンが吹き出し、`自信が少しずつつきます`。最初は魔法のようなエラー文も、数をこなすと解読ができるようになってきます。そして同時に、エラーへの耐性がつき、エラーの出現によって萎えることも減っていきます。
この過程を通して`自己解決力`にも非常に磨きがかかります。全部一人ですから。
プログラミングの能力だけではなく、`人間力も磨かれていきます。
アプリ開発は`アウトプットの連続`なのです。やらない手はありません。

そして、ここまでいくつもの修羅場を越えて出来上がった、
自分の最高傑作のアプリを見てみると`だいたいショボい`というおまけ付き。笑
つまりまだまだ成長できるということであり、今以上に成長したらこの先どんな世界が待っているんだど、
ワクワクしかないわけです。ドラゴンボールの悟空気分ですね。

たくさん考え、たくさん手を動かし、プログラミングだけでなく人間力も磨いていきたいですね。

なので、初めから全てを上手にやろうとせずとにかく手を動かし、経験値を積み上げていきましょう。
<hr>


# オリジナルアプリの開発手順
## 開発前
### 開発アプリのアイデアを出す。

### アイデアの出し方
#### ターゲットを絞って絞る
エンジニアの中でも`駆け出し`のエンジニアの課題に取り組もう
#### 身近な問題に目を向けてみる
服買うの面倒だけど、自分に似合うかっこいい、カワイイ服が欲しい
→　他の人に自分の服を選らんでもらえるwebサービス
#### アイデアとアイデアを合体してみる
共有 x 写真 = Instagram
共有 x 日常 = blog、Twitter
共有 x ストレス = なんかカオスなアプリ

## コアな機能を一つ明確に絞る
アイデアを考え始めるとつい楽しくて、機能をあれもこれもつけたくなってしまう。
目的は、たくさんの機能をつけることではなく、サービスを通じて課題を解決すること。
まずはコアな機能を一つ絞り、それに全力を注ぐ。

## アプリのデザインを設計
### デザインの決め方
既存のアプリやウェブサイトを実際に見てみるのが一番早い。
探すと色々面白いものがある。
https://muuuuu.org/
### ペーパープロトタイプを作成
紙とペンを用意する。
書くページの見た目を実際に紙に書き出す。
ボタンや画像の配置も忘れずに。
## DBのテーブル設計
### 情報を洗い出す
例、Twitter
ユーザーの情報
ツイートの情報
コメントの情報
### 情報を整理する
##### リレーション
ユーザーは複数のツイートを持ってる。
コメントはどれかのツイートに属している、など
##### カラム
ツイートはつぶやきの内容、画像、投稿時間を表示する
→　つぶやきのカラム、画像のカラム、投稿時間のカラム

<strong>後に変更があった場合も対応できる冗長性・拡張性を意識する。</strong>
仮にユーザーにコメントカラムがあると、ユーザーは１つのコメントしか持つことができない。
よって、コメントはコメントのテーブルを用意し、ユーザーが複数のコメントを持てるような設計が必要。

ここまでちゃんとできれば`開発の８割が完成`したようなもの。
それくらいの気持ちでやる。

# 開発スタート
## Git管理
何が何でもブランチを切って機能実装ごとにコミットして、開発をしっかりと管理しましょう。
これは死守です。初めはgitコマンドすらわけわからないかもしれませんが、
数をこなして慣れていくしかありません。

## DB設計
モデルとマイグレーションファイルを作成。
開発前に整理したDBの設計を元に、テーブルを光速で作る。
アソシエーションを組む
あとで修正できるから`スピード意識`
## ビュー→ルーティング→コントローラー→ビュー
投稿機能を例にすると、
投稿のためのビューファイルを作成し、フォームだけ用意する。
ルーティングを記述する。
アクションを記述する。
データが保存されているかDBを確認する。

これを機能ごとに中身だけ変えて繰り返す。
## デザイン設計
全ての機能の実装が終わったら、デザインの設計をする。
まずは、初めにペーパープロトタイプに落とし込んだ設計に忠実に作る。
ここで、_見た目こっちの方がいいなー_、とか、
_ここにこんな機能あったらいいなー_、とか思ってしまうかもしれないが、
こらえて、まずは何が何でも忠実に最初のものを貫きます。

## デプロイする
一通りできたらデプロイする。
ここまでくるとやっと終わった感があるが、デプロイ時やデプロイ後にバグが出たり、
画像が表示できないなど、普通に萎えるようなことが起き得ます。
気を抜かずにとりあえずデプロイしましょう。

# 開発後
## アプリを公開
SNSや友達、家族にアプリを公開する。
人に使ってもらうためのサービスを作っているのだから、
どれだけ酷いアプリでもまずは人に知ってもらい、さらに良ければ使ってもらう段階までいきましょう。

使ってみた感想が聞けたら成長のチャンス。ユーザーの素直な感想は次回の開発にとても役立つ。
## 修正点をストック
気になる部分、修正したい部分をストックしておく。
## 修正 or 新たなアプリ開発
アプリの開発から公開までを通じて得た学び、を現在のアプリに活かすか、
新しいアプリ開発に反映させましょう。

以上。