Zenn
🐷

最近のふりかえり(2022/1~2022/3)

2022/04/06に公開
#
キャリア
#
振り返り
idea

エンジニアになって半年が経ってしまった……
四半期ごとに振り返りをしようと思っているので、とりあえず今回もやってみる
この前の振り返りで反省した点が今回できたかどうかから振り返る

総論

フロントエンドに力を入れた3ヶ月のような気がしている
ありがたいことに、今の職場はバックエンドメインとして入った自分にも興味がある限りフロントエンドの仕事もやらせてくれる。本当に感謝しなければならないことだと思う
TS+Reactに加えてJestやredux,それにモノレポのNxなど、けっこうイマドキのスタックでやらせてもらえている。本当に勉強になっている
一方で毎回のスクラムタスクの振り返りが甘くて、知識以外の部分(仕様の議論の進め方とか)の伸び率が悪くなっている気がする。アウトプットはサボらずにしっかりとやるべき
ただ、アウトプットをサボってしまうのは仕事に時間をかけすぎている、というかダラダラ仕事している感じがあるからで、そこは前職の効率的な仕事の進め方をもう一度おもいだして、心を鬼にして日中を過ごしたい
また、アウトプットがしんどくても、振り返りは月末にやるようにしようと思った(四半期ごととか言ってないで！)

思ったこと

エンジニアはキャリアに迷うらしい。みんなと話していてそう思う。自分もフルスタックか、BE特化か選ぶ機会が1つやってきたので考えなければならない。また、長期的に自分はどうするんだろう。色々考える事が多い……
しかし技術だけのことを考えていてもあまり豊かな人生にはならないと思うので、これからも色々なことがしたい。とはいえ最近は量子情報や圏論に少し興味を持っている。Haskellの本も買ったし、圏論と関数型プログラミングを勉強してみようかな

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

  • XXヶ月後にXXできるようになる、というような具体的目標を作りたい
    →これはできていない。ただ、手帳に明記してトラックするという案が出たので、今月はそれをやってみよう。
  • secutiryについてももう少しがんばって何か進めたい
    →pwnableを少し進めようとしてみたけど、他にも興味あるの色々出てきたからそっちをやっていた。例えばホームページづくりとか、関数型プログラミングやフロントエンドなど。一旦securityに限らず色々やってみよう
  • キャッチアップみたいな状態から早く抜け出したい
    →エンジニアは一生キャッチアップであることが、色々な人と話した実感として分かってきた。みんな日々勉強している
    →バックエンドでは、機能開発(=API開発)はかなりキャッチアップできた感じがある。手詰まりが起きても自己解決して、レビューもして、けっこうがんばれている気がする。しかしaggregationとかDDDの戦術によっては「見れば分かるが、自分でゼロからはできない」という状態にあるので、もう少し頑張りたい。あと、認証とかに手を伸ばしていくべきかも
    →一方でフロントエンドはCSS(styled component)やReactやRedux/Contextなど、FE特有の概念は一通りさらったくらいで「コードは読めるけどまだ十分には書けない」状態にある。もう少し慣れが必要。簡単めなPRのレビューに混ぜてもらった方がいいかもしれない
  • 1ヶ月に1冊の読書と3週間に1本の記事のリリース
    →これはプライベートで色々忙しかったことを言い訳にさせてもらいたいところ。次からちょっと頑張ろう
    →1ヶ月に1冊なんて、趣味の本で余裕達成しちゃうので、技術書って縛りにする
    →とにかく、ある程度まとまったらとりあえず記事で出してみるようにする
  • AWSなど使い、サーバーレスアプリケーションを自分で作ってみる
    →slsを使ってやってみた！また、redis(Elasticache)の勉強もした。前よりはわかるようにはなったが、まだ自分で構築できるかは微妙
  • 実装したい機能の仕様を今よりも細かいレベルで、最初に確認して把握できるといい。誰がどのようなモデルをいつ、どのように生成して、どのような通信の後にどう処理されるのかを、シーケンス図に落とし込んでみるのが手っ取り早いのではないか。とにかく仕様を詰めて、適切なモデリングをする！
    →今回は機会がなかったけど、気をつけていきたい
  • 作った機能の効果測定
    →全然気にかけていないので、やれるようにしないといけない

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

  • フロントエンドの簡単な実装(少し凝ったvalidation(e.g. ユーザーのタイミングで増減する複数フォーム同士で重複をチェックする)を含んだフォームの実装やAPI連携をTS+Reactで実装できる)
  • react dev toolsを使ったパフォーマンス改善のやり方が分かる(本格的にやってはいない)
  • ブラウザ開発ツールを使ったフロントエンド開発(CSS変えるとかログ出すとか)
  • APIのサーバー実装を割と早くできるようになってきた(DDDなどアーキテクチャもあまり迷わない)
  • 言語の細かい仕組みや大局的な設計など、コードディング以外の部分にきちんと集中できるようになってきた(バグの対処もわりといけるようになってきた)
  • コードレビューを通じた改善の指摘や、hotfixができるようになってきた
  • slsでサーバーレスアプリケーション作ってみることができた
  • 絵文字周辺の文字コードについて分かった
  • オートマトンと正規表現の関係性について少し分かるようになった

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

  • ドメインモデルのvalidationで複雑な操作(他ドメインとの連携、他マイクロサービスとの連携)が必要な場合、validationを専門でやるクラスを定義するといい。specificationクラスなんて呼ばれる
  • DBのレコードに「状態」を持たせない。状態が分かれるなら、テーブルごと分けてしまったほうがいい。例えば削除はフラグではなく、削除テーブルの用意をする
  • 各層の定数やメソッドのスコープをきちんと狭めることが大事。例えばドメインモデルが持つべき定数やメソッドは大抵の場合プライベートにしておくべき
  • ドメインモデルにプリミティブ型を使わない！独自の定義型でドメインモデルを固めておく。ビジネスロジックに適した型が絶対にあるはずなんだから、きちんと作る。あんたのとこの会社はint型の金額を扱うのか？？
  • システム内部のログとして残すエラーが定義されており、それらを一般的なステータスコードと対応させることでエラー時のレスポンスやアラートを制御している。①ログとしてエラーを残すようになっていること、②監視システムがログのエラーによってアラート制御されていること、③したがって実装時にエラーを選ぶことでレスポンスのステータスコードやアラート有無も選んでいること、を意識すべき
  • 集約を意識する。どのデータからどのデータまでをまとめて扱っておくべきなのか。例えばあるデータをDBから取ってくるときに、そのデータの翻訳データもともにDBから取ってきてまとめるなど。
  • ループごとにDBへのアクセスをするなんて馬鹿げている。一括でまとめて持ってくる
  • if-elseはelseに予期せぬケースが混ざることがある。ifがたくさん増えるような話もあるので、switchでdefaultを例外処理にするって感じにすると3ケースとかでも見やすい
  • フロントエンドの実装では、最後にコンソールで警告とか出てないか見る
  • jsではnamed importするのがよい。全部インポートすると重くなっちゃう
  • reactならとにかくメモ化やデバッグツール駆使して、パフォーマンスチューニングを遂行する！！！
  • JS/TSのコードではforループは使われないとか、Goとはまた違う趣があるので気をつける

各論D. 気づいたこと

  • 仕様と設計をきちんと固めるのが大事。修正するエンドポイントの洗い出し、ユビキタス言語の設定、などをしっかりやりたい。やらないと二転三転する。意見が多い人にあらかじめ聞いておくのも大事
  • フロントエンドのデバッグは慣れていないせいかまだ難しい
  • リリース手順を書くのを忘れそうになるので注意
  • 十分条件になっているテストかどうかを確かめる！！！！テスト総体が仕様と必要十分になるようにする！(厳しすぎてもいけない。ゆるすぎるよりは全然いいけど)
  • 電話して伝えれば終わることは電話する
  • スクラムはリリースにおいて自立している。CSレビューは承認ではなく、今後に向けたアドバイスでしかない
  • mockはmock化されているモジュールの内部状態を理想的なものとして仮定して作られる。例えば、repositoryのmockはDBの遷移を想定して作られる。なので、当たり前だがmockを使うと、mock化した向こう側の状態と結合したテストはできていないことになる。よって例えばrepositoryメソッドを呼ぶ順番を間違えていてDBの状態がおかしくなるといったバグには気づけなくなる。そのため、mockによるテストがあるなら、結合テストもまた必須である
  • PRは小さく切って出していくべき。プロトタイプ的な段階で見せるのもあり。また、実装に限らず、どんなこともとにかくいい感じのひとまとまりで大きくしすぎずに確認をとっていく。とにかく、フィードバックループを早くまわして確定させていく
  • レビューコメントはHRTに気を配りながら書く

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

  • ダラダラ仕事せずに、朝のタスク整理と時間見積もり、優先順位付けをいままで通りやる
  • 手帳に今月の目標を書いてトラッキング。また、1日の終わりに今日やったことと気づいたことを書いてみる(ちょっとしんどい＆意識高すぎるけどやってみよう)
  • 月末に振り返りをする
  • 1ヶ月に1冊の技術書の消化と、3週間に1本の記事のリリース(ある程度まとまったらとりあえず記事にする)
  • バックエンド: API開発以外に食指を伸ばす
  • フロントエンド: TS+Reactを自分のページやアプリ開発、仕事でたくさん書く＆簡単めなPRのレビューからやらせてもらう
  • 仕様策定からテストまで、各フェーズで気をつけることや採るべきやり方を言語化する(いままでの振り返りの分類+どこかで得た知識って感じになりそう)
GitHubで編集を提案

Discussion