Zenn
👶

最近のふりかえり(2022/4~2022/7)

2022/08/25に公開
#
振り返り
idea

エンジニアになって10ヶ月くらいになった！黙々とがんばりましょう

総論

興味が強くもてる領域でいろんなことをやった4ヶ月間だった！

アーキテクチャについてフロントエンドでもバックエンドでも議論できるようになってきた。
また、型演算やreduxなどに関するreact+TSスタックにつきものの知識がついてきている実感がある。DOMスクリプティングも、playwrightのような要素探索まわりのコードが読めるようになったり、自分で簡単なブラウザゲームをピュアなDOM操作で作ったりくらいのレベルになってきた。

また、抽象的な議論をする機会がいくつかあった。スクラムの進め方やオンボーディングについて考えたり、組織設計(マネージャー制度の設計)で議論のリードをさせてもらったりした。バックエンドチームが抱えている課題のファクトベースでの整理もした。やはり課題解決においては、抽象的な議論も絶対にファクトとのつながりを失わないようにすることが大事だと思った。
こういう部分や、人とのコミュニケーションは前職の経験が生きている感じがする。

仕事から離れた文脈でも、自分が興味のあることを中心に色々なことができた。OSSを作ってみたり、イスコンに参加してみたり、関数型言語を掘るなど。
OSSは途中で「これもしかしてあんまりみんな要らない？」となり、モチベーションが下がってしまった。でも、のんびり修正して育てていってみたい。ハンガリーの人が星つけてくれたのは嬉しかった！
また、グラフDBを触ってみることができた。

自分が興味を持てる4つのことがわかった。もちろんこれ以外にも興味持てると思うけど。

  1. 少し小難しいロジックが関係すること(TSの型パズルや複雑なdomスクリプティング、jsエンジンの仕組みなど)
  2. 楽しいもの(ゲームや見てたり触ったりして楽しいおもちゃ)を作ること
  3. 人と気分良く協力しあうこと(どうすればお互いがモチベーションを高く保って仕事できるか)
  4. 世界が少しでもみんなが嬉しい方向に変わること(政治的な意味で)
    少し小難しい仕組みのゲームを作るのが楽しいのかもしれない……それか政治運動のためのプラットフォーム？

起業することには興味がないということが確信に変わりつつある
自分は、面白いものを作って多くの人が喜んだり、変化をもたらすものを作って世界が変わったり、そういうことができれば、それでいい
むしろ起業すると大変そうだなとか思う。共感する人間が集まって、自然と法人になるとかならまだわかる。それでもなるべくVCが入るとかは避けたいなと思った

思ったこと

  • やりたいことや目標を手帳に書くようにしていたけど、それがなんとなくTodoリスト化してしまう
    • 目標というより、場当たり的になんとなくやれるようになりたいこととか興味があることに近くて、長期的な視点や戦略的な視点でなにか考えられているわけではないのが、ちょっと不安。大丈夫かな
  • 簡単なサーバーやAWSの構築はさっとできるようになりたい。バックエンドも絡むサービスやプロダクトのプロトタイピングの速度が全然異なってきそう
  • 技術の勉強だけしていてもアイデアが枯渇というか、作りたいものが浮かばくなってしまうことがわかった。いろいろなことに興味を持つ哲人でいたい

各論A. やりたかったことの結果振り返り

全体的にけっこうやれたと思う！

  • ダラダラ仕事せずに、朝のタスク整理と時間見積もり、優先順位付けをいままで通りやる
    → まあまあという感じ。外部ライブラリの仕組みの理解とか、バグの原因究明みたいなタスクだと見積もりが難しいのがきつい
  • 手帳に今月の目標を書いてトラッキング。また、1日の終わりに今日やったことと気づいたことを書いてみる(ちょっとしんどい＆意識高すぎるけどやってみよう)
    → やってみた！いい感じ！1日の終わりに書くのも日記みたいで楽しいので、もう少し続けてみるんだろうなと思う。やってよかった
  • 月末に振り返りをする
    → 毎月、その月の目標を考えるときに自然とまあやっている
  • 1ヶ月に1冊の技術書の消化と、3週間に1本の記事のリリース(ある程度まとまったらとりあえず記事にする)
    → 一冊まるっと読んだ本は「標準DOMスクリプティング」だけだけど、「プロを目指す……TypeScript」や「関数型リアクティブプログラミング」とか、必要なところを必要なだけさっと読めた！
  • バックエンド: API開発以外に食指を伸ばす
    → 開発チームの課題整理を任せてもらえた！技術課題や設計の議論も、解釈にブレがないような具体的なファクトベースで行うことが大事だとわかった👶
  • フロントエンド: TS+Reactを自分のページやアプリ開発、仕事でたくさん書く＆簡単めなPRのレビューからやらせてもらう
    → 仕事でかなりたくさん書いた気がする。最近は複雑なロジックが絡む部分のバグも自分が見るようになったりしていて、嬉しい👶
  • 仕様策定からテストまで、各フェーズで気をつけることや採るべきやり方を言語化する(いままでの振り返りの分類+どこかで得た知識って感じになりそう)
    →　記事にした。これからも気づいたことがあれば付け足していこうと思う

