最近のふりかえり(2022/8~2022/11)

2022/12/01に公開約2,900字

エンジニアになって1年と2ヶ月くらいになった!
ついに1年経ってしまった。1年前にあこがれていた「あの感じ」にはどのくらい近づけただろうか??

総論

この4ヶ月のうち3ヶ月はプライベートのことがかなり忙しく、正直仕事をするので手一杯だった。
だから前回の振り返りで書いたような、下記のような感覚が今回はまったくない。

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

まあでもこういうこともあるかなあと思っている。
他にやるべきことがあったのは変えようのない事実なので、終わった今からとりあえずまた色々やってみよう👶

ただ、会社では仕様検討と技術実装がいずれもかなり重めの仕事ができたのでそこは不幸中の幸いというか。
仕事は仕事でかなり頭を振り絞らないとできないことをやらせてもらえていたので良かったと思う!
そのため各論Bで書くように、できるようになったことはまあ思ったよりあった(少し目には見えにくいが……)

アウトプットも滞っていたので再開したい。ちょうどアドベントカレンダーの時期だし。

思ったこと

  • プライベートのことではあるけど、自分の人生でいま何を一番やりたい時期なのかをしっかり考えて時間の使い方を考えた方がいいなと思った👶

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

  • 業務を通じてDOMスクリプティングに磨きをかけたい。お手軽なブラウザゲームも作れるし
    → 詳しく話せないけど、業務ではCSSのルールやReactのライフサイクル、popper.jsをかなり深堀りしないとできないことをやった。DOMスクリプティングではないけど、ブラウザ博士になりたいなあと思っている身としてはけっこう良い経験だった

  • 来年にイギリスとかに行けるように英語をちょっと頑張る(前職で使っていた頃のレベルとは言わないまでも、いい感じのレベルにしたい)
    → 幸運にも忙しかったプライベートの用事とやらは、英語をヘビーに使うものだったのでこれは意外とやれたと言っていいのかもしれない汗

  • いろいろなものを考えて、わっと作ってみるみたいなことをがんばりたい

    • (DOMスクリプティングを使った)ブラウザゲーム/体験型コンテンツ
    • unityゲーム
    • OSSをもう少しいい感じに仕上げて、きりのいい感じにする
    • 面白いchrome拡張
    • slack bot
      → 全然できなかった……!これは次の期間の目標としよう
  • 手帳に1日ごとに日記書くのは続けてみる。面白いから
    → 「面白いから」って理由でやっていたけど、最近は無理せずたまにやるようになった。まあこれで良い気もする

各論B. 気づいたこと

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

  • オペレーションへの影響の有無は大事
    ビジネスサイドのオペレーションに影響を与えるような変更、例えばプロダクトの従来のドメインモデル制約を取っ払うような変更は、実装に入る前の仕様の議論にめちゃくちゃ時間がかかる
    なぜならビジネスサイドは顧客への説明やサポートの手間が激増する場合、やはり納得しづらい。これで本当にいいのか、これ以外の方法はないのか、この方法の拡張性はどのくらいあるのかなどなど
    また、そもそもそのような大きな変更はビジネスサイドでなくとも、プロダクト実装者としてドメインモデルが破綻しないかなど不安になる。
    要するに、言い方は変だが「説明責任」が激増し、検討することがめちゃ増える
    結果として、このような「ビジネスサイドのオペレーションに影響を与えるような変更」は、例外なくかなり時間がかかる。であれば、死ぬほど時間がかかりそうってことをPdMなどステークホルダーに最初から伝えるようにすべき

  • 歴史を知ることは大事
    開発技術の歴史を知るにつれて、いまの開発事情(マイクロサービスのようなアーキテクチャ論から、FE/BE分業体制のような組織論まで)が大きな流れの中に位置づけられて面白くなってきたし、理解しやすくなった
    科学史や哲学史もそうだけど、知識獲得や状況理解はコンテクストを踏まえるほうがいいのは明らかよね

  • コーディングのトレードオフ
    コーディングにおいては設計思想(e.g. うちはRESTでやる)をはじめとした原則論が制約として存在する。それに則ることで、開発メンバーのコミュニケーションコストの減少やコード乱雑化の防止が達成される
    その一方で、原則論に則ることが難しい意思決定を迫られることもある。原則が想定していなかった範囲の問題や、原則同士の衝突などはやはりあるから
    そして原則論に則ることが難しい場合は当然だが、トレードオフで判断するしかない。このとき下記のことをとりあえず取っ掛かりにすると良さそう

  1. 短期的な工数
  2. 開発効率への長期的な影響
  • 理解のしやすさ
  • 直しやすさ
  • そのコードはそもそも長期的に残るのか(残すべきなのか)
    原則論も、そもそもそれをなぜ守っているのかなど深く検討して答えを出すべき(コメントを残せば達成できるような目的のために原則論に固執してしまうのは勿体ない)

業務(コーディング)

フロントエンド

  • popper.js の仕組みに詳しくなった
    • ライブラリの公式ドキュメントを読むのがうまくなった気がする → とりあえず動かしまくってみるのが大切かも。codesandboxとかガンガン使おう
    • ライブラリのソースコード読むのがすこしできるようになった気がする。ブラウザで動くjs系もブレークポイントをDOMとかに開発ツールで仕込んで、コードを見るとなんとなく分かったりする。強引に取っ掛かりを得て、読んでいくあの感じ
  • jestでのテストの仕組みが分かってきた。レンダリングしてはいないからスタイルは基本ついていないとか

バックエンド

  • golangのcopierライブラリがDTOを作るのに便利だと発見できた。うれしい

各論C. 次の2ヶ月で実践すること

  • いろいろなものを考えて、わっと作ってみるみたいなことをがんばりたい
    • (DOMスクリプティングを使った)ブラウザゲーム/体験型コンテンツ
    • unityゲーム
    • OSSをもう少しいい感じに仕上げて、きりのいい感じにする
    • 面白いchrome拡張
    • slack bot
  • 自分のサイトをdeno+freshでリアーキする(いまはスクリプトをgolangで書いて, フロントエンドはts+react+webpackとかいう構成)
  • ブラウザかjsについて何かおもしろいトピックを深めてみる
  • アウトプットのペースを戻す!!!!(特に記事だけではなくてLTとか探してみる)
  • 面白いサービスのアイデアを探す

(ブランクできちゃってたけど、こうやって記事をひとつ簡単にでも書いてみるとハードルが下がるなと思った。明日からまた色々やってみよう✌)

GitHubで編集を提案

Discussion

ログインするとコメントできます