$30 off During Our Annual Pro Sale. View Details »

インプットとアウトプットのサイクルを回す暮らし / Kichijoji.pm 29

インプットとアウトプットのサイクルを回す暮らし / Kichijoji.pm 29

utagawa kiki

April 12, 2022
Tweet

More Decks by utagawa kiki

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide