Zenn
😈

実務1年経過エンジニア奮闘記：失敗と学び

2024/10/06に公開
ポエム
DDD
振り返り
失敗談
エンジニア転職
idea

実務1年経過エンジニア奮闘記

バックエンドエンジニアとして
実務経験1年が経験したので、私の経験した失敗談と、そこからの学びをまとめてみる。
個人的に失敗という言葉は好きではないので、経験という言い方をさせてもらう。

幸運なことに最初から実装もたくさん任せてもらい、その中で大小いろんな経験をしたので、
その中でも印象的だった失敗を振り返りたいと思います。

<前提事項> 私は...

  • Kotlinを使用しSpringBootでBtoBアプリケーションの開発
  • DDD オニオンアーキテクチャを使用したBE開発をしています
    • バッチ、新機能、既存機能の修正、パフォーマンス改善等
  • アジャイル開発です

🚨 設計を曖昧に疎かに、手を動かしてしまって大手戻り事件　(×2pattern)

▶️ 1.既存機能を一部使用した新機能作成時

背景

既存機能にプラスで新機能追加タスクを行なった際のこと。

👮 事件録

実装に必要なリクエスト値が、取れると思って進めていたが、
PCからはできてもアプリからは不可能だということが発覚したのがイテレーション終了週。
しかもそれを実現するのであれば、既存機能の設計から直さないと実現できないとわかったのは
イテレーション最終日。ストーリーポイント8〜13は必要。

結果、一旦、 お蔵入りです。

⛈️ 問題点

  • 既存機能の設計の理解が足りずに勘違いしていて実装に取り掛かってしまったこと。
    　→ 手を動かすのが早すぎ
  • できるという過信した。チームには共有していたが、
    そこの機能の専門のメンバーからの意見を聞きに行っていなかったこと。

👩‍💻 解決策, 成果と学び: このような大手戻り、お蔵入りをなくすために

  • 手を動かすのが早すぎる。１番の問題はこれでした。
  • Swagger定義もある場合エラーハンドリング含めて、アプリチームとの共通認識を早めにとること。
  • 設計を十分に理解した上で、実装を焦らず、今回実装する機能のことを
    コードにするだけのレベルまで砕いて整理    してみること。
    • シークエンス図の更新
    • ドメインモデル図見直し
    • 疑似コード

この経験を他チームもいる中で共有した時に、初めて"疑似コード"にであった。

疑似コードについて

ここで私は初めて"疑似コード"に出会う。
疑似コードは、シンプルな自然言語とプログラミング言語の要素を組み合わせたもの。
ここまで整理できていれば、実装で悩むことは少なくなる。

1. 機能の目的と要件を明確に
2. 処理の流れを整理
3. サブ機能を分解
4. エラーハンドリングやエッジケースも整理

ex.


FUNCTION addReview(userId, eventId, rating, text)
  -- 1. ユーザーがすでにこのイベントにレビューを投稿しているか確認
  IF hasUserReviewed(userId, eventId) THEN
    RETURN "Error: User has already submitted a review"
  END IF

  -- 2. レビューを作成
  review = createReview(userId, eventId, rating, text)

  -- 3. レビューをデータベースに保存
  saveToDatabase(review)

  -- 4. イベントの平均評価を更新
  updateEventRating(eventId)

  -- 5. レビューを表示用に返す
  RETURN review
END FUNCTION

このイテレーション中、私のタスクは他のタスク含めて巻きで進められていました
(実装速度上がってきて成長したのかと感じたし、最近上がったと言われて喜んだ)
でも、巻きで進められていても、それが本当に巻いているのか?疑う必要があった。

▶️ 2. 初めてドメイン設計から任せてもらった時

背景

  • 新規バッチを実装する際に、初めてドメイン設計から担当させてもらった。
    (DDDはドメイン大事、をまだ言葉でしか理解していなかった)
  • コンテキスト跨いだ新規モデルを考えないといけなかった.

👮 事件録

  • 新規バッチで新コンテキストで新規ドメイン、とはいえ既存機能に関連している.
    　→ コンテキスト跨いだ新規モデルを考えないといけなかった
  • 既存コンテキストとの関連を先に考えず、新規に集中してしまう
  • ドメインモデル図を作るも、全体ミーティングを1回しか設置せず。
    　→ 早めにドメイン完成させないと他の人の実装にも影響出ると思い、
    ドメインモデル図のレビュー中にも関わらず、実装始めてしまう。
    　→ その実装のcode reviewもきて修正→モデル図も修正を繰り返し始める
    　→ 既存コンテキストとの関わり箇所のコード修正に差し掛かった際、
    想像以上に実装が増えることが発覚。
    → 実装が間に合わない!!!!! → ヘルプをもらい助かる....

⛈️ 問題点

  • ドメイン決まってないのに実装にかかったこと
  • 新規モデルばかり考えて、既存のモデルに変更かかりそうな箇所の考慮を疎かにしていた
    → 手戻り大発生

👩‍💻 解決策, 成果と学び

  • 既存のモデルに変更かかりそうな箇所から考えて、それから新規のモデル設計に着手すること。
  • 実装も既存箇所のモデル修正,実装からすることで、手戻りが生じずらい。
  • 早めに完成させるには、まずはベースを自分がつくったら時間をとってもいいから
    全体の共通認識Meetingを決まるまで入れること。reviewもらって修正するだけだと足りない。

🚨 同じreviewを何度ももらってしまう事件

👮 事件録

これはこれは実務半年ぐらいの頃のお話。

  • 前も似たreviewもらってたの気づいてるかメンターに聞かれる
  • 自分では気づいていなかった。　(失礼すぎるだろう)

(言ってくれるメンターで、かつそれを早めに気づけてよかった)

⛈️ 問題点

  • もらったreviewを「おおおお、そうかこの方いいのか」で脳死でcommit suggestionを押していた。
  • そこに疑いを持つこともなく、なぜそうなのかも考えていなかった。
    → reviewする人も嫌になっちゃう&時間とらせてしまう。
    → (個人的には)code reviewをたくさんもらえる環境を活かせていなかった
    → 自分の実装に責任を持っていないのと同然。

👩‍💻 解決策, 成果と学び

  • もらったreviewの意味を解釈して分からないなら聞こうぜという話

  • 自分の実装に根拠と責任があればそうはならなかったよね。

  • 今、自分がメンターする立場になってさらに意識できている

おわり

正直周りにはたくさん迷惑かけてきたと思いますが(確実にそう。)、
自分の考えとしてはそれでも今は気にし過ぎず挑戦しながら、
私が教える側になりながらその恩を返していこうという考え方をしています。

今、メンターになり未熟ながら勉強しながら頑張っています。
まだまだではありますが、引き続き挑戦してたくさん経験する中で
学び成長していきたいと思います。

おまけ

私の可愛い愛猫Roséです。(生後2ヶ月のベンガル)
今月お迎えしたのですが、猫に時間取られすぎないように毎日葛藤しています。笑

メリハリつけて頑張ります。笑


木にのぼる私の愛猫Rosé

Discussion