TECH CAMP 18日目 ぎっとはぶ…?

自分用のアウトプット。

Webアプリケーションの設計について。

基本設計(外部設計)
要件定義の内容を、開発に必要な内容へとまとめる。

詳細設計
実際に書くべきコードを洗い出す作業。

画面遷移図
どの画面でどんな操作をしたらどのページに移動するか、を図で表記したもの。

DB設計
開発で使用するDBの表を設計すること。
テーブル、カラム、関連付け(アソシエーション)など。

エンティティ
サービスで扱われるデータ自体のこと。
「データが登録されるとき」に着目して洗い出すとよい。
※異なるジャンルの情報は混合させないようにする。
Pictweetでいえば、ユーザーに関する情報、共有する写真に関する情報、など。

アソシエーション
1対多のとき、多の方には外部キーを置くことができる。

user has_many tweets ←user_idという外部キーを
user has_many comments ←user_idという外部キーを
tweet has_many comment ←tweet_idという外部キーを

モデリング
エンティティの分類や関連付けなどを行い、模型のように表すこと。
エンティティ自体を見直したり、さらにエンティティ同士の関係性を考え、図などに表記する。

正規化
データベースの構造を効率的でシンプルな形にすること

非正規形 … 何もしていない状態。
第一正規形 … 重複する値やカラムを分離する。
第三正規形 … 情報が混在するエンティティを分離する。

制約
DBにおいて、カラムに設定できるもの。
データが保存される際に制限をかけることができる。
バリデーションの仕組みと似ている。
※DBに直接設定するため、後に変更することになると非常に手間がかかるので注意。

NOT NULL制約
テーブルの属性値にNULL(空の値)が入らないように制限する制約。
t.string :name, null: false のように記述。

一意性制約
テーブル内で重複するデータを禁止する制約。
同一メールアドレスの登録などを防ぐ。

主キー制約
そのデータが空になることがなく、かつ重複していないことを保証する制約。
Railsでテーブル作成をすると、主キー制約はidカラムとして自動作成される。

外部キー制約
外部キーの対応するデータが必ず存在しなくてはいけないという制約。
t.integer :user_id, foreign_key: true のように記述。

チェック制約
値が保存される際に条件を満たしているかチェックできる制約。
(名前の文字数制限など)

ER図
DBのテーブルなどを図で表記したもの。
1対多の関係がひと目でわかるようにする。

Git
ソースコードなどのファイルやフォルダの変更履歴を記録・追跡するためのバージョン管理システム。
セーブポイントを作れるイメージ。

GitHub
Gitの仕組みを利用し、簡単に複数人での開発ができるようにしてくれるWebサービス。
途中まで実装したプログラムのコードを簡単に共有でき、コメントをもらうことができる機能がある。

リポジトリ
Gitの管理化にあるファイルやディレクトリの変更記録を保管しておく箱のようなもの。
管理したいアプリケーションのディレクトリを、バージョン管理の範囲として指定。

ローカルリポジトリ
ローカル環境に置くリポジトリ。

リモートリポジトリ
外部サーバー上に置くリポジトリ。
これを直接修正するのではなく、ローカルリポジトリの方を変更し、それを反映させる。

commit
ファイルやディレクトリの変更修正をリポジトリに記録すること。

コミットメッセージ
ファイルの変更修正の内容を分かりやすくするための記述。

push
ローカルリポジトリでのコミットをリモートリポジトリに反映させること。

commit log
今まで行ったcommitの履歴が確認できる。

インデックス
変更修正が一時的に保存される場所。
ここに保存されている内容がcommitの対象になる。

add
追加するファイルや変更修正をインデックスに登録すること。
チェックを外すと、インデックスには追加されない。

ブランチ
リポジトリで管理しているファイルやディレクトリの変更の流れのこと。(commitの連なり)
リポジトリは必ずブランチを持っている。
開発における本流をマスターブランチ、分岐したものをトピックブランチと呼ぶ。

ブランチのメリット
・リポジトリで管理しているファイルやディレクトリの本流に影響を与えずに作業ができる
・ブランチを切ることで、目的別に同時並行で作業ができる
・不具合が発生した場合も対応が容易になる。

ブランチは実装機能ごと、または変更修正作業ごとに作成をする。
例)ツイート投稿機能、ユーザー管理機能、ごとに分ける

コードレビュー
ブランチをリモートリポジトリに反映後、それでOKかどうかコードを確認してもらうこと。
コードレビューを担当する人をレビュアーという。

レビュアーはコメントをすることができ、修正が問題無ければLGTM(Looks good to meの略)と伝える。

merge
機能実装のために作成したブランチを、リモートリポジトリ上のマスターブランチに反映する作業。

pull
リモートリポジトリの変更をローカルリポジトリに取り込む操作。

get cloneコマンド
リモートリポジトリを自分のPCにダウンロードするコマンド。
git clone https://github.com/ユーザーネーム/git-app.git
https://〜appまでの部分がリモートリポジトリのURL。

リモートリポジトリとローカルリポジトリがすでに紐付いているのであればpull
リモートリポジトリだけ存在し、リモートリポジトリからローカルリポジトリを作成したい場合はclone

新しい用語がたくさん出てきて、まだまだ整理が追いつかない状況です。
Rails勉強会ということで、同じ85期の人たちがzoomで一堂に会し、チームに分かれてエラー問題を解くというイベントがありました。
なかなか正解まではいかなかったものの、自分ひとりの作業ではなく共同でやるというのが新鮮で非常に面白かったです。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする