Slide 1

Slide 1 text

インプットとアウトプットの サイクルを回す暮らし 吉祥寺.pm 29 @utgwkk (うたがわきき)

Slide 2

Slide 2 text

自己紹介 ● @utgwkk (うたがわきき) ● 株式会社はてな Webアプリケーションエンジニア ● 主にTypeScriptとReactを書いて 暮らしています

Slide 3

Slide 3 text

これまでのあらすじ ● アルバイトエンジニアとしてサーバーサイドのコード (Perl) を書いていた ○ たまにJavaScriptも書く ○ アルバイトはコードレビューのレビュワーにならない ● 2021年に新卒入社 ○ TypeScriptとReactを使う新規案件のエンジニアになる ○ サーバーサイドのコードは書かない !! ● 暮らしぶりがガラッと変わる

Slide 4

Slide 4 text

先に1年間暮らしてきた感想 ● 思ったよりはやっていけていると思う ● 今のところ、行き詰まっている感じもなく暮らせている

Slide 5

Slide 5 text

振り返ってみる ● 試行錯誤をする ● いろいろ目を通してみる ● アウトプットをする ● コードレビューをする

Slide 6

Slide 6 text

手を動かすのが手っ取り早い ● ドキュメントやチュートリアルを読むだけだと実感がわかない ● 世界観を把握するのには手を動かすのが手っ取り早いと思う ○ ドキュメントを読むだけでは分からなかった実感を持てる ○ うまくいく体験・うまくいかない体験ができる

Slide 7

Slide 7 text

簡単に試行錯誤できる環境を作る ● 簡単にセットアップできるツールがあると良い ○ Reactならcreate-react-appとか ● 趣味なら何をやっても・いくら壊してもよい ● 作りたいものを作ってみるのが手っ取り早い ○ 他言語からの移植でもよさそう ○ 例: twitter-textのPerl実装 Twitter::Text を公開した - 私が歌川です

Slide 8

Slide 8 text

いろいろ目を通してみる ● 片っ端からドキュメントを読む ○ チュートリアルからAPIリファレンスまで ○ たまに思い出して役に立つこともある ● 片っ端から型定義ファイルを読む ○ たまに役に立つものが見つかる ● 分からなかったら実装を読みにいく ○ git cloneしてVSCodeで読み進める ○ GitHubの定義ジャンプがけっこう使える

Slide 9

Slide 9 text

規格書にあたってみる ● そもそもどういう振る舞いが想定されているのか、が分かる ● 意外となんでも規格書に書いてある ● 例: Webフォントを分割して読み込む際にunicode-rangeを指定しなかったらどうな るのか - 私が歌川です ○ 先に実験してから規格書を読んで確かめた

Slide 10

Slide 10 text

規格書を読むコツ ● 1つのWebページに長大な規格が書いてあるとページ内検索が難しい ● 必要そうなセクションだけエディタにコピペすると検索しやすい ○ 関係ありそうな箇所を片っ端から持ってきたとしても、 元の規格書よりはだいぶ短くなるはず ● 用語集に目を通しておく

Slide 11

Slide 11 text

わかったことをアウトプットする ● 知識を反芻して理解を深める ● チーム内にアウトプットする ○ 調べたこと、検討したこと、やったこと、などなど ○ 個人ではなくチームの知識にする ● インターネットにアウトプットする ○ ブログ記事にまとめる

Slide 12

Slide 12 text

アウトプットのコツ ● 前提を書く ○ ランタイムやライブラリのバージョン ○ いつ時点の情報か ● 事実と考察を分ける ○ 何が起こった・何が出力された (事実) ○ こういうことかもしれない (考察) ○ 検証した結果も書けるとよさそう ● 参考にした情報源を書く ● 「理科系の作文技術」を読む

Slide 13

Slide 13 text

以前からやってた ● Webフロントエンド開発にガッツリ携わる前も同じようなことをやっていた ● 新しいことをやっても基本的なエッセンスは変わらなさそう ○ 試行錯誤する ○ 分からないことがあったら調べる ○ 分かったことをまとめる

Slide 14

Slide 14 text

ところで、コードレビューの話 ● コードレビューやっていますか ● アルバイトの頃はレビュワーをやっていなかった ● いざレビュワーをやってみると考えることがけっこうあると気づく ○ コツはある ○ コードレビュー - hitode909の日記 ● 油断するとコードレビューに時間を使いすぎてしまう ○ さくさくコードレビューしまくる問題 - 私が歌川です ○ 午前中に自分用のレビュータイムを取ってみている

Slide 15

Slide 15 text

コードレビューで心がけていること ● レビューコメントに[MUST][SHOULD][MAY][nit]など (温度感) を書く ○ 必ず修正してほしいのか、実装方法の提案ぐらいなのかを明確にする ○ 温度感が違っていたらチューニングできる ● [memo][感想]とかも使うことがある ○ レビューしていて気づいたことがあったら書いておくと吉 ○ そこから議論が発展して、よりよい解法に落ち着くこともある

Slide 16

Slide 16 text

なぜコードレビューの話をしたのか ● コードレビューはコミュニケーション ● 一種のインプット・アウトプットともいえる ○ レビューする場合も、レビューしてもらう場合も ○ こういう書き方ができる、こういう場合を考慮している、といった知識を 吸収できる

Slide 17

Slide 17 text

ここで一句 (まとめ) ● サイクルを 回して質を 高めあう ● 解説: インプットとアウトプットは両輪になっていて、両方のサイクルを 回して知識の質を高めていくことだなあ