0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

設計と実装にずれを感じることはありませんか?

私の場合、設計がそもそも曖昧になっていて詳細は実装を見ろみたいな状況だったのでむしろずれがあるというレベルですらありませんでした。。。

ここではずれがおきる原因について考察していきます。


🎯 ズレが起きる本当の原因

まず原因を押さえます👇

  • 設計が曖昧
  • 実装者の勝手な解釈
  • 認識合わせ不足
  • 途中変更の未共有

👉 つまり「情報のズレ」


🚀 ズレを防ぐ具体的方法

① 設計を“説明できる状態”にする

👉 読むだけでは不十分

やること:

  • 設計内容を自分の言葉で説明する
  • 「つまりこういうこと?」と確認

👉 説明できない = 理解していない


② 実装前に認識合わせをする(超重要)

やること:

  • 処理フローを説明
  • 入出力を確認
  • 不明点を潰す

👉 実装前の5分で炎上を防げる


③ 小さく作ってすぐ確認

NG:

  • 全部作ってからレビュー

OK:

  • 一部作る → 見せる → 修正

👉 ズレは早く見つけるほど良い


④ 設計をコードに落とす時に“対応付ける”

やること:

  • 設計の項目とコードを対応させる
  • コメントや命名で紐付ける

例:

  • 設計:バリデーション処理
  • コード:validateUserInput()

👉 迷いが消える


⑤ 不明点は即質問

NG:

  • とりあえず進める

OK:

  • 小さい違和感でも確認

👉 放置した曖昧さは必ずバグになる


⑥ テストで設計を検証する

👉 テストはズレ検出装置

  • 設計通りの入力・出力か?
  • 例外は処理されているか?

👉 テストを書けばズレが見える


⑦ 設計レビュー+コードレビュー

両方必要です👇

  • 設計レビュー → 設計のズレ防止
  • コードレビュー → 実装のズレ検出

👉 どちらかだけでは不十分


⑧ 変更を必ず共有する

ズレの最大原因👇

👉 「途中で変わったのに伝わってない」

対策:

  • 変更履歴を残す
  • 関係者に共有

⑨ 用語・データを統一する

  • 設計とコードで同じ名前を使う
  • データ構造を一致させる

👉 名前が違うだけでバグになる


⑩ ログで設計通りか確認する

  • 設計したフロー通り動いているか
  • 想定外の分岐がないか

👉 実行結果で検証


🔚 一言でまとめると

👉 設計と実装のズレ対策 =
「理解 → 確認 → 検証」を回し続けること

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?