公開コードレビュー会に参加してみての感想

こんばんは。

ここ最近、コロナショックなどの影響で大きな変化を世の中にもたらし、令和時代の過酷さを身に感じて来ています。

荒波にのまれてる場合じゃない。真っ向勝負や

どうも、ハチマキです。

本日の概要 : コードレビュー会に参加してみての感想

• レビュー会概要
  • ポートフォリオレビュー者（3名）に対して、一人30分程度で現役エンジニアの方が公開レビューしていく
  • レビュー会のみ参加者：15名ほど（私はこちらで参加）
  • 平均年齢：おそらく20代中盤

• 3名のポートフォリオ一覧（個人アプリケーション）
  • 1人目：昆虫食専門のサイト
  • 2人目：一人旅行で現地で遊んでくれる人を探すような掲示板サイト
  • 3人目：本のアウトプットアプリ

総論

1番の学びポイントは、自身のマインド面に変化をもたらした。
同じような駆け出しエンジニアの人たちであろう、自身の作成したサービス（ポートフォリオ）に素直に驚かされた。

と同時に、レビューされる人はもちろん、レビュー会のみ参加している方々の温度感、熱量に焦りすら感じた。
自身を見直し、改めて計画して頑張ろってなった。

あとは、テーブル名やカラム名、メソッド名の一つ一つに意図した意味をしっかり持たせながら設計していくことの重要性を学んだ。
ちゃんと一つ一つに開発者の意味がこめられていることを知らなかった。

学んだこと

大きく下記2点

1.　レビューする側の視点を知れたこと
　→現在、レビューしていただく側のため、レビューする側の観点や流れをざっくり知ることができた

2.　勉強会に参加している人たちの熱量が高すぎて、良き刺激をもらえたこと

具体的に

• レビューする側の視点を知れたこと
  • メソッド名 / テーブル名 / カラム名は、意図した(相手へのメッセージ)名称の定義を行なっているか
  • テーブル名、カラム名が、UI画面と紐づくように意図して定義されているか
  • コードに処理の意図を感じ取れるか
  • コードは、シンプルにわかりやすく書かれているか

• レビューする時のfile確認の流れ
  • README(github) → schema → routes → models → controllers → ・・・

各fileの確認ポイント

• アプリケーション概要を把握するためのREADMEに詳しく書く
  • 概要
  • 技術ポイント
  • 機能一覧
  • 環境 / 技術構成
  • インフラ構成
  • テーブル設計
  • etc...

　※インフラ構成や、テーブル設計を記載する際は、図で表現するとイメージがついて良い

• schema
  • migration file内に、null: falseを書く癖をつける
  • テーブル内で重複するデータを禁止するために、unique: trueを書く
  • 名前に不可算名詞を使うことは、良し
  • テーブルの紐付けは、リレーションシップをうまく使い分ける
  • DBのテーブル名、カラム名をユーザー行動から考えて作成する
  • テーブル数を意識して、作成する

• routes
  • ユーザーにわかりやすく、意図したURL設計をしていく
  • resourcesメソッドを使ったroutes設定
  • member routesを活用する → 初学者の場合、get / postのみで書いてしまうことがある
  • URLに動詞を入れない（規約で決められている）
  • 単数形リソースを使った方がわかりやすくなる
  • ホワイトリスト形式とブラックリスト形式の使い分け
  • shallowオプションでroutesを整える

• models
  • 最大文字数が必要な箇所には、バリデーション(lengthオプション)を定義してあげる
  • バリデーション例外を捕捉する "!"を加える
  • 他のユーザーが編集不可能にするために、current userと紐づける
  • Active Modelを使用し、簡潔に書いていく
  • 複雑な処理は、controllersに記述していくのではなく、modelsにメソッドを用いて記述する
  • スコープを積極的に使用し、意味のあるまとまりを作る
  • has_manyを使って、追加されるメソッドを使う
  • アソシエーションを貼ることで、使えるメソッドが複数ある
  • findとfind_byの使用を明確にする
  • 該当するレコードがあれば取得、無ければ作成してくれるfind_or_create_byメソッド

• controllers
  • controllersでの処理はシンプルに記述する
  • modelsに処理を切り分ける

• その他
  • RESTの原則 → REST入門 基礎知識 - Qiita
  • Fakerというgem → Fakerでダミーデータを生成する - Qiita
  • GIF画像 → 最近よくみるGIF動画って何？ | ウェブラボ（株）スタッフブログ
  • ページングの実装 → 一覧画面のページングについていろいろ考えた - Qiita
  • 外部APIを使うと実装がいきなり難しくなる
  • DB(MySQL / Oracle / PostgreSQLなど)によって処理の挙動が若干異なることがある
  • ユーザ認証機能を簡単に実装できるライブラリSorcery → Rails+Sorceryで認証処理を実装する | SG Labs

実践してみようと思うこと

• ステップ1
  • 名称設定時は、開発者にどういう意図か一目でわかるように設定する
  • まず5月までに自身のアプリケーションをどんな形であれ、作成する
  • Octotreeのインストール（デベロッパーツール）

• ステップ2
  • 上記学んだことを自作アプリケーションに反映
  • 業務で必要であれば、上記を参考にリファクタリングしてみる

まとめ

• 周りの温度感に焦りすら感じた
• 良き刺激で本当に有難き
• やるかやらないかじゃなくて、やるかやるか。これに尽きる。ってなった
• プログラミングは、奥深いことを改めて感じ、頑張ろ。ってなった
• テーブル名 / カラム名 / メソッド名などの名称一つ一つに開発者のメッセージが込められている

こんな感じでしょうか。
エンジニアになって、前職の営業のように、とりあえず行動力があれば成果のでる世界ではないことをこの数ヶ月で肌で体感している。

またエンジニアになったことで、よく勉強会に参加するようになったし、苦手な本も読めるようになり、少しづつ自身の変化も感じるようになった。有難き。。

燃え尽き症候群にならぬよう、これからも継続的にやっていきたいと思う。

参考資料

• schema
  • migrationファイル内のnull: falseとは - Qiita
  • カラムにかける制約について整理 - Qiita
  • 複数のテーブルに対して多対一で紐づくテーブルの設計アプローチ｜スパイスファクトリー株式会社
  • https://products.sint.co.jp/siob/blog/relationship#toc-1

• routes
  • リソースベースのルーティング設定 - Ruby on Rails入門
  • Railsのroutesにつけるmemberってやつ - Qiita
  • Rails のルーティング - Railsガイド
  • 基礎Ruby on Rails Chapter8 単数リソース - Qiita
  • ホワイトリスト式セキュリティの仕組みとは？ブラックリストとの違い | DAiKO＋PLUS（プラス）
  • rails save! create! update!のバリデーション例外を捕捉する - Qiita
  • resources を nest するときは shallow を使うと幸せになれる - Qiita

• models
  • 【Rails入門説明書】has_manyについて解説 | WEBCAMP NAVI
  • 【初心者向け】丁寧すぎるRails『アソシエーション』チュートリアル【幾ら何でも】【完璧にわかる】🎸 - Qiita
  • 【Rails】findとfind_byの違い - Qiita
  • Ruby on Rails レコード検索、無ければ作成 find_or_create_by メソッド
  • Railsのモデルのscopeを理解しよう - Qiita

• Octotreeのインストール
  • Octotree - Chrome ウェブストア

• • • • • • • • • • • • • • • • • • • • • • -

勉強会は個人的におすすめです。
以上、ハチマキでした。