各論B. できるようになったこと

業務(設計など抽象的な議論)

  • 技術課題特定や設計を、まあまあ任せてもらえるようになってきた
    • フロントエンドではモノレポ管理ツールNxに合わせたリアーキテクチャ、バックエンドではチームの技術課題整理をリードさせてもらえている。マイクロサービスの切り直し設計も議論相手として重宝してもらっている
    • API周り、とくにGraphQLでできることやRESTの定義・理念について学んだ
  • 技術課題や設計についての議論をバックエンドとフロントエンドで初めてしっかりやって、下記の感覚を得た。全体的に、とにかく極限まで言語化して最終目的から離れないようにすることが大事って感じ
    • 技術の議論でもイシューを見失わないことが大事なのはビジネスと同じだと思う。まあそりゃそうなんだけど
    • 言葉の粒度を極限まで細かくしながら、ファクトをもとに議論することが大事。例えば「バックエンドのコードはなんか読みづらい」と言うのではなく、「usecase層のロジックを中心に、ドメインモデルのメソッドの命名が実際の処理とずれていること、また、メソッドが適切な範囲で分割されていないことがあり、読みづらい」と言うべき
    • 設計、とくにリアーキテクチャの議論では、解決したい問題をきちんと言語化して、まずはそれを解決するための議論をする。目標が定まっていない設計の議論は永遠に着地できない
  • 抽象的なことを扱うプロジェクトについて、みんなで協力的に議論すれば、多少イシューの言語化方法や議論の進め方に違和感があっても、途中でいくらでも方向修正できることが実感できた。最初から完璧にやろうとするよりも、みんなで楽しく議論していろいろな発想が出るほうが大事なのかもしれない。文句があったら言えることが大事。それがあれば修正できる
  • 会社で技術的な分野でも主体的にいろいろな提案ができるようになってきた
    • 外部ライブラリの導入提案(jest-preview)
    • 技術課題の特定
    • モノレポ管理ツールの思想にあわせたリファクタリング設計
      ― コメント追記・リファクタリング推進運動

業務(コーディング)

全般

  • 単体・結合テストの題名は、何のどのような動作を担保しているのか具体的に書く
    • 特にsnapshotテストは何をテストしているのかわからなくなるときつい。snapshotテストでも、サボらずにちゃんと書こう

フロントエンド

  • ブラウザの開発ツールを使ったデバッグが更にうまくなってきた感ある。この前はスタイルが変更できるとか、ログが出せるって言ってたけど、例えば……
    • 要素を定数として保存して、好きな要素に対してスクリプトをうてる
    • ブレークポイントを設定して、変数を見る
    • 要素のイベントハンドラーを消去して、ホバーやフォーカスに左右されない状態でデバッグする
    • console.logを使わなくても出せる(chromeの話)
  • DOMスクリプティングの知識が増えてきている。要素探索&変更検知&改変ロジック実装やブラウザゲーム作成ができるようになってきた
  • TypeScriptの型演算にめちゃなれた。オーバーロードのことも知って、型演算への抵抗がなくなった
    • 実際、型述語や型パズルについての記事を書いてみたり、型起因のバグが直せたりするようになった
  • JSの非同期処理について、async/awaitを中心にとりあえず理解できた
  • Reactの思想についてWEBDBの記事で学んだ。かなり解像度が上がった気がする。Portalも役に立っている(MUIにもあるよね)
  • redux, contextが教科書どおりには使えるようになった。めちゃくちゃ理解できているか、自分でイチから書けるかと言うと微妙
    • contextでもpropsでもDIはできることに注意！
    • contextの値が変わったら、それを使っているcomponentは全部再レンダされる！メモ化に注意しよう
    • reduxもuseSelector使ってたら話は同じ。便利だね

