目的

• AppBrew Rails Best Practiceの内容を理解した上でmake-serverのコードを書いていけるようにする

• 守れていない場合にレビューで指摘しやすくする

やり方

• みんなで一緒に読んでいく

• 適宜深ぼったり議論したりする
• ここの部分とか守れてないよねとか
• こうするとよさそうとか
 

• Rubyの書き方に従う
• 例：サブクラス書くときはsuper書くとか
• どういうライブラリを参考にするのがよさそう？
• r7kamuraさんがかいてくれてるやつ
• serializable

• 誰が書いてもそうなるコードを目指す
• rubyは自由度が高いので
• 隠し機能使わないとかより、Rails Guidesに従うというような意味合いがつよそう？
• arrayで返すのやめてほしい search
• この変数この使い方みたいなの
• 順番がアルファベット順
• でもidは上に来てほしいはありそう
• has_manyとかはそろえたい→やりたい

• 開発環境構築手順を保守する
• 頑張りが必要そう
• Dockerでやるデメリットある？
• おそい？
• コマンドが長い
• なさそうであればよせていけるとよさそう

• ログを出す
• bulletだけ落とす
• 過去にやってたが多すぎて無理
• rails server or test
• テストで出すやり方

• YARD
• パーサーがある
• https://yardoc.org/types.html
• YARDは義務教育？
• YARDのlintある？
• いれよう
• struct

• モデル
• 複数モデルまたがる場合はServiceから呼ぶ
• 依存関係が循環するとダメ
• ActiveRecordに存在しないモデルも積極的に生やして良い

• 独自のアクション名を使わない
• bulk系はresourceを使う？

• 不要なルーティングを定義しない
• pathが作られないことによって何が嬉しいのか
• →聞いてみる @Pin📍

• 適切なステータスコードを返す
• ざる
• 403使うべきか404使うか決めたい
• to cは基本404でよさそう
• to bは404 or 空配列にしてた
• 方針決めましょう
• テックリード人おなしゃす！
• seo
• 基本404, 301
• 1mmも権限持ってないときは404、
• 適切ななのか、統一するのか

• hashのやつ
• strongパラメータのやつ聞く