Zenn
👾

最近のふりかえり(未経験からBEエンジニアになって経過した3ヶ月:2021/10~2021/12+α)

2022/01/13に公開
#
キャリア
#
未経験
#
振り返り
idea

2021年10月になんとかバックエンドエンジニアとして仕事を始めることができました👶
未経験なのに働かせてくれている会社の方々に本当に感謝です……！
そんなこんなでエンジニアになってから3ヶ月と少しが経ったので、自分用に軽くふりかえりしちゃうよ！

総論

未経験の自分が、とても興味のあったバックエンドエンジニアに転職できたことはとても良かった！
キャッチアップもそれなりのペースで進んでいて、良い傾向っぽい。
ただ、一方で進め方、技術知識、スピードいずれもまだまだなのは痛感しており、ラーニングカーブをあと少し急勾配にしたいところ。
例えばXXヶ月後にXXできるようになる、というような具体的目標を作りたい。
それに、キャッチアップとかではないフェーズにそろそろ入らなければいけないと思っている。
また、ずっと興味を持っているsecutiryについてももう少しがんばって何か進めたい。もちろんソフトウェア開発が主軸にはなるのだろうけど(現時点ではそれでいいと思っている)。

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

できたこと

  • エンジニアへの転職

できなかったこと

  • securityの勉強
  • webアプリの作成
  • OSSへの貢献
  • 月に1冊の読書
  • 週に1本の記事リリース

やりたくてもできなかったことは何故できなかったか？今後はどうやるか、もしくは一旦やめるか

  • securityの勉強
    → 業務のキャッチアップで精一杯だった。また、自分の興味も少し薄らいでいた
    → hardening, incident response, penetration testingの分野に絞って、①目標を立てて、②イベントに参加しながら、③楽しくやることを最優先にして(=無理はしない)、勉強したい
  • webアプリの作成
    → 業務のキャッチアップで精一杯だった。また、作りたいものがあまりなかった
    → 業務のキャッチアップも兼ねてやりたい。AWSを使ったBEの構築、TSを使ったフロントの実装をする。こちらも楽しくやることを最優先にして(=無理はしない)、実施したい
  • OSSへの貢献
    → 貢献できる/したいものが見つからない
    → これは一旦おいておく。よほどやりたいものを見つけたらやる
  • 月に1冊の読書/週に1本の記事リリース
    → 現実的ではない。「数を目標にしてとにかくやればいい」というものでは全くない
    → ただ本は読みたいので、1ヶ月に1冊の読書と3週間に1本の記事のリリースとする。趣味のブログでもいいものとする(書きたいことを書くことによるストレス解消の意味も大きいため)
    • 直近で読みたい本: シェルワンライナー160本ノック, secure by design, 実践ドメイン駆動設計入門, 失敗から学ぶRDBの正しい歩き方, サイボウズの研修資料

各論B. やったこと・学んだ知識の詳細振り返り

キャッチアップ

  • gitの使い方
  • ネットワークの仕組み(IP層の仕組み)
  • 文字コードの基本
  • DBの基本(クエリ, トランザクションと分離レベル, インデックス, レプリケーション)
  • Go(gin/gorm)+MySQL+DockerによるCRUDサーバー構築
  • コンテナ間の通信(CRUDサーバー同士の連携)の実装
  • CRUDサーバーのクリーンアーキテクチャ化

業務

  • 新しい機能のBEとFEの実装
    • 大きなコードの読み方、追い方
    • 慣習に則ったコードの書き方
    • クリーンアーキテクチャおよびDDDに則った、BE(API)の実装
    • TypeScriptをすこし実装
  • マスターテーブルの編集
    • マスターテーブルとトランザクションテーブルという概念の理解
    • 開発環境という概念の理解(development, staging, production)
  • リファクタされたコードの検証用スクリプトの作成
    • クラウドサーバーを使ったサーバーレスアプリケーションの基本的な構成、仕組みの理解
    • makefileやシェルスクリプトの作成
    • 比較的複雑なロジックを伴う処理の実装
  • 新しい機能のBEのみの実装
    • FEとのインターフェースの合意
    • モデル設計からデータバリデーションおよび永続化方法まで含めた一連のBEの、DDDおよびクリーンアーキテクチャを意識した設計と実装
  • hotfixの実施
    • 大きなコード中にある修正必要部分の、設計や処理フローを材料にした目処つけ

業務外活動

  • iOSアプリの作成
  • ホームページの作成
  • penetration testingの勉強を始めた(HTBやその他脆弱アプリ)
  • アドベントカレンダーなどへの参加を通して記事を書いた
    • 前職(経営コンサル)とエンジニア職の比較
    • Makefileにおける環境変数の使い方の注意
    • Postmanのスクリプト作成における注意点
    • セキュリティ(covert channel)
    • IP層の仕組み
    • iOSアプリ作成記

