2020.03.16 ~ 2020.03.22 の週報

この記事は何？

1週間の振り返りとして、インプットしたことを「週報」という形でアウトプットしたもの。 業務では、フロント(React,TypeScript)とバックエンド(Golang)が多いので、その辺りのインプットが多い。 また、仕事を進めるにあたりマインドセットに課題を感じているので、その辺りのインプットも多めとなっております！

フロントエンド系

lodash

• https://slideship.com/users/@iktakahiro/presentations/2017/12/MArWbm3VYEKCqB2ZNd5dts/

Axios

• オフライン時の挙動について https://devsway.net/2019/07/24/axios%E3%82%AA%E3%83%95%E3%83%A9%E3%82%A4%E3%83%B3%E6%99%82%E3%81%AE%E6%8C%99%E5%8B%95%E3%80%81%E3%81%9D%E3%81%97%E3%81%A6%E3%82%A8%E3%83%A9%E3%83%BC%E3%83%8F%E3%83%B3%E3%83%89%E3%83%AA%E3%83%B3/

エラーハンドリング

• Axiosのエラーに型をつけて書くだけで、エラーハンドリングがとたんにしやすくなったのを実感した。

TypeScript

• ジェネリクス
  • https://future-architect.github.io/typescript-guide/generics.html
  • https://qiita.com/tfrcm/items/cd8dafcc8ee4f824ccf5
• 記事
  • https://logmi.jp/tech/articles/322649

    • そもそも型とは、値とその値に対して実行できる操作の集合ということはもうみなさんご存じですよね。私はけっこうこれが目から鱗でした。

    • 数字で「2」とあったらこれはnumber型だよねとか、「text」って文字があったらtext型だよねというのはなんとなくわかっていたんですが、それに対して、型が決まると実行できるアクションが決まるというのは、言われてみれば当たり前のことなんですが、文字にされると「あっ、そうか、そういうことか」ということですごく腑に落ちました

    • 自分もこの記事を見て、「あ〜確かに」と腹落ちした。
    • 「型が決まると実行できるアクションが決まる」 = コードを理解する時間が短くなる。という理解。
      • コード読むってしんどいよね...
    • ただ、コード量が多くなるので、全てのプロジェクトで使うべきかは、検討する必要あり。複雑なプロダクト(ドメインが複雑である)を作る時には、有効だという理解をしている。

コンポーネント とロジックの分離

• https://qiita.com/tuttieee/items/a3ca7d9d415049d02d60
• 社内の先輩にかなり特訓していただいた。僕自身もこの書き方にしっくりきたし、何よりReactの良さを引出しているように感じた。

async/await

• https://qiita.com/jkr_2255/items/62b3ee3361315d55078a

スプレッド構文

• https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Operators/Spread_syntax
  • なんとなく使ってたけど、改めて学習。

react-router

• withRouter

  • https://github.com/ReactTraining/react-router/blob/master/packages/react-router/docs/api/withRouter.md
  • match, location, historyをwithRouterを使ったところで扱えるようにする
  • withRouter will pass updated match, location, and history props to the wrapped component whenever it renders.

• RouteProps

  • match, location, historyをうまく扱えるようにできる
    • Routeからrenderするcomponentに渡せる
    • ちゃんと理解できてなかった
  • https://qiita.com/takeyuichi/items/fa6ab3a347c9fc537be4
• Routerをカスタマイズして、認証の確認ができる

バックエンド系

• MongDB

  • 楽観ロック
    • https://www.mongodb.com/blog/post/how-to-select--for-update-inside-mongodb-transactions

• Golang

  • 値渡しとポインター渡し
    • https://github.com/golang/go/wiki/CodeReviewComments#receiver-type https://medium.com/finatext/go%E8%A8%80%E8%AA%9E-golang-%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E5%80%A4%E6%B8%A1%E3%81%97%E3%81%A8%E3%83%9D%E3%82%A4%E3%83%B3%E3%82%BF%E6%B8%A1%E3%81%97%E3%81%AE%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9%E5%BD%B1%E9%9F%BF%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6-70aa3605adc5

• Context

  • https://qiita.com/convto/items/0f9e844a1775b80cdbd9
    • チョット抽象的でわかりにくいかも...
    • 「リクエストスコープ内で共有したい値の伝搬」
      • 具体の話で言うと、Contextを使うことで、一回のHTTP通信で使いまわしたい値を利用できるということ？（うまく言語化できん...）
• FireStore
  • https://www.wakuwakubank.com/posts/723-firebase-firestore-query/

その他考えていたこと、学び

プルリクのお作法

• ブランチを切ったら、まずは空でも良いのでPRを作る
  • 周りの人がタスクをやっているかも知れんし、見といてくれるかも
• フローを整理すると。。。
  • タスクをもらう
  • ブランチを切る
  • PRを作る(空でも良い)
  • PRに作業内容を記載
  • 上長に報告
  • 一旦、このフローでタスクをこなしていく中で、改善を積み上げていく。

どのタイミングで周囲の人と相談するのがベストか

• 自分の経験との差分が大きい場合
  • スキルと経験の棚卸しをしていないと、差分が見えない
    • ex) フロントエンド => Reactはできるけど、TypeScriptは厳しそう
    • ex) バックエンド => 簡単なモデリングはできる
  • 経験を積んでいくと、差分は小さくなるので、周囲との相談が減っていきがち？
• 解決すべき論点が多い場合
  • 前提：タスクに取り掛かる前に論点の洗い出しを行う(一人 or チーム)
  • 論点の構造化をすると把握しやすそう
    • Google Docで大論点、中論点、小論点を意識して書き出してみる
  • 自分のスキル、経験でどの論点まで検討・解決できるのか目星をつける。
  • 解決できない物が多いと感じたら、ヘルプを求める
    • 「多い」とはどのくらいか、タスクをこなす中で言語化していきたい。

マインドセット

• タスクフォーカス
  • 自分のタスク(課題)にフォーカス、それ以外については仲間を信頼する。
  • https://logmi.jp/tech/articles/322464

    • たちはその意識を変えることはできるんですね。外側の環境を変えることはできませんが、自分がその環境をどう捉えるかということは変えることはできるんです。今日の覚えて帰ってほしいことの1つは「コントロールできないものと戦わない」ですね。わからないものはわからない。変えられないものは変えられないんです。