Quantcast
Channel: 初心者タグが付けられた新着記事 - Qiita
Viewing all articles
Browse latest Browse all 21081

無知でWebアプリをつくったときを振り返ってみた

$
0
0

はじめに

こんにちは。新卒エンジニアの@ohakutsuです。
これは、Qiita夏祭りのシステム開発における過去の失敗と乗り越えた方法について共有しよう!の記事です。

今回は僕が大学生の頃、

  • 初めてのWebアプリを開発していて失敗したなと思ったこと
  • 実際に改善をして乗り越えることはできなかったが、こうすればよかったなと思ったこと

を書いていきます。

実際に失敗を乗り越えた方法ではないですが、お許しください。

開発していたWebアプリについて

まず、どんなものをつくっていたのかというと、ごみの日アプリのPWA版です。
機能としては、

  • ユーザーが設定した地域のごみの収集日を見ることができる
  • ユーザーはごみ名を検索すると何ごみか知ることができる

という、ごみの日アプリによくある機能です。

なぜごみの日アプリをつくろうと思ったのかというと、

  • 僕の住んでいた地域にはごみの日アプリというものがなかった
  • プログラミングを知った頃で、プログラミングを使って何かしらつくってみたい

というのがありました。

その頃、プログラミングって面白いんじゃないの?と思い始めていたころで、何でもいいからつくってみたい!という気持ちでいました。

どんな開発形態だったのか

開発メンバーは、僕と大学の友人3人の4人で開発をしていました。
僕含め、メンバーのレベル感は次のような感じでした。

    • C言語を大学の授業でさわったことがある
    • 大学の授業で、HTML、CSS、JavaScriptをさわったことがある
    • Railsの入門書を半分くらいやってた
    • PythonでAtcoderやpaizaの問題をやってた
    • Gitを触ったことがある
  • 友人M
    • C言語を大学の授業でさわったことがある
    • 大学の授業で、HTML、CSS、JavaScriptをさわったことがある
    • C言語でAtcoderやpaizaの問題をやってた
  • 友人N
    • C言語を大学の授業でさわったことがある
    • 大学の授業で、HTML、CSS、JavaScriptをさわったことがある
  • 友人O
    • C言語を大学の授業でさわったことがある
    • 大学の授業で、HTML、CSS、JavaScriptをさわったことがある
    • SQLを触ったことがある

全員、大学の授業でプログラミングはしたことがあったため、簡単なコードを書くことはできるという感じでした。

ごみの日アプリをどんな構成で開発していたかなのですが、誰もWebアプリを開発したことがなく、手探り状態でした。最終的には、以下のような構成になりました。

  • フロントエンド
    • HTML, CSS, JavaScript
    • PWA
    • バックエンドのAPIを叩いて、データを取ってくる
    • FirebaseHostingで公開
  • バックエンド(API、管理者画面)
    • Rails
    • Herokuで公開

フロントエンドは全員で、バックエンドは僕が開発をしていました。

なぜ、フロントエンドとバックエンドを分けることになったのか。
Railsのテンプレートを使えばいいじゃないかと聞こえてきそうです。
分けた経緯を簡単に説明すると次のような感じです。

ごみの日アプリをネイティブアプリでつくろう!
↓
ネイティブアプリつくったことないから、自分たちが今できる技術でつくれないかな〜
↓
Monacaってやつを使うとHTML, CSSとかでつくれそう
↓
早速つくっていこう!
↓
(ある程度つくってみて、)やっぱり難しい...
↓
PWAってやつ使えばアプリっぽくできるからそれにしよう

PWAにする段階で、Railsのテンプレートに移行してしまえばよいのですが、

  • 他のメンバーがRailsのテンプレートのことを知らない
  • 移行するのが面倒

という理由があり、分けて開発をすることになりました。

また、ソースコードの管理は、
始めは、大学のパソコンで、全員アクセスできるディレクトリからローカルにコードをコピーして開発し、完成したら全員アクセスできるディレクトリにコードを保存していくというスタイルでやっていました。たびたび起こるコンフリクトは僕がコードを読んで手動マージしていました。
しかし、それに苦労するのが嫌になり、途中からはGitHubで管理をするようになりました。ですが、ブランチというものがあることを知らず、コードを書いたらmasterにプッシュをするようになっていました。また、コンフリクトが起きた場合、メンバーがコンフリクトの解消を僕に依頼するようになっていたため、GitHubを使ってからもコンフリクトの解消は僕が行うことが多かったです。

失敗したなと思ったこと、こうすればよかったと思ったこと

1. 始めに基礎を学ぶ時間を設けるべきだった

メンバー全員がWebアプリを開発したことがなく、終始、何をしなければならないのかすらわからない状態でした。
これを解決するためには、実際にWebアプリの開発を最初から最後までやるしかないと思います。
そこで、Web開発をするにあたっての基礎を勉強する時間を設けるべきだったなと思います。ここで言う"基礎"というのは、入門の技術書(Railsとか)を1度やって、開発の雰囲気・流れを掴むことです。何もやったことがない場合よりかは、圧倒的に差が出てくる部分だと僕は思います。
また、次に上げる「バックエンドの属人化」や「ソースコードの管理」の問題を防げたかもしれません。

2. バックエンドの属人化

メンバーのうちRailsをさわれる(というよりかは、Railsという存在を知っている)のは僕だけでした。そのため、Railsに機能の追加や変更をする際には、僕がいなければならないという状況でした。また、相談をする相手がいないため、苦労したのを覚えています。
これに関しては、チームで使う技術は、勉強会などを開き、使う技術に触れる機会というのを増やすべきだと思いました。メンバーがある程度その技術を知っていることで、1人にすべてを任せる必要がなくなり、また、困った際に相談をすることができると思います。

3. ソースコードの管理

先に述べていたとおり、ソースコードの管理は全くと言っていいほどできていませんでした。また、新しく書いたコードを上書きしてしまうので、正しく動作しなかったとき、戻すのにも苦労しました。
これは、Gitの知識をメンバーに共有し、練習する機会を設けるべきだったと思います。GitHubを使い始めた頃、メンバーに対して使い方を教えていたのですが、最終的にはmasterにプッシュすることしか覚えていませんでした。やはり、その場その場で教えるのではなく、勉強する機会を設け、1人で使うことができるまで練習をするべきだったと思います。

最後に

他にもこうすればよかったと思うことはたくさんあります。
しかし、それは今の自分だからであって、昔の自分にできるものとできないものがあると思います。
今回は、これなら昔の自分でもできたなと思ったものを3つ上げました。
これらを考えてみて思ったことは、やはり何事も最初に基本に触れてみることが重要だと思いました。

もし、こうするともっと良さそうだよ、それは違うんじゃないのと思うものがありましたら、ぜひ教えて下さい!


Viewing all articles
Browse latest Browse all 21081

Trending Articles