各論C. エンジニアリングにおける継続すべき点ともっとよくできる点の振り返り

コーディングやドキュメンテーションのスキル・技術知識

  • コードの他の部分を参照しつつ慣例にならったコーディングができるようになってきた
    → 継続
  • 大規模なコードを検索やジャンプを活用して追えるようになってきた
    → 継続
  • 技術的な知見の不足から内容に漏れが生じることがあるものの、構造化して議論したりドキュメントを書いたりは早くできていそう
    → 継続(技術知見はあとからついてくるはず)
  • よく使うコマンドが手打ちで行われている
    → 頻出コマンドは早急にエイリアスを作る
  • DDD的な設計でわかっていないことがまだ多い(fctryとか何？ってまだなっちゃってる)
    → 戦術的なDDDを早く勉強する
  • サーバーレスのことを知らなすぎる
    → AWSなど使い、サーバーレスアプリケーションを自分で作ってみる
  • SocketとCacheのことを知らなすぎる
    → SocketとCacheのことを勉強する
  • フロントエンドの話を知らなすぎる
    → 自分のアプリ作成などで、TSでフロントエンドを理解しながら実装してみる
  • デバッガーの使用経験がない
    → 便利かどうか確かめる意味でも、デバッガーをちゃんと使ってみる

開発の進め方

  • 問題解決のためのコミュニケーションを適切にとれている気がする(課題の明確化、現在の方針、不明確な点の提示)
    → 継続
  • 業務ではスクラムで割り当てられた作業だけをする状態になっており、日常で使うテストや開発環境の改善であったりhotfixであったりに時間を割けていない
    → まずは割り当てられた仕事を余裕をもって終わらせられるようにする。話はそれからっしょ！
  • 問題の報告だけしてしまうことがあった
    → エラーを読んで推測したりして、まずは自分で原因究明して解決する。もしダメなら相談する
  • 新機能実装にあたり、フロントエンドとのインターフェース擦り合わせとバックエンドの実装の検討の順番がこんがらがった
    → インターフェースは先にアラインする。ここはFEの開発を進めるために必要だし、BEの実装はそれに応じて調整できる
  • 新機能のBE実装を考える際、モデルから考えるかDB設計から考えるかこんがらがった
    → DOAではなくOOAでいく。すなわち、まずはモデルを起点に、それから自然な永続化方法を考える。他の候補がないかは一つ固めてから考える。それから、根拠をつけておしまい。変に構造化とかは最初からしようと思うと遅くなる。あとで考えればいい

エンジニアリングにおける姿勢

  • 疑問については全部分かりきるつもりで調べ、それでもわからないことは教えてもらうように努めている
    → 継続
  • FE/BE関係なく色々なことに垣根なく挑戦し、自らに半強制的にキャッチアップをさせている
    → 継続
  • 目的を持った自主開発、課外活動ができている
    → 継続
  • 細かいところでよくわからないままコードを書いて、あとで自分に跳ね返ってきた。
    → 細かいところも曖昧なままでは大事故を招くことがわかった
    → よくわからないコードは書かない！よくわからないことは言わない！
  • ありがちな機能について、誰かが既にモジュールを開発してくれていることを知らないままゼロから実装しようとした(例: テストの自動化、URLのvalidation)
    → これ絶対必要だろってもの、あったらいいなと思うものはまず検索してみる。9割ある
  • バグ修正や実装の際に、どこをさわればいいのかの初期仮説をもっとはっきり持ちたい。例えば、これはレポジトリ層だなとか、もう少し土地勘を働かせたい
    → 仮説を持ってから取り組むようにする。すなわち、それぞれのレイヤーで、なんのコンポーネントがどう連携して処理が行われてるかをまず思い浮かべ、どこで何が起こると現象が再現されるか考える

追記: お世話になっているエンジニアの方から出たポイント

  • 自社アプリケーションのソースコードも含め、ドメインの知識をとにかくもっと付けていく。そうすれば自然と作業も早くなるだろうし、レビューとかもできるようになっていくはず
  • 実装したい機能の仕様を今よりも細かいレベルで、最初に確認して把握できるといい。誰がどのようなモデルをいつ、どのように生成して、どのような通信の後にどう処理されるのかを、シーケンス図に落とし込んでみるのが手っ取り早いのではないか
  • FEなど、いろいろな仕事をどんどんやるといい。エンジニアを始めたばかりなのだから、色々な世界を体験したほうがいい
  • 自分が作った機能のインパクトを数値で追えるようにしておくといい。作って終わりではなく、きちんと効果測定まで心がけるようにする
  • とにかく、仕様を詰めて、適切なモデリングをする！バックエンドはやっぱりそれが大事！
GitHubで編集を提案

Discussion