Rails Developers Meetup 2018 Day 3 Extreme 参加レポ
この記事何？
2018年07月14日にやってた Rails Developers Meetup 2018 Day 3 Extreme に参加したレポート
気になったパートだけ抜粋してメモ書きと感想。
Rails DM 1-B (曖昧さを受け入れて開発していく方法)
新規サービスの立ち上げの時にエンジニアリングにフォーカスした個人的な考え。 意思決定など。
曖昧さ
ソフトウェア開発で事前に要件や仕様がハッキリと決まっていることはまず無い。 曖昧さがゼロになるのは、ソフトウェアを実現したときだけ 熟考によって作るものがどんどん変わる
しかし、リリース日はハッキリしている。
作るものを Fix すればいいじゃないか！ (静的なモックを作る) けど、変わる時は変わる。
考えがまとまるのを待っているとエンジニアは暇だし、時間がもったいない。 一度決めたけど、他にいい案が出たらできる限り採用したい。
作りながら考える、考えながら作るをチームでやっている
作っている途中に仕様が変わったら変わったで受け入れる。 小さくどんどん作って見せるイメージ
Docker イメージでサーバー定義を書けば、 PR・マージするとデプロイできる。ぐらいの爆速感大事。 サーバー構築どれでやる？ デプロイ環境を構築する技術は大事。
適切なケースを選ぶためには結局ケース・バイ・ケース 事例がオープンなんで、他の人の事例を参考にしてみる。
素早く実装≠雑に設計
将来どうなるかわからないので、その時の手持ちの情報で必要十分なものを設計する。
マネージドの知識・経験があったとしても設計や実装にはコストがかかる。
画面変更をする時に GraphQL 使っていれば呼び出し方変えるだけでよかったりするので、いい感じに変更に強くなる。 チームがアーキテクチャに合わせる。
Rails DM 2-B Octocatは技術的負債の夢を見るか?
技術的負債とは？ なぜ技術的負債=>害なのか？ - モチベーションが低下する - チームの健康性の低下 - 離職・採用難
種類 - クソコード(今日はこれ) - スケールしないアーキテクチャ
ケース１ 独自 DSL/フレームワークをアプリケーションコードに入れる
バグフィックスや機能追加のワークアラウンドが積み重なって、見通しが辛い。 開発者が気軽に入れやすくなる設計 属人性上がる
ケース２ 責務が曖昧なクラスを取り入れる
疑似サービスクラス的なコード。 結合度が上がり続けて、インスタンスの相互参照が止まらない。 触りたくないし、触るとバグるという事象が発生。 ビジネス的にコア要素だったりする。
要因
時間不足 技術力不足
技術的に価値があると、負債が溜まりやすい
- 仕様がいっぱいある
- 変更が多い
- 度々触る機会がある
サービスを走らせ続ける限り、コードの変更は避けられない。
技術的負債を避けるのではなく、向かい合う
チームで地図を共有する Rails はレールに乗り続けることで、地図が共有される。 地図のない世界もあるし、持たない人は探す・知ってる人から書く 持ってる人はどんどん共有してこう。
5-B オブジェクト指向設計実践ガイドこれだけは実践しとこうガイド
【前提】限られた時間とリソースの中 【目的】最小限のコストで、最大限変更に強いコードを書く
実用的な設計とは、未来を推測するものではなく、未来を受け入れるための選択肢を保護するもの
- TRUE 原則
- 単一責任
- コメント
T 見通しが良い R 合理的 U 利用性が高い E 模範的
TRUE 原則から外れる場合は、コメントで補う。
常に TRUE 原則を意識する。 総力戦で変更に強いコードを作っていこう
常に意識TRUE原則を心がけ単一責任できないときはコメント
番外編
コピペは時として武器になる。 抽象コストを考えるコストが高くなるぐらいならコピペしちゃう。 コピペできないほど長いコード複雑なコードは書かない せいぜい３回目ぐらいまで。４回目以降は普通に抽象化しようね。 コピペを何回かくりかえすことで、どこにおいたら最適化が見えてくる
間違った抽象化よりはコピペしようね。
コードの合理性はプロダクトのフェーズ、チームによっても変わるのでよく話そう 議論の土台共通言語が必要。
ブルーハーツに学ぶ
あれもしたいこれもしたい もっとしたいもっともっとしたい 限られた時間の中で 借り物の時間の中で 本物の夢を見るんだ
なるほど。かっこよい。
6-B IKUSEI on Rails
どうやって育てれば、どうやって育つか。
学ぶ方法は２つある。
- 教えられて学ぶ
- 発見して学ぶ
研修の目的としては、自ら課題を発見して学べるエンジニアになれるように育成する。
育成が最適化している。 研修の長さ・速度、パイロットプロジェクトレビュワーの人数。
パイロットプロジェクトとは？
プロダクトオーナーの要求にあうものを20日間で開発する。
設計や計画の時点では想定していなかったことが起こる。 優先順位を付けてオーナーと交渉するようになる。 機能の性能面を考えつつ話す。
プロダクトオーナーがわざと仕様を漏れを出すようにトラップを用意する。 あえてハマってもらう経験を積んでもらうのも大事。
先輩たちとプルリクエスト上で議論することは大事。 自分の理解度を確認できる。
先輩たち
良いところは良いと伝える
これってここに書くべきだっけ？という感じのレビュー 考えてもらうことも大事。 なぜこう書くか？というのをしっかり伝えた。
相手に伝わるプルリクエストとは？
定期的な 1on1 早いレスポンス
エンジニアのためのスライドデザイン実践講座
- 伝わる・読まれるスライドレアウとの作り方。
- トークの場にいなくても Web で読んでもわかりやすい
- 簡単にできる。
- 話の構成や喋りやすさには踏み込まない
表紙は OGP でも出るので、読みたくなる表紙。 自社やサービスがアピールできる。
タイトルをロゴっぽくする。 吹き出し便利(アクセント)
ビックリマークを明朝で少し斜め。勢いが出る。
カラーリングは MAX でも ４つぐらい。 主に2色。たまに白黒。
情報の整理。
フォームオブジェクトとの向き合い方
Rails のきれいな設計を最初からするのは難しいので、反復して作ると良さそう。
DB のテーブルにほぼ一致した構造のデータが POST されることはなかなか無い。 ユーザーが目にする情報単位と正規化されたデータ構造は異なる。
DB に永続化するだけでは済まないことがある。
差異を埋めるテクニック
accept_nested_attributes 辛い。 callback も辛い。
最も有用な設計原則。 プログラムのプレゼンテーション層とその他の機能をうまく分けると良い。
入力とその他で分ける。
params から値を取り出し、 Hash や文字列として扱う。 http 由来のデータも先に Hash の中に含めちゃう。
フォームオブジェクトでやること(入力)は PORO として実装できる。 インターフェースが安定するので、ロジック部分を変化/洗礼する自由度が得られる。
入力とロジックを分けよう。
ビュー/コントローラー/AR::B の三層構造で賄えない場合、薄い層をもう一層作る。 Web 入力値とロジックに必要な入力の境界として扱えるようにする。
ナイーブかつテストが書きやすいレイヤからはじめて、反復しながら変化していけるようになるといい！
メモは取れなかったけどすごかったやつ
感想
今回もボリューム満タンな感じで圧倒的なインプットでした。 オブジェクト指向これだけは実践しようガイドとか読み返したくなるぐらいに面白かったし、自分の理解できる世界が広がってるなぁという風に感じれた。
あと、赤塚さんの話は毎回おもしろい！ スライドづくりの参考にしよう！！！
そして、 youtube にあげてもらえるの復習だったり、裏番組見れたりで良いなぁという気持ち。
また Rubykaigi で悩んだ登壇者としゃべるミッションは無事に達成できました :tada: 個人的には１人だったのも良かったかも。 多分知り合いがいるとそこと話しちゃうけど、それがないとしっかり話すしかなくなる。 そんな感じなんやろうなぁ〜
