ITとdesign エンジニアのブログ by エンジ庭

IT業界のトレンドなどIT分野について学んだ事を書いていきます。プログラミング技術などについて現在Qiitaメインに書いてますので、そちらを参照ください。  https://qiita.com/kota_sho

個人アプリまとめ

2019-07-17

 

勉強も兼ねて家計簿アプリを作りました。

細かい部分で修正が必要ですがここで一旦、個人アプリ開発に取り組んでみた感想をまとめます。

 

①よかったこと

②難しかったこと

③改善できるところ・反省点

 

概要:

アプリ内容:家計簿アプリ

使用言語・フレームワークRuby on Rails

 

①よかったこと

考える力、想像する力を鍛えられた

今回は、課題を与えられてないので何のアプリを作るのかというところから自分一人で考えました。そしてアプリに必要な機能は何か(必須なもの、応用的なもの)、それらを実装するために必要な処理の流れを考え全体の設計をしました。また、家計簿アプリは分析ツールであるため、データが非常に重要です。そのためDB設計にもかなり神経を使いました。チーム開発も勉強になりましたが、一連の処理を自分一人で考えたことは非常に鍛えられました。3ヶ月間スクールで課題に追われながら、何とかやりきったのが精一杯でしたが、個人のアプリを開発することで、いい復習にもなりましたし、少しずつ勉強したことが繋がってきています。

 

 

②難しかったこと

よかった点で、自分で考えれたということを書きましたが、同時にそれは難しいことでもありました。「自分の考えたアプリを作る」ということは自由度が高い分、何から手をつければいいかわかりませんでした。もちろん設計〜開発という流れはありますが、細かな部分をどう進めれば良いか分かりませんでした、またスクールの課題で開発したクローンサイトのように見本がないので、機能の抜け漏れもあり、手戻りも結構ありました。ゲームで例えるとオープンワールドみたいな感じですかね。自由だけど何していいか分かんないみたいな

 

また、「設計」にどれだけこだわるかという点。

自分は元々、完璧主義なところがあるので、スクールに通うにあたってそこは意識して捨てるようにしました。多分まだ残ってますが。今回の個人アプリも設計を固めてから開発始めたいという想いはありましたが、完璧主義すぎていつまでも開発が始まらないという懸念がありましたので、今回は実験的に、大まかに作って仮で開発をスタートさせてみることにしました。だいたい1週間掛けました(毎日ずっと考えてたわけではありませんが)。案の定抜け漏れ、矛盾などわんさか出てきます。

経験を積んで、設計〜開発の流れもスムーズにできるようにしていくのが1つの目標です。

 

 

③改善できるところ・反省点

バリデーション:

「月ごとカテゴリー毎に金額を計算し、合計金額を表示する」という機能をつけました。この時、データベースに値が入っていない時、ページを表示しようとしてもエラーになりますので、値が入っていない(nil)の時は、¥0を返すように設定しています。

それ以外にまだ設定していないところがいくつかあります。

・「予算設定」では何回も同じ年・月に金額を設定できてしまうので、2回目はできないようにする→「すでに設定されています」の表示や、編集ページに飛ばすなどの対策が必要。

・収入、支出入力ページで値が入力されなかった時のバリデーション。

 

データの取り方、加工のしかた:

上述の月ごとにカテゴリー毎に金額を計算し、合計金額を表示するという機能について、そのコードは修正の余地ありです。

検索結果は以下のように表示されます。

 

f:id:Arts91:20190708214210p:plain

 

そしてコードは、

def show
 
@search_year = params[:year]
@search_month = params[:month]
detail_year = @search_year
detail_month = @search_month

# 以下問題ありコード。修正を検討する
# 長すぎる
# カテゴリーIDを1つずつ取ってきているため、もしユーザーが独自にカテゴリーを追加できる機能をつける場合、対応できない
 
#収入計算
@income_detail_saraly = Income.group("YEAR(date)").group("MONTH(date)")
.where(income_categories_id: 1, user_id: current_user.id).sum(:amount)
@income_detail_saraly[[@search_year.to_i, @search_month.to_i]]
@income_detail_saraly_view = @income_detail_saraly[[@search_year.to_i,
@search_month.to_i]]
 

まず@income_detail_saralyに入っているのはデータベースの収入テーブルの給与カラムの合計金額。ここでは月ごとにハッシュ形式で取得できてますので、ページで年、月を選択すると、その対象となる期間の合計金額を表示させるという流れです。

問題はカテゴリーを一つずつ取ってきているということ。

影響1:

1カテゴリーのデータを取得するのに数行書いていますので、複数のカテゴリーについて書くとコードが非常に長くなり、見ずらくなる。いわゆるファットコード。

影響2:

1つずつコードを書いてカテゴリーのデータを取得しているということは、仮に将来、

「ユーザーが自分で好きにカテゴリーを作り追加できる」という機能を追加したいと思った時に対応できない。柔軟性に欠けます。

 

DB設計:

データベース設計もまだまだです。

例えば、家計簿アプリなので、いろんなところで日付を扱いますが、カラムの型がバラバラで、日付をもとにデータを検索する際に、いちいち日付を認識できるようにコードを書く手間が掛かりました。

@income_detail_saraly = Income.group("YEAR(date)").group("MONTH(date)")
.where(income_categories_id: 1, user_id: current_user.id).sum(:amount)
 

group.("YEAR(date)").group("MONTH(date)")と書かないと、日付がうまく認識されず検索がうまくいきません。

あとは、収入用のカテゴリーと紐付けるcategory_idカラムを作り忘れ、途中で追加しました。途中でも追加、編集はできるとは言え、最初の段階でがっちり固められるようになりたいです。

 

gitの扱い

スクール似通っていた時から、gitの作業はGUIgithub desktop)を使っていました。バージョンが古く、新しくしたかったのですがなぜか上手くいかずそのまま使いました。新しいバージョンになれるように、今からでも使いたいです。また、GUIだけでなくコマンドでも作業がスムーズにできるよう慣れていきたいです。

 

以上