バックエンド

  • GolangのSyncパッケージの理解が深まった。特にMapやPool。Ginのcontext事情深堀りのおかげ

自主的な活動

  • 関数型言語について知ることができた。カリー化の概念とかが、TS(JS)の高階関数、コールバック関数の理解に役立ってよかった
  • モナドの定義をしって、まあこれは一旦あとでいいかなと自分の中で決着をつけることができた
  • 圏論の関手およびモナドの定義を知り、それがHaskellでどう実装されているかを知った
  • フロントエンドの歴史を知った。なぜブラウザごとに仕様が違うのか、誰がweb周りの仕様を決めているのか、どんな流れでreactになり、それがどう革新的だったのか。FE開発のエコシステムとは何なのか
  • ReactはReactive Functional Programmingではないことを知った
    • Reactive Programmingでは時間が引数(第一級オブジェクト)だけど、Reactはそんなことない
    • Reactはpure functional languageでもない
    • ReactはReact。もちろん「リアクティブ」なアプリを作ることは得意だけど、RPやFPかと言われたらもちろん違う
  • OSSを作ってリリースしてみるという流れをとりあえずやってみることができた(イシューやCI/CDも整備した)
  • 社外のエンジニア(他の会社のカジュアル面談3つ、イベント3つ)とお話できた
  • イスコン出場で、topなどを用いたパフォーマンス改善の流れがなんとなくわかった

各論C. PRを通して学んだこと

  • ADRを用いて非同期的に設計についての情報共有・意思決定ができると便利！
  • JSでthisを使うとちょっと難しくなりがち。thisは使うとしてもthisが指したいものの直下で使えるといい。別で定義した関数にbindを使い始めるとバグが起きやすいのでやめたい！
  • ReactのErrorBoundaryをうまく使えるといい
  • フロントエンドの場合は特に、エラーが起きた時に表示し続けるのか、間違った情報が含まれるから全部もう消しちゃうのか、とかエラーハンドリングに気を遣わないといけない
  • コメントがあるコードは読みやすい！
  • ドメインモデルにプリミティブ型を使わない！独自の定義型でドメインモデルを固めておく。ビジネスロジックに適した型が絶対にあるはずなんだから、きちんと作る。あんたのとこの会社はint型の金額を扱うのか？？
    　→ この前書いたこれについては、domain primitive obsessionになるのもよくなさそうだとOSS書いてて思った。string型の振る舞いはみんなわかるけど、他人からしたら独自型の振る舞いはコードを読み込まないと分からない。これはけっこう負担を強いることになっている
  • ループごとにDBへのアクセスをするなんて馬鹿げている。一括でまとめて持ってくる
    　→ この前かいたこれ、要するにN+1問題なんだなとイスコンやった今ならスッと入ってくる

各論D. 気づいたこと

  • 技術領域での抽象的な議論について、各論Bで書いたことに気づいた
  • RESTのエンドポイントの定義の仕方について、リソース単位ではメソッドだけで表現しきれないことがある。複数のドメインモデルをまたぐ処理なんかは、リソース＋アクションになることも避けられないことがある
  • コードにコメントを残すのは本当に大事
  • ライブラリの哲学を正しく理解して使うことが肝要(Reactの記事を読んで思った)
  • snapshotテストはUIだけでなく、オブジェクトをシリアライズしたJSONにも適用するなどしてsessionのテストにも使える
  • TSにおいてはassert関数やif文による制御もいいけど、型で制御できると強い

次の1ヶ月で実践すること

  • 業務を通じてDOMスクリプティングに磨きをかけたい。お手軽なブラウザゲームも作れるし
  • 来年にイギリスとかに行けるように英語をちょっと頑張る(前職で使っていた頃のレベルとは言わないまでも、いい感じのレベルにしたい)
  • いろいろなものを考えて、わっと作ってみるみたいなことをがんばりたい
    • (DOMスクリプティングを使った)ブラウザゲーム/体験型コンテンツ
    • unityゲーム
    • OSSをもう少しいい感じに仕上げて、きりのいい感じにする
    • 面白いchrome拡張
    • slack bot
  • 手帳に1日ごとに日記書くのは続けてみる。面白いから
GitHubで編集を提案

Discussion